[DrScientist]

Ideally, good ideas battle tested in various frameworks, would make it into the browser over time.

For example with signals https://github.com/tc39/proposal-signals

I agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing and perhaps the most valuable ideas ( custom elements and ES modules ), were those which did have the biggest precedence.

> Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.

This feels a bit deflective from the very real issue of in page framework interoperability - which is different from dev's taking to each other and sharing ideas.

[austin-cheney]

What does battle tested really mean in numbers?

When people say battle tested what they are really doing is looking for bias confirmation. Its no different than when they say software becomes more durable due to community validation.

The only way to be sure is to actually measure things, with numbers, and then compare those numbers to some established baseline. Otherwise its just a guess. The more confident the guess becomes the less probable from the average it becomes. This is how rats out perform humans in weighted accuracy tests in clinical trials.

[DrScientist]

> What does battle tested really mean in numbers?

Not sure what you mean - are you asking number of users, length of time etc?

All I'm saying with this is that ideas which have actually been implemented, used and evolved, are much less likely to have rough edges than something that's never left a whiteboard or spec document. I wasn't expecting that to be controversial.

This stuff is difficult - if I remember correctly the original web components vision was a completely self-contained package of everything - that didn't survive contact with reality - however the things like custom-elements, templating and ES modules are, in my view at least, very useful - and I'd argue they are also the things that had the most precedents - because they were solving real world problems.

[austin-cheney]

That is an irrational comparison. There is no comparison between components and something imaginary or theoretical. The comparison is between components and not imposing components into the standards, which are both well known conditions.

People don't need components. They want components because that is the convention familiar to them. This is how JavaScript got classes. Everybody knew it is a really bad idea to put that into the standards and that classes blow out complexity, but the noise was loud enough that they made it in for no utility reason.

[DrScientist]

> People don't need components.

The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.

We can argue about whether components as proposed was the right solution, but are you arguing that templates, custom elements and modules have no utility?

Templating, for example, has been implemented in one form or another countless times - the idea that people don't need that seems odd.

Same goes for a js module system, same goes for hiding markup soup behind a custom element.

[troupo]

> The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.

And web components are an extremely shitty half-baked near-solution to any of those.

[DrScientist]

Still not sure what you are attacking - is it just custom-elements or does that include js modules etc?

[austin-cheney]

That completely misses the point. You are mistaking your preference for some objective, though unmeasured, benefit.

I could understand an argument from ignorance fallacy wherein your preference is superior to every other alternative because any alternative is unknown to you. But instead, you are saying there is only way one of doing things, components/modularity/templates, and this is the best of that one way's variations, which is just a straw man.

You really aren't limited to doing this work the React way, or any framework way. If you want to continue doing it the React way then just continue to use React, which continues to evolve its own flavor.

[DrScientist]

> But instead, you are saying there is only way one of doing things,

Nope. I did not say there is only one way of doing things. I asked you whether you really thought people didn't want improved modularity, encapsulation, reusability, interop.

For example without standardised modules you either had to choose one of several community module systems or live with poor modularity and encapsulation. And by standardising modules interop improves.

> If you want to continue doing it the React way then just continue to use React,

Only one of us is appearing to want to stop the way the other only likes to develop. If I want to use custom elements why all the anger?

[jazzypants]

You can interoperate between frameworks the same way you interoperate between web components-- with events and attributes.

[troupo]

> agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing

What battle testing? Literally nothing in Web Components was ever battle-tested before release. You wouldn't need 20+ specs to paper over the holes in the design had they actually veen battle-tested.

[DrScientist]

Read my comment again. I literally said that various parts had various levels of precedents - and that the more successful parts were those with stronger precedents.

> Literally nothing in Web Components was ever battle-tested before release.

So you don't thing the ideas of modules or templates had had multiple precedents?

Totally agree that some aspects had much less precedent - and that's why, in the end, they either didn't get implemented or haven't got much traction.