4 ms·

This is why I prefer web components. This is nothing against React. But it's a library, and they make breaking changes just like all libraries (eventually) do.

by Touche 9y ago

This is why I prefer web components. This is nothing against React. But it's a library, and they make breaking changes just like all libraries (eventually) do. The great thing about web components is that they cannot make breaking changes now that it's been implemented by multiple libraries. It's stamped in time forever. If there ever comes a time where the existing API can't be updated any more because of mistakes or whatever, they'll just make a new API and your existing code will continue to work, forever. Look at XMLHttpRequest and fetch(). Did you have to migrating your XHR code over to fetch()? No, it works fine, and always will.

TomMarius 9y ago
Actually synchronous XHRs will stop working in Chrome soon.
- Touche 9y ago
  Fair point, standards aren't immune to breaking changes, it's just a lot rarer, smaller in scope and with a much longer time frame to upgrade.
  - TomMarius 9y ago
    Definitely agreed, just wanted to point out that it happens.
hazza1 9y ago
I got pretty burnt by the big changes in custom elements v0->v1. Admittedly v0 was only a proposal but v1 took a long time coming.
H1Supreme 9y ago
When the Polyfills are gone (mostly), I'll come back to web components. I love the idea of web components, but the browsers are still pretty fragmented in terms of support. There's definitely progress, but an older Polymer 1.0 app of mine is painfully slow on everything but Chrome.
- ergo14 9y ago
  Hm, DBmon benchmarks show that Polymer 1.x with polyfills is a lot faster than Angular 1.x which has thousands of production sites and was acceptable not that long ago. So I'm not sure that non-polyfill execution will really fix the performance for you. Maybe chrome is better at rendering your application structure?