alt Hacker NewsIdeally, 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.
Replies
You can interoperate between frameworks the same way you interoperate between web components-- with events and attributes.
> 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.
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.