5 ms·

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 b

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
> 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. So, React is just a view library. It's made to map state to DOM changes. Except it's not just a view library, because if you write an app with React, you are writing a React app. You slice and dice your view up and put them into React components. Now, since you want to use your React components on the server and not slice and dice them up again in another view library, you morph that DOM-manipulating lib into a templating engine that generates static HTML. Except you call it "server side rendering", because "templating engine" sounds so 2010 and "static site generation" is also not the right term, because the output isn't a static HTML page, but can change with every page request. Of course, the "React" part of React is completely ditched in SSR, because you don't need to continuously modify the DOM based on your state. React on the server is what PHP templates have been doing forever. Outputting HTML in PHP is "view = f(state)". We've come full circle. I sometimes wonder if younger web devs even understand that SSR isn't, like, really rendering a page on the server, but basically means "we produce frickin HTML like we've been for the last 30 years, except our tools are now 10x as complex to such a point that we don't understand them anymore", because 90% of our view library does nothing on the server, because, you know, there is no DOM. There is only HTML as a string send over HTTP. Having said that: Your analysis is completely correct. The discussion really is orthogonal and I'm not sure I see the point in rendering web components on the server, since most web components benefit from interactivity through JS. If I merely encapsulate a bunch of HTML tags, I can ditch the custom element entirely and send the HTML tags down the wire by themselves.
- MrJohz 2y ago
  I think when trying to understand SSR, it's worth remembering what actually was happening with older systems like PHP. You say that outputting HTML in PHP is `view = f(state)`, and this is to a certain extent true, but it meant that anything on the client side was then `view = f_client(state_client, f_server(state_server))`, and getting applications to remain sane with anything more than the bare minimum of interactivity was painful. I remember this era, and debugging constant state issues was very much the reason that we ended to moving towards client-side web frameworks: you only have to worry about one `f` and (mostly) one `state`. In my experience, most of the people exploring SSR are very acutely aware of that era, both the benefits and the negatives, and are trying to build systems that allow developers to retain a consistent overall view function without having to maintain that across multiple codebases in multiple languages. That doesn't just mean rendering HTML, but also ensuring that the frontend and backend agree on how to update that HTML if the state ever changes, or ensuring that progressive enhancement is possible while not requiring the entire site to reload every time I update a form field. Now I think there's a good argument to be made that many applications don't need this additional complexity - they can continue to be rendered entirely server-side, or entirely client-side, and not need to share state at all. But if you do need state to exist in both the server and the client, modern SSR frameworks are typically a pretty good approach.
nosefurhairdo 2y ago
> WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries Help me understand; is this suggesting that older frameworks/libraries are expected to stop working at some point? I'm shipping 10+ year old libraries in production without incident. Really don't understand the "resilience" argument for WCs.
- pegasus 2y ago
  10+ years is nothing compared with a human lifespan. Web standards are more likely to still be around in 50 years than react vX.
  - teg4n_ 2y ago
    react uses those same web standards. It will not stop working either. You may not be able to upgrade to the latest React version assuming there are breaking changes, but the same can be said for the various frameworks people use to create web components.
    - IlPeach 2y ago
      I might be nitpicking but, the transpiled version of React is the one that uses those standards. If you are thinking of trying to get a 5+ years old project working in a development environment you might effectively be out of luck. To reduce the argument to a simpler one, this is effectively the difference between using vanilla js to build anything Vs using any abstraction over it that has a number of dependencies you don't control that are effectively a working solution of a dependency hell in a specific moment of time.
      - svieira 2y ago
        Yes, but then you are not comparing apples. Web components projects without a build step and relying on only stable standards are a subset of all web component projects. Same with React projects, though the ratios of without build vs. with build are obviously different.
