TL;DR: There are a lot of people who love both JS and UX/CSS/etc. If we stop labeling people just as “JS developers” or “UX developers”, we can achieve a ceasefire in the current “JS vs. CSS” war and get closer to peace.
The War is Real
Some call it The Great Divide: the frontline is real, with JavaScript diehards on one side, and UX/CSS people who advocate non-JS approaches to interfaces—on another.
Front-end developers are afraid of losing their jobs if they avoid the whole JavaScript hype. And it is perfectly understandable: CSS is out of trends. There are significantly fewer CSS conferences and meetups compared to JS/React and friends. For instance, there are 6+ JS meetups in New York and 0 regular CSS meetups.
On the other hand, we see simple static websites being over-engineered out of a sheer FOMO.
We see prominent figures in the front-end community passing the blame on each other every day and that is unfortunate, to say the least.
Look Beyond
The warring factions are often labeled as:
- “JS-JS-JS”: Developers who create SPA with client-side JavaScript frameworks like React, Vue.js, and Angular. They are heavy users of innumerable build tools (Babel, webpack, etc.) and JS libraries.
- “UX developers”, “CSS developers”, “HTML-JS-CSS developers”: Developers who create static websites with vanilla JavaScript and plain CSS. Accessibility and performance are most important topics in their community.
But do we have to have this split? Maybe this dualism is based solely on our own bias?
In my opinion, this bias is largely caused by two things.
First of all, there is a trend to separate CSS and JavaScript conferences. I think it got started by a very popular and successful JSConf/CSSConf family of events and by a trend for Put-Your-Own-City-Here.js meetups. Content platforms also support the divide: some of them publishe mostly React/JS articles, others focus on CSS and UX.
Second of all, social networks are good at polarizing society. We put ourselves in a bubble of likeminded individuals by subscribing to their feeds and make things even worse by reposting only the most aggressive opinions coming from the other side.
The modern web is incredibly complex. It is extremely hard to master all the technologies that power it and no one can really call oneself a 100% “full-stack” developer. But due to the fact that the JS and CSS/UX discourses have become so (artificially) separated, people with different, but not necessarily opposing passions are bing shoved into a black-and-white “JS vs. CSS” world view. React developers who are passionate about CSS animations and a11y are labeled simple as “JS folks”. And a CSS developer who loves Babel and zero-runtime CSS-in-JS will still be painted as a “CSS guy/gal”.
People Who Love Them Both
As a creator of PostCSS, I could never really pick a side, even if I wanted to. On one hand, PostCSS is a tool for CSS (hence the name). On another hand, PostCSS is a JavaScript build tool and build tools are not well accepted in a modern CSS community.
And I am not alone, there are so many people like me: the creator of an amazing React toolkit for animations, or the creator of a CSS a11y linter, to name a few.
To say the truth, each of us knows only a small subset of technologies that exist out there. And one’s passions not necessarily come from a single topic either. It is OK to love both React and CSS. Or use complex build systems to be sure about you got your a11y right. Or you can dive into distributed systems because you want to make great UX with a bad Internet connection.
Even technologies themselves cannot be seen in black and white.
BEM is often mentioned by the proponents of “CSS faction” as a way to avoid the possible confusion of CSS-in-JS. But few people know that it was not designed by Yandex as a purely CSS technology! It also contains a JavaScript framework and originally had a set of ideas that were later used in React (like nesting small isolated components).
ESLint configs, popular in React community (like AirBnB config), contain a lot of a11y rules.
The Solution
I think the war is real. I think we can stop this war if we stop dividing developers into black and white categories.
- If you like technologies from both “sides”: say it out loud! Make it visible, so people can start a civilized discussion. Do you like modern JS frameworks, but also like creating static websites that don’t involve client-side rendering at all? Tell the world about it. Open source authors will create more frameworks for static websites, if they see the need.
- Let’s have a public forum for a conversation between JS and CSS worlds. If you are organizing a JavaScript meetup, set aside a day for CSS/UX talks. Let’s “front-end” conferences instead of “JS conferences” and “CSS conferences”, where people from different camps could explain their daily problems and preferred solutions to their opponents.
- Let’s try technologies coming from “the other side”:
- If you are a CSS/UX developer, start with linters. Stylelint is a good CSS linter to start with. It will warn you about mistakes and allow you to share best practices across the team. And you can run it as a plugin for your favorite text editor, so you can start even without any bundlers.
- If you are React developer, try some vanilla JS on your next landing page or a blog. This will allow you to better understand your framework’s internals. And your users will thank you for increased performance due to a lighter JavaScript bundle.
Further Reading
Here is my article about the future of PostCSS, linters, and CSS-in-JS at Martian Chronicles.
Top comments (29)
In my book, I promote an even more open definition of developers. Basically anybody who works on a software product. We have to stop being divisive, and look to solving user problems.
Good article. And a good point about social perspective. Although I do not really see this 'war'. But that's likely because I do not find myself in those social surroundings.
I like and use Vue. I use a lot of components but I won't use JS if it can be done with CSS. Simply for performance benefits. But that doesn't mean the HTML won't be rendered with JavaScript on build time or on server side rendering stage, even being hydrated on clientside. I think JS and CSS can work perfectly together.
Yeap, likely Vue has fewer conflicts about “CSS vs. JS”.
I think it is because they didn’t start CSS-in-JS movement with very aggressive ideas at the beginning (“you do not need CSS anymore”, etc).
BTW, I really like CSS implementation in Vue. It combines CSS syntax with the best part of CSS-in-JS (one file for the whole component with built-in selectors isolation).
I think you are right about that. I like reading react articles though, a lot of concepts within the Vue ecosystem are and will be based on those of React. But I also think Vue does a better job of combining both CSS and JS. That also goes for UX, it got a place at both sides. At least that's how we look at it from within our company.
Furthermore, I think that because React is initially so JavaScript focussed, that it's much harder to think outside the box of JavaScript. Note that my knowledge of React is not that extensive.
That might also be the case for the 'CSS guys' you are talking about. They may not be able to think outside that box that easy.
This makes it hard to combine both. But that's my opinion and interpretation of this 'war'.
:)
Were are at war. And even if we stop it - The Great Divide would exist.
It's more about mindset - black and white, cats and gods, meat and fish, iPhone and Android.
My wife is HTML-CSS-(js) person, as long as she started as "PDF-to-HTML" developer. She likes "the picture". Every time I am writing some CSS - she is crying - so much better it could be. But I am not understanding her.
I honestly not giving a shit about BEM-compliance. Hello! We are using CSSModules!
She could not understand what the fuck is redux, why I need it.
It's super cool to work together.
Redux is a horrible solution for the problem it tries to solve. But at least, when it was invented, there was an actual problem to solve. In the cssinjs case, the problem doesn't even exist. It's just another way of making web development a bit more convoluted, retarded and broken. Whats going to be next, ascii in js?
Well, one could argue that everything global in css is a problem.
I hate css in js, but i like two solutions to this problem:
I'm exhausted with all the semantics around programmers and the different types. A developer learns to use the tools they need to get the job done and I think we've tried too hard to force specializations.
It's like a damn class system in an MMO. Everyone is so concerned about what is "best" and what is "right".
I never grasped this mentality. We have so many tools for a reason. Just like games. Sometimes I want Chrono Trigger for a great story and experience and sometimes I just want Kitten Cannon.
I feel like there's another component to the problem that honestly bothers me the most: the developers are way too dogmatic. For some reason we look at the world like our own point of view is the only one.
When we argue about CSS, we either perceive CSS-in-JS as the only right or ultimately wrong way (depending on the view). We can't accept that in a certain team, requirements or context one or another solution is more applicable than another.
For example, if the team has established a design system with well developed React components library, it will be a crime to build a landing from scratch ignoring the library. On the other hand, when the team has no or little prior experience with React and needs to quickly ship a marketing page, it will be insane overkill to use Gatsby only because everyone on Twitter says so.
I myself is guilty of getting it too far. I remember when I finally understood the concept of tests I came to the conclusion that there are the devs that write tests for everything and the ones that didn't wake up yet. When I'd meet a dev that doesn't write tests regardless of the context I considered them amateur. Now I work on my own business and write tests only when they are absolutely necessary.
I'd like to see developers became more open-minded and accept that everything in the world is relative and what's good for team working in the enterprise might be deadly for small team work on a pre-market-fit startup.
Interesting take on the topic! Personally I lean towards the JS-JS-JS side of things as I enjoy the sheer amount of tooling and enhancements that have been brought over to JavaScript, but I was on the vanilla side years ago just like everyone else. Although I wouldn't consider myself a CSS guru, I'm good enough to get a responsive layout going, and I find with styled-components in React this is much easier to manage (w/ effective code splitting) and modularize instead of a vanilla stack.
I will say that while I agree with many of the points you made, I saw a similar post labeling the other side of the frontend spectrum (the HTML-CSS-JS side) as claiming accessibility and design as their core focus rather than performance, which I think I agree with more. I would also bundle semantic markup into this as well as I know I do not consider this a first-class citizen when writing components for the first time.
Overall I think it's negligent to say either is more effective/efficient than the other since both sides present valuable aspects to building modern web applications. I'll list out a few of my thoughts on what is easier to implement (and maintain) on both sides:
HTML-CSS-JS:
JS-JS-JS:
Array.map()to generate content rather than hardcoding the markup, I'm happy)I like both. I wrote a blog post about it:
The "Backendification" of Frontend Development
Sorry it's so long, but people seem to like it :)
I try to get the best from both worlds. I'm doing a design system for my company using React and styled components via styled-jsx. I give styled components for React devs and a CSS file for web designers. IMO, devs trends to be very partials choosing one of two options instead choosing both.
BTW, you can try Astroturf zero-runtime CSS-in-JS. Compare to SC it has better performance and it generates a static CSS file, which you can give to web designers. Could be even simpler build system. And it has the same API.
Awesome. Thanks for the tip!
This thread seems to be on point, though on another aspect of this divide:
Thanks for the boost! To be honest, I kind of wrote that thread as a subtweet of this article (and of the overall "debate" recently more generally). I think that when we look at the "purely technical" questions we discover that everyone is trying to solve different problems, but there's ultimately no such thing as a purely technical question when humans are involved.
And then of course there's the question of whose problems are prioritized.....
Mind you, I think the OP has admirable positive intent! But I think that papering over the really nasty gender dynamics underneath all of these debates is unlikely to lead to a lasting "peace."
Thank you Betsy, I didn't know it was sparked by this. I feel like we're going meta now then.
Yesterday I was reading this thread
and today yours.
I wonder whether in 3 to 5 years your argument will be still valid, hopefully not but I might be a tad optimistic.
yeah, this is one of those things that you either learn or you shun at the risk of becoming one of those "rockstar ninja developers" nobody really wants to work with :D
Do you mean "prioritized by the industry/companies to be solved" ? Or do you mean something else?
You say "build tools are not well accepted in a modern CSS community" and that we should use linters, but people have been using Sass and Less for donkey's years, which are build tools that won't transpile if there are CSS errors.
So I'm not sure that's a problem.