Love to know the current general feeling on css framworks around hn crowd.
Personally I'm using them less and less as css evolves. You can have a pretty good responsive grid with just a few lines of css as for the other things I end up styling them a lot to my own needs so frameworks don't provide me that much value.
As it happens, yesterday morning I tried using one for the first time in years. Material UI for React. Looked incredible, is very impressive, and yet within only 2 hours I ran into a scenario that couldn't be handled by the framework.
This morning, I'm stripping out all of it and starting over from scratch, like I should have done in the first place.
A caveat is that I love their color system, so I'm importing and using that, but leaving out everything else.
Would highly recommend Tailwind if you don't like the boxed-in nature of most frameworks. Tailwind is more of a design system than a CSS framework. It simply gives you guidance on establishing proper constraints of your design system and then a nice set of utilities to get started with. There is no "can't be handled" scenario in Tailwind.
EDIT: And the book by the same author, Refactoring UI, is also a fantastic primer on the philosophy behind Tailwind.
Refactoring UI looks awesome, thanks for the recommendation, will check it out. I've heard of Tailwind and I can't remember what the price tag was, but it made me raise my eyebrows a bit lol.
> I've heard of Tailwind and I can't remember what the price tag was
It was (and still) is zero. Maybe you have it mixed up with Tailwind UI? (which is a paid library of ready-made components built using TailwindCSS framework)
Converting a tree-like structure into a nested form inputs. Material seems to be rather opinionated about what a "form" is, and I found it too constricting for my needs.
More specifically, the TextField component assumes an accompanying label, while none of the other form components do. It seems like a very odd choice to me, since all form elements should have a descriptive label.
Eh I wasn't super descriptive in my response, but it was connected to that. It wasn't that I didn't see a solution, it was more "how much effort modifying in a solution will take vs just writing it myself". I decided the latter was more cost-effective for my particular use case.
I'm more inclined to use them these days not less. Bulma CSS framework is well structured and easily extensible. Tachyons is really good for prototyping. I am looking forward to try tailwind
Hasn't had any updates for two years and looks like it's doing something weird with the base font inclusion assuming you have "nunito" already (not a safe assumption).
Also I'd suggest to anyone to potentially avoid using CSS vars if you're looking for enterprise browser support due to old IE. Obviously make your own decisions on this one but it I think 10 starts getting really weird with them...
All-in-all for the limited benefit this micro-lib brings I'd say go to something that's popular/supported vs. a project that hasn't seen a commit in 2 years.
> I'd say go to something that's popular/supported vs. a project that hasn't seen a commit in 2 years.
Isn't the whole point of a micro lib that it is limited in scope, well-designed, and shouldn't need to change much? I have my own libraries that see few commits as of late but still work fine
I haven't tried this yet, but in the author's defense the repo has no issues against it, so it's not like there is tangible proof that the author is neglecting maintenance or anything. Besides, the whole thing <500 lines of CSS - if it does what you need it to why go with anything that would be more complicated and more likely to break with an upgrade?
Isn't the whole point of a micro lib that it is limited in scope, well-designed, and shouldn't need to change much?
In the case of a CSS framework specifically, browsers are a moving target and you would expect changes to either fix issues or to take advantage of new features. 2018 is more than 10 versions of Chrome old, and while it's possible that nothing in that time was worth adding to this framework it does seem unlikely. At the very least you'd expect a line in a readme to be updated to say its been tested and it works.
Sure, which is exactly why I said I'd expect at least an occasional update to a readme to say the framework has been tested and still works.
More broadly for web dev though, the fact a feature isn't available in old browsers is a bad a reason not to use a new feature if it's useful and improves a site for the user. Obviously you shouldn't break your site in old browsers but progressively enhancing to take advantage of things is a very good thing. Browsers implemented @supports in CSS for precisely this reason.
> Also I'd suggest to anyone to potentially avoid using CSS vars if you're looking for enterprise browser support due to old IE.
You can trivially process your css files through babel + postcss to support arbitrary browser targets. In this case, postcss will inline the vars letting write modern css while shipping css that works in old browsers.
1) the grid doesn't have gaps between columns. look at the form example, see how the two form field are right next to each other with no gap between them... that will cause a lot of headaches trying to layout even a slightly more complex form.
2) the naming of the colors in the util is inconsistent... they follow bootstrap with info, error, success, but then go with black, white, gray??? wtf is that. what about just sticking with the bootstrap naming and using dark, light, and default like they do. why switch when you already copied 80% of bootstrap's naming convention? makes no sense.
3) back to the grid. there are no viewpoint or reordering classes. do you know how much of a life saver it is to change the column order between devices with a simple order-md-2 in bootstrap. my god... if you ever had to do css trickery to move an element on mobile you see that the reordering in the grid is a god send.
i'm sorry, but i personally see these micro frameworks as traps. bootstrap is very easy to recompile and strip out what you don't need to roll your own essentially.
I've been meaning to put picnic to use in future projects. I very much like the minimal reliance on JS and the semantic class names (nothing irks me quite like CSS concerns bleeding into the HTML).
> (nothing irks me quite like CSS concerns bleeding into the HTML)
Don't knock it till you try it! If you're generating HTML dynamically, define functions in code for your custom style classes which consist of a set of atomic styles provided by something like Tachyons.css. Then just call those in your template while rendering.
All the benefits of CSS variables and tooling like Sass/Less/etc. without the need for any special tooling!
Typically, by the time I'm at the point where I'm dynamically generating HTML, I'm also at the point where I've got enough tooling around it already that adding Sass/Less to the mix ain't much of a big deal.
So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change.
Workflow under Tachyons: change html, reload page to see change, change html, reload, change html, reload, ....
> So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change.
Most frameworks nowadays ship with Sass/Less built-in, or at the very least make it trivial to bolt it on. Further, most frameworks nowadays fully support the ability to automatically rebuild stylesheets when regenerating the HTML, in which case it's quite literally: change CSS, reload, change CSS, reload, etc. The build times are negligible (especially if I'm using Erlang/Elixir or C# or something else that needs compilation on changes anyway).
Also, since I'm in the habit of keeping the HTML I write or generate concerned solely with describing the content rather than the appearance thereof, there's rarely (if ever) a separate "change HTML" step there; the HTML (or the templates to generate it) is already written alongside the content, and it's just a matter of adding enough CSS to make it look decent.
Importantly, since the HTML makes no assumptions about its appearance, it's straightforward to define different stylesheets for different contexts (whether interactive v. print, or reusing a given page on multiple sites/applications with very different styles, or what have you).
I can vouch for skeleton, modified a few variables (default page max-width not fit for modern monitors) and tweaked things to my liking but hurrah - base functionality makes for super simple & nice layout and works on everything from desktop to phone. Have no regrets on fact that it hasn't been updated for 4 years at present.
They are different. Spectre is more like a lighter, smaller non-JS version of Bootstrap, but both still provide recognizable "components" like navbars, form inputs, dropdowns, tabs and so on which are common to most web sites and applications. Tailwind (and maybe Tachyons, I don't know) is a utility framework, or meta-framework if you like: it provides a toolbox of lower level primitives for spacing, fonts, layouts, colors and so forth, out of which you can build your own custom components (or use a palette of existing ones, like Tailwind UI). Of course Spectre/Foundation/Bootstrap etc have these primitives too, but their base premise is that you have higher level components common to every or most sites, so there is no need to reinvent the wheel by rebuilding the nth navbar or tab menu.
YMMV, but probably if you are building, say, a standard "boring" CRUD application and you need to get it out quickly you can get a lot of mileage out of Bootstrap or similar frameworks. There is a ton of work already done for you with things like accessibility and browser compatibility, and while these kinds of sites are a bit samey, that is also a plus in that users don't face a learning curve - a menu or calendar widget will behave like every other menu or calendar widget they've seen. An off the shelf theme or some SASS variable tweaking can provide enough branding differentials.
On the other hand if you have very demanding customers/designers who require everything to be pixel perfect and "popping" then something like Tailwind that gives you more low level flexibility with some sensible defaults might be a better fit (honestly though, with these kinds of clients you're probably going to have to mess around with CSS anyway).
TIL! as with most languages, css indentifiers can't start with numbers, but you can get around that using backslash-escapes. you'd use these classes like this:
I'm a bit confused - is the name of this project "lit" or "lit [U+1F525 FIRE]"? The linked page has the latter as a heading, and the more complete name would also resolve the ambiguity with existing projects that others are pointing out.
Thanks for sharing this. 365 bytes gzipped is really amazing ! A lot of times for a simple page, just the basics like grids and all, I use custom trimmed down bootstrap. I would love to give this a try and some feedback on the experience !
I like the minimalism, but I wish the buttons had something on hover or on click (e.g. invert the colors). You should give user feedback that it's a clickable button and it has sent the form
