alt Hacker News>No build process, no web-packer, no framework, no npm requirement. Just include the JS in your HTML and then you can create and include components.
How does the rest of your codebase look?
This is the primary problem with web components. No frameworks sounds nice in theory, but it only solves about 30% of the problem. The rest ends up an ad-hoc mixture of libraries and custom code for state management, routing, styling, cross-component communication, etc, to the point that you end up building your own framework that is brittle and unmaintainable. Applications like this generally end up as a huge confusing web of global event buses or with multiple tightly coupled layers of prop drilling because of that.
There was a dream that was web components once upon a time. It felt like the future. But the APIs ended up half implemented (poorly), and the spec was more or less abandoned by everyone but Google. Browser vendors could have done things right, and focused on pulling in the good things from the framework world (i.e. what happened with jQuery), but they didn't.
Replies
> the spec was more or less abandoned by everyone but Google
This is very, very much not true.
All browsers are very up-to-date with web components APIs, and Safari is leading in some areas like scoped custom element registries, which they're about to ship first.
> How does the rest of your codebase look?
Quit neat, compared to the React/Redux things I've maintained in the recent past.
> No frameworks sounds nice in theory, but it only solves about 30% of the problem.
"No framework" is not meant to be a prescription, it is an indication of the dependencies.
IOW, I mean to say "No framework required", I did not mean to say "Don't use a framework with zjs-component".
> the [web component] spec was more or less abandoned by everyone but Google.
Are you being sarcastic, maybe?
I think Google has done a great job of making Web Components seem both poorly implemented and way too complex. If Angular is the "Google blessed" way of writing Web Components and Angular makes a terrible hash of it, who can build good Web Components?
Angular and a couple other well known frameworks were targeting for far too long pre-spec Google-specific versions of Web Components and Web Components moved quickly past that and settled into cross-vendor specs with smarter defaults and simpler APIs a lot of the marketing damage was already done that Web Components were too complex and too poorly supported.
So much of the Web Components world is stuck with the quagmire of the Shadow DOM, and while there are some generalized use cases for the Shadow DOM, I have the harsh opinion that the Shadow DOM was mostly invented to be "better IFRAMES for Ad Publishers" and not much else. I don't think enough web developers yet realize that the Shadow DOM is entirely optional and its complexity is so much easier to ignore and toss than to try to utilize.
> focused on pulling in the good things from the framework world (i.e. what happened with jQuery), but they didn't.
I'm coming to the growing opinion that between Web Components and the TEMPLATE tag Browser vendors have finally caught up with some of the best ideas of the Knockout-era "Progressive Enhancement" world, assuming you ignore the Shadow DOM as mostly YAGNI.
Sure, a lot of cross-component communication and some of state management goes back to DOM APIs and DOM event management, but there used to be a lot of knowledge in those areas and maybe it past time to return to Vanilla JS ideas about some of that. In the time since jQuery and Knockout, all browsers today have much more consistent DOM APIs for event management, at least.
(Similar for routing. Vanilla routing, even "SPA" routing is easier than ever with modern APIs, even the API not fully standardized and cross-browser yet, but also the improved APIs for hash navigation. Also, Web Components seem a great reminder that MPA routing is great and brilliant, and so well tested in browsers and servers. With View Transitions now generally well supported, and getting better, many MPAs feel as good or better than SPAs even.)
(And I feel like most styling problems with Web Components are self-inflicted with and by the Shadow DOM. It's nice to embrace the cascade again, if you can.)
I was bullish on Web Components for a while, but most of my complaints have disappeared in recent months, and especially in realizing that I was very happy ignoring everything about the Shadow DOM. Sure, I'm not using Web Components without a "framework" but I'm using a far smaller "view engine" than a React or Angular, a lot more "Vanilla", and feeling a bit like it's a Revenge of Knockout sort of era.
Disagree, done several custom frameworks for highly regulated areas and high load userbases - and as long as you keep to seperation of concerns it is a lot more nimble and long term viable - easy to wield that 200000 dependencies just to set a history state