MrJohz 2y ago
> 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. I'm not sure that's even that correct. If you write code using browser APIs that are currently standardised, your code will work indefinitely, whether or not you use Web Components, React, or jQuery. Hell, we used to have jQuery-based components with the whole $(...).datepicker() system. Yes, it has its flaws, but it'll still work today if that's what your want from it. Secondly, I don't think Web Components do work well from a progressive enhancement perspective. Progressive enhancement is starting from the bare minimum (i.e. just HTML and some styles, if that), and progressively adding features to that initial state that don't prevent any of the previously-added features from working. So you start with an HTML form skeleton, and you add some validation attributes, you add an event handler that calls fetch instead of reloading the page, you extend the address input so that it suggests real addresses - but the whole time, the HTML form is still there and it still works. But without Javascript, Web Components are essentially empty holes that can't do anything. They don't progressively enhance anything. You can to a certain extent wrap existing elements, you can take the isomorphic approach described in this post, etc. But even when you do that, the browser will replace the contents of the element with the component's rendered output when the Javascript comes online, potentially deleting any user inputs if they'd interacted with the previous context. If your aim is true progressive enhancement, you should probably look in a different direction. In fairness, I don't disagree that these claims are often made by Web Component proponents. But I think they're the wrong claims to be making. Web Components seem to be most useful if you're trying to isolate a complex stateful component written by one person or team and ended it into a complex stressful application written by a different person or team. They're essentially like lightweight iframes. This is really useful, and should be promoted more - but it's also quite a specific use.
- throwitaway1123 2y ago
  > I'm not sure that's even that correct. If you write code using browser APIs that are currently standardised, your code will work indefinitely, whether or not you use Web Components, React, or jQuery. The most charitable interpretation of this argument is that framework specific component libraries assume for the most part that you're using that specific framework. The documentation for popular React component libraries like shadcn are largely incomprehensible if you're not using React. Libraries like Shoelace (now being renamed to Web Awesome) make no such assumptions. You can just drop a script tag into your page's markup and get started without having to care about (or even be aware of) the fact that Shoelace uses Lit internally. > But without Javascript, Web Components are essentially empty holes that can't do anything. They don't progressively enhance anything. This is not true if you're using the new Declarative Shadow DOM API [1]. You literally just add a template tag with a shadowroot mode attribute inside your custom element, and then the component works without JavaScript. When (or if) the JavaScript loads, you simply check for the existence of a server-rendered shadow root using `internals.shadowRoot`. If a shadow root already exists then you don't have to replace anything, and you can attach your event listeners to the pre-existing shadow root (i.e. component hydration). [1] https://web.dev/articles/declarative-shadow-dom#component_hydration https://web.dev/articles/declarative-shadow-dom#component_hy...

solardev 2y ago

Exactly. Good breakdown.

WA 2y ago

> 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. So, React is just a view library. It's made to map state to DOM changes. Except it's not just a view library, because if you write an app with React, you are writing a React app. You slice and dice your view up and put them into React components. Now, since you want to use your React components on the server and not slice and dice them up again in another view library, you morph that DOM-manipulating lib into a templating engine that generates static HTML. Except you call it "server side rendering", because "templating engine" sounds so 2010 and "static site generation" is also not the right term, because the output isn't a static HTML page, but can change with every page request. Of course, the "React" part of React is completely ditched in SSR, because you don't need to continuously modify the DOM based on your state. React on the server is what PHP templates have been doing forever. Outputting HTML in PHP is "view = f(state)". We've come full circle. I sometimes wonder if younger web devs even understand that SSR isn't, like, really rendering a page on the server, but basically means "we produce frickin HTML like we've been for the last 30 years, except our tools are now 10x as complex to such a point that we don't understand them anymore", because 90% of our view library does nothing on the server, because, you know, there is no DOM. There is only HTML as a string send over HTTP. Having said that: Your analysis is completely correct. The discussion really is orthogonal and I'm not sure I see the point in rendering web components on the server, since most web components benefit from interactivity through JS. If I merely encapsulate a bunch of HTML tags, I can ditch the custom element entirely and send the HTML tags down the wire by themselves.

MrJohz 2y ago
I think when trying to understand SSR, it's worth remembering what actually was happening with older systems like PHP. You say that outputting HTML in PHP is `view = f(state)`, and this is to a certain extent true, but it meant that anything on the client side was then `view = f_client(state_client, f_server(state_server))`, and getting applications to remain sane with anything more than the bare minimum of interactivity was painful. I remember this era, and debugging constant state issues was very much the reason that we ended to moving towards client-side web frameworks: you only have to worry about one `f` and (mostly) one `state`. In my experience, most of the people exploring SSR are very acutely aware of that era, both the benefits and the negatives, and are trying to build systems that allow developers to retain a consistent overall view function without having to maintain that across multiple codebases in multiple languages. That doesn't just mean rendering HTML, but also ensuring that the frontend and backend agree on how to update that HTML if the state ever changes, or ensuring that progressive enhancement is possible while not requiring the entire site to reload every time I update a form field. Now I think there's a good argument to be made that many applications don't need this additional complexity - they can continue to be rendered entirely server-side, or entirely client-side, and not need to share state at all. But if you do need state to exist in both the server and the client, modern SSR frameworks are typically a pretty good approach.

