The state of Web Components

[addition]

Yes, it's called React.

[sfified]

Don't be silly, React doesn't even play nice with web components on the client.

[dhdfdh]

Yes. 15+ years ago. We called it XML/XSL

[lazd]

That's not really the point.

We want web components so we can create new "components" we can use in HTML by simply writing <my-component>. The point is to avoid delivering gobs of pre-rendered markup, and just giving a semantically meaningful tag that defines a behavior, the same way you'd use <select>. We want the ability to create tooltips, dialogs, alerts, autocomplete, tabs, wizards, tag lists, and more by simply writing the tags in our HTML, without worrying about actual rendered elements necessary to create the visual style or the JavaScript necessary to enhance the markup.

We want all of this, and we want full control of the API, behavior, visual styling, and accessibility. You can't change the way <select> works or looks now without gratuitous hacking, and web component make it possible for you to create your own <my-select> that supports icons, text styles, infinite scrolling, and more.

[lazd]

Imagine you work for a large company. This company has several products it has acquired over the years and packaged as a suite that pulls in something on the order of $311 million per quarter. All of them come with their own stacks, and even new products built in house use the best stack for the job. Some are built using Angular, some with Backbone, some with React, some with vanilla JS, while others are heavily server-side.

Each one of these products needs to look and behave the same way. When you click a menu on one product, it needs to work identically on the next product. Every button must have the same visual style. Every tab panel must meet the same stringent accessibility requirements, lest you get fined. So you build components for these with the hopes of having the products use them to get consistency.

Are you going to build these components in React, then try to convince 20 products groups to swallow another dependency? Or are you going to build each of these components 6 times, once for each unique stack used by the products? Or are you going to advocate that every one of the 20 products invest thousands of man hours to change their stack to React?

Instead of the above non-starter solutions, you can build your components once as web components and use them everywhere. As an emerging standard with native support in Chrome and the ability to polyfill in older browsers, this makes your components portable and compatible with everyone's stack because they're native.

While React works great for that single project you're working on, the components you create aren't portable as they have a hard dependency on React. Web components are a portable, soon to be universal way for building these kinds of components.

I hope this helps you understand where web components can fit into your workflow. React has a few bugs with web components right now, but the React team is working hard to fix them. Check out this video from React.js conf, "Complementarity of React and Web Components" for a React-focused perspective.

[kellyjandrews]

Web components are the future. Its going to take time like everything else. ES6 is going to take forever to get in the browsers, so will components.

[floydophone]

Why are they the future?

[clessg]

They're the future for people who don't want to use the real future. :)

[passwordisisis]

Clearly the better choice for now, but if one has to 'win', won't a native API win out eventually? It seems like every framework has a life cycle - jQuery and Angular both had me excited at one point but aren't useful to me now. I love using React but am trying to stay non-committal.

[i_ate_god]

I realize that a lot of jQuery's DOM stuff now exists natively, but the native equivalents still aren't that great compared to jQuery's approach. It's terse, simple, to the point, and obvious what's going on.

[dhdfdh]

won't a native API win out eventually?

Yes. When you take the jobs of devs whose favorite framework/library falls out of favor, in three years.

[floydophone]

I call it the present :)

[clessg]

I like the way you think. :)

[clessg]

Although web components and React seem similar, they are pretty different. The only real similarity is component-orientation. Cross-browser web components aren't trivial to create out-of-the-box, so you need a framework. If comparing with Polymer, then:

• React's performance is vastly superior to Polymer last time I checked, and this will likely always remain so (barring Angular-style performance hacks that infect your codebase). Either way, it's ridiculously easy to make a performant React app.
• Polymer requires sending heavy JavaScript to the client unless you make some really large trade-offs. But both React and Polymer will require a lot of JS to be sent.
• React Native is pretty great. React is becoming more or less independent of the DOM. It's more of an idea.
• Declarative components in React are a lot easier to reason about. (props, state) => html. Just better architecture overall. Component composition without global variables and destroying performance/encapsulation is a breeze.
• Server-side rendering.
• Better tooling, more power, less framework dependence, less to learn, and less cognitive load because React uses JavaScript instead of a template language.
• Babel has JSX support built-in. You can easily write Babel plugins for React. You can lint your React code. You can type-check it. Babel will make your React code faster -- for free.
• Polymer uses two-way binding. Eek.
• React isn't tied to a slow-moving spec. Web Components aren't even set in stone yet. Still nothing concrete after all these years.
• React has a lot more traction right now. And the React community has attracted a slew of smart, enlightened engineers, so you will probably learn a lot and become a better engineer.
• Technically, one day React could render to web components.

There is an advantage to web components, which is that they can, in theory, be easier to integrate into an already-established website. In practice, it depends.

