alright @slightlylate, I'm intrigued by your rants against React and I want to refresh/update my understanding of web client development using built-in web components, etc. What's the right starting point?
I've started a dozen or so small webdev projects in the ES6 / no-bundler future... all but one hit the "screw it; I'll just use webpack" point over some CJS-only dependency. :-/
My most recent experience with web components was a joy, though.
If I were teaching this, would start out with an inline <script type="module">...</script> in a page and build out a component or three that only have light DOM, then work on moving them out to module scripts w/ `import`, then look at things like shadow DOM and styling.
Assuming the components you've got are simple-ish, I'd try porting/rewriting them in a few different tools; lit/open-wc tooling is nice, and Stencil is great.
Once you've got a favourite, I'd work on exporting a WC from one of those tools and then do an integration.
Through that journey, you'll get an appreciation for how the basic APIs give you a full lifecycle to work from (that you can always reach back to), and how the libraries on top add reactivity in an interoperable way, at low incremental cost.
Once you get through all of that, there are many styles of building, and they all have advantages/tradeoffs.
E.g., the way Elix is built almost entirely of mixins is really interesting:
And Haunted is nice for React refugees:
One last thought: CSS got REALLY powerful in the last couple of years. Many things you might have needed a framework for regarding layouts and animations are now either part of the Web Animations API or handled by new layout modes like Grid. Worth digging into as you explore.
Safari supports everything web components except native element subclassing e.g. extends HTMLInputElement.
On the topic of nice-to-haves: it also recently shipped some of the custom element form association APIs
It also supports all the CSS APIs Alex listed above
There's a narrative that "WC might be fine for the leaves, but you need <bloated thing> for full apps", and that seems to come from folks who don't understand what they actually do and don't need. Puncturing it has huge value.
would be nice to shortcut this; tho I have heard many say there is no compression algorithm for direct experience. its clear that folks will opt into whatever narrative they want to believe and popularity/group membership almost forces it. only way to undo is direct experience.
Give it time
The conversation is still dominated by the outspoken minority (ie DevRels) pushing for FW adoption
But the majority of web devs (ex WordPress) have been avoiding FWs altogether
WC have all the benefits of encapsulation w/o the ridiculously high cost of FWs
Suggest modern-web.dev/guides/ for buildless and testing.
Also note that once you get the basics, a light, prudent framework that is constantly working to minimize its footprint like @buildWithLit, is still super nice an brings back some of the abstractions that actually help you.
Not stupid. A lot of the problem with this stuff is we actually have unlearn the convoluted build systems we previously used. Yeah serve right out of node_modules or let esbuild do some bundling that doesn’t transform your app code much.
The problem is that so much of the job market specifies job candidates have existing commercial React experience.
I've never bothered with an application framework for any apps I've built, just using WCs (Polymer/Lit) for structure, but now I can't find work, because React.