DEV Community

loading...

Discussion on: Why React is winning over Angular?

Collapse
scott_yeatts profile image
Scott Yeatts

Having worked in Web Components for years (since 2018 when Firefox adopted the spec), and ALSO having years in React and both flavors of Angular, this comment intrigued me.

To be honest, the compiler approach that Svelte, Stencil, Catalyst and others of the new generation of frontend tools have taken has really been a breath of fresh air after a decade of overly-complicated framework madness (this includes React). All of them have at least the option to compile to Web Components, and two are WC native

I would never say those are always the right choice, the same way I would never pick a frontend or backend framework for every project, but I will say I don't see any similarities between Web Components and Angular.

I'm interested in what experience or reading brought you to this conclusion! The only pitfalls I would warn my clients about are that they don't have the same level of third party library support... But since they are native to the browser (as part of the spec) that's a lot less concerning than a custom run-time that you have to download into the client to interpret your code.

It's really more of a tradeoff, where you need more custom third party libraries written for React and Angular as custom run-times vs being able to use vanilla js tooling with WC, but the most popular framework-specific libraries won't be available unless you introduce the framework as a wrapper/controller/router to contain your WCs. It's really all about what you need to accomplish, and I just didn't understand where you're coming from. Thanks!

Thread Thread
lukeshiru profile image
LUKESHIRU • Edited

Richard Harris made an excellent summary of the issues Web Components have (and still have nowadays) here. I used to love the idea of native web components (I was one of the early adopters of Polymer), but the thing is they still have lots of issues that can't be solved easily.

Some of the issues that come to my mind: A11y and styles are kinda busted if you use shadow DOM (one of the main selling points for encapsulation of WC), SSR is kinda useless without loading JS, prop handling needs you to observe props to react to the changes, you have to use classes even if your component is just taking props and rendering based on them, the is property is not fully supported yet, and so on...

Thread Thread
scott_yeatts profile image
Scott Yeatts

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!