Isomorphic Web Components
jakelazaroff.com
jakelazaroff.com
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.
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.
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.
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.
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...
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.
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.
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'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.
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...
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.
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...
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.
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 `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.
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!
The thing that is lost on me with all of these webcomponents solutions is that they inevitably rely on tagged templates to do the heaviest lifting.
I don't want to write strings, I want to write statically analyzable code. IDEs do some heavy lifting here for visual hints, and there are a few html-in-js linting solutions, but none of them are very compelling.
> You’d be forgiven for thinking you were looking at a React component! Frankly, I don’t see a fundamental difference between these and frameworks like Svelte or Vue
Regardless of whether you should be forgiven for thinking it’s a react component, it omits it’s biggest strength - JSX is just JavaScript function calls, and thus can be composed as JavaScript and type checked as java/typescript.
This to me is the fundamental difference between React/JSX and other approaches. Any framework that gives up on type checking for the view layer is a non-starter in my books.
Vue, Svelte, web components, and vanilla only execute code that is marked as a callback.
Example:
let x = 0
var counter = computed(() => ... )
DOM + JavaScript is the same
React invokes the entire component function and all calls and allocations in the path of the component function. The mental model is inverted in a sense.
This is one of the reasons React generally performs more poorly in both speed and space.
Lit's templates are HTML with bindings. They're very analyzable, including checking for valid structure, associating tags with definitions, type-checking bindings. The tools that do this parse template strings, build an AST, and run analysis passes just like other source analysis tools.
Developers get standard intellisense features like jump-to-definition, hover-over docs, errors on invalid properties and events, etc.
But also... templating is an implementation concern.
To build a web component you don't have to use a tagged-template-based system. There are template systems that use JSX. You can use Preact, or React themselves. And your component users don't ever have to know what template system you chose to implement your component.
I work on one of the underlying libraries that provide it said portability, Extism, and I love to see how WebAssembly actually bring some of the coolest parts of the web browser into other applications.
Let's say you are making a splitter component. Do not do this:
<my-splitter>
<div slot="left">
<my-handle slot="handle">
<div slot="right">
</my-splitter>
<my-splitter>
<div data-slot="left">
<my-handle data-slot="handle">
<div data-slot="right">
</my-splitter>
Stay on the light side.
https://lit.dev/docs/ssr/overview/
I also sort of made SSR work under next.js (not to be mixed with server-components), but that took a lot of hacks and going off the beaten path:
I don’t think it means what they think it means.
To me, two types of values are isomorphic if they share the same cardinality. The isomorphism between two isomorphic types is a pair of morphisms (functions) that when composed one after the other is the same as doing nothing.
This word is a couple hundred years old, so it long predates front-end development. It has a pretty specific and established meaning in mathematics. It’s not right to use this word when you just mean “shared code”.
A technical term having a different meaning in two different fields doesn’t mean that the version with which you’re more familiar is correct and everyone else is wrong. That would be like commenting on an article entitled “Syrian rebel forces take Damascus” to say “National-security people keep using the word ‘forces’. I don’t think it means what they think it means. To me, force equals mass times acceleration.”
I don't have a background in mathematics either, but I think it's quite clear that the use of "isomorphic" here as a stand in for code sharing is forced, to say the least.
It's the same kind of silliness as using the term "tree shaking" in place of dead code elimination (which is, you know, an established technical term in the same field). In this instance however, instead of using a fancy-sounding word (which I think is a little pretentious), they've gone with an analogy with a less obvious meaning (what are you shaking from the tree? Are the good bits falling off also?).