5 ms·

I don't really think server-side rendering is an important reason why most people don't use web components. Most web applications that use components of any sor

I don't really think server-side rendering is an important reason why most people don't use web components. Most web applications that use components of any sort are largely SPAs of some variety and don't care one bit about server-side rendering. In my opinion, the main reason web components aren't widely used is that the alternatives are just better. I'm yet to see a strong case being made where web components are favorable for a reason other than purism.

afavour 2y ago
From my personal experience the lack of SSR is one reason I don’t use web components. But that said there isn’t a particularly persuasive case to use them either, other than it being nice to use standards.
pier25 2y ago
> Most web applications that use components of any sort are largely SPAs How did you get to that conclusion? Honestly asking because my hunch is that it would be the opposite. > I'm yet to see a strong case being made where web components are favorable for a reason other than purism. IMO it's wrong to see web components as a universal solution to all client-side use cases. Web components are amazing for distributing widgets to third party users. From users authoring HTML in any number of environments to a way to plug modern JS stuff into SSR backend frameworks. Back in 2016 I worked in library of widgets for interactive education ebooks. People producing the ebooks could barely write HTML so being able to add interactivity with configurable custom tags was extremely easy for them. Currently I'm working in an embeddable and customizable audio player with web components. Typically you'd use iframes which are quite heavy and have serious limitations. In both use cases, web components were the right choice.
- DrFell 2y ago
  Websites built with JavaScript frameworks need SSR because of SEO. Applications don't, so most are SPAs, because they can be. The fully decoupled SPA is a special architecture. Complexity isn't just lessened, a lot of it vanishes. Poof, bye bye headaches. If you can use it, you do, and most web applications can, so they do.
ww520 2y ago
I’m curious to see a plus and minus comparison of web component vs other techs (I assume those are React, Vue, etc.)
egeozcan 2y ago
Here's one case that I think is strong: At work some teams use JSF, some use React. We need to deliver components to both. We chose lit and we're very happy.
deergomoo 2y ago
I read a lot of blog posts from both sides in the most recent big "web components vs frameworks" brouhaha a month or so ago. The conclusion I came to was that both sides' arguments were mostly correct but orthogonal to each other, so neither side is ever going to convince the other because they're not really seeking the same goal. The pro-web-component folks argue that WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries, and because it's easier to progressively enhance and therefore more accessible. This is correct, and those points are valuable if what you seek is a way to add resilient islands of interactivity to your document. The pro-framework folks argue that in their model where the entire UI is a function of state, WCs are incredibly cumbersome, because all you really want from a component is to be a smaller function with which you can compose part of the whole. They are not nearly as concerned with maintaining that component under React vX in five year's time, because the entire system is written in React vX. The components are not maintained or used as individual units unless you are shipping a library. This is also correct, and those points are valuable if what you seek is an effective way to break down complexity in your application UI. Of course, many (maybe even most?) SPAs should be documents with progressive interactivity—it involves less fighting with the fundamentals of the web (which is, ultimately, still based around documents) and therefore offers better performance and accessibility with less effort. SSR for frameworks is an absurdly complex solution to a problem that doesn't exist if you can just send a complete document right to the browser. But, likewise, implementing a genuine high-interactivity web application using web components would be far more difficult than using a framework, and I am certain would result in re-implementing some sort of reactive UI/function-of-state paradigm anyway. Personally I think it's kind of a pointless debate, until and unless we get something that is close enough to <insert popular JS framework here> + SSR built into the browser. I don't know how that would work or whether it's even possible, but at that point the set of standards would actually cover all of the problems everyone is trying to solve and it would be worth arguing whether or not to use them.
- solardev 2y ago
  Exactly. Good breakdown.
- WA 2y ago
girvo 2y ago
> Most web applications that use components of any sort are largely SPAs of some variety and don't care one bit about server-side rendering That's just not that true when TTI and TTVC matters. SSR is only one piece of the puzzle, for sure, but it is useful still. That said I still agree with your overall point!

afavour 2y ago

From my personal experience the lack of SSR is one reason I don’t use web components. But that said there isn’t a particularly persuasive case to use them either, other than it being nice to use standards.

pier25 2y ago

> Most web applications that use components of any sort are largely SPAs How did you get to that conclusion? Honestly asking because my hunch is that it would be the opposite. > I'm yet to see a strong case being made where web components are favorable for a reason other than purism. IMO it's wrong to see web components as a universal solution to all client-side use cases. Web components are amazing for distributing widgets to third party users. From users authoring HTML in any number of environments to a way to plug modern JS stuff into SSR backend frameworks. Back in 2016 I worked in library of widgets for interactive education ebooks. People producing the ebooks could barely write HTML so being able to add interactivity with configurable custom tags was extremely easy for them. Currently I'm working in an embeddable and customizable audio player with web components. Typically you'd use iframes which are quite heavy and have serious limitations. In both use cases, web components were the right choice.

DrFell 2y ago
Websites built with JavaScript frameworks need SSR because of SEO. Applications don't, so most are SPAs, because they can be. The fully decoupled SPA is a special architecture. Complexity isn't just lessened, a lot of it vanishes. Poof, bye bye headaches. If you can use it, you do, and most web applications can, so they do.

ww520 2y ago

I’m curious to see a plus and minus comparison of web component vs other techs (I assume those are React, Vue, etc.)

egeozcan 2y ago

Here's one case that I think is strong: At work some teams use JSF, some use React. We need to deliver components to both. We chose lit and we're very happy.

deergomoo 2y ago

I read a lot of blog posts from both sides in the most recent big "web components vs frameworks" brouhaha a month or so ago. The conclusion I came to was that both sides' arguments were mostly correct but orthogonal to each other, so neither side is ever going to convince the other because they're not really seeking the same goal. The pro-web-component folks argue that WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries, and because it's easier to progressively enhance and therefore more accessible. This is correct, and those points are valuable if what you seek is a way to add resilient islands of interactivity to your document. The pro-framework folks argue that in their model where the entire UI is a function of state, WCs are incredibly cumbersome, because all you really want from a component is to be a smaller function with which you can compose part of the whole. They are not nearly as concerned with maintaining that component under React vX in five year's time, because the entire system is written in React vX. The components are not maintained or used as individual units unless you are shipping a library. This is also correct, and those points are valuable if what you seek is an effective way to break down complexity in your application UI. Of course, many (maybe even most?) SPAs should be documents with progressive interactivity—it involves less fighting with the fundamentals of the web (which is, ultimately, still based around documents) and therefore offers better performance and accessibility with less effort. SSR for frameworks is an absurdly complex solution to a problem that doesn't exist if you can just send a complete document right to the browser. But, likewise, implementing a genuine high-interactivity web application using web components would be far more difficult than using a framework, and I am certain would result in re-implementing some sort of reactive UI/function-of-state paradigm anyway. Personally I think it's kind of a pointless debate, until and unless we get something that is close enough to <insert popular JS framework here> + SSR built into the browser. I don't know how that would work or whether it's even possible, but at that point the set of standards would actually cover all of the problems everyone is trying to solve and it would be worth arguing whether or not to use them.

solardev 2y ago
Exactly. Good breakdown.
WA 2y ago

girvo 2y ago

> Most web applications that use components of any sort are largely SPAs of some variety and don't care one bit about server-side rendering That's just not that true when TTI and TTVC matters. SSR is only one piece of the puzzle, for sure, but it is useful still. That said I still agree with your overall point!