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?

/subscribe (I've found MDN good. All the frameworks seem to still be bundler obsessed which isn't for me.)

Yeah I'm ready, for this refresher, to jump into raw ES6 / whatever is supported in modern browers without bundling / transpiling.

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.

Great question! The Web Fundamentals site is good in terms of the low-level bits (in addition to the MDN docs, which have gotten good!): developers.google.com/web/fundamenta…

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.

When you've got a flavour for that, you'll probably be a little tired of writing out boilerplate for things like plumbing attribute values, and a library for automating things will seem attractive.

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.

E.g., start a boilerplate Vue or Angular start project and try to integrate your component into it. It will be interesting!

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.

And most of all, you'll be writing HTML most of the time. And so will the folks who you give your components to.

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: component.kitchen/elix And Haunted is nice for React refugees:

This is lovely, thank you.

Yes this is great!

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.

awesome. One painful question if you have time to address: how much of this breaks on mobile Safari?

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

why this step tho? are there no entry points tools / frameworks / or plain approach to "app building" with WC that doesn't involve adopting the whole ecosystem of those frameworks?

think this step exists to help people realize how pointless this step is…

💯 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.

I think all that's missing from a true frameworkless future: - no page loads on navigation (Portals!) - local routing control

e.g. 80% of React dev work is building components and data, ~20% Routing

Ironically, routing is relatively easy to implement But most people use web components in conjunction w/ frameworks so framework-less routers aren't discussed much

EXACTLY

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

yeah that checks out; its funny how many contortions people will go through for those features given how many situations require neither

And more to the point, they're actually cheap-ish to build in userland these days? Dynamic import is good.

one thing that I don't understand at all in non-framework modern front-end right now is dev ergonomics -- testing & easy reuse of others' code. I look forward to understanding how this can be solved.

Suggest modern-web.dev/guides/ for buildless and testing. Also code reuse is super easy, barely an inconvenience when you don’t have a huge framework dictating the hoops to jump through. It’s just JavaScript.

My setup has typescript so not completely buildless. But it’s basically pass-through compiled, and tests run through a real browser. So much of a typical tool chain is just obliterated.

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.

Thank you for all this!

Dumb question: is npm kosher for this modern framework-less web? I imagine it is a must, but trying not to make too many assumptions.

Yep, npm is how I do it. Lately been toying with directly importing from urls and using import maps. Trade offs.

Another stupid question: and then you bundle the npm packages or... What's the browser delivery mechanism for those dependencies? Just serve the node_modules dir as static?

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.

_furiously copies homework_

I also found this page to be a useful companion when building custom elements from scratch

Good shout!

Two good starting points for Web Components: - developer.mozilla.org/en-US/docs/Web… - developers.google.com/web/fundamenta… #WebComponents

Offering my seasoned, personal help if it’s going to support voting systems or democratic initiatives.

Awesome :) right now it's more for me leveling up, but may be helpful to VotingWorks in the future!

I like open-wc.org, and it has a group of talent to help on the Lit&Friends slack channel.