| > I'd love if you could point to any relevant mailing list/google groups discussions or whatever around this time I heard about Web Components spec in late 2012. There are some blogs from around that time: https://hacks.mozilla.org/2013/05/speed-up-app-development-w... In five years not much has changed. > Yes! I often have to work with multiple frameworks. There is an easier solution to this than Web Components - using a single framework. Unless you are a consultant same as me, than we can only blame ourselves for having to deal with this. > My point is: The fact that anyone can write them means that there'll be a sort of evolutionary competition That's not what happened with React component libs (material-ui, react-toolbox, etc.) - none of them has "won", all of them are pretty similar in quality. I would say that quality of a component is less important than how easy it is to adapt them to your business needs is. My point is that having more ways to create a component is irrelevant - Framework churn existed not because we couldn't share components, but because writing components and managing state was awful. Web Components are still terrible at both of these things. The good thing is that there hasn't been any new JS innovations in three years since React, Cycle, Elm, ClojureScript boom. And I would claim that there is not going to be because we are limited by the textual representation of our programming language. So the Framework churn ended not because everything is perfect, but because we couldn't make UI development better. |
Yes, we all know how easy that is. I mean, really, come on -- that's not realistic in any reality.
EDIT: We all know the "n+1" standards XKCD joke, but the reality is that standards (HTML, CSS, HHTP, DNS, TCP, UDP, IP, etc.) brought us the fucking Internet, flawed as those standards may be. As I said, I'm cautiously optimistic that standardizing "custom DOM" will eventually get us to a standard slightly above raw HTML.