[masiulis]

> How on Earth do you figure that?

We were discussing Web Components at the time the Angular was getting popular and before React was even released.

> for non-browser developers to ... have those components work just like native elements

Honest question, how do Web Components help native developers in any way? Because from UI devs perspective, Web Components are useful only in a single edge case - when you must make sure than it's impossible for Cascading Style Sheets to cascade to your component.

For a developer, Web components are solving problems that almost no one has or that were solved better by React and Vue.

[lomnakkus]

Do you not count e.g. jQuery as a framework? Angular and React are also pretty late entrants. Before that there was Backbone, Ember, etc.

> Honest question, how do Web Components help native developers in any way?

Being standardized, i.e. any old framework that can work with the DOM can with them, i.e. it reduces the number of truly necessary components to an "N" problem instead of an "NxM" component. Simple as that.

(Let's say we're looking for a "scrolling/sortable table" component. N is the number of different components along the 'features' axis. M would be the number of frameworks (Vue, React, etc.). It's a massive waste of resources that M > 1.)

EDIT: Yes, frameworks will still be around and that's fine.

[masiulis]

> Do you not count e.g. jQuery as a framework?

Not really, it was used as a library to make JS work consistently across browsers and add missing features like querySelector and ajax fetch. But it had no opinion on how you should structure your app.

Angular, Backbone and Ember is from the same post-jQuery era when talks about Web components started.

> Being standardized, i.e. any old framework that can work with the DOM can with them

But does a developer really care that it's possible to use the same component in different frameworks, when you need it to work with just one (yours)?

I think the biggest fallacy is that people expect a technology to appear where you could just drop the component and it would work perfectly. From my experience, that will never happen - external component libraries are 90% what you need and 10% of hacking around missing features. The easier it is to safely and predictable hack the last 10% the better the framework/component library is.

Web Components provide nothing that help in UI development:

Helps manage multiple components state? Nope.

Provide a declarative API for components? Nope, imperative - the one we are trying to get away from.

Prevent CSS from affecting components? Cool, or I could just not write global styles, use BEM or CSS modules.

Easy to share components? NPM still works just fine for that.

> It's a massive waste of resources that M > 1

Agreed, that's something I thought a lot about. So I have created a cross-framework visual component editor - one component exports to many frameworks: https://github.com/UgnisSoftware/ugnis

[lomnakkus]

> Angular, Backbone and Ember is from the same post-jQuery era when talks about Web components started.

Really? Maybe I was just out of the loop. I hope we can agree that Web Components were little more than a gleam in somebody's eye at that point, right?

(I'd love if you could point to any relevant mailing list/google groups discussions or whatever around this time, because apparently I missed 'em.)

> But does a developer really care that it's possible to use the same component in different frameworks, when you need it to work with just one (yours)?

Yes! I often have to work with multiple frameworks. Also: It'd be fanstastic if I had a choice matrix of "N" vs. "MxN" when I had to choose an implementation of, say, a scrollable-live-loading-table. That would be amazing, especially since we'd already decided on the "M" axis and written 20k LoC! I could choose the very best feature set for me! Ok, I might have to write a thin "shim" to have it interact with React or Vue.js or whatever, but the point is that this would be a trivial shim. I wouldn't have to rewrite the whole frontend when $BOSS decides that they want SuperLongUberTable.

The mere fact that the contents of such a table are just DOM nodes would also mean that I would be able to publish (as OSS) our own implementation of said beast... to much acclaim and prestige.

I also appreciate the fact that changing "NxM" to "N" means that (eventually) we'll get higher-quality components. For example, the components shipped in your browser are actually quite good. How many "good" video players did you see before HTML5 <video/>? My point is: The fact that anyone can write them means that there'll be a sort of evolutionary competition which tends towards an (admittedly, local) maximum -- but it's not as if the framework world has done much better, so... (Of course this is still at least a little hypothetical. We'll see, but I'm cautiously optimistic.)

EDIT: I might not have articulated it, but I think it goes without saying that I obviously want all components to evolve towards the "stateless-and-emits-events-to-container-components" model of e.g. React... and I think that will happen because it's simply easier to integrate into any framework.

[masiulis]

> 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.

[lomnakkus]

> There is an easier solution to this than Web Components - using a single framework.

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.

[masiulis]

> I mean, really, come on -- that's not realistic in any reality.

Huh? Most projects use a single framework in a project, sometimes two if they are migrating. If I had multiple frameworks in my project, sharing components between them would be the least of my problems.

> standardizing "custom DOM" will eventually get us to a standard slightly above raw HTML

I understand this sentiment, but DOM is irrelevant to front-end work right now. DOM is just a render target for frameworks, making DOM smarter changes nothing.