The more web development I’ve done the more I’ve swung back to just writing CSS myself rather than depending on CSS frameworks; I’ve ended up seeing these less as ways to accelerate development for a team that is skilled at frontend, but instead as a way for people who don’t like styling or have little experience in frontend development/low design sense to style things reasonably.
But I keep seeing frontend frameworks on HN - am I/teams like mine that include at least one person fluent enough in CSS to write reasonable style sheets/styled components, just not the target audience? Or do other experienced frontend devs swear by UI frameworks like these for reasons I haven’t grasped yet? If so, why?
While I share your sentiment about frameworks, I work in enterprise app development and I can't remember the last time I encountered someone else who had a firm grasp of CSS or even the Frameworks.
Our organization adopted Bootstrap because it's a consistent and familiar framework and it takes less time for the inexperienced developers (most in my experience) to come up to speed on an app.
When you have 20 developers rotating responsibilities between 40+ apps with regular turn over and contractors cycling out, have consistent project setups and standard frameworks across the organization is essential.
I'm going to have to agree. Out of all the technologies my team had to juggle while I was on a web team, CSS and its various components (CSS precompilers, sass/scss/less, frameworks, etc) were the hardest to keep neat.
You don't _have_ to write CSS well to get it to work. People wouldn't follow naming conventions, wouldn't group common components near others... some people didn't understand CSS precedence and it could lead to incredible confusion, spaghetti code and extra work. Often people re-implemented functionality that was present elsewhere. And problems were exacerbated with sass.
From my perspective, tools that prevent people from writing additional CSS code will have a niche to fill for the foreseeable future.
As useful as this tool may be, it doesn't seem to prevent redundant or repetitive styles from being created, which is a bigger issue than ensuring correct syntax (since your editor is likely to do that already).
This, in my opinion, is why frameworks of any ilk exist at all. Too many developers out there don't want to take the time to learn the language and the frameworks give them a (false, again, my opinion) sense of productivity.
But, especially with CSS, I really don't see the value provided by a framework. CSS isn't hard to learn or master! And as OP suggested, doing so means you get more done with less code.
I know a guy who set up a project with a framework. He had a nice scaffold of the project and was amazed and overjoyed with what he had done with so little effort until it was pointed out to him that he had 40,000 files in a project that didn't actually do anything. Much less solve the customers problem.
CSS is incredibly hard to learn and master. Everything is extremely unintuitive and subjected to subtle inconsistencies between browsers and browser versions. It’s just that we’ve been living with this insanity for so long that we fail to see it for what it is.
Frameworks aren't at odds with knowing CSS or any other language. You're missing the point with "CSS isn't hard!"
And you're wrong. CSS is incredibly hard to maintain. It easily becomes an append-only list of rules. Medium.com for example hired a team a CSS developers including a co-creator of Bootstrap just to work full-time on its CSS.
This is a good example of developer hubris and the HN trope of "it isn't that hard, why don't other idiot devs just do <X>? It must be because they're incompetent." I'm not convinced you've drunk your own Kool-aid in production on a non-trivial project. Because then the trade-offs would be obvious to you and you wouldn't think one is better.
I think I fall somewhere between the two extremes you guys represent. It's not hard and it's not easy.
Also, some developers are developers because they wanted to GTFO of some situation and don't give two shits about personal development, best practices, efficiency, long term maintenance, or any else. They're just showing up for a paycheck.
Ideally you want to avoid those developers but realistically you don't always have a choice because not everyone who is passionate about software can work for Goopplebooksoft.
Not OP, but I'd say a willingness and proven ability to learn far outweigh any particular tools. Proving ability to learn does require past experience, of course.
I think it helps a lot more to show that you understand styling principles (reusability, selector precedence) than it does to be able to make pixel-perfect implementations based only on knowledge off the top of your head. [0]
That being said, in order to have that understanding, you probably need to have some experience with CSS or similar.
Basically, hands-on CSS experience is the means not the ends.
[0]: Perhaps all of this is what you meant by having a "firm grasp of CSS".
It depends on where that developer was slotted in.
We currently have ~3 dedicated front end developers who have limited skills beyond HTML, CSS, and Javascript who maintain our large forward facing public presence.
The remainder of our developer pool are full stack developers who maintain a myriad of internal systems and apps used to run the business. A few of these apps are publicly accessible but they're niche and don't require strict adherence to brand or accessibility standards. The remainder are simply internal applications.
A firm grasp of CSS would seem to be essential to the front end devs, though I might be inclined to say it's not given some of the code I've seen. I am however willing to give them the benefit of doubt because I know they're a newer team that inherited an unfathomably large site running on an ancient CMS (Stellent) and the new products they're working on are integrated with some pretty heinous 3rd party platforms.
For the remainder of our Devs usability and appearance take a back seat to functionality. So CSS chops are more of a nice to have.
Frameworks are handy for — you know — framing. They’re a helpful scaffold provided your project aligns with their model. This applies to UI framework, app frameworks, whatever.
Why do these not “accelerate your work”? Maybe because you’re taking work that’s differently shaped. Maybe original, custom styling is an important part of what you’re selling. That’s great.
But it’s not nearly true for everybody. And so a lot of people use frameworks like this to get the styling where it needs to be, so that they can focus on whatever other thing they’re really selling.
I've done frontend for quite awhile. I usually start with some sort of framework for every project and use only the minimal pieces for the foundation.
Generally you need the same stuff for every site:
- reset/normalize the styling cross browser
- basic grid system
- typography, forms, and buttons
- "componentized" files with variables (sass, less, post css, etc)
Basically I start with a custom build of whatever framework, use that to build the MVP, then customize it according to the designer requirements. Lastly, I'll pull in components as I need them.
But is that grid system consistent across different sites? In my experience, I usually need to customize the "grid" to specific breakpoints and widths, as defined by designs/content. I find that it's often faster to just write a few helper classes for layout – specific to the site I'm working on – rather than use 15% of a framework's grid and still do heavy lifting. Of course, this isn't the case if the design team designs with a framework's grid system/breakpoints in mind.
For sure. Like I said, I usually do a custom build of a framework, then strip out the stuff I don't need. And if it's designed with variables, changing small stuff like breakpoints etc is maybe a few quick changes.
As a "non-fluent CSS user", I find it challenging and frustrating to maintain visual consistency and cross-browser compatibility without frameworks. I totally appreciate the fact it's me being lazy to really learn CSS who is at fault.
Think of it like different construction methods - you can build something, let's say the Pyramids, or you can take something already built and beautiful, but is not what you need, and slowly curve Petra inside the walls. Both work.
I think you're probably still thinking about CSS as it was 5 years ago. When you had to do weird hacks to get things the way you wanted them. Modern CSS is much easier.
In fact, if you are sticking .row and .column everywhere you are doing considerably more work than just to define a grid layout using display: grid once in your CSS, and then just use semantic HTML thereafter.
While the grid and flexbox have made things better, the display:grid is still not supported in IE 11 very well. The grid css model was implemented in IE very early but as the specification got updated, IE remained with a different(older and incompatible) implementation of display:grid. Of course, we can still make display:grid work in IE11 by some additional work. But this is an additional overhead.
Flexbox has very good support and consistent behaviour in all major browsers and for most of the time we can use flexbox model. With some learning for using flexbox and grid I could appreciate their utility. (though I do not use CSS regularly)
The state of CSS is very much improved and these days we don't have to depend on hacks like the float and clear in CSS. But, minor problems like the inconsistent behaviour of display:grid in IE 11 - make the need for a CSS framework relevant.
What really amazes me is that wpf was release 12 years ago with all these problems solved. Grid, alignment, center, Center!! You can center something in xaml and it'll just be in the damn center of the parent container. And surely xaml is far from being the first layout descriptor to actually work. But no, with browsers - we have to use fat framework to achieve the triviallest of behaviors.
One possible solution with a bit of little work is to write layouts with grid. And then, as a fallback, query a no supported grid feature for IE 11 and write that layout in flexbox.
The layout in grid can be responsive. But the layout in flexbox for IE 11 only will be mobile, if it's mobile it will work in any display.
I always find it difficult to write css. The fact that this framework is half broken on Microsoft edge 41.16299.726.0 is a good incitation to use reputable frameworks instead of trying to create it myself.
Except that with using a framework you have a big black box of unknowns. And they will remain unknowns to you unless and until you take the time to dive into the internals of the framework (StackOverflow only gets you so far), at which point you might as well learn CSS.
So what happens when the framework does something unexpected? Or, as is more often the case, you run into a situation where you need to do something to satisfy the requirements of your project that the framework simply didn't think of? Again, you can dive into the internals of the framework to figure it out.
I'm arguing that in the long term you're better off learning CSS. Then you KNOW you can do what needs to be done. And with CSS you can still use a framework if you want but fall back to pure CSS if and when you need to.
Now apply what you said to the mess of style.css that the churn of developers before you has appended to on an as-needed basis.
Except nobody has the time nor role to organize and maintain your project's CSS like Spectre.css' developer could. And nobody wants to because CSS accumulates technical debt rapidly. Everyone opens up that file just long enough to do what they need and then they get out before the house of cards falls down. To avoid adding rules that break existing UI, they add a new class and a new rule just for that class to be safe.
And let's say you're a CSS master. Which doesn't help all that much beyond being able to maneuver in the mess that was created. The above paragraph happens in projects where everyone knows CSS just like a project can evolve into spaghetti code between capable developers over the terrain of changing requirements. And being a CSS master equips you to understand a CSS framework too, so I don't understand why you keep alluding that CSS knowledge makes frameworks obsolete. I'd rather read organized framework code than whatever the bespoke clusterfuck people end up when left to their own devices under the constraint of time and deadlines.
Frameworks help contain complexity. They aren't just a tool for beginners and non-professionals.
You're making the wrong assumption that messes in programming are only made by not knowing the language. I remember thinking the same thing at my first job out of uni, but I was quickly straightened out at my first job when I realized that being good at a language meant almost squat against the real reasons: real world applications fighting between churning requirements, business concerns, and scarce developer resources like time.
A lot of my projects are UIs for robotic hardware manipulation and monitoring. The style is one of the lowest priority items. I love libraries that are just pre styled components in a box. I usually only have to use CSS to adjust their positioning and size.
When the occasional project comes along where some misinformed decisionmakers decide that the UI needs to be sexy, then it's vanilla CSS or maybe SASS time.
I find the critical difference is length of time committed to a project. For my core business interfaces I use my own framework developed and refined over many years.
For front end website development I just recently gave up and decided to use Bootstrap. (not implemented yet, just decided it recently) Mainly so that any web designer can jump in on the site and be productive with it, not just me.
I don't want to use my personal framework for sites that others will have to work with because onboarding is too much work for them and I am constantly improving my framework. But for my own work you couldn't pay me enough to use someone else's framework.
> Mainly so that any web designer can jump in on the site and be productive with it, not just me.
This is why I think CSS FWs (but also web FWs) are often preferred. At some point a large'ish team should be able to dive in to the project, get some shit done, and more on to other work. This get reeeealy hard without a high degree of standardization. FWs are primarily a means of standardization for me.
>At some point a large'ish team should be able to dive in to the project... FWs are primarily a means of standardization for me.
I don't work with a large team internally, but externally I do. Every website built using my platform has potentially multiple people editing it.
Also, wouldn't you consider long term support just as important as team size?
As much I don't like other people's frameworks, the more common the framework the more history of support online and ease of finding someone who can fix/upgrade it later.
At least that is my assumption moving forward with Bootstrap. Anyone else have feedback on supporting Bootstrap sites long term?
This is exactly why Bootstrap is so useful. As it's so well used and known there's generally a solution out there for any weird problem you might have, and any developer can pick it up and be productive immediately.
Yes it's big, and to get the most from it you have to design for it from the start, rather than make it fit whatever the design is.
For a large web project I'm leading, we're using Bootstrap 4 with our own styling, but at every step from information architecture through to front-end we're using default components and variables wherever possible. It definitely makes things faster, more convenient and maintainable.
It's like using a well-known content management framework like Drupal instead of a home-brewed CMS built in Racket* or something. Drupal is boring, heavy and overkill for smaller websites, but it solves common problems for big websites really well, has a huge library of contributed code and is well understood by lots of people. The Racket site would probably be more fun, faster and cheaper, but a nightmare to maintain three years later when all the original team members have left.
* Not knocking Racket, I love Racket. Just picked it as an example of something more obscure than Drupal.
It's good to get more confirmation that Bootstrap is the way to go. Just today a cohort from Startup School sent a link to a screencast where he had built his entire admin in Bootstrap, and it looked like it saved him a ton of time.
That being said, I built a CMS with a key idea that the site editing/configuring should be under the control of the designer. (as much as reasonable) And anything that couldn't be should be as easy as possible to understand. (down the road exporting the entire site to static files will be an option as well)
I think we all have limits on what control we want to give up but it's easy to set aside when there's a large community support around a framework. I picked up Vue and I am dumping my custom framework that it replaces. And made a new micro-framework to replace jQuery functionality not easily found in vanilla js.
(isn't Racket a programming language?)
Is it hard to design on top of/customize Bootstrap 4? A colleague of mine knows version 3, and is concerned about diving into 4 because community support isn't robust around it yet. (ie, low number of answers on Stackoverflow for 4)
We’re transitioning a 20 year old website with over a billion annual page views over to a fully bootstrap 4 front-end. The site is a grab bag of technologies and frameworks from across the ages, so it’s not a simple task.
We’ve approached it using component based ‘atomic’ design principles, using Bootstrap’s defaults wherever possible. The company is rebranding next year so the styles need to be really easy to change.
As for v4 vs v3, there’s a few changes in syntax and the under-the-hood move to Flexbox, but as far as I’m aware the front-end team haven’t run into any showstoppers.
Once the transition is complete the plan is to compile our own version of Bootstrap with only the js and css we need.
(Yes, Racket’s a language. I was thinking of a nifty static site generator I saw written in it the other day. I’d love to build a site with it but under no circumstances would hand it over to a client.)
Agreed, That's certainly what I do and how I use it, also BS4 is very modular, you can tear out all the bits you don't use (or comment them out in case you ever do need them) and it's relatively trivial to alter other things (I use a 24-col grid with a 16px gutter width instead of the default 12/30 etc).
I could replicate the bits I use from bootstrap using something else or from scratch but the RoI in terms of time invested just makes no sense.
I don't think I've ever used bootstrap 'as is' since 2, I generally create something similar to a 'theme' that is layered on top of whatever is BS-current, makes upgrading a lot less painful that way since I isolate a lot of my changes.
The big advantage is done right you leverage all the thousands of bug reports to fix things without overly constraining yourself.
Why is that bad if you have users with older browsers? I have thousands of paying customers with a very wide range of browsers. Why should I make their lives harder by using flexgrid?
I never understood how people could use bootstrap with custom designs. It gives you CSS and JS for so many elements and classes so if you want it your way then half your CSS is just undoing (like `margin-left: 0` or `font-size: inherit`) their styles.
If the decision is to use Bootstrap then you have to design with it rather than against it.
The defaults are pretty sensible, so as long as everyone - including the designers - understand they need to customise the design to Bootstrap rather than Bootstrap to the designs it works really well.
It' a fast way of working as Bootstrap has already done most of the basic stuff, and by making changes in the right places it's easily possible to not make it look like 'just another Bootstrap site'.
From what I understand CSS frameworks used to make web dev more bareable because you could just use a simple class name and the framework would apply a load of hacks to get something sensible that works in all browsers.
Bootstrap always seemed like a polyfil for flexbox.
We’ve ended up with our own, not so much a framework but a set of commonly used mixins and set of SASS files - some of which might even be empty placeholders - that stop us trying to work out the same issues over and over.
I treat it a bit like adding packages with NPM, just adding the small bits we need to achieve certain things.
When I’ve tried to use proper frameworks before they have always been too opinionated and I would find myself working around them.
I've been writing my own CSS too, but the problem is that my site looks really awful. I'm not a good designer, so I'm going to rewrite my front-end using a CSS framework that has great components and a nice design out of the box. It's really great for people like me who need a few more "guard rails" to keep things looking alright.
> am I/teams like mine that include at least one person fluent enough in CSS to write reasonable style sheets/styled components, just not the target audience?
I think this is only partly correct. I am an experienced front-end dev who is very CSS-capable, but I enjoy using Bulma[0] as of late because its default styling is very close to what I want already. The default style works well enough for me because the projects that I work on (prototypes, experimental stuff) generally don't involve or need custom designs.
Edit: However, I work mostly alone... back when I was on a larger team working on different stuff, we'd usually use Bootstrap. In my experience most Bootstrap users don't even know how to use Bootstrap well though...
They are very popular on HN because the main users here are not front-end engineers or designers. They are hackers who want a quick landing page for their project. Those quick and dirty frameworks are perfect for it.
You might like inuit.css. It's a SASS framework that only includes helpers and an overall structure (no actual visual styles).
I use it for all my projects. The most useful bit is that it allows you to choose a line height and then gives you padding varibales based on that, so it's really easy to have consistent padding everywhere.
I'm the author of one of these independent CSS libraries that has been in the front page of HN several times. I normally use the libraries I write quite a lot, and it speeds things up for myself. This is mainly because of the deep knowledge I have for them, but if other people find them interesting so let it be.
Why would still make sense for skilled teams like yours? I can think several reasons:
- Prototyping: Probably not everything you do is detailed development and you might want to throw a quick prototype with not-too-bad styles. It won't be groundbreaking, but the ROI of using a CSS framework for those normally pays off.
- Cross-browser testing: an open source library will get bug reports from many varied places, and normally it's well tested cross-browser. Do you know about all of the flexbugs [1]? Do you even want to know? What about the 2012 trick of Paul Irish for box-sizing [2]? Did you know it was updated in 2014 and how awesome this update is?
- Documentation: when onboarding a new member on the team, if you are using one of the more popular libraries there is a large amount of documentation, github issues, stackoverflow questions and general articles on the web. While you might put the work to do this internally, even with great teams the internal documentation is normally very much worse than the OSS docs.
- Other topics such as accessibility (color contrasts, keyboard states, etc) are normally polished in the libraries. It's not free, it comes after bug reports.
For these reasons it doesn't make any sense that an experienced team build the whole CSS utilities from scratch for each project. So the only sensible thing as a company is to reuse some of the CSS through projects. Then you got an internal library! Why not open source it? You got one of those!
Just look at the CSS [3] of "simple button" of my library, which already inherits half the style from a label. If I had to do buttons from scratch I'd forget at least 2 of those: the cursor pointer (because most links with .button would have it naturally, but not those with events and without href!) and the box-shadow to 0 (which only happens in some obscure combination of browser, device AND resolution). I just offloaded that knowledge long time ago into my library and now I focus on improving on other things :)
As far as I can see, people who know a client-side language well do not need to fall back on a framework, as the languages these days are more than capable of completing the tasks themselves, without being reimplemented by a framework over and over again.
What I enjoy about Spectre.css is that there is no javascript and the CSS is readable. It's easy to drop their CSS into a react component and extend it because it's so readable.
I generally like to see a "kitchen sink" page with everything from the framework in addition to the option of having to go through the various parts and discovering whether they exist and what the defaults look like. I don't know if this is a popular opinion, but if so it would be nice if it became the de-facto practice when these are released.
This applies to all frameworks pretty much - if your web framework supports out of the box internationalization, caching, authentication, etc. the best way to sell me on it is for you to release a demo with all the bells and whistles, written with the conventions, folder structure, architecture, etc. that you advocate.
IMHO Everyone should write at least one framework of some kind. Bonus if it's open source.
It's a huge learning experience. Gives you a deeper understanding of how other other frameworks work. Helps you understand user and customer support. How to write documentation. Great for your resume. Etc.
In other words, if you only ever consume frameworks it makes it difficult to know what to do or how to approach solving some of the lower level issues a framework may present.
Do you have any personal experience in doing so? They seem like tempting projects from the outset, but getting started with some clear goals in mind, alongside philosophical/idealistic differences from what's already out there so you're not simply rewriting something for the sake of it has prevented me from getting too far down a particular rabbit-hole.
My first php framework was something called php4gl back before ruby on rails was created. It used the command line to bake controllers and such. Just a private project never released. Lost the code now!
I also wrote another couple more php frameworks. I used one for all my personal side projects. And I wrote a couple for day jobs website over the years.
Actually it wasn't until Laravel came out that I was convinced NOT to write or use my own php framework ;)
So, now I've stopped writing php frameworks. But, I still write a CSS component framework from scratch for every project.
I wrote a really quirky javascript framework called Double Dollar that worked using a kernel pattern. Anyone I showed it to thought it was nuts. I abandoned it and now just use jquery for projects I work on like https://nugget.one
Probably the most sucessfull open source project I created was ezSQL. Wordpress ended up using it as their original database class and then as the API interface for their current wpdb database class. I think a lot of people probably curse me for that ;)
I like fast, small web pages because not everyone has a broadband connection at all times. Can you tell me what other mature, tested, well-supported CSS frameworks have a feature set that large in less than 25% of Bootstrap's size?
[EDIT] - BTW, I mean this with less snark and more did-you-know-all-these-existed? I knew of purecss & skeleton (and I've forgotten a few, because it used to be very common to see these), and I've seen bulma before but some others were new to me (and I favorited them to give a try on some random project)
PureCSS was one of my favorites for a very long time. These days I use component frameworks like ElementUI[0] more than anything else to maintain consistent styling (since most things on the page happen to be components).
For me, the default answer is "yes" for many reasons:
* I'm not smart enough to handle most browsers well in a short amount of time
* I'm not primarily a designer and these frameworks are often gorgeous by default
* I don't want clients to pay for me to reinvent the wheel, and I don't want them left with my personal framework when there are many, better documented ones available
* These designers thought more than I did about accessbility, and I place a high priority on it
* These frameworks can sometimes deliver a lot of bang per byte, and I'd rather be writing stuff only I can do than wasting time trying to get mine as small and efficient as theirs
Perhaps the issue is with the constant use of the adjective "modern" in many new libraries and frameworks. It implies that there are no other notable benefits than the implementation being based on newer technologies and development practices.
Is it faster (than what's current out there), more stable or easier to use, would be the answer that most prospective users look for...
Curious what people are using css frameworks for these days. I used to use minimal ones to get some kind of grid support. But now I just use css grid. Are people still using frameworks due to needing to support old browsers?
A lot of modern CSS frameworks choose to ignore the cascade.
This trend has grown in response to how difficult it is to avoid regressions at scale - large or multiple projects, lots of components, lots of independent teams, etc.
The cascade really is an elegant and efficient idea but it becomes really difficult to manage as projects grow.
The different with inline CSS is that those helpers are the building blocks — that’s where your standardize your design system metrics.
As others have pointed out this library provides a mechanism to abstract into components as well.
How do we classify the progression that is tachyons/tailwind? Each time I see a new CSS framework I also think, is this yet another framework for devs that can’t desigh or is someone working to move the needle beyond what tachyons/tailwind have set a new place of maintainable CSS.
> How do we classify the progression that is tachyons/tailwind? Each time I see a new CSS framework I also think, is this yet another framework for devs that can’t desigh or is someone working to move the needle beyond what tachyons/tailwind have set a new place of maintainable CSS.
AFAIK, functional CSS frameworks like Tailwind are getting relevance thanks to the recent boom of functional programming.
I really do hate to be the guy this guy, but after having to maintain a website a contractor built in Tachyons, I've hated it with a passion of [insert hyperbolic phrase here].
What do you love about it/what am I missing? For me it felt like a tutorial on the most egregious CSS/dom anti-patterns, and I haven't been able to get past it.
The patterns are easy to learn (for me) and makes building components very quick while still being very customizable without having to add a whole bunch of one-off styles. And everything is still standardized.
It also removes the need to constantly reference CSS at all, and can just stick to HTML/JSX instead. It can get very verbose though, but that's a minor trade-off I think.
It's a direct 1-to-1 mapping to inline styles so why not just use inline styles? If the answer is "standardization" then using CSS as it is normally used is the logical conclusion of that concept.
Inlines styles are verbose and hard to change. Component styles allow us to build up components and customize as needed, but the styles themselves are well defined and coherent.
For example: MA1 (margin-all-size1) and MA2 (margin-all-size2) allow me to make a component with more margin, but the margin steps are standardized so everything will follow the same sizing and fit together well, and can be changed easily in one spot later if necessary.
It really only takes a few days at most to get used to the class names, and then you can easily tell everything about the component by just looking at the HTML. We follow an internal rule to place spacing first, then borders, then text, then colors at the end.
> MA1 (margin-all-size1) and MA2 (margin-all-size2)
Honestly these aren't too bad. But all the CSS frameworks I've seen of this style instead are like MA-10 (margin all 10- pixels) and MA-20 (margin-all 20 pixels) which of course completely defeats the idea of standardized steps beyond limiting you to that subset.
I think there is some value to a few of these styles in any project but ultimately you get more standardization with semantic names. "alert-danger" instead of "alert-red" for example.
There's no reason you can't combine then, and frameworks like Tailwinds mentioned above let you make those combined styles through config automatically.
However, my point was that it's a great fit for React and other SPA frameworks, where you can just create a <DangerAlert /> component instead, and inside you can use component styles.
But if you're isolating styles inside react components, you're back to being able to use inline-styles. You can just functions and variables if you need standardization. Something like Tailwinds adds a level of indirection not a level of abstraction.
I don't like that concept of essentially inlining styles in the class attribute. It is just a misuse of html classes.
Class names should be used sparingly and describe the semantics of an element rather than its visual appearance. It should be something like class="button submit disabled" instead of class="f6 link dim br1 ph3 pv2 mb2 dib white bg-black".
If anything these styles should be exposed as sass mix-ins that you can use in your own styles. So you have a named set of style mix-ins that do not pollute class names.
button is a tag, submit and disabled are tag attributes -- surely you don't need these classes, they're either superfluous or you're not doing semantic HTML.
I agree that you could in a lot of cases get along without these classes. But sometimes you want e.g. an anchor acting as a button in a web application. Or you want a button element with browser styles. You could argue that this is also already an anti-pattern but it does way less harm then leaking inline styles into the namespace and it is still semantic. Also this was just an example (maybe not the best one) to illustrate my point that class names should be semantic and not express solely presentational attributes. The later is what styles are there for.
Especially in a javascript driven web application you may want to select all "buttons that are disabled". But you never want to select elements that "have a rounded border of 2 px and a grey background and italic font style and....". This takes class names ad absurdum.
does the last example if you classed that style, doesn't it? I've only done a little CSS, not very recent ... unless you're recruiting, then I'm an expert ;o).
I imagine though there are times when you want to class (some) button tags as .button.
Same, not in anything intensive. Used it for my home/blog page. Looks like they definitely extended it further. I've liked the results better than some other lightweight frameworks. Didn't customize it much, either. Site's in my profile.
Thanks a lot! I've been looking at a lot of different CSS frameworks lately. So far I'm considering Semantic UI, Bulma, Tachyons, Tailwind, and a few others. I initially skipped over Spectre because I thought it was a just a lightweight grid framework, and didn't realize it had so many components in less than 10kb. That's really amazing, and I also love the super clean design. You also get a little bit of Tailwind with the functional classes.
The only thing I don't like is how it uses native browser select dropdowns. They're really ugly, so it would be nice if there was a proper select component (although I can just add my own CSS or use Select2.)
Anyway, this looks really awesome. Especially for a landing page that needs to load really fast.
I wish people would stop using "awesome", especially in a "curated" (don't get me started there either) list that has tens to hundreds of things. There is no way the author could possibly know if all of these frameworks are "awesome".
Confused why this is posted again, it's been submitted many times. (Maybe there was a big release? Just looks like updated docs). Having said that, I've used this for a number of projects and enjoyed it much more than heavier solutions.
There is no js so you just write your own in and it's really easy to mold to your own liking. It was "just" enough and produced polished looking crud apps. Mostly search and form stuff with tables but users have enjoyed it so I give the author credit. I also had to spend way more time working on the backend and this did not get in the way.
HN doesn't mind revisiting topics from time to time. It's been a couple of years and HN has grown enormously since then. And FWIW I spent a long, long time settling on Spectre,css, which isn't perfect but which I feel covers a huge range of standard business purposes with an amazingly light footprint.
This will probably be a unpopular opinion but I think HTML should be fully semantic with a naming scheme for custom elements (not BEM, etc), take for example classic breadcrumb navigation, the element name would be <breadcrumb-ul> to convey it inherits from HTMLUListElement so the actual structure isn't just an unknown mess of custom tags.
CSS grid works in all modern browsers now. It’s totally change the way I do layouts and is way less cumbersome to just use directly than these other hand rolled float or flex grid systems.
Not mine (I'm OP), but Yan Zhu, the creator, just needs way more attention. If you imagine an ego continuum with Richard Stallman on one end, Yan Zhu is the exact opposite. It's a little bit of effort just to find his name.
The example pages are unbearable slow and lagging on my 4-core 7700HQ CPU.
I don't know what the reason is, but it sure isn't a minimal framework.
I am no web developer, mind you, but I have yet to see any case where such heavy load really increases the benefit I get from a site. Usually it is quite the opposite.
It is my opinion that any web-developer using these sort of megabyte-sized frameworks should have their license revoked.
Perhaps I should clarify. I've got no issue with engineers seeking compensation for their work. I know the world can be a harsh place, and some people truly need the money.
Michael, you're absolutely right. People can insert whatever markup and JS they choose.
It simply seems an odd strategy for a CSS framework to squeak by on ads in the docs. An unfortunate side effect in this case is it makes it unclear what parts are documentation or examples, and what is an ad.
But I keep seeing frontend frameworks on HN - am I/teams like mine that include at least one person fluent enough in CSS to write reasonable style sheets/styled components, just not the target audience? Or do other experienced frontend devs swear by UI frameworks like these for reasons I haven’t grasped yet? If so, why?