Hacker News new | ask | show | jobs
by eeJah9to 2163 days ago
I've rewrote the frontend of one of my personal apps from react to webcomponents lately. For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it.

For the same reason, only the first example in this page would do for me (the one based on standard without using any library). But I suppose that for actually publishing something, such library would be needed, if anything for polyfills for older browsers (but then again, we don't expect published work to stand for decades without changes, so maybe the call for standardized technology is not as strong there).

5 comments

> For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it.

Doesn't really make sense because for JS frameworks and for the "pure" component the dependency is the same - browser. If i don't have to maintain a project i can just pick whatever is the current version of React/Vue/Other and have the project running as long as the browser doesn't break/change something.

Isn't React itself still basically written using standard JavaScript? Why won't it run in the future?
> For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it.

I mean, you can also do that with React. Just don't update the library. The reason a web-component for decades without maintenance is because you won't be using all the new features— same thing.

I think the difference is that when you design a full React app, everything sit on the same "React base". If you want to move to upgrade to a new React version everything needs to upgrade. And if you need to migrate to Vue or Ember or Svelte... everything needs to migrate (or move to some sort of microfrontend strategy. But given the javascript cost of some of these frameworks, it's not cheap to go this route).

Web Components have a longer life span as they can be used in another app or another version with another technology without been migrated. Makes more sense for expensive component that have been battle tested. You don't want to rewrite them.

React is built to interop with "general" JavaScript, so in theory you can use it with other rendering frameworks. I used React and D3 all the time.

Performance-wise, it IS better to stick to a single framework, so I see what you mean. Web components being implemented in the browser do mean the user doesn't have to download any more JS.

> so it means that I can use this app for decades without having to maintain it.

That seems highly optimistic to me.

Considering all mothballed APIs still supported in modern browsers I'd say it's accurate.
Did they improve the SSR story lately?