|
|
|
|
|
by dmix
1049 days ago
|
|
Modern JS frameworks are heavily mixing mostly static with limited amounts of interactive components but all in one system. Where everything can still be the same component architecture, the same UI systems, same CSS/JS packages, same build systems, etc but you selectively choose which components (or small sections of a page) are interactive and require hydration. I don't really see how Web components fill that picture as cleanly. You would basically still forced to choose between component overhead/custom code OR static HTML, creating a formal discintion rather than a boolean or flag or whatever. Why create that distinction just because it's "native" to the browser? The DOM is sufficient when your default is static and components are always SSR in the same DOM model. It basically only makes sense if you're not building a "holistic" single frontend framework driven site and rather are mixing various server side view systems and occasionally adding a couple components. Basically the sort of thing better suited for major legacy sites like Google rather than something you'd ever choose from the ground up. |
|