Mini.css: Minimal, responsive, style-agnostic CSS framework
chalarangelo.github.io
chalarangelo.github.io
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/
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."
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.
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.
Thank you for your contribution!
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.
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.
> 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
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.
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.
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.
https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...
http://glinden.blogspot.com.au/2006/11/marissa-mayer-at-web-...
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.
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.
In 99,9% of cases it's not worth it to go ultra lightweight.
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.
Otherwise for all my needs it's pretty much perfect.
[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.
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.
EDIT: and it's based on LESS which I currently use, double cheers!
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.
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?
W3CSS 6.7KB (gzip)! Beat that. https://www.w3schools.com/lib/w3.css
I wonder what even goes on behind other larger frameworks like bootstrap that makes them so huge.
Small kits can be great, but there are certainly drawbacks that you would never even notice (or rarely notice) with a framework like Bootstrap.
- 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
el.addClass("btn btn-primary")
works in JQuery and fails in UmbrellaJS
https://jsfiddle.net/sfmdc5yy/
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?
$el.addClass((i, existingClass) => (i % 2 == 0) ? 'odd' : '')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:
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).
You can't just exclude other functions like that.
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);
https://github.com/twbs/bootstrap/blob/v4-dev/scss/_card.scs...
.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.
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.
Do you know or use such a setup ?
Edit. Oh it does read react and classNames. I'm sold!
The simple answer why it is larger is because it offers far more features/components (and browser support is considerably better).
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.
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.
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.
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.
For the vast majority of sites out there, though - no, not really.
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.
That's like saying Ford thinks Ford makes the best cars.
Either accurate or inaccurate, it's not a relevant point.
Just open dev tools and throttle your connection to 3G, that's what most of your users are seeing. Enjoy!
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.