Andy Bell is documenting is journey of getting to grips with web components. I think it’s so valuable to share like this as you’re learning, instead of waiting until you’ve learned it all—the fresh perspective is so useful!
One of the things we’d hoped to enable via Web Components was a return to ctrl-r web development. At some level of complexity and scale we all need tools to help cope with code size, application structure, and more. But the tender, loving maintainance of babel and webpack and NPM configurations that represents a huge part of “front end development” today seems…punitive. None of this should be necessary when developing one (or a few) components and composing things shouldn’t be this hard. The sophistication of the tools needs to get back to being proportional with the complexity of the problem at hand.
I completely agree with Alex here. But that’s also why I was surprised and disheartened when I linked to Monica’s excellent introduction to web components that a package manager seemed to be a minimum requirement.
Monica explains how Shadow DOM could be the perfect answer for scoping CSS:
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
A really great introduction to web components by Monica. But I couldn’t help but be disheartened by this:
Web components tend to have dependencies on other web components, so you need a package manager to herd all them cats.
For me, this kind of interdependence lessens the standalone nature of web components—it just doesn’t feel quite so encapsulated to me. I know that this can be solved with build tools, but now you’ve got two problems (and one more dependency).
Smart thinking from Harry here on a common issue when it comes to naming and styling. As he points out, the solution is not technical, but lies in how you form your mental model:
The design issue here is solved by subtly inverting the problem.