Hacker News new | ask | show | jobs
by spankalee 3521 days ago
First, all Web Components libraries are by default compatible with each other, so by using this instead of React you aren't locked into a non-standard framework. You can mix and match elements written using different libraries, and migrate single elements from one library to another without breaking clients.

Eventually React will fall out of fashion like every other framework before it, and teams that went all-in on it will have to do a painful rewrite. Web Components based apps will be able to incrementally migrate, element by element, to a different library.

Second, by relying on the browser to host components and run the component lifecycle and composition parts, it's pretty easy to be smaller and faster than frameworks like React.

Third, Shadow DOM fixes CSS. Scoped styles are simpler, easier to reason about, faster, have lower specificity, ID's become useful again, and it's much easier to do things like lazy load below-the-fold styles because you transform that into lazy-loading below-the-fold components (simpler than teasing apart rule soup).

2 comments

Eventually React will fall out of fashion like every other framework before it, and teams that went all-in on it will have to do a painful rewrite.

Or they could just keep using what works? React's surface area (compared to something like Angular or Ember) is so small, it's not obvious to me why you'd want to do a rewrite just because it "fell out of fashion".

> React's surface area (compared to something like Angular or Ember) is so small

Sure, the core React library is small. But when do people ever just use the core library? Think of all the additional libraries and components in the React ecosystem that get used in projects. The footprint of the average React project ends up being just as large as the footprint of the average Angular or Ember project.

React isn't small - it's over 130k minified and gzipped.

Fashion matters more than it should. The ecosystems move on, support lessons, new hires are less likely to know and really desire to learn the old thing...

edit: More importantly, the new applications in your organization might move on to the new things and then you usually have a hard time sharing components between them.

> You can mix and match elements written using different libraries, and migrate single elements from one library to another without breaking clients.

Why someone would be doing that? I mean mix and matching libraries could be asking for unmaintainable code...

Because the alternative is a complete rewrite, which is usually very costly.
Sure, without Web Components is might be, but Web Components and the DOM are the interop layer. As long as your component has properties, attributes, children and events, it's an element and can work with other elements. How it's implemented internally, and what library it uses, shouldn't matter at all.