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 particular I liked how I could author a SASS file that was still entirely vanilla CSS and it just worked. And I could then sprinkle in things like variables and nesting only when I needed.

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.

Peanut Butter & Chocolate

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 what they push to the browser is HTML/CSS/JS.

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.

Or are they…

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 xhtml 1.1 more than html5. The very fact that you couldn’t use a normal semantic inline SVG due to JSX limitations (Reacts version of markup) just added to the feeling that React was designer hostile.

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 I just like beating up React I don’t, I just want to see it improve. React gets the attention because it is widely considered the most popular modern way to write a UI for a web application and it deserves the fame it has. It is a brilliant and amazing thing to work with. React was pitched as a way to write web components and what is a web component without CSS. The fact that React was so popular despite having no great way to write scoped CSS shows just how great it is as many were happy to overlook that downside.

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.

Enjoy the Vue

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 work in very similar ways but by allowing experts who write a lot of markup and CSS to continue to do so in a way they have spent decades learning to do is very smart.

I am still holding out hope that React finally gets an option that looks like Vue’s offerings. Realistically it will be the tooling that saves the day as it will auto convert all of my carefully crafted SVG’s into something JSX doesn’t lose its lunch over just because I didn’t camel case the “view-box” attribute.

Is it safe yet?

In reality, CSS in JS today is just yet another form of applying new tooling to how we write our front end markup and styles. As the tools improve it will feel like just another way to improve how we maintain our code.

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.