Why doesn't CSS move faster (like JavaScript)?

JavaScript has always had warts that people put up with—but recently it has evolved a lot and really started incorporating more powerful features. And babel means it's pretty reasonable to make use of the new hotness.

My question is—Why isn't css going this route more? With canonical bleeding edge and mainstream transpilation options that make this a good choice.

I'm aware of CSS transpilers, but they're all sort of their own thing. They are not necessarily moving things forward the way JS seems to be.

I may be off-base with this whole idea but I'm curious about the topic.

Comments

[Yechiel Kalmenson]

I think the underlying question is not why is CSS moving slow, it's how is JavaScript able to move so fast.

I don't think there's a single language/ecosystem out there that's moving as fast as the JavaScript ecosystem. You blink and there are 3 new frameworks 😂

[Alyss 💜]

This is all speculation on my part, but some of it has to do with the history and intent of JavaScript and CSS. Developers have a penchant for JS more than CSS (at least by appearances). I find I'm more likely to come across someone with JS expertise, despite CSS offering plenty of elegant solutions.

Prior to ECMA, there was no real JavaScript standard. There's plenty of posts about the history of JavaScript, so I won't go into too much detail there. The main point is that JavaScript ended up in such a complex state because of its use on websites (compared to server-side languages). First, you can roll-your-own JS package, then creation of frameworks becomes more accessible. It follows a similar structure to programming languages that came before it. Even when vanilla javascript doesn't support a piece of functionality, it does support building the functionality on top of the existing tools. ECMA can observe and implement the most prolific ideas.

CSS is too often neglected, but it also has some beautiful compilers and libraries. If compilers are so useful, why don't more flavors exist?

Creation of a new tool or framework or compiler requires:

• Time
• Impetus

I normally see new JS frameworks come out of big companies like Facebook. A team is given time to create and maintain it. Bootstrap came from Twitter. But how accessible is it to build functionality on top of vanilla CSS? Not very.

The incorporation of new ideas to vanilla CSS is done by the CSS working group, but they don't get the same exposure to the creativity and community implementations that occur naturally in JavaScript. Some cool new things are coming out though (as soon as browsers add support), like variables and snap scroll.

P.S. this was a total brain dump after a long day. I'm sorry for run-on sentences or poorly explained bits.

[Ben Halpern]

Super great thoughts, thanks Alyss

[István Lantos]

We talking about a language that's syntax is basically this:

.selector {
    foo: bar;
}

This language is just slightly more complex than a TOML or an .ini file. Like a key-value store, just with enough syntactic sugar on the cake to f*ck it up if you want.

Of course it will evolve slower. I would say it's "standard library" have some pretty neat new elements (like flexbox, grid, calc() and basic variable support) that's fairly new and gives you lot of opportunity, but they worth nothing until the browser doesn't support them NATIVELY, because there's no anything that you can transpile it back, only if you hardcoding the variables into the final build, but again, that's bigger file size, not a native solution (I think everyone's final goal with CSS would be to have more complex UI with less filesize like some frameworks).

CSS cannot offer a new built-in Bootstrap like solution every new year also, because the people will have the same fatique like Javascript developers.

I think the CSS at the current state is fine and the extensive languages (like Stylus) is fine too. You have options, if you want something more complex.

[Ali Spittel]

I think that CSS has focused on adding styling features rather than language features. Flexbox, grid, variables, Houdini etc. are huge in terms of making design easier with CSS.

I think the basic syntax of CSS is pretty great -- it's super explicit. I could see it adopting some of the awesome SASS/SCSS features in the future (like looping), but that could be difficult to implement in the browser.

[Meghan (she/her)]

There's one key feature that I see JavaScript have that makes this possible. JavaScript has the very unique feature (hailing from being dynamic and loosely typed) in that developers can make polyfills. Between extending prototypes, writing new functions, backwards-compatible transpilation, and more, it makes a project like Babel possible.

CSS on the other hand is very not extensible. Or at least yet. CSS Houdini brings some promise, but this is brand new and not actually possible yet in any browser. Due to this lack of extensibility, pre-processors have had very little wiggle room in the land of the amount of features they can add. We got nesting, we static variables, we got mixins, but still no parent selector.

[Michael De Abreu]

I forgot about Houdini, but I had read about how complex it is to develop a CSS polyfill compared to a JS polyfill.

I think this is one of the most important features about JS moving fast. Right now you can use transpilers, for sure, but for the things that are not already implemented, then you have a good polyfill waiting for you. (Web Components, to say something). I hope with Houdini API developers that do CSS polyfill have a better work, and can implement new features faster.

[panta82]

This is the correct answer.

[Alexander Kluth]

I like that CSS stays as-simple as it is. JavaScript is moving too fast. The whole JavaScript ecosystem seems to be running blazingly fast on a hype train. It's nearly impossible to find a solid route for newbies to follow.

CSS is just what it is: CSS. Of course, there are less and SASS, but compared to JavaScript this is still just simple, clean and easy to follow.

And no, this is not a baddy-maddy JavaScript hate post. It's just my opinion mixed up with the opinions of other people who told about their experience - especially the new one's to the business.

[Miff]

It seems to me that a lot of what made JavaScript move so fast is polyfills. Sure, there is CSS transpiling, but it's not as just "one and done" as

<link rel="stylesheet" href="//cdn.example.com/cquery.css">
<style>
    .roundybox ${ border-radius: 1em; }
</style>

We were able to use jQuery and the like to fill around the gaps until browsers had a consistent implementation of things like XMLHttpRequest. There is no pure-CSS way to do something like that though.

[Vincenzo]

a good answer to this question is another question "why would we need the css to move faster?"

[Max Antonucci]

Because CSS is already amazing the way it is, and we love it for that 💜

[rhymes]

Could it also be the fault of frameworks + resources allocation in companies?

My experience here is that companies doing web apps have backend developers and designers but frontend devs are a rare breed. The ratio designers / backend devs is also not in favor of the designers.

Which means that those web apps start as prototype using a framework chosen by such backend devs who adapt the mockups / wireframes coming from the designers. So they pick up "Bootstrap CSS classes" or "Foundation CSS classes" or "Bulma CSS classes" plus maybe a bit of SCSS to structure the files.

Any reference to the author of this comment is purely fictional :P

So, in many cases, frameworks are enough and this doesn't really foster the development of the actual CSS.

It's in now way a justification on my part but I have no idea how to create a flex box website or a grid website from scratch but I can create a website using a framework like Bulma that uses flex box underneath.

So devs and companies contribute to the slow growth of CSS :D

ps. that's also why there are so many lookalike websites that an experienced frontend dev would never sanction let alone create :-)