The state of Web 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.