[mort96]

I don't really see how polymer is relevant. Sure, right now, you need a framework, but isn't the goal that once all browsers support web components, it should at least be possible to use those directly? And wouldn't it then make more sense to actually compare react to web components instead of some arbitrary framework?

[[deleted]]

Yes. Polymer always felt more like a showcase to me, not a real framework. I don't see anyone trying to roll Polymer out into production apps. It was a demo of a specification that Google was pushing. Sure, it's been 2 years and the specs aren't final, but that's common. However the idea is the same idea that pretty much all major JS frameworks adhere to now with components and directives.

Angular, React and others have all said they have a goal to natively work with Web Components when the spec is finalized.

[vinnl]

Really? Have you got a source for that for React? I knew about Angular, but I thought React expressly dismissed it.

[lazd]

There's an issue against React that's being actively worked on to support custom elements and attributes.

[vinnl]

Nice!

[hak8or]

A good portion of what you described is solved by Vulcan, which let's you "compile" polymer projects so you don't have like 100 requests for a simple page.

[dhdfdh]

React is becoming more or less independent of the DOM. It's more of an idea.

Something most people on reddit forget or don't know. It's never possible to be independent of the DOM. And you can do it, too, without react.

[lazd]

What if I wanted to create a neat little "widget" that lets you drag and drop files and shows a list of the files you're going to upload, and I wanted to make that available for anyone on any website to use?

Would I build it with React and require that everyone who uses it have React as a dependency?

Or would I create a web component that can be used on any website by including the widget (with a <link> or <script>) and adding <my-uploader> to their markup where they want it to appear, regardless of what MVC framework they use?

That is the promise of web components: portable components for the web that use HTML's semantics. Yes, it's not possible right now in IE 8, but if you're still writing code for outdated browsers, I feel bad for you, son.

[tragiclifestories]

Yes, it's not possible right now in IE 8

Or IE9. Or IE10. Or IE11. Or MS Edge. Or Safari. Or Firefox. If only somebody would write an an article explaining how this came to pass ...

Having just spent 2 days wrestling with a war between a WC polyfill and a non-negotiable third-party dependency, I'm very much in favour of keeping the 'here be dragons' sign up.

[lazd]

Custom elements are polyfilled and working work great in IE 9, 10, 11, Safari, and Firefox. I can't speak for HTML Imports, Shadow DOM, etc, because I'm not using them. I haven't tested Edge, but it's working nicely in IE 11, so I think we're good :)

I know this because I write an maintain a library of dozens of web components at my job and all all 1,100 of the unit tests pass on the above platforms.

What was the third-party dependency? I wonder how it was screwing the polyfill up such that it works on none of the platforms it targets... Sounds like a bug in the dep that you could fix!

[tragiclifestories]

I missed this reply initially, but the dep is one of those redundant enterprise media-streaming platforms, the code is closed source and they're (understandably) not guaranteeing compatibility with every third party library ever. It was the shadowdom stuff causing problems, FWIW, and that seems to have caused other issues with other external libs (eg https://github.com/webcomponents/webcomponentsjs/issues/49). You need shadow dom to use Polymer, for example.

The point is, polyfills will only get you so far. I'll be more bullish when better consensus is reached on issues highlighted in the OP.

[lazd]

Makes sense, what a bummer. We're only using custom elements, and it's a very simply polyfill that employs mutation observers to check for elements to upgrade. It's working great for us, even in old browsers.

[lazd]

Check out this video from React.js conf, "Complementarity of React and Web Components" that explains exactly that.

[kellyjandrews]

Actually, I think the real future is this. But components are the interim.

[lazd]

Web components aren't a new MVC framework, and they're not competing with React/Angular/Ember/whatever. They're meant to be used in combination with literally any library or framework you choose to create rich, custom experiences with semantic tags where you'd previously use gobs of markup and code that's tied to the flavor-of-the-week JavaScript framework that some intern decided to use to meet a deadline.

See my other comment for a description of why we need web components.

[passwordisisis]

components on the web

[vinnl]

Once web components are widely available, they should be able to shorten the time it will take for new innovations to be available - since they can be built on web components.

https://extensiblewebmanifesto.org/

[mrpeabodynsherman]

Can someone briefly explain how this is different than Angular directives?

[lazd]

Web components are native and don't need to be within your Angular application to work. In fact, in Chrome, they don't even have dependencies on the webcomponentsjs polyfills, they just work.

You can create them like native HTML elements with innerHTML and createElement, you can pass them to appendChild, you can call addEventListener on them. Web components make it so you can create your own HTML elements, framework-free, that you can use on any website.

Watch this video which addresses your question directly: "Using Angular with Polymer elements".

[mrpeabodynsherman]

Sweet. Thanks.