Web Components: A Cautionary Tale about the Shadow DOM and innerHTML
After six years of writing React professionally, I have decided that I really
prefer Web Components to React,
Angular, Vue, or any of their ilk. Web Components are the browser's native model for defining
components; they don't need huge libraries to "route around" deficiencies in the browser nor do they
need special context or event types; they just use the browser's own event dispatcher, and context
is managed by putting stopPropogation
on the context handler's DOM Node.
I recently spent some time trying to port my old jQuery/Backbone demo, Fridgemagnets, to a Web Component model.
I started out by using Lit-Element. Lit is a very small toolkit from Google which creates a bundle of only 5KB, much smaller than React's 40. I had good reasons: due to the history of Web Components, the API is awkward with very long method names and an annoyingly complex dance to convert text to a DOM Node. Lit streamlines a lot of that, but it also adds something that I usually find annoying: all your events that cause a state change in a component are batched and propagated at once, debounced to prevent refresh pauses. Lit wants to make web components "reactive," so your state is stored in monitored attributes.
For the most part, I can live with that. But in the conversion to FridgeMagnets, I hit a headache.