| I'm not in the US either but I'm sure someone will know how to make it happen, even if it goes to charity or something. (no crypto though) I guess the second bet's criteria would depend on both the recommended practice for moving components today and the recommended practice in the future (which we don't know yet so it'd have to be done in good faith). Currently, web components are designed to be portable so they can easily be ported between projects by copy-pasting a single hunk of code. Whereas react components can be copy-pasted, but (as far as standard practice is concerned) require build systems and their dependencies (both of which rot over time) before they can be considered functional. Aside: There's an argument to be made about the difficulty of migrating some web component based design systems (due to build systems and dependencies), but those difficulties that would be experienced are locked into the design system itself and would be experienced regardless of whether the design system was implemented with web components, react, vue, svelte, angular, lit etc... The bet is about an individual component and how easy it would be to port. ----------------------------------- To respond to your reasoning, I feel that it's important to point out there is a difference between standards and web standards. The pendulum of standards themselves may come and go, but web standards almost entirely swing towards the coming side. The going side is reserved almost entirely for newer standards that subsume older web standards so the older web standards are still supported. Anyone can make a standard, but a web standard proposal doesn't become a web standard until it has become adopted and implemented. This means that web standard proposals can be thrown away without affecting web standards themselves. It takes a black swan event to remove a web standard (e.g. spectre/meltdown leading to SharedArrayBuffer's removal). When it comes to web standards, backwards compatibility is sacrosanct. Consider this simple ES1 example code: ----------------------------------- var person = { name: "John",
age: 30,
sayHello: function() {
console.log("Hello, my name is " + this.name + ".");
}
};console.log(person.name); // Output: "John" person.sayHello(); // Output: "Hello, my name is John." ----------------------------------- It still works. Now try to picture this functionality implemented in "nonstandard-but-popular-in-the-past formats" like java applet, flash file, coffeescript and an old jquery plugin. Would that code be more straight forward to make functional today than the web standard ES1 code above? Now that question above doesn't neatly fit with your reasoning because you were comparing "nonstandard-but-popular-in-the-past formats" with "a standard format that didn't see wide adoption". I think we can both agree that ES4 was something that fit into the second bucket. And judging by your comments I think you would say that Web Components as they exist now would also fall into that second bucket. But I would counter that with: 1. Web components already have wide adoption even if a lot of people aren't aware about it. (see comment: https://news.ycombinator.com/item?id=40295978) 2. Backwards compatibility is sacrosanct. |
I'm not up for a charity thing - if we're betting I want to be able to win as well as lose - but if there's a way to do it then I'm down.
> I guess the second bet's criteria would depend on both the recommended practice for moving components today and the recommended practice in the future (which we don't know yet so it'd have to be done in good faith).
Right, yeah, happy to just say we look at it in good faith and reach a conclusion.
> Currently, web components are designed to be portable so they can easily be ported between projects by copy-pasting a single hunk of code.
> Whereas react components can be copy-pasted, but (as far as standard practice is concerned) require build systems and their dependencies (both of which rot over time) before they can be considered functional.
I don't think that's a huge difference; copy-pasting your dependency declarations and your implementation is not conceptually any harder than copy-pasting just your implementation. If the accepted dependency format changes, or your component needs custom build steps, then that might be a harder piece of porting (but I wouldn't consider a simple mechanical change like changing dependency notation from JSON to XML to be a significant burden).