JavaScript has always had warts that people put up with—but recently it has evolved a lot and really started incorporating more powerful features. ...
For further actions, you may consider blocking this person and/or reporting abuse
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 💜
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 :-)
I see a lot of well thought out responses, I just want to remind everyone: CSS is a markup language that can be made programatic through the pre-processors and compilers like Sass. A lot of stuff like animations used to require javascript to accomplish them, just like HTML DOM manipulation used to require jquery or it was too much effort to accomplish. I think we don't see rapid and massive change because it does what it needs to do, and has been in a good place for 8-10 years. Same reason we haven't seen a push for HTML 6, there's not a significant pain point to address, whereas javascript has a ton of pain points that every developer/company/person with an opinion has a different idea on how to solve and no one agrees on what the biggest problems are (or even what the problems are). Long story short: CSS does what it's supposed to, and there's not a huge need for it to do more. CSS frameworks all work the way we need them to, and there's no real driver to change them.
People like building weird thing with Javascript, so they are constantly finding its limitations. At the same time, CSS is advancing, but browsers aren't really following. There's lots of cool things that cannot yet be used because of browser support; if you want your stuff to work on IE not even
display: flexis really viable yet. I've been waiting forbackground-filterto be a thing for almost a year now, and it's still only supported by safari and, ironically, edge.First of all, I think we need to challenge your question: does CSS really evolve slower than JavaScript? Recent major developments (Grid layout, Flexbox, Picture specification, Houdini...) have radically changed the way style sheets are produced today. So I think CSS is evolving very fast.
Some may consider that the language itself scarcely evolves. But compared to JavaScript, the language is incredibly simple and above all, its interpretation is blazingly fast. JavaScript code has an incredibly high cost of parsing and interpretation and we are very far from being able to do the same thing in JS and CSS with the same file size. IMHO, the simplicity of CSS is its strength.
Yes, CSS is moving a bit slower, but not necessary on another route than ECMAscript. PostCSS is CSS' direct equivalent of babel, especially for supporting upcoming standards, but also for easing the use of existing ones.
There are a lot of upcoming CSS4 standards supported by postcss-cssnext: cssnext.io/features/ - some of them already working in the most modern browsers, others only usable with some workarounds. The one I'm most eager to see is nesting (tabatkins.github.io/specs/css-nest...).
What wonderful timing. Someone brought this up at work today, saying CSS is broken because it moves "too slowly". But wait, weren't we all complaining about how unrealistically quickly Javascript was changing just a year or so ago? Front end fatigue and all that?
This comments thread is such a great read though. And I agree with @Yechiel Kalmenson, perhaps the more interesting question is to try and understand how JS has gotten to a place where it can be in such constant evolution.
I'm a huge forever-fan of CSS though and I'll always argue that those who turn up their noses at it for whatever reason, probably haven't taken the time to really learn how to use it.
Can't speak to any larger trends, but the bottom line for me is twofold:
I think JavaScript is moving so fast it makes the movement of CSS look slow. There has been movement of CSS (CSS3, grid, flexbox, transpilers galore) but not as fast as JavaScript. JavaScript was kind of reborn when Node.js hit so there was huge enthusiasm, interest and movement there but CSS hasn't had a Node-like event.
Fortunately..
CSS is limited by Browser
But JavaScript, if limited by browsers, there'll placeholder/polyfill.
I've had the exact same question, but with HTML.
May be it’s tough 😐😐