The framework being advertised as a minimal lightweight framework and having its size compared to the biggest frameworks is a bit off-putting to me.
I get that they wouldn't want to advertise their competitors, but the comparison matrix on the page makes mini.css seem tiny, where as a google search shows it's the biggest popular framework like this.
Mini.css is 7KB gzipped, Milligram[0] (the first google result I see for "minimalist css framework", mini.css is second) is 2KB gzipped. Pure.css[1] (the third result) is 3.8KB gzipped.
Such a pity you didn't include my own, Picnic CSS[2]. One of the main features is Lightweight (7kb min+gzip, same as mini), and it is also popular (2177 stars). It focuses on beautiful and cohesive components out of the box:
Thanks! It's a pity that the SCSS is basically undocumented, as I use it in most projects and it has really awesome features that only I know. But the time sink would be tremendous and I'm focusing on another project right now.
I guess it's a translation issue, no need to insult me. The tone was intended to be totally different, the first one like "hey take a look at this" and the second one more like "I wish I could have done it" (and because of the different feeling I didn't realize I had already written the same expression before).
Nice, while you are at it I also have a production-ready JS library https://umbrellajs.com/ and an experimental and not so browser-compatible one https://superdom.site/ in case you are interested.
BTW I cannot seem to see the people behind it, the "About" only says "This website was made by people. In the interests of inclusivity, we're aiming to get some robots to contribute soon."
Seems a bit lame to complain that someone chooses to not reveal who they are.
Frankly, I think you need to be less aggressive shilling your own projects in a "competitor's" submission. ctrl-f for your own username. It's a bit much.
But I wasn't complaining at all! I was just curious about who was behind it so pointing it out just in case it was an error in the code or in my browser.
And sure, I am passionate about minimal programming so I've done quite a few projects and point them out as relevant examples. Though I agree I got a bit carried away (3 comment threads with external links) in this thread, my apologies (cannot change it now). See my submission history ( https://news.ycombinator.com/threads?id=franciscop ) for a full picture, I don't link to my projects nearly as much as I did in here and I'll just comment relevant info without so many external links in the future.
About the "about" page, the site is quite unfinished :( I want to add more information, examples and resources, but have fallen behind. I hope to fix that quite soon.
Also a lot of the frameworks compared against are totally modular, so comparing against the full framework size doesn't really mean a lot, because it almost never makes sense to include every framework module.
E.g. in Bootstrap 3 if you only want typography, it's 9kb min/2.8kb gz, for typography+forms+buttons it's 27kb min/5.kb gz, for all 'common CSS' (incl grid + responsive utilities) it's 46kb min/8.8kb gz.
The comparison size of 20kb gz is only if you pulled in every additional component available.
Both of those are gorgeous. Mini.css, not so much. I mean, Mini is fine...better than I could do. But, when I visit, I feel neutral about it. I can't imagine it improving my projects just by including it. And, the example of Mini customization (http://codepen.io/chalarangelo/pen/YNKYgz) is downright ugly.
I use CSS frameworks (mostly Bootstrap) because I suck at design. I need a hand up, and a good framework provides it. Customization is necessary, but not all that's necessary.
And a nice illustration for why startups often do well focusing on very specific use cases first.
Replacing Excel for the general population is a moon-shot project; replacing it for a well selected set of use cases hard but, as history showed, possible.
Counterpoint...For years, Google's search page was famously minimal/unbloated. That lack of bloat and overall search speed was a big part of them winning.
Just be careful that you don't remove too many of them in your efforts to eliminate bloat. For example, last time I checked, the Qt toolkit implements accessibility (e.g. for blind users) in a plugin. How many Qt-based applications are completely, utterly inaccessible to some users just because they didn't ship that plugin? Again, one person's bloat is another persons' necessary feature. Yes, I made a typo the first time; I noticed it too late.
Only in our wet dreams exists a competitive edge where you copy a website 1:1 but use vanilla JS over their jQuery so things load a tiny bit faster and their users flock over to your website, chanting your name.
I'm sure I read essentially the same from ebay as well at some point. It's worse than being a competitive advantage : extra milliseconds seem to matter a lot for the size of the market in the first place.
If Amazon loads .1 second slower, are users not buying from Amazon or not buying at all? Until you know the answer to that you're not really making a convincing point.
Whoa whoa whoa. Amazon has focused on page speed load and user experience for over a decade. Their core business is their website. They have refined and improved thousands of times. You should ask "What would happen to Amazon's sales if they suddenly stopped caring about page speed?" The answer is over time they will add additional bloaty libraries and it will eventually slow down to a horrible crawl. This will likely start turning customers away who want a better user experience.
On a daily basis I have to interact with HPE's website. Now THAT's a company that could care less about their user's experience on their website. Pages take on average 20 seconds to load and sometimes up to 3 minutes! They are lucky that it's not their website that is their business but it's their products or else they'd lose business so fast. I absolutely HATE interacting with their site because of how slow it is. I can deal with bad UX if the site is quick to load, but I can't deal with bad UX if the site is extremely slow.
Another thing to think about is simple single content pages, like ones that just tell you the time, or tell you what your IP address is. The ones at the top of Google searches pay extremely close attention to page speed load times. There is so much competition in their space that they know they need to be the best and that is just another way to do that.
No, it's not. If a user chooses a 'no purchase' option then it means that the product assortment offered was not worth it for the price. That means Amazon needs to change the assortments of products it offers users. If a user chooses to purchase elsewhere, it means Amazon needs to improve the website.
That's assuming a consumer decides to purchase something solely based on price/product assortment and there's no impulse factor. One could very well be willing to purchase something at one moment but 30 seconds later be unwilling. I wonder if anyone has any data on time spent on a website vs. likelihood of making a purchase.
The market votes for bloatware because people are lazy.
If you are someone who cares about speed and simplicity and generally doing things right, I don't see how this fact relevant to the current discussion. Sure, frameworks like mini won't be as popular as bootstrap. But there are plenty of people, myself included, who'd rather use them.
Your users simply won't notice the difference. If you for whatever reason need to include a picture on your page it's going to be bigger than the ultra lightweight bootstrap page.
Most of the conversation here is about the front-end user experience. However, for a developer, size is often a stand-in for complexity. I am attracted to "minimal" CSS frameworks not because they are marginally faster for my visitors, but because I hope they ease the pain of managing complex CSS structures.
I love skeleton. Unfortunately it's difficult to change the colour scheme on that framework. I wish a new version would come out which allows me to uniformly change colours throughout the page.
Otherwise for all my needs it's pretty much perfect.
Give that a try. I used that and broke it into modules for a website redesign I'm working on. It's going quite well. I love using skeleton as the starting point for projects rather than picking some css framework to build on top of.
I could write a long explanation on why I think tachyons is the final destination of CSS-frameworks, but I save myself the time. Just try it.
I don't believe there's a simpler or more maintainable (read: "better") way of handling CSS.
I use it for fresh web, electron/desktop and react-native projects since about two years, and I don't think I'll ever have to use something else again.
While I like the idea of lightweight UIs, this one seems to have some problems[0] in Firefox 55.0, the responsive mode view looks better but still has some issues with the menu. I thought I had failed to download a stylesheet at first but the desktop view actually has all the assets for the page.
That is absolutely beautiful. Thank you for that, I know what I'll be using the next time I need to use HTML (I'm terrible with JS/CSS - I usually spend 15+ minutes trying to center something).
Does "minimal" really matter when you'll probably take this and run this through all kinds of code bureaucracy (powered by NPM) which will end up with probably like 1MB of JS files?
Also on top of that you'll probably include bunch of 3rd party javascript that wastes tons of user traffic, such as ads, analytics, etc.
I'm being half sarcastic half realistic. When was the last time you cared about 2KB reduction in your CSS files? If you did, you're probably focusing on the wrong things. The only people who should be thinking about these size reduction is sites on a scale of Google or Facebook or Amazon where every kb matters in terms of their operational cost. But these companies probably roll their own.
It's important to note that most css frameworks are incredible smart when gzipped. Nearly all users can afford to load a 50kb file. Keeping your page lightweight is mostly about using your graphics right. And avoiding deep dependencies in your JS frameworks.
I just made a game in HTML5. You'd be surprised the speeds that can be achieved by just having a large canvas element and drawing on it with RequestAnimationFrame. Wtf.
Partially agree. The big problem IMO is momentum in the code. While they do solve many issues, once a browser is not supported anymore the library doesn't get "cleaned up" to reflect it because it just works. So you end up with this stark difference (disclaimer: Umbrella is my own):
So the choice is either well-tested libraries that slows your users down so you'll lose a % of them, optimize the hell out of them so you'll "waste"* time, or use a smaller library which is a compromise between them you'll loose a tiny % of users who you don't support, but you have to invest some time to learn it.
It is not black and white, so luckily we have a choice here and different scenarios warrant for different libraries.
* I specify waste since it's probably something you already know and just have to do it; if you're learning it for the first time then it's not wasted at all
In Umbrella JS, you select elements with u() instead of $() because the APIs are not totally compatible so it avoids confusion for people joining a project that uses the library. Did you find a bug? Is the jsfiddle example not working on your device?
Not only that, Umbrella will handle many more class name separations compared to jQuery. All of these (and more) are valid:
u('a').addClass('a,b c', 'd'); // No typo here, four classes added
u('a').addClass(['a'], ['b,c', ['d']]); // Again no typo, 4 classes added
Of course you normally don't use this, but you might have the class list in an array or a comma-separated string or something else which makes it really convenient and it was basically for free as the method is really reusable. See the documentation:
Nop, but if you want to be fair jQuery's addClass is also not implemented in those 29 lines of code, it also uses these: each, jQuery.isFunction, getClass and stripAndCollapse.
Umbrella's single eacharg() uses in exchange .each() (which is public-facing, so it really doesn't count) and .args(), which is private but used in MANY places through the code. At 11 lines for args(), I'd say proportionally it'd be 1-3 lines corresponding to addClass. So worst-case scenario it'd be the equivalent to 8 lines exclusive for a much more flexible function with no internal dependencies which is still alot less than jQuery's 29 lines with 3 internal dependencies and 1 external.
* I wrongly counted spaces in jQuery's function while I didn't in Umbrella
Edit: the magic for the size of Umbrella JS is really through heavy code reuse and modern API usage. For this example, el.classList.add(name);
There is a case where jQuery cannot use it since they aim to support SVG in all officially supported browsers, and classList doesn't work properly inside SVG in IE11 (Umbrella doesn't officially support SVG).
I tried refactoring a bit of the code of jQuery, but every thing I touched or changed a lot of tests failed; so I'd have to do a ton of work ignoring the tests and then fix a ton of bugs for a low chance of success (so it was not cost-effective relatively to improving Umbrella).
Nop, but if you want to be fair jQuery's addClass is also not implemented in those 29 lines of code, it also uses these: each, jQuery.isFunction, getClass and stripAndCollapse.
Umbrella's single eacharg() uses in exchange .each() (which is public-facing, so it really doesn't count) and .args(), which is private but used in MANY places through the code. At 11 lines for args(), I'd say proportionally it'd be 1-3 lines corresponding to addClass. So worst-case scenario it'd be the equivalent to 8 lines exclusive for a much more flexible function with no internal dependencies which is still alot less than jQuery's 29 lines with 3 internal dependencies and 1 external.
Edit: the magic for the size of Umbrella JS is really through heavy code reuse and modern API usage. For this example, el.classList.add(name);
Doesn't matter what jquery vs umbrella is, if you're wrong from the start then everything you're basing your argument is also misleading. Not saying jQuery doesn't have more lines, but the reasons for it aren't going to be discussed if you use helper functions as your example.
The biggest bloat is that for every component you are always sending all the css for every possible combination of feature that might be used on that component.
etc. etc. It's 280 lines of source code (before you even run auto-prefixer)
Each one of these components repeats styling that other components will use. Because they want it easy to use so you just apply .card instead of individually composing all the style effects you want.
The other day I used semantic-ui, just added in a few components and it was 56k compressed. Because the component ships with support for all options, not just what you use.
True, all those variants to allow the developer flexibility.
That's why plugins like purifycss[1] etc are interesting. When properly used and configured, a developer has the full framework under his fingers, while not outputting anything unused to the users.
With internet speeds only getting faster as time moves forward, does size REALLY matter? Is there an honest tangible difference between a 7kb and 30kb download? Also what about obsessing over a 10ms difference in render performance? Is that even noticeable? I can't help but think it may be wasted effort.
Maybe that's the perspective from your bubble, but I still have users on dialup and satellite links and ten-year-old notebooks, and I expect this situation to persist for years. Perhaps even more so if we launch in developing locales. "The future is already here — it's just not very evenly distributed." - Gibson, W.
Presumably that requirement rules out using any of these frameworks because they're all optimized for download size rather than browser support or rendering speed.
Yes. Especially for resource constrained IoT devices serving up their own web pages. Smaller is always better. My current mission is to rebuild an embedded site into a sub 100k single file SPA. I can't afford bloated CSS and Javascript libs and I can't shove everything off to a CDN that may not exist ten years from now.
If you do so please send me a link, I'm compiling a list of all sub-100kb sites I can find (so far I got 100kb.org and probably will make a display as a side-project to showcase https://serverjs.io/ functionality).
They're not getting faster uniformly. Even on my phone, one minute I have high-speed LTE, the next minute I'm on EDGE. Happens a lot during inter-city travel. Not many things piss me off like "simple" sites that fail to load on weak connections, because they're too bloated.
> I can't help but think it may be wasted effort.
Multiplied times the number of users, efficiency improvements in popular software translates to saving quite a lot of electricity. Something worth consideration, IMO.
I agree that alone, agonizing over 7kb vs 30kb is probably silly. It's more the overall effort of doing that sort of thing across the site for more than one library, image, etc.
There are still many people that will access your site via mobile in spotty coverage areas with low speed. Or after they've exhausted their included high speed monthly allotment, and are now throttled.
Also, egress bandwidth at popular clouds is ridiculously expensive. Enough so that the effort of trimming down pays for itself pretty quickly.
its not size that matters. its how you use it. a superb user experience might be worth it. some times web devs go to great length to minify the css yet serve a 10mb video background.
By reading the docs on the grid it seems like its the same as bootstraps 4.0 grid. The classes are exactly the same.
I will stick with bootstrap just because I am working with it a long time it has WAY more exposure, people building on top of it, contributing...
The difference between 7 KB and 20 KB gzipped is not really that big of a deal for me. Also you can obviously custom build bootstrap and just cut the modules out you don't need.
Also in that context of this small size difference I think its perfectly fine to compare it to the big frameworks out there.
I get that they wouldn't want to advertise their competitors, but the comparison matrix on the page makes mini.css seem tiny, where as a google search shows it's the biggest popular framework like this.
Mini.css is 7KB gzipped, Milligram[0] (the first google result I see for "minimalist css framework", mini.css is second) is 2KB gzipped. Pure.css[1] (the third result) is 3.8KB gzipped.
[0] - https://milligram.github.io/ [1] - https://purecss.io/