5 ms·

I appreciate the author's attempt to contextualize web components, but I have a few bones to pick, having seen web components used to a pathological extent in v

I appreciate the author's attempt to contextualize web components, but I have a few bones to pick, having seen web components used to a pathological extent in various projects First, the idea that one of web components' strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components. Second, the transition example from react to svelte highlights the use of web components as a bridge, but I fear it oversimplifies the reality of such transitions. Its true that web components might provide a superficial level of interoperability, underneath, the application architecture, state management, and data flow can differ vastly between frameworks. Simply plopping an old component with a new one doesn’t mean they’ll play nice without substantial architectural considerations. Finally, the mention of "no bundler, no transpiler" as an advantage is curious. in practice, the modern web development ecosystem has moved towards using tools like bundlers and transpilers to optimize delivery, reduce overhead, and facilitate modular development. this isn't about complexity, but rather about efficiency and best practices. Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet.

jongjong 3y ago
- Server side rendering is essentially a hack to work around web crawlers' inability to parse dynamic single page apps... My first issue with this is that it doesn't make sense to me why someone would build a high-exposure public website/landing page as a dynamic single page web app, what you really need is a website; these are much more lightweight, easier to cache and deliver over CDN and they use up far fewer resources (no need to serve libraries which are not necessary for the current page). Also, why would you want web crawlers to parse a dynamic application (e.g. dashboard and private areas)? It shouldn't even be visible unless the user is authenticated (which the crawler is not!). What should you show the web crawler in that case? Do you really need Google to see all your apps' form templates with all the empty input fields? SEO is for marketing; in this case, you need a website with a landing page and potentially a blog, not a dynamic single page app. - About bundling, the current reality is that frameworks like React come with a huge amount of dependencies/boat... On the other hand, native Web Components require no dependencies. Web Components will generally load much faster even without bundling than React + all dependencies in a bundle because those bundles are often huge... Not to mention that nowadays, tags expose some nice attribute which let you control the loading and execution order of scripts in a highly fine-grained way (e.g. async and defer attributes on the script tag). That's even without going into the fact that since HTTP2, servers have the ability to preemptively push resources to the client without any round-trip latency. Also, loading resources separately allows for more fine-grained cashing with CDNs; you share some components between some pages and you only need to load what you need explicitly as needed.
- boredtofears 3y ago
  SSR feels like it was a term coined by marketers more than it does engineers. Every time I hear someone describe their reasons for using SSR I usually can't figure out why they're building an SPA in the first place.
  - JodieBenitez 3y ago
    > SSR feels like it was a term coined by marketers more than it does engineers. What I see is that sometimes young front-end developers use their favorite tools (ie. the JS ecosystem) and are unaware of (or have not practiced) the "old way" of building server-side applications and websites.
    - MrJohz 3y ago
      There's definitely some truth to that, but I also see a lot of older developers who are equally unaware of the newer ways of developing, and then struggle to see the potential improvements there. For example, front-end templating systems are usually come with a lot more than more traditional templating engines. I can get autocomplete on component names and attributes, squigglies when I do something wrong, type safety, as well as more logical import/scoping rules - just follow the import lines and you find where a component was defined. Meanwhile, partials tend to be much more stringly typed, have very little IDE support, and often still seem to use a global partials folder to define reusable components. The other big thing that I miss in traditional templating engines is scoping for web technologies. Being able to collocate styles and HTML structure is incredibly useful, and makes it a lot easier to share components around in different contexts. Similarly, if I have an accordion partial that uses a bit of Javascript for progressive enhancement, it's very useful to be able to group that Javascript with the partial, scope it to that context, and let the templating engine hook everything up. Scoped CSS (however you implement it, be that CSS modules, CSS-in-JS, tailwind, or whatever else) is a godsend for making really robust components, and I've never found anything even half as good on the server side.
      - boredtofears 3y ago
tipiirai 3y ago
@canvascritic great points. What would you say where web components are good at?
verisimilidude 3y ago
> First, the idea that one of web components' strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components. This comment deserves some clarity. Web components should not bypass server-side rendering. However, that server-side rendering should not come from the web components themselves. Rather, the "SSR" in this case should be the job of whatever generates the page HTML. The page HTML should include default "slotted" content (inside the custom element's tag) to be picked up by the web component when the page loads. That's the best way to do progressive enhancement in web component land. Whenever I reach a point when I think, "Gee, I wish I could SSR this web component," I take it as a bad smell, like I'm probably not taking advantage of web component features. Put another way, I wouldn't want to SSR a web component for the same reason I wouldn't want to SSR a <p> tag. The latter makes no sense, right? Web components are custom elements, and they should be treated like elements, and designed like elements. > Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet. Fully agreed with this, it should be repeated over and over. Web components can be part of a balanced diet but they can't be the whole meal.
- dgb23 3y ago
  If I understood you correctly, then we’re exactly on the same page. That is, web components being a standalone thing that you render “as is” on the server. Their point is to extend interaction on the client and not to be a templating language on the server. The author mentioned Lit not having a stable SSR story (a small, fast library to leverage web components). My suspicion here is that some do too much within their components that they want to render on the server. There’s two possible solutions already: 1. Don’t generate all your html inside the component (in js), but instead use the component to enclose markup that you render on the server. 2. Decouple html rendering (lit-html) from your component. If your component calls a function that spits out html, so can your server (if it runs JS).

