I’m aware that the era of web components is upon us and that plenty of people are excited about them.
So I figure I better get my act together and start getting to grips with them.
The thing is, I’ve long been an advocate of the kind of approach to web dev articulated by Jeremy Keith in his ‘Building’ talk, which he gave in January at New Adventures 2019. I wasn’t there but I was particularly taken by 6 of his slides that he shared on notist: slides 34 to 39 to be precise. I tweeted about them.
The important point about Jeremy’s slide 39 is that JavaScript is still an enhancement, not a dependency. I know it’s old fashioned to say this, but I still think @sil’s Everyone has JavaScript, right? matters.
And it’s with this in mind that I’m looking for clarity on the landscape of web components.
I’ve speed read (but not yet knuckled down with) a few tutorials and introductions to web components. All the ones I’ve seen just hand wave over how the code gets deployed to the user, or assume you just know all that stuff.
The intro on MDN describes web components as:
“A set of JavaScript APIs that allow you to define custom elements and their behaviour, which can then be used as desired in your user interface.”
My reading of that is that if JS doesn’t run in the client, the web components don’t either. Is that right?
In other words, are old fogeys like me gonna have to accept that the world of total JS dependency is nigh, and we just better suck it up?
Or is it the case that one can have an authoring environment that then deploys the components as regular HTML and CSS, with JS still an enhancement?
Is there somewhere that is making this environmental stuff clear that I’ve missed? Perhaps one which describes what the dev toolkit can be other than Node – for laggards like me who are still heavily invested in PHP/MySQL frameworks?
Hoping someone can help.
Top comments (4)
Web Components are JS. They directly manipulate the DOM similar to the way devs used to w/ document.createElement() but with a hell of a lot more capabilities for efficiency and encapsulation.
For now. Most devs working on WebComponents use some sort of microframework (see open-wc). ITT, I'm one of the very few building WC in a way that requires no build toolchain. If you want to see it in action look up VanillaWC.
Thanks Evan. I will definitely look into VanillaWC more than my cursory look just now.
What has prompted my sudden growth in interest in WC is every-layout.dev. In reviewing their component demos yesterday, and looking at caniuse, I've discovered the following:
It's a WIP for now, I still need to build an entire proof-of-concept site using only WC. Either way, feedback is always welcome in the vanillawc/vanillawc issues.
I've heard of every-layout, guess I need to take a closer look.
A lot of the "WC aren't supported" talk is just FUD from the framework ecosystem. Specifically, React devs love to trash WC b/c React is fundamentally incompatible w/ Standard Web Components.
The reality. The latest Edge evergreen switched to using the same rendering engine as Chrome. Ie Edge should now support everything Chrome does.
The last major blocker is IE, which is a PITA for everybody using ES6, ES modules, CSS Flex/Grid.
Interesting, thanks.
With regard to IE, I set out my current thoughts in a short Twitter thread, culminating in a link to Sam Thorogood's excellent What To Expect When You're Expecting To Drop IE11 on this here site.