In the past, I haven’t really been a big fan of trans-piling one language to another. It always gave me nightmares that the pseudo languages I would be coding with might one day break and my knowledge in what the browser was actually interpreting would wilt. HAML, Jade, etc weren’t really my thing and they didn’t seem to offer me anything that I wasn’t already doing by just knowing actual HTML.
Over time that disdain for not coding in the vanilla languages started to wear off and I did start to enjoy the perks of SASS. In
This has been my preference to this day. I prefer to write my code in the vanilla languages of the web (HTML/CSS/JS) but if there is tooling to improve the maintenance output of the code in a way that saves me time, I am all for it.
CSS and JavaScript are two of the three pivotal components of any website. It doesn’t matter what languages a given site or app use behind the scenes. At the end of the day
But CSS and JS have often been separate disciplines for many front end designers and developers. The resilient nature of CSS and its purpose on a website is quite distinct from the traditionally “optional” scripting that Javascript brings to the table.
I think this gets at the core of the online drama over this concept of CSS in JS. There is a rather sizeable group of people who are great at CSS and know it well but aren’t comfortable writing JS that often and a group of Javascript programmers who aren’t great at CSS and just lean on existing libraries like Bootstrap. And now it would appear to some that the Javascript group is stealing the CSS machine and tinkering with it.
I think the CSS in JS thing got off on the wrong foot when React started to take off. The initial version of CSS in JS in React components was horribly ugly and unmaintainable versions of camel-cased JS objects that looked vaguely like CSS properties that were placed as inline styles on every single element. Anyone who writes a lot of CSS will tell you that is a really bad idea. And if you were a CSS author trying to get in on the hype train that was React it felt like someone just took your luggage and set it on fire.
Ok, it’s not a great analogy. The point is that the hype surrounding web components combined with the introduction and rise of React created a world that was proposing writing front end code that went against decades of good CSS best practices. Inline styles, onClick actions in the markup, JSX looked like
In Reacts defense, anyone advocating for React wasn’t asking everyone to really write CSS in that quirky JS object way. It was only what you had to do to scope your CSS to a component. And those onClicks I mentioned actually do get transformed into event listeners at build time. The JSX quirks though, those are still very real, and very annoying but that’s another post for another day.
Now before anyone thinks
Thankfully, many passionate people in the React ecosystem knew component scoped CSS needed a better option and have since come up with new ways to write CSS in React that didn’t demand your veteran CSS authors learn all new CSS properties just for one application library. Emotion and Styled components have come along and have gotten us much closer to a more ideal working scenario. And I’m sure things will continue to get better from here.
Now if only they would figure out all those JSX quirks.
One thing that is noticeable is that no one is pointing the finger at Vue JS in this drama, or at least not much. Some say it’s because it doesn’t have as big of a user base or because it is flying just under the radar. I would argue that Vue did things correctly from the start by letting your HTML look like normal HTML5 syntax and your CSS look like normal CSS all within your single file components.
Vue and React both
I am still holding out hope that
In reality, CSS in JS today is just yet another form of applying new
Should you worry about CSS in JS? No. But its worth keeping an eye on what the JS experts are doing to keep them honest when they try to implement CSS.