nosefurhairdo 2y ago

> WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries Help me understand; is this suggesting that older frameworks/libraries are expected to stop working at some point? I'm shipping 10+ year old libraries in production without incident. Really don't understand the "resilience" argument for WCs.

pegasus 2y ago
10+ years is nothing compared with a human lifespan. Web standards are more likely to still be around in 50 years than react vX.
- teg4n_ 2y ago
  react uses those same web standards. It will not stop working either. You may not be able to upgrade to the latest React version assuming there are breaking changes, but the same can be said for the various frameworks people use to create web components.
  - IlPeach 2y ago
    I might be nitpicking but, the transpiled version of React is the one that uses those standards. If you are thinking of trying to get a 5+ years old project working in a development environment you might effectively be out of luck. To reduce the argument to a simpler one, this is effectively the difference between using vanilla js to build anything Vs using any abstraction over it that has a number of dependencies you don't control that are effectively a working solution of a dependency hell in a specific moment of time.
    - svieira 2y ago
      Yes, but then you are not comparing apples. Web components projects without a build step and relying on only stable standards are a subset of all web component projects. Same with React projects, though the ratios of without build vs. with build are obviously different.

MrJohz 2y ago

> 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. I'm not sure that's even that correct. If you write code using browser APIs that are currently standardised, your code will work indefinitely, whether or not you use Web Components, React, or jQuery. Hell, we used to have jQuery-based components with the whole $(...).datepicker() system. Yes, it has its flaws, but it'll still work today if that's what your want from it. Secondly, I don't think Web Components do work well from a progressive enhancement perspective. Progressive enhancement is starting from the bare minimum (i.e. just HTML and some styles, if that), and progressively adding features to that initial state that don't prevent any of the previously-added features from working. So you start with an HTML form skeleton, and you add some validation attributes, you add an event handler that calls fetch instead of reloading the page, you extend the address input so that it suggests real addresses - but the whole time, the HTML form is still there and it still works. But without Javascript, Web Components are essentially empty holes that can't do anything. They don't progressively enhance anything. You can to a certain extent wrap existing elements, you can take the isomorphic approach described in this post, etc. But even when you do that, the browser will replace the contents of the element with the component's rendered output when the Javascript comes online, potentially deleting any user inputs if they'd interacted with the previous context. If your aim is true progressive enhancement, you should probably look in a different direction. In fairness, I don't disagree that these claims are often made by Web Component proponents. But I think they're the wrong claims to be making. Web Components seem to be most useful if you're trying to isolate a complex stateful component written by one person or team and ended it into a complex stressful application written by a different person or team. They're essentially like lightweight iframes. This is really useful, and should be promoted more - but it's also quite a specific use.

throwitaway1123 2y ago
> I'm not sure that's even that correct. If you write code using browser APIs that are currently standardised, your code will work indefinitely, whether or not you use Web Components, React, or jQuery. The most charitable interpretation of this argument is that framework specific component libraries assume for the most part that you're using that specific framework. The documentation for popular React component libraries like shadcn are largely incomprehensible if you're not using React. Libraries like Shoelace (now being renamed to Web Awesome) make no such assumptions. You can just drop a script tag into your page's markup and get started without having to care about (or even be aware of) the fact that Shoelace uses Lit internally. > But without Javascript, Web Components are essentially empty holes that can't do anything. They don't progressively enhance anything. This is not true if you're using the new Declarative Shadow DOM API [1]. You literally just add a template tag with a shadowroot mode attribute inside your custom element, and then the component works without JavaScript. When (or if) the JavaScript loads, you simply check for the existence of a server-rendered shadow root using `internals.shadowRoot`. If a shadow root already exists then you don't have to replace anything, and you can attach your event listeners to the pre-existing shadow root (i.e. component hydration). [1] https://web.dev/articles/declarative-shadow-dom#component_hydration https://web.dev/articles/declarative-shadow-dom#component_hy...