> 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 an hour ago | parent [-]

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 an hour ago \| parent [-]
		> 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.