DEV Community

Why We Use Web Components

Max Lynch on July 08, 2019

Web Components are all over Twitter (again), thanks to a great post by Rich Harris about Why [he] Doesn’t Use Web Components. Rich details a numbe...
Collapse
 
nagaraj_hubli profile image
Nagaraj Hubli

I work as a consultant for one of the big market research company, and over the past 2 years we have built a library of web components which is now being used across various projects in the company, and any new project that's getting started is using this library to bootstrap the application, and the library has few web components which have business logic tightly integrated into them.

The business is seeing the benefits of using web components, as teams are free to choose the framework they want to work on while still being able to use the web components.

Collapse
 
alaindet profile image
Alain D'Ettorre

Any drawbacks? Developer-wise or performance-wise...?

Collapse
 
wintercounter profile image
Victor Vincent

We went on the way of writing our new UI kit in WebComponents using Stencil. We were suffering performance problems (using ~200) components on a single page, but it was reasonable. That was in Chrome but we checked Edge then. It took the site 20+ seconds to load! Upgrading to Stencil One then made it even worse. Seems like using slots is just not a thing using polyfills, it causes re-layout every time it moves an element in the DOM. After struggling for a month with it, we decided to port the kit to React components. Even solved every Chrome issues we had regarding performance. TLDR; WebComponents are fun, but if you need performance and your app has higher magnitude of complexity, native DOM ftw.

Collapse
 
maxlynch profile image
Max Lynch

Hmm, something seems up. Did you ever file an issue? Can dig into it on our end. We have a number of apps with many more components than that without those perf issues.

As for edge, unfortunately due to the lack of native WC support the slot polyfill is used which can impact performance. We see this as a short term problem though it may impact certain users more than others depending on how many Edge users you target. Edge is really the last thorn in the side of WCs.

Collapse
 
leob profile image
leob • Edited

Funny ... Edge was supposed to be a complete rewrite that was going to solve all the issues with IE once and for all, right? Guess we were naive to believe it. They should have just used Webkit, less headaches for them and for the rest of the world. Microsoft under Nadella changed a lot, but old habits die slowly.

By the way, fantastic post, Max! Really impressive work with Stencil, and the case for Web Components (e.g. in a larger heterogeneous corporate setting etc) is articulated well.

Collapse
 
wintercounter profile image
Victor Vincent

Well, the most important Edge user for us is the company owner :D Don't tell me... :)

Thread Thread
 
_ergo_ profile image
Marcin Lulek

Hey do you have a demo of old version of the component system somewhere to look at? Granted we do not use Stencil in our systems but we had pages with hundreds of components and never faced issues like this even in IE.

Thread Thread
 
wintercounter profile image
Victor Vincent

Unfortunately not. It's not public. What I can tell is that we were deeply relying on slots with multiple levels of nested components supporting multiple slots also.

Collapse
 
alaindet profile image
Alain D'Ettorre

Can you elaborate on why Web Components performed significantly worse than React components?

Collapse
 
wintercounter profile image
Victor Vincent

The main problem was the polyfilled slots in old Edge.

Collapse
 
megazear7 profile image
megazear7

Great post! I think the only thing I am not sold on with regards to web components is the concept of hydration. It seems to me that the correct solution should not be to mimic render the component on the server and then replace the light dom with shadow dom after the page comes on line.

I would almost rather see some standardization around web components using the light dom for stuff that should be SSR, and the shadow dom for stuff that is "internal". I don't know exactly what the best approach would be, but I would like to see some exploration around alternatives to hydration.

Although I think the "right solution" will be the one that major web component based libraries and frameworks can agree on over the next five years. If everyone seems to come to an agreement on it I would go for it, but before the community comes to a decisive opinion I would like to see some other options explored.

Collapse
 
kevnz profile image
Kevin Isom

"The reality is, if you add a tool or library on top of Web Components, like Stencil, suddenly almost all of those issues go away and the power of Web Components really shine through."

And there you go. If you have to have a framework to solve the problem, then you haven't really solved the problem. WebComponents do solve a problem, a problem nearly no team has. They are okay for low-level parts, but the API is clunky and dated. The web developer community has moved on from when the WebComponents spec was created, but the spec spent years in "development hell" waiting for all the browsers to implement it (and still some areas are not covered) and the polyfills required crippled some browsers. At this stage, the browser vendors should be shipping web components to spec out newer ideas. Not expect the dev community to take a step backward or embrace frameworks that have only a fraction of mindshare as the other web frameworks.

Collapse
 
maxlynch profile image
Max Lynch • Edited

Hey Kevin, I already addressed several of your points in the post.

And no, it’s not the same as a framework because the output is portable, and that’s a huge difference. Whether you use Stencil or something else the components can work together without you having to use that framework, which is a huge difference.

As noted in the post if you’re not satisfied with tooling then you won’t be satisfied with my argument and that’s okay.

Collapse
 
kevnz profile image
Kevin Isom

I recently gave a talk on web components, and I have wanted to like them for years. But the compromises they had to come to (like only supporting the class syntax) have hurt more than helped.

WebComponents have a place, and your case is a prime of example of that. But I would hate to tell someone just learning web development to learn and build something with them. Or that they would have to use another framework that pushes them even farther from javascript/html/css.

As primitives, yeah maybe. For application dev? I'd have to take a hard pass.

Collapse
 
thepassle profile image
Pascal Schilp

Great and nuanced post, glad to see the discourse steer this way :)

Collapse
 
kahlil profile image
Kahlil Lechelt

Love this post! It’s so well written and to the point. Thank you!

Collapse
 
hyperpress profile image
John Teague

Nicely done. Love seeing posts correcting the record on the current state of web components.

Collapse
 
drewroberts profile image
Drew Roberts

Thank you, Max. I greatly appreciate you taking the time to write this.

Collapse
 
yinon profile image
Yinon Oved

love the post - read rich's first so this set me back on track. btw server side rendering and progressive enhancement - how can this be accomplished in stencil? can u refer doc or guide please?

Collapse
 
adoumas profile image
Alex Doumas • Edited

We using stencil for a year now to build our Shared Design System for our company's Products that uses react and angular frameworks. We manage to build a Design System (ui tookit) with 80+ components based on bootstrap layout (grid,flex,responsive,spacing), material web components (ui elements), material icons (120+) and some custom components (carousel, datetime picker, steppers etc) in a bundle of 278kb all inclusive. A similar approach for react with material ui was double and some times triple the size just for the UI same for the angular with mat and we had to support 2 different design systems. And with this aproach we had inconsistencies in the UIs. Some architectural strategies that we pick was not to use the shadow dom because we want themability without extra packaging/processing so we use css vars with BEM methodology and selenium GUI testing. Overall the outcome was lighting fast apps, one design system for all frameworks and N themes on the fly just writing 10-80 css vars on how you want to enhance the theme.