CSS is an art, and it's dying. A reflection on CSS and JS frameworks and the evolution of CSS
Hi all! I've been learning full-stack JS/Serverless dev recently. I've only been a static front-end dev before, working with Jekyll and WordPress if not just raw files, so CSS was something that I know well and love. With the advent of ideas like atomic frameworks (Tailwind CSS), CSS-in-JS, and higher-level JS frameworks like React, it seems like CSS, as I learned it, is dying. So in the middle of my Serverless project, I had a mini-crisis and decided to bash out an essay about it.
I woke up and was surprised to see a good bit of discussion about the essay on DEVto, including a reply from one of the creators of SASS, providing some really interesting pushback against CSS and JS frameworks that is bit more nuanced that the gut reaction "nononono" that I and many other CSS developers first had. A response to this was essentially, "get with the times," while the original commentor continued to push back: "I'm not saying that you should quit, but each of us need to take a bit of an activist stance when it comes to being told things like 'if you don't feel jubilant about containers, microservices, serverless and writing CSS in JS, you are stupid or old or old and stupid'."
This is a topic with a lot of nuance and different from every perspective, so I'd be really curious to hear what you guys think, whether a new developer, more "traditional" front-end developer, or seasoned hacker who knows their way in and out of frameworks and all the ways to do things!
The Blind Men and the Elephant :)
I'm by no means an "expert" on all things software - I wrote my first QBASIC when I was around 12, so I guess you could say I've got 18+ years experience in a bunch of different domains (mainly web). Nowhere near the 40+ year careers that industry veterans have, and those are the people I try to learn from.
While I don't consider myself an expert, I have been around long enough to see patterns emerge. Like leastbad says on DevTO- "a few pendulum cycles". The one pattern that becomes clearer over time is: There aren't actually any new category problems in computing (maybe machine learning).
Every program ever written tries to do one of two things: Get machines to exchange data with other machines, or get machines to exchange data with humans. While every new framework, library, toolset, paradigm, standard etc will market itself as the best new thing ever, fact is: It's doing one of those two things, just slightly differently.
Which is why I think the Blind Men and the Elephant parable is so apt: The full domain of software development is not really visible to the people that are just starting out - or the people that declare blind loyalty to a particular way of doing things. If you're just going by the limited information you gain in the first few years, then form an unalterable opinion, you're probably going to be wrong.
The people who learn C++ first will argue with the people that learned Rust. Ruby and PHP developers will argue over which framework is better for the web. And from what I've seen, Javascript and Javascript developers will argue over which framework is incrementally better at a specific task, usually the ones they learned first before learning anything else.
Worse, people will approach every problem as if they're the first ones to ever conceive of it, then argue that their solution is clearly superior since nothing like it has existed before. And while the specific implementations may be new, none of the ideas are.
"CSS-in-JS" is basically a reinvention of the Winforms model (coupling style and logic directly in components), which itself is probably a reinvention of something earlier. Serverless sounds modern, but it's really just the old-school mainframe timeshare concept, sold with billing to more decimal places.
So if you want my opinion: Relax! There's more out there than any one person could ever know, so don't stress about having the "best", "right", "leading" or any other superlative. While kids are arguing about CSS and JS, the real world is (right now!) trying to hire COBOL developers - a language that was "supposed to die out" when more modern languages came along.
Wow, thanks for the insightful response! This is a good reminder of how big/long-historied the field of programming/development actually is and how much I have to learn. Thanks for sharing!
This comment was deleted 3 years ago.
We do it faster, but do we do it better?
I'm speaking about quality. Which means: do we have less legacy codebase? Large codebase are still awfully complex, we create micro-services all highly coupled to each other, we use cool technology without any benefits, and we have a real hard time to measure what's the best thing in a scientific way.
It doesn't mean that large codebase have to be a pile of mud, it means that the ratio between good large codebase and bad large codebase is not 50/50.
I do question that sometimes, though. Yes, in both absolute and relative terms there are more people writing software every year, the tools are more easily available, the industry is more accessible, etc.
But that doesn't necessarily mean that the craft, or the category problems it solves, has advanced at the same rate. A lot of the new solutions/frameworks/paradigms/etc coming out of this industry in the last 10 years seems to have evolved based on the new people joining it.
Javascript is a great example. It was initially conceived as a way to enhance web pages. For people who learned that as their first language (and have it as the only tool in their toolbox), it makes complete sense to "advance" Javascript by adding more and more features/complexity to it.
Cue NPM, a package manager that has, over the years, made a lot of the same painful mistakes that prior package managers (yum, apt) went through. I haven't been directly involved in that, but I get the impression that the people who built it didn't spend a lot of time learning from the failures of their predecessors. If they had, things like left-pad wouldn't have happened.
In net terms, did the craft of software engineering advance? In some sense maybe, in that major languages all have similar-behaving package managers now. But package management itself is ancient. While the concept has been implemented more broadly, it's still an old concept - APT's precursor was conceived back in 1997.
Same craft, new artisans, most of whom seem to be learning things the hard way. I count myself among them: It took me quite a few years to realize that the "previous generation" had a ton of stuff worth listening to :)
Great article. I can see the fear but honestly I think the Tailwind, React, css-in-js trends are just that, trends. They come and go.
I'll keep writing vanilla CSS and the little JavaScript I allow my sites to have. A language designed in 13 days to make text jiggle isn't eating the world, it's a teetering skyscraper that falls and gets rebuilt every ~ten years. I've been writing JavaScript off and on for 20 years and it's always a changing guard.
Experiment with your own CSS "framework" if you like, BEM-style, or not, play! CSS3/4 are amazing as is HTML5 today. Ten years ago I wrote an entire client side MVC in Google Closure and Soy. It was a multi-kLOC application to render interior maps and do space planning with HTML5 Canvas. Zero pieces of the tech I used then are in common use today, zero. I can say confidently, vanilla web dev has never been been better.
Sit back and relax. Today React and Tailwind have their day. The frontend is light breezy tech that blows away from time to time. Learn your fundamentals and build on, don't worry
Reasons you may want simple/vanilla:
https://jeffhuang.com/designed_to_last/
Hilarious talk:
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
Mm this is an interesting perspective, thanks for sharing! Learn the base-level skills well and on top of this adapt to whatever is in demand at the time.
I think it depends on your use case. As someone who grew up indoctrinated with "separation of concerns", utility frameworks initially seemed like heresy. It took me a long time, but they finally won me over – but only because what I'm building right now IS utilitarian.
What won me over is the speed of development and iteration in the form of 1) don't have to craft or think too hard about css, 2) since the css is now co-located with html it's faster to see/edit – yes it's uglier but it is faster, and 3) when the codebase gets larger it's easier to manage, and 4) when the codebase gets older there's no need to remember why/how css worked.
I'm using Bootstrap as my base, and I still use custom css whenever Bootstrap doesn't work the way I want it, but I keep that to a minimum. I like Bootstrap because of all the pre-built components, but there are times when it doesn't work the way I want. The consensus here seems to be to use Tailwind for more fine-grained control, but I'm not quite there yet.
If I were building a personal blog or an unconventionally styled website, then I think old-school css has its place and is probably better than utility frameworks. But for projects that are large-scale or multi-developer and where function is more important than style, I think utility css is clearly the winner.
When my partner, whom I relied on for everything CSS related, left me a couple years ago, I had a decision to make: whether to hack my way through the CSS and just "get it to work" or whether to invest a few weeks to learn CSS fundamentals.
I am very glad I chose the latter. After learning CSS fundamentals, I feel I was able to understand and use the frameworks much more effectively. I use Bootstrap and SASS. I considered using "CSS in JS", which was all the rage at the time, but that was a bit too advanced for me and the benefits were not immediately clear; decoupling style from interaction logic felt more right to me.
I think if you are going to build a life around software development and coding, then spending the time to understand the fundamentals is crucial, because it will pay dividends your entire life. But if you are just doing something one-off and not sure if you want to be a coder, then it might not be important to understand the intricacies of CSS (or setting up a server, etc...). Just use a framework and don't bother with the how and why.
It is like buying furniture. I don't see myself devoting my life to carpentry, so I will go to IKEA which will make my life easy. I don't care why the nuts and bolts are a given size; I just trust IKEA that my bed won't fall apart. But if I got interested in carpentry with dreams of making my own furniture, with my unique style, and selling it on Etsy, then I better damn well understand which size nuts and bolts to use where.
I really like this analogy, thanks for sharing! I guess what we're seeing with today's frameworks and component libraries is that there are more, better, and easier options for IKEA-style mostly pre-built furniture, while carpentry remains its core thing that underlies all this, going through incremental improvements of its own over time.
Hi @wwsalmon
:) I too felt same, when I was learning How to my code a web page using HTML and CSS. But later I used Sass and CSS-in-JS while using Reactjs. I found that there is a definite gap in the process of building an application, which these language and libraries are filling.
I read the essay in Dev. to about writing simple CSS.
See, every developer including the persons who wrote SASS knows how to write CSS. But they also know the advantages of these new platforms, which you will rejoice when you will be building larger and more complex applications.
Also my experience tells me that simple "margin 0px" doesn't always work. This formula gave me few bad days when I use to center bootsrap form-group elements.
This comment was deleted 3 years ago.