WebComponents Are (a Part of) the Future
There’s been a big brouhaha about whether Web Components have lived up to their promise. Can they replace React? Definitely not. But they can absolutely augment it and minimize the need for React in many apps.
What started nearly ten months ago as a simple exploration of state machines (inspired by CGP Grey) has now grown into a full-fledged existential crisis, leading me to question web development and the virtual DOM.
The simple GIF you see below was a product of four complete re-writes. And since I’m a new father caring for a 1.5 year-old, those four rewrites took me about six months. (Imagine me getting 3 hours of work in per week, with the first hour being mostly me scratching my head wondering what exactly I was doing the last time.)
My first implementation was, like all new side projects, in React. It’s the framework I knew best, and I just wanted to get something out the door. Professionally, I make simple CRUD apps that toggle buttons and call various endpoints. And while React is more than sufficient for those types of use cases, it simply wasn’t cutting it for a game or more complex animation. Rich Harris has talked about this extensively, and it was a big motivation for him creating Svelte. In this case, React topped out at around 40ps, and there was noticeable jitter when dragging pieces around.
My second implementation was creating one giant SVG. SVGs are handled by the browser in the fancy Skia engine by simply converting SVGs to Skia commands, and theoretically this would unblock all the performance I needed. That was all well and good, but SVGs are really not built to handle things like grid of flexbox. For example, SVGs have no concept of z-indexes, so when I wanted the currently dragged piece to show up on top of everything else, that was basically impossible to do. I also kept running into other layout issues, and the whole approach felt rather cumbersome. (The performance was as promised though!)
My third approach was just raw JS with some fancy CSS-based clipping to form hexagons, but rely mostly on flex and grid to handle the finer details. This was great from a usability standpoint, but still had performance issues. We were now up to 90 FPS, but resizing the board was abysmal.
The broader issue was that, I still didn’t know what type of web server I was going to use. I try to learn new technologies for side projects, and it didn’t make sense for me to have to commit ahead of time. Also, if hexagonal chess was ever going to be popular, it would need a sort of forum / community where folks could easily embed games they had played and share. The board would have to be fully functional, where certain moves could be pre-programmed in, while others could evaluate new lines that hadn’t been played.
All of this mandated a framework-agnostic solution.
Advantage 1: Performance
Webcomponents solved basically all my problems. Since there is no virtual dom, you’re at the very least starting from my second approach (already twice as fast as the React approach).
After learning even more about hexagons (major shoutout to Red Blob Games), my performance was as you see above. Perhaps more impressively, even resizing the board is now blazingly fast.
People seem very hung up that web components should be used in place of every button, every tooltip, every etc. Almost like they’re supposed to replace a full fledged component library. I’ll be the first to admit they are far too heavy-weight for that. But if you have a webapp that has one or two extremely complicated components, then in my opinion it makes more than enough sense to move those to dedicated web components.
For a calendar app, this may be the calendar view itself. For a project planner, perhaps the Gantt chart. Narrow, load-bearing cases where performance really matters.
Advantage 2: Minimal Dependencies
All of this was done with (almost!) no dependencies! I’m in control of all the code, and if something weird is happening I can fix it myself. Currently I’m using lit, but now that I’m more familiar with web components I can honestly say I don’t even think it’s that necessary! Web components are just not that hard, and the team has done a fantastic job in making them more accessible.
Advantage 3: Easy Distribution
The best part is that the install story is dead simple. Have a blog and want to show a hexchess board on your site? Just add this:
<!-- Polyfills only needed for Firefox and Edge. -->
<script src="https://unpkg.com/@webcomponents/webcomponentsjs@latest/webcomponents-loader.js"></script>
<!-- Do NOT use unpkg due to https://github.com/mjackson/unpkg/issues/351 -->
<script type="module" src="https://esm.sh/@hexchess/hexchess-board@latest/hexchess-board.js?module"></script>Then you can embed a hexchess board anywhere you like:
<div style="width: 100vw; height: 100vh">
<hexchess-board
id="hexchess-board"
board="start"
orientation="white"
></hexchess-board>
</div>My own site, hexchess.com, currently works the exact same way. Everything else on the site is server-side-rendered via Phoenix Framework, and I let the bulk of the complexity rest on this rather well-tested web component.
Disadvantages
Because each web component now lives in isolation, the communication boundaries must be drawn clearly. Each component has its own API and emits a few custom events or takes in a couple properties. This lets the developer properly separate concerns.
If your website has a single major web component, this is not only fine but honestly perfect. As someone who was coding on three or four hours of sleep a night with a baby in one hand, this let me just dump stuff onto the board and worry about that later when I was programming the server. And when I was programming the board, I could just emit whatever I needed, and worry about the other side another day.
The issue is, obviously, this approach would not scale to tens or hundreds of custom components. But having worked on a calendar app where we use Full Calendar, this web components-style approach is already what’s happening. The calendar devs practically have to memorize Full Calendar’s API anyway, so the burden of an “extra” API to know about doesn’t really matter in most heavy / custom webapps.
The only major disadvantage I’ve seen is that we’re not yet ready to replace React or Svelte or whatever and just go full web-native. That promise definitely has not been fulfilled yet. But honestly, in 2024 are you really still clamoring for web components just to help make trivial buttons?
As a component author, you want to enable people to make cool, performant experiences and let people build on your components regardless of what framework they’re using. And for that use case, web components more than solve the need.
P.S. Chrome Dev Tools is actually built using Lit! So you can power some incredibly cool experiences with nothing more than web components.
