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.
Top comments (25)
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 😂
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:
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.
Super great thoughts, thanks Alyss
We talking about a language that's syntax is basically this:
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.
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.
Don't forget that JavaScript has NOT been moving at all for years, and all this fastness is fairly new:
ECMAScript 3 was released in 1999, ECMAScript 4 was abandoned, and ECMAScript 5 didn't came out until 2009, with a 5.1 update in 2011.
It wasn't until 2015 that ES6 was introduced, together with stages and a yearly release cycle.
And a big-up to BabelJS as well, which I think is incredibly important for the fast moving pace of JavaScript. For more on this, check my post on Transpiling: dev.to/ardennl/what-i-talk-about-w...
Nowadays JavaScript is moving fast and has a stable release cycle, but remember that this hasn't always been the case.
About CSS, I have no clue! Something interesting to look into!
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.
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.
This is the correct answer.
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.
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
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.
a good answer to this question is another question "why would we need the css to move faster?"
Because CSS is already amazing the way it is, and we love it for that 💜