Hacker News new | past | comments | ask | show | jobs | submit login
Mini.css: Minimal, responsive, style-agnostic CSS framework (chalarangelo.github.io)
189 points by zoria on April 15, 2017 | hide | past | favorite | 95 comments

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.

[0] - https://milligram.github.io/ [1] - https://purecss.io/

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:

[2] https://picnicss.com/

Sorry I was mostly going off the google results. Your library looks really nice, the SCSS variable changing is awesome!

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.

Pedantic. Wondering why you used 'its a pity' twice. I want to believe it was pure luck, but otherwise it sounds snarky.

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).

I have a list on a (largely unfinished) site I'm working on here: https://www.lightentheweb.com/libraries/

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.

Ah it's fine, I really didn't mean to not have my name on the site anyway, I just didn't get around to adding it. I'll do that soon!

Ah, thank you, I will add those.

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.

Thank you for your contribution!

I love Picnic; thank you for your contribution.

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.

To quote Joel Spolsky [1]:

> For review: Bloatware and the 80/20 myth. No matter how much it bothers you neat freaks, the market always votes for bloatware.

See also [2].

Basically, one peron's bloat is another person's necessary features.

Hell, I should have posted this on the Electron rant thread the other day.

[1]: https://www.joelonsoftware.com/2002/04/07/20020407/

[2]: https://www.joelonsoftware.com/articles/fog0000000020.html

This is the old argument about replacing Excel. No one uses all the features offered by Excel, but every feature offered is used by someone.

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.

Not only that, often the when Excel users are asked what features they desire, the desired feature is already in Excel.

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.

Basically, one person's bloat is another person's necessary features.

And that is why I like modules.

> And that is why I like modules.

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.

I think if there are two sites with the same content and functionality, people would hands down prefer the faster page.

The thing is that, there aren't.

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.

Really ?



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.

Nowhere upstream did someone say "smaller isn't better".

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.

From Amazon's perspective it's the same and worth optimizing

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.

https://lite.twitter.com just launched, eventually that may show a preference either way.

Twitter is a page with only one feature. Lite.Twitter is a version of that feature for a very specific subset of mobile users.

In 99,9% of cases it's not worth it to go ultra lightweight.

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.

Mini is 7kb; Bootstrap 20kb

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.

The mini frontpage seems to be comparing mini to the wrong frameworks... how about:

https://purecss.io/ http://getskeleton.com/

N.B.: Skeleton is not maintained anymore since December 2014. Skeleton framework [0] is an actively maintained fork.

[0]: http://skeleton-framework.github.io/

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.

The fork skeleton-framework [0] has variables [1] to easily customize colors and other stuff.

[0]: https://skeleton-framework.github.io

[1]: https://github.com/skeleton-framework/skeleton-framework/blo...


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.

Another occasion to promote: http://tachyons.io/

Also available for react-native: https://github.com/tachyons-css/react-native-style-tachyons

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.

[0]: http://imgur.com/a/On8hZ

If you want to try something really lightweight (1kb in fact) I made "mu": https://github.com/BafS/mu

This is exactly what I was looking for. Thanks for creating and sharing it. I'll give it a try.

I've had a good time using Spectre (10kB): https://picturepan2.github.io/spectre/

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).

This one looks really good. Cheers!

EDIT: and it's based on LESS which I currently use, double cheers!

No worries.

And for the info of others, I just saw that someone posted an issue 3 hours ago showing their Sass port, which I might switch to.

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.

So who is the "minimal" selling point really for?

In case you don't know, W3css is much lighter than this. And it is a complete css framework with no javascript required.

W3CSS 6.7KB (gzip)! Beat that. https://www.w3schools.com/lib/w3.css

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.

Am I missing something with your comment? Sorry but I don't get where you're coming from, or how the comment is relevant to a css framework.

I felt like pointing this out because of the whole CSS framework that's smaller and faster premise. A canvas app is faster still.

This is excellent! Thanks for sharing this.

