51–60 of 279 posts
I don't know any project in JS-land that is more serious about semver, backwards compatibility and reliable upgrades than react. If facebook dropped the project tomorrow, Vercel alone could probably continue to maintain it well.
The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like ). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't sc…
> To re-render, you have to manipulate the innerHTML--usually replacing the string every update
"Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What you're really giving up, then, is the reactive programming model. Web Components are just a way of modularizing things; they have nothing to say about how you update the DOM (for better and worse).
You are right (I think) that there's no good way around converting attributes to and from strings, though the performance overhead there should be minuscule in most cases. The bigger problems with that are a) some data (like functions) can't be serialized at all, and b) it leaves a lot of room for passing invalid values
I'm moving towards vanilla JavaScript for my platform, and one of the things that I've discovered is that if you have a reactive data source then you don't need a lot of framework. Granted, I'm taking advantage that the core platform is much more stable than a decade ago.
What is a reactive data source?
Don't use it
Earlier quoted context omitted.
I don't think so. I want to wrap webgl games with a custom component, and they share basic UI (which are also custom component dependencies). But none of this has anything to do with the larger web application (Angular) which manages much much more. So stuck with iframes which although I can hide to some extent, are terrible.
But React does much much less than Angular.
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like ). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't sc…
> Web Components is it's slower than React or other vDOM implementations > To re-render, you have to manipulate the innerHTML--usually replacing the string every update "Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What y…
Earlier quoted context omitted.
> Web Components is it's slower than React or other vDOM implementations > To re-render, you have to manipulate the innerHTML--usually replacing the string every update "Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What y…
If you're using a framework like lit-html as the author recommends, it will replace the string every update. Most people will prefer that way since it's more ergonomic and similar to React. You could do imperative DOM updates, but that'd be like going back in time to jQuery.
Earlier quoted context omitted.
Anyone know what is going on with lit-? Their TypeScript starter is painfully bloated and outdated and never seems to keep pace. I actually ended up looking at microsoft/fast for my use case but that seems to be stale in some way. I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring. Note: I cannot do better.
Can't speak for the Lit framework, but never had any issues with lit-html or it's typescript defs, it's been rock solid.
I don't use lit-element, it's too heavy for me.
lit-html, on the other hand, is wonderful and rock solid.
I typically do light dom components, rendered with lit-html. Simple classes that extend HTMLElement.
When I want reactive style, I add setters that call render(). When I want imperative, I add class functions.
All my components generally take care of themselves and are mostly encapsulated, they'll generally have a init() method that loads the data they need, and calls a setter which kicks off the render cycle.
Alternately, data will be passed from a parent component via a property, and that'll also kick off the render cycle.
In many cases I do a combination of the two in order to support deep linking.
I'll mix and match design systems sometimes, depending on the payload weight. Ionic, shoelace, etc...
The Vaadin router ties everything together beautifully.
I also have a small state utility called ApplicationState[1] that I use for the edge case of cross-component communication and triggering. It provides a graph-based approach to notifications/state change.
I've been using this approach for several years with success, with deeply complex and large applications and small lightweight tiny footprint apps.
Aren't web components more of an addition to frameworks like Bootstrap than a React replacement?
Really enjoyed this article. Web components seem promising, I played around with them a bit but I found it difficult dealing with global styling (ie, how do I make my component have the same colour scheme as everything else?). Probably worth looking into again. I also concur with the author about lit-html. It does one thing and does it really well, easy to understand, and no transpiling needed. Can't recommend it eno…