The Failed Promise of Web Components

Moreso than that, Lea is near the end of a Ph.D. in David Karger's group, an expert on CSS, and overall amazing researcher and developer for the web.

If you build an app with web components, even if you're using one specific helper library to do it, it makes it possible, easy even, to incrementally migrate to other libraries. You can migrate top-down, bottom-up, or even middle-out to other helper libraries and have a continuously working app. You can import and use another web component built with another library without being constrained to just the framework you chose.

You can even build an app with all web components, later decide you really don't like them and want to use only a framework and still easily incrementally migrate top down and not break the app.

This makes web components the much safer choice for large and long lived projects, and more flexible for projects of all sizes.

This is a huge red flag for systems design to me. Whenever and whereever I've seen this abundance of assumed implicit knowledge instead of documented or introspectable configuration, the systems have invariably been excessively difficult and/or time-consuming to troubleshoot once in operations. This is overlooked and hand-waved away when the system is the new shiny, but once it becomes productionalized "legacy", it becomes a huge headache to leadership that appears to them as constant instability sucking up everyone's time on fire fighting instead of innovating more new shiny.

Here's to hoping better dependency management like from the Nix folks makes it into the mainstream platforms.

I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this).

React also doesn't have an easy means of turning React components into Web Components for publishing and consuming. (Preact does though, they put a lot of work into it).

Svelte, Vue, and (I believe) Angular can all emit web components.

In Vue, you can use the framework's standard data-binding and event capture syntax to interact with custom web components. You wouldn't be able to tell the difference between a Vue component and a Web Component you imported from a package.

(I can't speak for Angular, maybe someone could chime in here.)

To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard.

It seems silly to write a wildly popular component/component-library, and vendor-lock it to a single framework. Why not just publish a web component version as well?

https://cli.vuejs.org/guide/build-targets.html#web-component

https://preactjs.com/guide/v10/web-components/

https://dev.to/silvio/how-to-create-a-web-components-in-svel...

https://angular.io/guide/elements

Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile, because it doesn’t support https://caniuse.com/css-overscroll-behavior

Supporting swipe left/right fails hard on iOS Mobile Safari because the browser wants to history navigate back/forward if you misplace your finger, and it is easy to inadvertently refresh the page unless you are very careful not to. I don’t think there is any effective workaround.