You often hear engineers comparing Web Components with React. Here's my take on it.
Web Components are spec. Your web framework isn't.
The fact we don't need a JavaScript framework to use Web Components is a huge differentiator. The parts of the Web Components spec custom elements v1, templates, slots, and ShadowDOM all work in the browser. This means no dependency wrangling to start coding Web Components!
You don't need a ton of JavaScript just to render UI. Web Components are beneficial for instances where loading heavy dependencies prohibits user interaction, like in the case of mobile. It's more than that though. Turns out static site generation for web components takes a minimal amount of tooling. HTML Modules will make the ergonomics of handling template partials even better. This year the Chrome team announced the HTML Modules spec is on the way! While you may require a JavaScript framework for building complex web applications, static sites are optimally built with just spec. That's a huge deal considering how much of the web is static content. Sorry React and Gatsby.
Web Components are inclusive.
The JavaScript ecosystem is so fragmented. Web Components are an opportunity for everyone to speak the same language. Proponents of React are quick to point out there is "no single 'web component community', but the truth is the community is all of us. JavaScript frameworks are exclusive. You have to be part of the club. That's not true with custom elements v1. Beginners can start coding them without the uphill battle that is learning a JavaScript library.
Web Components solve a different problem.
React addresses the lack of state in UI development. Custom elements are stateless. You need to bring a state machine to custom elements. There will always be room for JavaScript frameworks. Web Components provide an opportunity to streamline this component paradigm that's been kicking around here the past few years so everyone can use the same UI components. Web Components are essentially solving the problem of ergonomics when extending the base elements we use everyday. It even says so in the React documentation. React and Web Components solve different problems.
Web Components are interoperable. Odds are your Javascript framework isn't.
Using custom elements in frameworks is not only possible, but should be considered a best practice going into 2020. Javascript frameworks should just be able to cope with custom elements just like they have to deal with DOM. There are many quirks to getting web components to work with JavaScript frameworks. React has some problems, however the React team has said they will consider tight integration with the spec. Angular doesn't support part of the spec for customized built-in elements. Angular has provided support for autonomous custom elements, even going to far to compile down to them using Angular Elements. Vue is fairly interoperable with custom elements, however someone who codes with Vue please chime in here if you've encountered issues. There are workarounds to solve problems that arise from integrating Web Components, but JavaScript frameworks have some work to do to ensure the complete custom elements v1 spec just works.
Web Components are a11y.
Customized built-in elements allow you to extend native elements like button, input, and select and implement your own functionality. By extending elements that have accessibility traits you gain those features for free. Normally you have to duplicate accessibility features when building UI components with JavaScript frameworks.
There is a problem with education and web engineering.
In code academies that have become popular over the last decade we forget to elaborate on spec and jump right into JavaScript frameworks. Even an introductory level course can include exposure to React. This is advantageous for the JavaScript frameworks that just want us to "use the platform", but it leaves a void where junior level engineers lack the knowledge of the platforms we all use: HTML, CSS, and JavaScript. Web Components solve this problem by providing a spec that everyone can learn and use.
Can't we all just get along?
Learning the HTML spec can be easy, even for beginners. Getting every browser and library to agree and support spec is hard. HTML is a living document and is constantly changing over time. Apple has refused to implement the customized built-in elements spec in Safari. All the most popular evergreen browsers have implemented custom elements v1 since Microsoft moved to Chromium in Edge. We all just need to work together a little better and Web Components can provide a sustainable paradigm for implementing UI components heading into the 2020s.
This doesn't mean you can't start using Web Components today. Polyfills exist for browsers that don't support the spec.
We should all be working together to ensure web components make their way into development workflows. From the very start of education in front end web development to the most sophisticated web application web components have the potential to streamline UI component development, provide accessibility features out of the box, and even reduce the amount of code it takes to build UI. It’s time we unleash that potential instead of squabbling over which JS framework is better at providing a component paradigm. JavaScript frameworks will continue to be good at what they do best: state management, providing architectural patterns and convenient tooling. Web Components are here to stay. We can all work together to make the web a better place.
Top comments (31)
Except not for Safari. From developers.google.com/web/fundamen...
chromestatus.com/feature/467014692... with links to every major browser vendor status on the subject.
What's the solution here?
github.com/ungap/custom-elements-b... Enjoy :)
Thanks, but are we supposed to ignore Safari development team arguments then as not having much basis?
github.com/w3c/webcomponents/issue...
No, Safari development team has some valid points, however the rest of the browsers have decided to implement customized built-in elements. Why should Apple engineers continue to resist over implementation details at the cost of failing to enhance Accessibility features for the greater community? Customized built-in elements made it into the spec. At some point they should just accept it.
I don't have an answer to this. Maybe @webpadawan can chime in?
I do like polyfill author's comment github.com/w3c/webcomponents/issue...
Just wondering if safe to bring to my platform production code. We would like to extend
articleelement to starters.That GH thread should maybe be published as an e-book. Still wondering if I should read all of it.
It is better to ask @webreflection who is the author of the customized builtin elements polyfill about how much is it safe to use in production.
The only thing I'm not sure about is whether Safari already supports
customElements.upgradeused in that polyfill: github.com/ungap/custom-elements-b...that polyfill is basically for Safari/WebKit only, so yes, it works there pretty well 😉
good helpful info here 🙏
any news with this subject?
There is another polyfill now that is regularly maintained customized built-in element support in Safari.
@corpuscule/custom-builtin-elements
Head of WebKit engineering wouldn’t confirm customized built-in elements are on the roadmap, but confirmed Apple never said they wouldn’t support it.
twitter.com/othermaciej/status/121...
There is github.com/ungap/custom-elements-new if you want to use
new, not sure why that is an issue, but on top of that, there is github.com/WebReflection/document-... that brings custom elements + built-in extends already to every browser down to IE8.The @ungap/custom-elements-builtin is specific for Safari/WebKit only, which is why it's 1.2K only
that polyfill unminified size is 14K, plus it needs @webcomponents/webcomponentsjs to work, none of mine does.
document-register-element has been used by Google AMP Project for dunno how many years, so it is also battle-tested.
I really wish that polyfill author would've contributed to @ungap instead of creating yet another issue with polyfills and custom elements, I have experience with these since 2014 so maybe we could've solved together.
I really wish you wouldn’t tell someone you don’t know they are creating issues right off the bat. I’m sure this fumble erases all the times I’ve supported Web Components, am I right? Jeez. People first, not code first. This isn’t an attack on the project or you. Getting along just fine with ‘ @corpuscule/custom-builtin-elements’ in my latest project, which doesn’t need to support deprecated browsers like IE8.
I haven't attacked anyone, and me and the
@corpuscule/custom-builtin-elementsauthor already clarified a few things in the repository, so that he changed the README about few wrong things mentioned about the@ungap/custom-elements-builtinalternative polyfill.There are reasons that poly has the constructor caveat, but I'll let you test yourself if it was valid or not.
I am not saying you attacked anyone, but your phrasing was rude in my opinion. No need for the last paragraph, just gratuitous.
I support Web Components (Custom Elements) since 2014 and before, and the
@corpuscule/custom-builtin-elementshad some FUD in the README regarding my polyfill, but it wasn't intentional, so that everything got sorted by me filing MR to that repository.I guess there's some history behind you are missing, but the fact people prefer writing from scratch anything already available, instead of helping out, is one of the most obvious reasons Open Source has issues.
So, my comment was about that, and I've clarified with the author of the lib you have pointed me at, so, at least to me, is all good, I hope it's good to you too.
You're free to use whatever library you like, I just know that library has inevitably other issues, but I am not here to describe third party work.
Take care 👋
If we are comparing Web Components to React, is there a create-react-app comparison?
Yes, almost all of the major UI web component based frameworks have this. A couple examples might be:
Angular:
Vue:
*EDIT: However, as Steve suggests, you shouldn't bloat your project unnecessarily with an application framework if all you need is just one or two simple web components.
Some of the web component libraries have that sort of thing:
github.com/ionic-team/stencil-comp...
github.com/CaptainCodeman/web-app-...
FWIW you don't need a lot to get started and IMHO create-react-app serves the most general of use cases so tooling like that can be hazardous for some projects. With web components all you need is a template index.html and some JavaScript and CSS. There are some polyfills, but they are minimal. None the less a starter project would be a decent idea or a CLI with scaffolding all the better. Parcel is primed for this kind of thing, so is Webpack. Rollup is even a fantastic idea here now that it can code spilt.
Thanks for those links.
I was looking around this past weekend for something that supported at least the following: TypeScript, Webpack, and Hot Module Reloading to make an app using Custom Elements. I only had an hour or two so I didn't want to write the Webpack config myself 😅 I ended up bailing because I couldn't find anything that looked like it was being actively developed.
Those two libraries you mentioned, neither has been touched for some months which makes me nervous relying on something that doesn't have an active community behind it.
Until there is a better community and tooling around Web Components, I will continue to sit back and watch.
I find this very interesting as someone who codes a lot of build tooling when something doesn't exist. Tools like create-react-app and Angular CLI only really serve generic use cases. The moment you want to do something else the tool doesn't you most likely have to roll your own, or extend the tool as is the case with Angular CLI.
It takes a lot of time to roll your own, so I sympathize, but if there were a tool for bundling Web Components it probably would only handle the most generic use cases.
My current workflow can be cherry picked from Readymade UI, a web component SDK I've been building just for kicks.
github.com/readymade-ui/readymade
My dev build is currently just TypeScript. I run
tscin--watchmode. In TypeScript 3.3--watchis using an incremental watcher by default.typescriptlang.org/docs/handbook/r...
The dev build isn't bundled, but I like that. It's fast.
The prod build uses rollup because well rollup is so easy to configure compared to anything else for me. Then I postprocess the output even more with PostHTML. PostHTML is a wonderful tool that transforms HTML templates. That's how I inlined nearly everything in the Github pages documentation for Readymade UI.
readymade-ui.github.io/readymade/
HTML Modules are coming and they will be a game changer.
Have you guys taken a look at Stencil?(stenciljs.com/docs/introduction)
Stencil 👍
I would love to take advantage of web components, but my understanding is that the polyfills are flaky and that there aren’t enough component libraries out there that are built directly on web components (yet). I guess I’m just holding out till things stabilize a bit. But the future is very exciting. Btw, if someone does know of a web component library that has all the major UI widgets... I would be very very interested.
The primary one that comes to mind is Ionic. Their latest version is all web components, built with Stencil (their typescript-powered WC compiler). Not a lot of other pre-built options though.
This is a useful list: open-wc.org/faq/component-librarie... and lots more just around the corner...
React is just one framework you can use for implementing web components. I feel like this article aids and confuses rather than disputes the current trend of treating React as its own component entity rather than as one implementation of web components
Edited to hopefully clarify.
Very cool, thanks @steveblue
Chromium based Edge will fully support CEs, as does Safari since 10.1. The PF are for pre-Chromium Edge and IE11. So, you really can use Web Components today.
@steveblue , Very nice read but its time to update your article (browser support caniuse.com/?search=web%20components)! Also, consider your statement about state machine, since an event driven architecture with web components needs none: dev.to/weedshaker/dom-and-the-even...
Updated to reflect Microsoft Edge supporting custom elements v1.
Informative discussion guys. Only 5 days ago Vue 3.2 release incorporated a very easy way to create web components. blog.vuejs.org/posts/vue-3.2.html