Comment by DrScientist
7 days ago
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.
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.
> 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.
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.
7 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.
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.