loading...
Cover image for CSS and JS Are at War, Here’s How to Stop It
Evil Martians

CSS and JS Are at War, Here’s How to Stop It

iskin profile image Andrey Sitnik Updated on ・5 min read

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:

  1. “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.
  2. “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.

  1. 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.
  2. 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.
  3. 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.

Posted on Jan 29 '19 by:

iskin profile

Andrey Sitnik

@iskin

The creator of PostCSS, Autoprefixer, Browserslist, and Logux.

Evil Martians

Evil Martians is a distributed product development consultancy that works with startups and established businesses, and creates open source-based products and services.

Discussion

markdown guide
 

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.

 

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.

  • I am JS-JS-JS person, mostly due to my hardcode backgrounds. I like "the code". Every time my wife is writing some JS - I am crying - so much better it could be. But she is not understanding me.
  • 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:

  1. TailwindCSS
  2. Svelte js way (and i think vuejs way as well)
 

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

:)

 

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.

 

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.

there's ultimately no such thing as a purely technical question when humans are involved

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

And then of course there's the question of whose problems are prioritized.....

Do you mean "prioritized by the industry/companies to be solved" ? Or do you mean something else?

 

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

 

I feel like there's another component to the problem that honestly bothers me the most: the developers are way too dogmatic.

Maybe but designers are also "quite" dogmatics.

Example:

<label>Customer</label>
<input type='text' style='width:500px' name="customer" />

A seasoned designer will look at this code and he/she will say

Even when it works.

 

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:

  • accessibility
  • conceptualizing cascading styles
  • low-level animations

JS-JS-JS:

  • modularization of components (this is my favorite one; no need to copy lines of markup, ensure you have them placed correctly, and ensure you have the right classes for the intended effect — yay props)
  • traverse markup and generate markup (any time I can use Array.map() to generate content rather than hardcoding the markup, I'm happy)
  • w/ the right build tools: code splitting and tree shaking
 

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.

 
 

I don't understand that split. A web developer should know how to develop a simple application using HTML, CSS, and JS in the same way as a WPF (aka Windows Presentation Framework aka Mono's Bane) developer should know how to make a simple application using XAML and C#.

 

There is no such thing as UX developers. There are only UX designers, and they are nothing compared to a typical developer. Their thinking process is way different than a dev's. And I'm saying this from experience.

 

The solution should fit the problem. Right now, I'm building a web app that is very user interaction driven, and using React and css-in-js for that because the CSS needs to be very dynamic. Then I'm also building a blog to support this web app, and the primary concerns are initial rendering time and meta tags for social media. So I'm building a server-side rendered app that's traditional HTML, CSS, JS. The solution should fit the problem.

 

I am 100% into the idea of a 'front end' conference! Any developer working with the front end should know some UX and marketing-tech basics, IMO, in addition to the tech we build the sites with; even if it's a static site! Expanding a 'front end' conference to include marketing and UX/Design talks makes a lot of sense to me. (Even if that might be a step further than you were thinking.)

 

Hi Andrey, do you mean by "UX developers"? Why not to use term "UI developer" regardless technology, whether it is JS, CSS, SVG, pure HTML controls, WebGL, Canvas or QT? After all business or end user doesn't care about tech.

 

I do not support this label at all. The idea, that it is a fake label and real developers mostly bigger that this separation.

 

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.

 

Some people are great at both things, but we still see lots of "mainly CSS devs" that simply can't / don't want to get into the JS heavy stuff, as well as "mostly JS devs" that are new to front end (either new to programming or coming from desktop / back end) that can't grasp the most basic CSS concepts.

But I don't they they are to blame. Sure, some have that "CSS is below me" attitude, but for the most part, the actually want to learn it, it's just that it gets really hard to find a decent source.

Most bootcamps, courses and resources out there barely burns through CSS from a "quick results" approach, sometimes even deferring to bootstrap, instead of teaching the core concepts.

CSS-in-JS is great, but it also allows this kinds of devs to mostly get away with it... until something fails and they bash CSS for their own flaws.
But the industry is in such a great demand for JS (mostly React) devs that they get really good jobs with great salaries anyway. Some companies proud themselves on "our designers make their own CSS", which is exactly just as wrong.

And that's the real issue right there. HTML, CSS, a11y and all that stuff requires a completely different skillset than "real programming", as well as different from "actual design". So most devs don't feel like CSS should be their responsibility, and neither do most designers.

JS is mostly about logical intelligence, HTML+CSS mostly about linguistics intelligence, and actual design (as in working with graphic tools) requires visual-spatial intelligence.

Some people are great at all of them, some at two of them, and some really shine in a particular one. But unless we start recognising the differences and respecting the role of whoever makes the HTML + CSS, we're gonna be stuck in this war.

That and actually providing decent sources for CSS learning, that get deep into the theory instead of pretending people to memorize a gazillion (and ever growing) set of properties

 

People who specialize in different things have especially a lot to talk about. I highly recommend for backend devs to go to frontend conferences, and vice versa.

 

Very interesting article. I can say I'm the kind that loves both CSS and JavaScript, gonna try linters!

 

I don't know. None of it rings true to me but maybe I'm missing out on some larger experience. My take:

 

I don't disagree, that's why I go into a lot of other skills the define programmers in my book. People who code Web apps and people that code drivers, share more in common than they have apart.

 

What is it with some developers that they value their opinions about how things are supposed to work more than the languages and libraries they are supposed to work with?