jongjong 3y ago

- Server side rendering is essentially a hack to work around web crawlers' inability to parse dynamic single page apps... My first issue with this is that it doesn't make sense to me why someone would build a high-exposure public website/landing page as a dynamic single page web app, what you really need is a website; these are much more lightweight, easier to cache and deliver over CDN and they use up far fewer resources (no need to serve libraries which are not necessary for the current page). Also, why would you want web crawlers to parse a dynamic application (e.g. dashboard and private areas)? It shouldn't even be visible unless the user is authenticated (which the crawler is not!). What should you show the web crawler in that case? Do you really need Google to see all your apps' form templates with all the empty input fields? SEO is for marketing; in this case, you need a website with a landing page and potentially a blog, not a dynamic single page app. - About bundling, the current reality is that frameworks like React come with a huge amount of dependencies/boat... On the other hand, native Web Components require no dependencies. Web Components will generally load much faster even without bundling than React + all dependencies in a bundle because those bundles are often huge... Not to mention that nowadays, tags expose some nice attribute which let you control the loading and execution order of scripts in a highly fine-grained way (e.g. async and defer attributes on the script tag). That's even without going into the fact that since HTTP2, servers have the ability to preemptively push resources to the client without any round-trip latency. Also, loading resources separately allows for more fine-grained cashing with CDNs; you share some components between some pages and you only need to load what you need explicitly as needed.

boredtofears 3y ago
SSR feels like it was a term coined by marketers more than it does engineers. Every time I hear someone describe their reasons for using SSR I usually can't figure out why they're building an SPA in the first place.
- JodieBenitez 3y ago
  > SSR feels like it was a term coined by marketers more than it does engineers. What I see is that sometimes young front-end developers use their favorite tools (ie. the JS ecosystem) and are unaware of (or have not practiced) the "old way" of building server-side applications and websites.
  - MrJohz 3y ago
    There's definitely some truth to that, but I also see a lot of older developers who are equally unaware of the newer ways of developing, and then struggle to see the potential improvements there. For example, front-end templating systems are usually come with a lot more than more traditional templating engines. I can get autocomplete on component names and attributes, squigglies when I do something wrong, type safety, as well as more logical import/scoping rules - just follow the import lines and you find where a component was defined. Meanwhile, partials tend to be much more stringly typed, have very little IDE support, and often still seem to use a global partials folder to define reusable components. The other big thing that I miss in traditional templating engines is scoping for web technologies. Being able to collocate styles and HTML structure is incredibly useful, and makes it a lot easier to share components around in different contexts. Similarly, if I have an accordion partial that uses a bit of Javascript for progressive enhancement, it's very useful to be able to group that Javascript with the partial, scope it to that context, and let the templating engine hook everything up. Scoped CSS (however you implement it, be that CSS modules, CSS-in-JS, tailwind, or whatever else) is a godsend for making really robust components, and I've never found anything even half as good on the server side.
    - boredtofears 3y ago

tipiirai 3y ago

@canvascritic great points. What would you say where web components are good at?

verisimilidude 3y ago

> First, the idea that one of web components' strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components. This comment deserves some clarity. Web components should not bypass server-side rendering. However, that server-side rendering should not come from the web components themselves. Rather, the "SSR" in this case should be the job of whatever generates the page HTML. The page HTML should include default "slotted" content (inside the custom element's tag) to be picked up by the web component when the page loads. That's the best way to do progressive enhancement in web component land. Whenever I reach a point when I think, "Gee, I wish I could SSR this web component," I take it as a bad smell, like I'm probably not taking advantage of web component features. Put another way, I wouldn't want to SSR a web component for the same reason I wouldn't want to SSR a <p> tag. The latter makes no sense, right? Web components are custom elements, and they should be treated like elements, and designed like elements. > Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet. Fully agreed with this, it should be repeated over and over. Web components can be part of a balanced diet but they can't be the whole meal.

dgb23 3y ago
If I understood you correctly, then we’re exactly on the same page. That is, web components being a standalone thing that you render “as is” on the server. Their point is to extend interaction on the client and not to be a templating language on the server. The author mentioned Lit not having a stable SSR story (a small, fast library to leverage web components). My suspicion here is that some do too much within their components that they want to render on the server. There’s two possible solutions already: 1. Don’t generate all your html inside the component (in js), but instead use the component to enclose markup that you render on the server. 2. Decouple html rendering (lit-html) from your component. If your component calls a function that spits out html, so can your server (if it runs JS).