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