Hello folks, its not standard for me article, as I prefer to not get into these kind of discussions, I know this topic is very hot, and opinions are very divided.
What I want to focus here is some workflow change we have because of the CSS in JS. I have lately worked with a project where some CSS in JS was in use, also there was TypeScript and React included. We had in the project person whose responsibility was the part of CSS/HTML, it was kinda - webmaster, I even don't know how to name such person in the current terms, for sure FE engineer focused on CSS/HTML, for sure good in it. To the point, he was struggling with CSS in JS, he was not able to work efficient, he needed to write functions, write TS types, pass props, do standard coding. He was great in CSS, he knew the staff, he was in different level there, no comparison with my skills in CSS land. But amount of calls, amount of trouble in writing his part was tremendous. It was not a great experience for any of us. And interesting is, as I supposed its not very original experience, I found at least few developers who had the same issues in different project, I assume its just common thing.
My background is quite old, as when I was doing my first web-apps, HTML was generated in the server, there was separation of concerns in terms of technologies, we had HTML/CSS/JS separated, there were disadvantages yes, there were issues in terms of possible overwriting not related parts of the view, as CSS can modify everything in its global scope. But... we could have people who were responsible for the view part, they didn't need to know if the app is in React, Angular, Vue or any other. They have seen the output, they had style sheets, they just could work fully individual. Now they can't, now all devs needs to do HTML/CSS/JS in one time, and sorry not only that, add to it React, Vue and any other super-trendy framework, and you say why not, they should? I say - do you know CSS is turing complete language, do you know it is complicated language and in order have expertise in it you need years of practice? And do you know TypeScript type system is turing complete on its own ? Do you require the same efficiency of all developers in all 3 or even 4 languages in the FE side?
There are many things which are hard in CSS/HTML land, this land is complicated by itself, no JS/TS included.
We lost something, we lost possibility to share the work for people with different experiences and focus in the FE. Why somebody cannot just style the page? Why?
What is your opinion here? Maybe you have different experience? Share your thoughts in the comments.
Top comments (30)
I think that CSS in JS is almost always the wrong answer to a question nobody really asked.
Yes, we've lost something.
Most JS frameworks are going back to the days where we put php and html together and a file with everything mixed up! So it was natural that they wanted to put the css in there ...
Speaking as a web developer who likes to guarantee access for everyone, I think that processing styles with js is a waste of performance, battery and time!
The one exception to this, that I find great pleasure in using, is the approach used by Next.JS: styled-jsx. It is basically scoped style tags in the context of React components. It supports everything that you would expect from CSS as well: media queries, etc.
Exactly
This is just a trend. Trends comes and goes. Someone important enough to change course will re-discover sooner or later that JavaScript is pretty lousy language to build around and SPA is not good for everything. Instead maybe it is good to have multi page applications and that way follow w3c standards.
But until then I have to love Angular, Vue, React just like did love before that Web Services, XML, XSLT, dHTML, jQuery, C#, Java etc...
Your answer has got the most likes, congratulations, but I think you've got it all wrong. Here's why:
Fashion trends just come and go, but technical trends have a reason for why they come. They almost always solve a problem we had with the previous technology. Such things won't just fade away like a fashion trend. You either have to come up with a better solution or render the problem obsolete.
Speaking of "someone important enough" sounds like a conspiracy theory, in which there's a hidden puppet master controlling all the technology being used worldwide. Nothing can be further from the truth. Compared to other business sectors today's open source driven IT landscape is probably the most democratic place in which everybody has the chance to succeed with a new technology just by showing everybody else that it's better than the rest.
Javascript has been laughed at when it came out, yes, but it seems like it isn't that lousy after all, now that (the single focus on) object oriented programming is not king anymore. Additionally JS has been "upgraded", making it one of the easiest languages to implement async programming.
SPA vs. multi page application doesn't match the author's question whether to pack HTML and CSS into JS files; you can very well put each technology in separate files when programming an SPA as you can see in Angular.
However I agree that including the CSS stuff into component oriented programming leads to a conflict between frontend developers and designers. We see a growing specialisation in all IT roles, so the need to come up with a workflow that decouples the designer's and the developer's workflow like it was when you could write all CSS code in a separate css file. Maybe we'll see these again if we accept that having a single CSS namespace is not as bad as forcing designers to learn JS.
Unfortunately IT is not driven by the technology quality, despite open source. Just like any other sector it's heavily influenced by the marketing and advertising campaigns performed by large companies. This is the reason why, for example, technically inferior solutions like Spring flood the market. Or zero real value dummies like Kotlin called "next big thing".
While I totally agree that IT is one of the most democratic places, I also realize that such a democracy is quite easy to affect and drive into necessary direction for those who has enough resources.
Hey, i'm late to the party, but could you explain why Spring is a technically inferior solutions ? And inferior to what ?
I'm not trying to annoy you with this question, I'm genuinely asking.
Spring:
Any of the above might be a sign of technically poor solution, but Spring collects them together and this indeed an achievement.
Spring is easy to start writing app, but at subsequent stages of development this is compensated by:
As a consequence, almost all Spring applications share the same properties - they are slow, consume a lot of memory, are hard to maintain and extend.
As for your question about "inferior to what?". I'd say that it is inferior to almost any alternative solution in each particular area. Lets take a look, for example, at core of Spring Boot: Spring DI and Spring MVC.
Spring DI is the slowest DI container. It even unable to complete all tests in the following benchmark github.com/greenlaw110/di-benchmark.
Spring MVC is one of the slowest among Java web frameworks: techempower.com/benchmarks/#sectio... Note that this is not a fluctuation, Spring is consistently lands among slowest through all tests.
Thanks for your extensive response !
I think I didn't work enough with Spring to be aware of all of this, except maybe your point about "Spring magic", but thanks again :)
There are many pros and cons to CSS-in-JS, but I believe it goes way past opinions and pros/cons, into neurodiversity territory.
CSS-in-JS is great at making CSS work for the JS-minded, and I would recommend it (preferably in some zero-runtime form) whenever the team is comprised purely by programmers in the traditional sense of that word (i.e. imperative programming CS background). Which is what most teams currently are, as there has been a ginormous shift from desktop and back end tasks into the front end, which made many of those devs switch as well.
Having a CSS expert in charge of the styling, I'd have let them choose whatever architecture they felt comfortable with. It'd let each shine in their own craft.
We can discuss all day if CSS is a programming language or not, but at the end of the day, it's more "language" than "programming". It is very, very contextual. Therefore, it relies primarily in verbal-linguistic intelligence rather than logical-mathematical one.
I've seen quite some companies trying to recruit programmers with claims such as "our designers make the CSS", but that approach is equally wrong. Designers, as in "people that work primarily with graphic tools", rely primarily in visual-spatial intelligence, and will probably struggle with CSS just as much as programmers do.
Each role has its requirements and work with completely different mind structures. Sure, you'll find some folk that can do both, and the occasional unicorn that can do it all. But trying to force someone into a completely different way of thinking usually doesn't end well.
CSS-in-JS can be a bit like trying to drive a screw with a hammer. It'll get int there, but you'll end up with bashed walls and swollen thumbs.
Personally, i think CSS-in-JS is fine but you've got to be a lot more careful when writing it. Inline styling is very easy to use but too much of it makes the code very hard to read.
The biggest benefit i've seen from CSS-in-JS is very easy bundling so that when a page loads, you're loading as little as possible.
You can also do some mathematical equations/variable manipulation which is just impossible any other way. (with a template engine you might be able to do stuff inline, but it's horrible to do).
It's up to the developer to write it correctly and it's very easy to get wrong which makes it harder to read and code around. The benefits are great but it's by no means the only way to write css.
Another great alternative is using a Utility Class library - something like Tailwind, which almost entirely removes the need for writing your own css (but that is a very different approach).
Or you could just use classic css or scss and write a really well defined webpack file to handle bundling. The great thing is, we have loads of options now.
I agree partially to this blog post. I will try to state my points clearly.
Yes, CSS in JS (assuming styled-components here) is big pain point when it comes to styling smaller projects since it adds the unnecessary boilerplate or defining components for small style changes(margin,padding...etc)
The benifits of CSS in JS really kick in when the application scales! Rather than having to put in a dozen of styles (intent, size,color,shape etc. you get the point) you can have the component adjust to props instead!
Also themeing is a major reason to choose CSS in JS because you can have a root level variable map with different values rather than having to maintain a million classes!.
All the styling is local, so there is no situation for style conflicts.
To conclude, CSS in JS is unncessary and more often annoying to style small apps, but the benefits really kick in for large web apps that have a complex design system in place(custom components, themeing, reusability etc)
PS. these are my 2 cents on the topic, yours may wary and I respect that.
In our pursuit of abstracting the web, we've definitely strayed far from the path.
The original point of being able to write Javascript and run it everywhere was to provide simplicity. We are trending in the opposite direction now.
Programming and computer science really haven't changed that much, but we've forgotten some of the old tried-and-tested rules on building effective solutions.
Two that come to mind immediately are KISS (keep it simple, stupid), and SRP (single responsibility principle).
We're breaking long standing rules in order to massage JS into doing things it really was never designed to do.
The technical debt is piling up.
I feel the same way when I as programing newbe sees js everywhere. I always thought that every language had it's own up and down sides and usage depends on context.
Why somebody cannot just style the page? Why?
You nailed it. I've avoided css-in-js till now, because I've seen no evident advantage. I might explore it sometime to see what it's all about, but forcing CSS/HTML people to do things in JS is indeed a whole new problem, and as someone who has been building websites for 20 years, I fail to see what problem this new problem is solving.
Lots of people here mention CSS-in-JS as though it is a new language. CSS-in-JS is still CSS, there is still cascading, inheritance and everything else you know (and don't) with CSS. CSS-in-JS solves some specific issues with CSS, but there is no getting around the fact that you have to know CSS to write good styling
Hence why I am more of a vue guy. It has figured CSS out at the very start. It's part of the framework and it follows much of the traditional approach.
I was lucky enough to teach vue to some backend devs/junior devs in the past and that moment of epiphany kicked in very early for them.
I think it's very important working alongside people who are not JS/TS developers to remain that sense of awareness and keeping the complexity down.
Great write up!
Was Brendan Eich wrong that invented JavaScript? No.
You like it, you learn it and use it.
Your CSS guy clearly overestimated his abilities and didn't prepare to work with new technology.
Being humble is also a skill. The one that many (sometimes great) engineers lack the most.
Interesting take. Did Brendan Eich invented JS in order to make stylesheets in it? I don't think so. It's totally not about being humble, this person was trying to get it, and this trying was a burden for the whole team.
New is not always better.
Not saying that CSS in JS is wrong but as every abstraction it has costs, and this is one of these costs.
You speak of humility while stating that the CSS guy should learn Javascript to do his work. Interesting.
Thanks for the comment but you don't know how to read my child. I am writing about not my own experience in writing css by experience of other people who are forced to learn React with TypeScript in order to style the page. I was working with Css in JS and it is nice experience from perspective of the person who is focused at data/logic part, but it's hard to share part of the responsibility to person who is CSS expert only. All ideas and abstractions have some costs, and saying something is perfect is just wrong.
Ok. Looks like you know more about me then I know 😉, I also admire your imagination. Your LoLs and how you speak is enough for me. I believe it's true that you like and see no issues with this technology, but next time you can focus more on valuable arguments instead of personal insult. Nevertheless have a good day and chillout.
Heyo thanks for that post. I was in the exact same situation. I learned react, typescript,next, css in js, jest and all that ecosystem around just to conclude, that this is the wrong way.
There are for shure benefits to pack everything in one language, but it feels unnatural.
I also do backend dev and there the devs are seperating everything in microservices😂 They learned from the big monolithics. Thanks to docker, we are able to develop services in the best available language. c#/nodejs/golang.I like the mix, which vue and svelte provide. one file for components but you write the native language for style/markup and behavior.
Just my humble opinion.
Here we are: Back to separation of concerns.
When developers discover there are other people working with them.
;-)
CSS-in-JS is hurting our environment for the sake of developers lazyness. Don't do it. Don't be a tech-bro, be a tech-hero.
Many style related problems cannot be solved with CSS alone; unless you try very very hard, but in the end who cares. Four extra CPU cycles won't make any difference on anyone's device anymore.
It does. It may be four extra cycles for a user of one project. Now multiply this by all users across all websites that use this technique.
It is not about the developers benefit or the users benefit, but the mass that has a huge impact on our environment. The web is already damaging our planet extremely. There is no need to make it even worse by making work for devs "easier" but hurting our planet.