Reading the article you can understand why perhaps I'm in this disillusioned area. I went all in Web Components for years. I could picture this future where everything just played nicely. My test harness that I play with is like 10 different libraries in Web Components all on the same page. In a sense it's kind of wonderful. I wrote a simple wrapper that could take any existing library component (VDOM, non-VDOM, reactive whatever) and turn it into a Web Component with basically a HOC.
And then the renderer I'd been working on proved that it wasn't just fast. It was the fastest. And as I got so engrossed in this zone I realized that Web Components were going to be the bottleneck. That's fine we don't need to wrap everything. And then when I started looking at the system holistically I realized Web Component timing based on DOM events was going to be very difficult. How do you do Suspense if the Web Component relies (and for good reason) on the connected callback. Well let's attach it to a different document when rendering offscreen. But what happens as soon as you are dealing with many isolated roots. The overhead and complexity due to time of using DOM APIs for things that don't have to do directly with the rendering was unnecessary. Similarly if you are not using a Virtual DOM but don't wish components to work under isolated roots (for things like Context etc) eager evaluation of child slots is broken. It's backwards. Basically there is always a performance cost. Web Components always add an additional overhead. I'm not going to say it isn't worth it in some cases, but it's hard to be defacto.
Rich Harris author of Svelte had an article a while back on Web Components and while I don't think he is actually right about most of the points. Point 5 is dead on. dev.to/richharris/why-i-don-t-use-.... Someone might just shrug that off as how the platform works. But it's incredibly important when you consider the ambitious things these libraries try to do.
So I understand the monolithic argument and I think using Web Components as a sort of micro-frontend approach seems reasonable. But this isn't unlike the classic issue we've had with state management. I suspect that the ability for the backend to split was the trend to make it more stateless, RESTful, etc. But someone is left holding the bag, the problem doesn't go away. We just pushed it to the client. And why not the closer to the client the more reactive we can be. Early MVC client frameworks like Angular1, Ember1 all failed here and required massive rewrites because they didn't understand their role in state management. That effectively a Controller was insufficient. KnockoutJS had a better approach with View Models which were instance based. React a few years later made it about Components (essentially the same thing) and we are here.
So how much can the client be split? Its and interesting question. We can use code-splitting to only load certain parts of the code as needed, but we are still working off a single backbone. I think there are opportunities to identify and isolate parts of an app, but we have to acknowledge the desire is for the pieces to coordinate in unison. This is very different than a micro-services backend. Even a completely separate advertisement panel should flow into existence. How much state does it share? How does it share that state? These are solveable but its not a hurdle you want to jump every time you render a panel. Or atleast that is my feeling. Libraries could work better with the platform for sure. But when they go beyond the whole DOM how can they view these components as anything other than just DOM elements?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Reading the article you can understand why perhaps I'm in this disillusioned area. I went all in Web Components for years. I could picture this future where everything just played nicely. My test harness that I play with is like 10 different libraries in Web Components all on the same page. In a sense it's kind of wonderful. I wrote a simple wrapper that could take any existing library component (VDOM, non-VDOM, reactive whatever) and turn it into a Web Component with basically a HOC.
And then the renderer I'd been working on proved that it wasn't just fast. It was the fastest. And as I got so engrossed in this zone I realized that Web Components were going to be the bottleneck. That's fine we don't need to wrap everything. And then when I started looking at the system holistically I realized Web Component timing based on DOM events was going to be very difficult. How do you do Suspense if the Web Component relies (and for good reason) on the connected callback. Well let's attach it to a different document when rendering offscreen. But what happens as soon as you are dealing with many isolated roots. The overhead and complexity due to time of using DOM APIs for things that don't have to do directly with the rendering was unnecessary. Similarly if you are not using a Virtual DOM but don't wish components to work under isolated roots (for things like Context etc) eager evaluation of child slots is broken. It's backwards. Basically there is always a performance cost. Web Components always add an additional overhead. I'm not going to say it isn't worth it in some cases, but it's hard to be defacto.
Rich Harris author of Svelte had an article a while back on Web Components and while I don't think he is actually right about most of the points. Point 5 is dead on. dev.to/richharris/why-i-don-t-use-.... Someone might just shrug that off as how the platform works. But it's incredibly important when you consider the ambitious things these libraries try to do.
So I understand the monolithic argument and I think using Web Components as a sort of micro-frontend approach seems reasonable. But this isn't unlike the classic issue we've had with state management. I suspect that the ability for the backend to split was the trend to make it more stateless, RESTful, etc. But someone is left holding the bag, the problem doesn't go away. We just pushed it to the client. And why not the closer to the client the more reactive we can be. Early MVC client frameworks like Angular1, Ember1 all failed here and required massive rewrites because they didn't understand their role in state management. That effectively a Controller was insufficient. KnockoutJS had a better approach with View Models which were instance based. React a few years later made it about Components (essentially the same thing) and we are here.
So how much can the client be split? Its and interesting question. We can use code-splitting to only load certain parts of the code as needed, but we are still working off a single backbone. I think there are opportunities to identify and isolate parts of an app, but we have to acknowledge the desire is for the pieces to coordinate in unison. This is very different than a micro-services backend. Even a completely separate advertisement panel should flow into existence. How much state does it share? How does it share that state? These are solveable but its not a hurdle you want to jump every time you render a panel. Or atleast that is my feeling. Libraries could work better with the platform for sure. But when they go beyond the whole DOM how can they view these components as anything other than just DOM elements?