I interview a lot of candidates for my company. More generally, dedicated UI developers are becoming harder to find in my experience. More often, I see “full stack” devs who turn out to be back-end devs with some exposure to UI development, mostly with big, popular frameworks like Angular, which simultaneously hide and increase complexity, adding lots of layers of abstraction. Much less do I see strong CSS knowledge and experience. I think much of this must come from the proliferation of UI libraries like Bootstrap and Foundation, where most of the design is done for you (even the responsive bits) so mostly all you have to do is copy and fill in boilerplate code. Don’t get me wrong, this is great and it saves a ton of time, allowing most projects to get away with not even having a single dedicated UI/UX resource, but it also means there are fewer and fewer UI generalist out there who actually know what’s really happening in the browser. Back in the day before all these fancy frameworks, I had a lot of time to luxuriously tinker with CSS and core Javascript, and I even developed a few of my own, admittedly horrible by modern standards, custom UI “frameworks”. These days that would be unheard of.
This is s very long-winded way of saying I generally agree with the article’s sentiments. CSS is no longer a core skill because it doesn’t really need to be, which is both good and bad.
To be fair, the same can be said of backend devs. Think of rails devs, they know the framework, barely the language, let alone sql and fail miserably at any sort of software design or even architecture for what matters.
I'm not sure CSS has anything to do with it, it seems to all be questions of "when does a dedicated designer make sense" that aren't even limited to the web.
CSS skill is the ability to implement a design, not the ability to come up with a good one.
Can you have the skill to come up with a good design if you have no clue how to implement it or how someone else would?
This is a straw-man. Real-world designers absolutely do have a sense of implementation constraints for their target platforms, yet are usually not deep implementation domain experts. Likewise, experienced UI devs often have a sense of design, but are often not going to draft and refine a whole-cloth new design. I’ve also met a rare unicorn or two: those magic individuals who are fully capable developers and designers.
Put another way: UI design and UI development are adjacent specialties. Visually, they’d be partially overlapping regions in a Venn diagram. A UI designer or a UI dev who somehow knows nothing of their peer discipline will be hamstrung. I’ve met devs who fit this bill, not by their own design, and they’re usually radically unhappy with their work until they manage to pivot to non-UI development.
I think yes, it probably helps to know the limits or difficulties of implementing something when designing it as well, so you can design something nice and easy to implement, but otherwise why wouldn't someone be able to design a mock?
1. I'm not sure "internal" vs. "external" is the right dividing line. I've worked for start-ups where doing something scrappy with our external look-and-feel was fine, and on the other hand my previous project was an "internal" tool that had thousands of internal users, which demanded a higher quality.
2. I've seen cases where internal standards slow things down, but I've also seen cases where internal standards speed things up. Yes, if you have to do the same amount of work every time to maintain a high bar, that would slow down CSS work. But we would never say that about bugs in logic, instead we'd say "Use the foo function that so-and-so wrote" and. The problem isn't the standards themselves, it's what corners are cut to achieve them. A "high standard" CSS can help remove friction by helping developers avoid thinking about things that are irrelevant to the task assigned, leading to a more sustainable overall design (see https://www.martinfowler.com/bliki/DesignStaminaHypothesis.h...).
2a. To be more specific about the last point, having a clear design language (we are allowed to use these font sizes and no others; we are allowed to have buttons that look like this one, that one, or the other one; we have to use these colors) forces constraints on developers that can make the overall code base easier to understand and maintain. The constraints remove the possibility of engineers who aren't all that strong in designing user interactions from designing something confusing or buggy.
3. I don't know what this "beforetime" is. I've been working in the industry since 2008. That was three years before Bootstrap's first release which the article mentions as some epochal dividing line. During the entirety of my career, CSS has always been a technology that many developers just don't want to deal with. The only change has been that now a team has 1 person (or maybe 2 people) who are good at writing new CSS definitions on top of a pre-existing CSS framework, whereas before a team had 1 person (or maybe 2 people) who made all the CSS definitions from scratch.
Totally false. This is like saying JS isn’t a core skill because there are site builders out there. You can get away without knowing a lot CSS but it absolutely makes a huge difference the more you learn
Depends on the team. I think we need to define basic understanding here, too many front end devs don’t have what I would call a basic understanding of CSS.
I'd like to take this opportunity to confess something:
I've been a web developer, for pay, for eleven years. I still don't really get CSS. I sort of know about the box model, about margin vs padding, about display inline vs block vs online block vs flex and so on (still not so sure about display: table), about relative and absolute positioning and units.
I can make you a website and make it look good and make it mobile responsive, but fundamentally, I don't know that I get how it all fits together and I don't know that I even care to, or that it even does...
You can take "easy" answers to these e.g. "margin vs padding is about how much distance from content outside and inside the element respectively" or "relative vs absolute is about placing the element relative to where it normally would have found itself or absolutely against a reference point regardless of what else might already be in that space" and so on... but if you want to truly get past the "CSS is an art not a science" feeling reading the specs is surprisingly not as hard as it seems and I can almost guarantee you'll leave thinking "CSS is a science not an art".
That being said as you say you might not really care as it probably isn't going to help you make pages any faster or better. I mean sure you can understand the nuance to a much fuller extent but at the end of the day it's simply unlikely to be what's holding you up from spitting out working CSS any faster if you've already been making pages for a decade. You have to go into it almost for a curiosities sake otherwise you'll get 100 pages of reading in and go "ya know, I really just don't care".
I'll have to disagree a bit on the "You don't need to design internal tools well" argument.
I get the point the OP is trying to make, and certainly agree up to a point, especially when you are comparing to an external UI. Obviously in most cases, your customer facing UI should be much more well designed compared to your internal tools. Of course.
... but, this argument only makes sense when there is a trade off like this to be had. In many larger organizations, (which tend to have more internal tools), it is not the same teams which build the external and internal tools. And the larger your organization, the more (internal) customers you have and the more married to these tools their work is.
Just anecdotally, if the tools we built for the internal customers for my team were not well designed (as in well thought through), it will definitely piss folks off - because many folks use these tools throughout the day. Many internal users spend > 90% of their time on a handful of tools. Looking great is optional, but looking good, and working great in not. I wish I could give more concrete examples, but in many of our internal tools I have found that a few lines of CSS could make a a difference of night and day.
Not necessarily against the point OP is making, but just wanted to flush it out in more detail.
I think OP isn't against well-designed internal tools, just against requiring the fine presentation and theming that custom CSS now enables. Their point becomes clear when they say that devs can just slap a framwork like Bootstrap on internal tools' presentation and call it a day, no CSS required.
As a designer, I learned CSS in two weeks and I love it, I will never understand all of the drama I read about it. I enjoy making complex UI / animations with CSS / SVG so much. To me, it was easier to learn than Javascript, and I use both everyday. All these libraries just get in the way of what is ultimately trivial imho. Emmet comes default with VSCode, so if you really can’t be bothered to type `position: absolute`, surely you can’t type `poa` and hit tab. With CSS custom variables, making a unique design system in a day is so much easier than almost all other programming challenges I’ve faced. I really wish I could understand where so many others are coming from.
HTML and CSS are not disjoint. And if you don't consider the two together, you're bound to end up with verbose code.
This is a slippery slope. HTML, CSS and JS are all core skills for any front end/full stack developer. You will develop expertise in time, but do learn the fundamentals.
I have a GET response. I want to know if a particular element has a CSS style. I don't want to ask chromium or FF if I can please use whatever annoying API they changed yesterday. Is there a UNIX philosophy tool that just does (just) this? (pretend JS does not exist for the purposes of this question).
I found a requests-(something) that wrapped chromium, but my tagging system fails me at the moment, and it's irrelevant because I don't want to use that shape shifting beast.
WebKit on the other hand is a ray of light... except now it requires JS to manipulate/query the DOM :((?)
I agree with the headline, but the arguments in the article are a bit all over the place.
Bootstrap, Tailwind and other libraries are abstractions because CSS as a core skill is quite complex. Sort of like the English language, the ratio of rules to exceptions is too high.
If your team doesn't know CSS very well, you have your designers stick to bootstrap, tailwind etc grids/designs.
You can make PLENTY of beautiful, functional, readable, designs within the frameworks. When you do, your deigns work in mobile, web and there are significantly less things to worry about.
Perhaps ironically Tailwind has helped me understand CSS much better than I used to. Adam Wathan has some brilliantly elucidating tutorials on his YouTube channel.
This is s very long-winded way of saying I generally agree with the article’s sentiments. CSS is no longer a core skill because it doesn’t really need to be, which is both good and bad.