3 ms·

> The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow do

> The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow dom content on the server to the client, so even if your web component is fully non-interactive, you still need JS on the client in order to render it. That's not the case with other frameworks. I thought you were going to argue that there is no way that a tag like <my-component></my-component> magically acquires all its inner html on the server all by itself. That it would need some kind of tool to help it. In that, I suppose, you are right. Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. But server-rendered shadow dom can absolutely be passed to the client. It is called declarative shadow DOM; and it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill.

bastawhiz 3y ago
> Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. If you need to add a templating engine to generate your markup, you're really just replacing a framework with web components...and another framework. Which is half of my point: you aren't getting rid of a framework by choosing web components. > it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill. https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 "Obviously not a commitment to implement, but potentially worth reevaluation" is not "working on it right now", unfortunately. Here we are again, however, in that a completely non-interactive web component still needs JavaScript to render because you need a polyfill to take static, server-rendered HTML and put it in the shadow root. Again, it begs the question of what purpose web components are serving here anyway. The developer has to bend over backwards for both the server side and the client side and there's no meaningful reduction in code at all for either the client or the server.

bastawhiz 3y ago

> Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. If you need to add a templating engine to generate your markup, you're really just replacing a framework with web components...and another framework. Which is half of my point: you aren't getting rid of a framework by choosing web components. > it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill. https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 "Obviously not a commitment to implement, but potentially worth reevaluation" is not "working on it right now", unfortunately. Here we are again, however, in that a completely non-interactive web component still needs JavaScript to render because you need a polyfill to take static, server-rendered HTML and put it in the shadow root. Again, it begs the question of what purpose web components are serving here anyway. The developer has to bend over backwards for both the server side and the client side and there's no meaningful reduction in code at all for either the client or the server.