Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
Yeah, that post is one I normally point to when I'm trying to introduce modern Web Component compilers to folks. Here's a comment I left for someone wondering about using Svelte with a web component compile target. I largely disagree with Rich's post, but I like to give him his due. He's written some great tools, I just think he's got some weak points in his stance on WCs. It's something I'd rather debate over coffee and not in little chat boxes!
I was an early polymer adopter back in 2016 or so too. It wasn't ready then, and it was still running off of the old pre-approval v0 spec, which needed significant retooling. I didn't return to WC's until 2018 or so because of the initial issues with it.
It is important to highlight some of the arguments against WC's like Rich's, because it's an architectural choice. Like I said, not every problem is a nail, and WC's definitely aren't a silver bullet. I find myself defending them often (generally due to unfortunate early implementations from 5 or 6 years ago), but keep in mind my defense is that they are a viable and legitimate approach... not necessarily the one I would always take!
Accessibility and styles being busted is also a common misunderstanding. There are longer breakdowns out there, but my favorite is in LogRocket's "React vs Web Components" article (Check out the accessibility section). I don't suggest ANYONE try and do large application development on base web-components without a compiler (too much boilerplate), but especially if you're extending an HTML element, there's no issue with accessibility. If you're creating a purely custom element, the "role" attribute is there to help, even if the "is" attribute isn't supported in... Internet Explorer and Safari?
Shadow DOM has never presented me with an accessibility problem above and beyond what I might expect in any other JavaScript context like React and Angular, but I'm open to any current links (IE: Within the last year or two), as I'm not an accessibility consultant, so there may be a problem I've missed :) It's really been testing tools which haven't adopted support for it that find me using "open" Shadow DOM more than anything else.
Most of the popular compilers have a SSR solution (I Linked Stencil's SSG capability which has a link to their SSR solution at the bottom), and especially when using a framework like Ionic's stencil, GitHub's Catalyst, or even Svelte's Custom Element API (Which Rich Harris still supports, even if he doesn't love Web Components), prop/attribute confusion tends not to be an issue. Not a lit-element fan (mostly because I haven't played with it enough), but I feel like it deserves a shout-out here too :)
Finally, I can't ignore all of the enterprise adoption that's been happening on the WC front. SalesForce has been using them since 2016, and released their component builder in 2019, GitHub uses the aforementioned catalyst in production, Apple has used them, RedHat has used them in their Design system PatternFly to create PatternFly Elements... the list goes on, so it seems that WC's are starting to gain some good traction...
All that said, I see WC's and the compiler pattern as a path out of the overly-complicated framework wars that have engulfed the front-end ecosystem for the last decade+, but again, they can be complementary to the frameworks as well as replacements for. No silver bullets here!
I guess working in a natively supported browser technology rather than the custom runtimes we've all gotten used to has me remembering that there's an easier way. A lot of the WC FUD I tend to see feels a lot like when we were all jQuery developers circa 2009 and were convinced you couldn't download ALL the JS for a framework, and the SPA pattern felt like madness haha.
Thanks for responding to me!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yeah, that post is one I normally point to when I'm trying to introduce modern Web Component compilers to folks. Here's a comment I left for someone wondering about using Svelte with a web component compile target. I largely disagree with Rich's post, but I like to give him his due. He's written some great tools, I just think he's got some weak points in his stance on WCs. It's something I'd rather debate over coffee and not in little chat boxes!
I was an early polymer adopter back in 2016 or so too. It wasn't ready then, and it was still running off of the old pre-approval v0 spec, which needed significant retooling. I didn't return to WC's until 2018 or so because of the initial issues with it.
It is important to highlight some of the arguments against WC's like Rich's, because it's an architectural choice. Like I said, not every problem is a nail, and WC's definitely aren't a silver bullet. I find myself defending them often (generally due to unfortunate early implementations from 5 or 6 years ago), but keep in mind my defense is that they are a viable and legitimate approach... not necessarily the one I would always take!
Accessibility and styles being busted is also a common misunderstanding. There are longer breakdowns out there, but my favorite is in LogRocket's "React vs Web Components" article (Check out the accessibility section). I don't suggest ANYONE try and do large application development on base web-components without a compiler (too much boilerplate), but especially if you're extending an HTML element, there's no issue with accessibility. If you're creating a purely custom element, the "role" attribute is there to help, even if the "is" attribute isn't supported in... Internet Explorer and Safari?
Shadow DOM has never presented me with an accessibility problem above and beyond what I might expect in any other JavaScript context like React and Angular, but I'm open to any current links (IE: Within the last year or two), as I'm not an accessibility consultant, so there may be a problem I've missed :) It's really been testing tools which haven't adopted support for it that find me using "open" Shadow DOM more than anything else.
Most of the popular compilers have a SSR solution (I Linked Stencil's SSG capability which has a link to their SSR solution at the bottom), and especially when using a framework like Ionic's stencil, GitHub's Catalyst, or even Svelte's Custom Element API (Which Rich Harris still supports, even if he doesn't love Web Components), prop/attribute confusion tends not to be an issue. Not a lit-element fan (mostly because I haven't played with it enough), but I feel like it deserves a shout-out here too :)
Finally, I can't ignore all of the enterprise adoption that's been happening on the WC front. SalesForce has been using them since 2016, and released their component builder in 2019, GitHub uses the aforementioned catalyst in production, Apple has used them, RedHat has used them in their Design system PatternFly to create PatternFly Elements... the list goes on, so it seems that WC's are starting to gain some good traction...
All that said, I see WC's and the compiler pattern as a path out of the overly-complicated framework wars that have engulfed the front-end ecosystem for the last decade+, but again, they can be complementary to the frameworks as well as replacements for. No silver bullets here!
I guess working in a natively supported browser technology rather than the custom runtimes we've all gotten used to has me remembering that there's an easier way. A lot of the WC FUD I tend to see feels a lot like when we were all jQuery developers circa 2009 and were convinced you couldn't download ALL the JS for a framework, and the SPA pattern felt like madness haha.
Thanks for responding to me!