5 ms·
Amen! The core problem now is that Web Components aren't any faster than userland frameworks like Preact. Specifically: 1) First Contentful Paint: Web Compon
by dfabulich 8y ago
Amen!
The core problem now is that Web Components aren't any faster than userland frameworks like Preact.
Specifically:
1) First Contentful Paint: Web Components require client-side JS to render, which guarantees that their FCP numbers will be slower than React/Preact server-side rendering solutions, which can render without client-side JS.
2) Time to Interactive: LitElement + lit-html at 4KB is smaller than React (but not if you include WC polyfills), though it's not smaller than Preact (3KB).
3) Efficient Updates: lit-html might be able to beat out React/Preact here if you have a large page and you don't use shouldComponentUpdate or React.memo, but lit-html doesn't use Web Components (custom elements, shadow DOM). Haunted "virtual components" (lit-html + React-ish hooks) look pretty cool, but that's still not WC.
Without a credible performance advantage, Web Components are a zombie standard, walking dead.
- pjmlp 8y agoIf I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac. Any JS component library needs JS by definition.
- RussianCow 8y ago> If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac. Not if you need both server-side rendering AND a rich frontend. Unless you want to duplicate logic between two frameworks.
- pjmlp 8y agoServer-side rendering and a rich frontend are orthogonal. And yes, JavaScript is absolutely not the best way to actually make use of the server rack. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- RussianCow 8y agoThey are, unless you want to avoid duplicating logic, like I said. That's where most of the benefit of server-side rendering via JS comes from: you can render the initial page on the server, but then have the client-side framework take over on load, all from the same framework and with very minimal code duplication. Otherwise you have to write most of your rendering logic twice, in two different languages/frameworks. Re: benchmarks, I don't know what that has to do with anything. JavaScript (via V8) is much faster than Ruby and Python, and yet Rails and Django are still massively popular. For most apps, using a super fast backend language is not a concern.
- pjmlp 8y agoI rather go with rendering performance of HTML, CSS and minimal JS.