Hacker News Reader

> 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.

> 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_hy...

> You literally just add a template tag with a shadowroot mode attribute inside your custom element, and then the component works without JavaScript.

Wtf is a shadowroot?

I'm of increasing confidence that the entire project to unify document display and application runtime has utterly failed and there's no way (and no benefit) to resuscitate it. We need two different internets: one for interactive applications and one for document browsing.

> Wtf is a shadowroot?

In the Document Object Model (DOM), every document has a root node, which you can retrieve by calling `getRootNode()` on any node in the document (e.g. `document.getRootNode()` or `document.body.getRootNode()`).

Custom Elements can have their own "shadow" document that's semi-isolated from the parent document, and the root node of that shadow document is called the shadow root.

The idea is to be able to create your own HTML elements (which also have their own hidden DOM). If you enable a setting in Chrome's Devtools (Show user agent shadow DOM) [1], you can actually see the hidden shadow structure of built in HTML Elements: https://www.youtube.com/watch?v=Vzj3jSUbMtI&t=291s

[1] https://developer.chrome.com/docs/devtools/settings/preferen...

At this point, I think it's better to point to the MDN docs.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...

Your link uses some deprecated functionality that was only ever created on Chrome.

Anyway, it's good to know that browsers actually did implement that. It was a major complaint when web components were created.

The only reason I avoid linking to that MDN page is because I think it does a bad job of actually assembling all of the pieces together into a working example. That's why I linked specifically to the component hydration section, which assembles it all into a functioning component complete with an actual class and constructor. The code example in that specific section doesn't appear to use any deprecated or non-standard features. Otherwise, I normally do prefer MDN as an authoritative source of documentation.

The MDN page has the deprecation notice for the `shadowRoot` property.

Yes, the examples on your page are way more comprehensive. Even with compatibility support for old Chrome versions. Unfortunately, that support example will also break your code on other browsers.

People may want to read it anyway, and just fix the problem. It being outdated doesn't make the explanation bad.

> The MDN page has the deprecation notice for the `shadowRoot` property.

The `shadowRoot` property of the ElementInternals object is not deprecated: https://developer.mozilla.org/en-US/docs/Web/API/ElementInte...

What's deprecated is the `shadowroot` attribute on the template element, which the example I linked to does not use. The second line of code in that example is `<template shadowrootmode="open">`.

All of this is mentioned at the very top of the article where it says: "Note that the specification for this feature changed in 2023 (including a rename of shadowroot to shadowrootmode), and the most up to date standardized versions of all parts of the feature landed in Chrome version 124."

> Unfortunately, that support example will also break your code on other browsers.

No, it will not.

> 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.

10+ years is nothing compared with a human lifespan. Web standards are more likely to still be around in 50 years than react vX.

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.

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.

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.

if JSX is your issue, that means a web component framework like Stencil is just as bad as React. But then again you can use React with htm to avoid jsx if it really bothers you.

A React component only works in React. WCs are self-contained and work like ordinary HTML elements. If in the future you don't use React anymore, you can keep using your WCs without change, but not your React components.

Author here — have you never returned to an old project after months or years and found it difficult to get working again? Maybe a dependency doesn’t work with the current version of your operating system, or you’d like to upgrade some component that now conflicts with another?

I’m not saying avoiding this needs to be a top priority on every project; some things just will not exist without ongoing effort to maintain them, and that’s okay! But for the other things, cutting the dependency surface area to an absolute minimum makes them significantly more resilient.

I mean you don't have to look far, it was just two years ago that React 18 was released, where the way detached nodes are handled changed. That broke integrations with pretty much every legacy plugin that needed to do that, and you had to wrap it specifically for React. If you live fully immersed in the React ecosystem, then maybe it wasn't a problem, but for a lot of projects, it was a very painful upgrade. The change itself wasn't large code wise, but the fact that if you wanted to upgrade React for some reason, you also had to go touch and test all these old pieces of code, really did not do anyone any favors.

Exactly. Good breakdown.

> 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.

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.

I can't comment on react, ssr etc, but one thing that I've been wondering about as a php developer is why even use custom elements at all, let alone web components?

As you say, why not just send normal, raw html down the wire?

I suspect I'm missing something though. Perhaps it's to do with being able to encapsulate/isolate each component's css and js, such that if you mix components across projects (or have different teams working on different components), their css and js have no chance of conflicting. Even if you are a single team, it would still, presumably, allow you to import existing components from external libraries etc...

Well, even in a server-side PHP app, you have some client-side stuff for better interactivity and a smoother experience. Custom elements let you encapsulate this stuff. It's really not necessary, but if you want to reuse or redistribute them, they are pretty nice and self-contained (mostly).