I wonder what even goes on behind other larger frameworks like bootstrap that makes them so huge.

You could take a look at [1]. The sheer amount of edge cases and bugs they've got covered are incredible.

Small kits can be great, but there are certainly drawbacks that you would never even notice (or rarely notice) with a framework like Bootstrap.

[1] https://github.com/twbs/bootstrap/issues

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):

- jQuery's addClass(), 35 lines: https://github.com/jquery/jquery/blob/master/src/attributes/...

- Umbrella JS's addClass(), 5 lines: https://github.com/franciscop/umbrella/blob/master/src/plugi...

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

Speaking of "edge" cases:

el.addClass("btn btn-primary")

works in JQuery and fails in UmbrellaJS

What do you mean?? It seems to work perfectly:


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?

jQuery's addClass 'does more', it can also take a callback:

    $el.addClass((i, existingClass) => (i % 2 == 0) ? 'odd' : '')

Sorry to dissapoint you but Umbrella also takes a callback! It just has more sane (ES6-compatible) arguments :)

u('a').addClass((el, i) => (i % 2 == 0) ? 'odd' : '');

See example: https://jsfiddle.net/r2f87hzk/

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:


Heh, props, I'm not disappointed, and yes that's a much better callback! But that is not implemented in the 5 lines of code you linked to is it? :)

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);

Cannot reply below, reached the limit of HN!

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).

Yeah I checked out eacharg in your codebase, looks tight. I learnt quite a lot from your code about how jQuery could be structured, nice job!

I can move all of those lines to a new function "addClassHelper" and then ta-da - 1 line.

You can't just exclude other functions like that.

Copy/paste from another answer:

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.


.card-outline-warning .card-blockquote .card-footer / .card-header .card-footer &:last-child .card { > .list-group:first-child { .list-group-item:first-child {

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.

[1]: https://github.com/webpack-contrib/purifycss-webpack

For that to really work we need a way for react components, Ng directives etc to export classes they use so that purify can parse them.

Do you know or use such a setup ?

Edit. Oh it does read react and classNames. I'm sold!

As I explain in this comment [1], Bootstrap is modular, you shouldn't be using the whole thing.

The simple answer why it is larger is because it offers far more features/components (and browser support is considerably better).

[1] https://news.ycombinator.com/item?id=14121631

My first question whenever I see a new framework like this is, is it going to be around for the long-run?

I'm a fan of Basscss which claims it's 2.13Kb and seems comparable in utilities provided.

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.

...ten-year-old notebooks...

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.

That sounds like a self-referencing definition of "these frameworks", so I can only respond with Mu.

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).

Someone is doing IoT development correctly!?

Right now I'm on a train, browsing with the train wifi along with thousand other users in the middle of the Italian campaigns.

Hn is one of the few sites that loads and works.

There's plenty person that for a reason or another are temporarily or long term broadbandless.

> With internet speeds only getting faster

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.

It matters if you are a large website pushing content to hundreds of thousands of users (or millions). Those KB do add up over time in cost.

For the vast majority of sites out there, though - no, not really.

> With internet speeds only getting faster as time moves forward, does size REALLY matter?

My mobile data plan isn't unlimited, and that's the case for a lot of people who use mobile to browse the web. Yes the size does matter.

Yes, size does matter. AMP limits injected CSS size and AMP sites heavily outrank non-AMP sites on Google's SERP.

>... and AMP sites heavily outrank non-AMP sites on Google's SERP.

That's like saying Ford thinks Ford makes the best cars.

No, it's like saying Ford owns the roads, created a standard car size limit, and penalizes people driving cars that are any bigger.

Either accurate or inaccurate, it's not a relevant point.

Outranks because google has a vested interest in promoting it

Yes it matters. It's easy to see for yourself though, you don't have to believe any of us. :)

Just open dev tools and throttle your connection to 3G, that's what most of your users are seeing. Enjoy!

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.

Faster for whom?

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact