Echo JS 0.11.0

This is not a pure JS article, but in the end I discuss CSS-in-JS solutions, and given their rise, I believe it is one of the most important ones.

I personally still recommend for pet-projects go with just CSS-modules and some preprocessor – tools are not there yet and this combination will be for sure a good choice in couple years, but keep an eye on JS solutions, because they are developed on a rapid pace.

It's a great article and very good to be aware of these risks. It's always fun to see hacking examples. 

I sure hope it's not a "few years" though before css-in-js solutions become best practices. The pace of some things in webdev is super fast and the pace of other things is super slow. I also have been still recommending css modules, but have really been hoping these tools are fully ready, like, tomorrow.

On a side note regarding things that progress slowly, I still find it ridiculous how horrible performance is in the browser with the DOM, yet you can use JS in React Native for far better performance. It's time browsers get a high performance API. Keep the old APIs, but build a "virtual DOM abstraction" that completely skips the DOM. No more DOM. It stands to reason you could code React Native style code in a desktop browser--and if the browsers directly supported it--it would perform far better than React Native itself! My hunch is web assembly still isnt the answer. It's still predicated on the fact that the DOM and its dom/paint/layout engine is there. We need a whole other engine.

> I sure hope it's not a "few years" though before css-in-js solutions become best practices.

On the contrary, I think CSS-in-JS is quite short-lived. A temporary patch before Web Components become widespread.

> Keep the old APIs, but build a "virtual DOM abstraction" that completely skips the DOM. No more DOM.

The DOM won't go away, there are 25 years of backwards compatibility to support.
And the concept of Virtual DOM isn't the "ultimate thing" of web development. It's not terribly efficient either. The real game changer is the stateful UI.

> It's still predicated on the fact that the DOM and its dom/paint/layout engine is there. We need a whole other engine.

There already is one: it's WebGL. Hard to develop with it? Well sure.
But given that engines improved *a lot* in the past years, why do you *need* all that speed for?

I'm not saying make a virtual DOM api. Make the react rendering model "THE API." And without JSX--just pure JS.

Also, 25 years of backwards compatability doesn't need to go away. They can build it into the browser as an option like WebGL. But it must support SEO, have a more efficient rendering engine like an iPhone app, and under a simpler API (similar to React). 

..In my estimation web components will never become big. Maybe something else like it. And browser folks are working on another "web component"-like model that truly gets it right by the way. And ultimately that's the point. So in general, I agree. Something truly "right" and high performance should takeover here. 

It's not one or the other--the 25 years can stay, it's gonna have to. But websites should be able to perform as amazingly as React Native does by now. The performance is horrible. You can't build animation heavy stuff like you see on your AppleTV or FireTV without encountering much jank, bar WebGL which isn't the right API and doesnt offer SEO. The best API to me is React. To others it's Vue. In terms of actual app building productivity, Web components falls short of both by a long shot. So that's its problem. Let's not marry ourselves to yet another crappy API when there are clear and far better alternatives.

> A temporary patch before Web Components become widespread.

Maybe, but there is still no standartised (and widespread) way to communicate between components, and therefore, no way for convenient composition -- and it is crucial.

And regarding engines, I don't know too. WebGL does not have any SEO, so it is no-no in modern web, unless you want to do some very specific app. To be honest, DOM and CSS layout are not that bad, so I think eventually the most convenient engine will win (maybe even they, just with more convenient APIs).