Hacker News Reader

Comment by ergo14 | Hacker News Reader

I'm more interested to see if polymer/x-tag/webcomponents will replace react/angular/other stuff.

AngularJS already has third-party libraries for polymer/webcomponents, and from what I've heard, they're integrating it more solidly in Angular 2.0

React is pretty new, once it gets bigger it'll also follow along too.

React will probably just integrate those as they become usable, since React acts as a layer of abstraction between the DOM and your presentation logic.

Not so. React does not really play well with web components. Currently React has to internally define JSX elements for every known HTML element that's out there, namely to track internal state and respond to events (i.e. input fields). Because they won't be able to do the same for the vast ocean of web components that will be authored in the coming years, it will be difficult to provide clean interop with new custom elements. The React maintainers have even stated that they don't believe web components are the right way forward for web application development. React was never designed to work well with web components in the first place. On the other hand, the main reason why Angular 2.0 is such a drastic rewrite is because they needed to do it in order for Angular to work seamlessly with Web Components. It's no coincidence that both Angular and web components are Google initiatives.

You're wrong about web components and react. As of 0.12, if you register a web component like you normally would, you can reference it in a react component. React no longer has a white list, and instead assumes all lower case tags are HTML tags (standard or custom).

The only drawback is that it doesn't support custom events out of the box. Instead, you have to manually create event listeners on elements on mount. As far as I can tell, there's no reason why it couldn't in the future though; Web component adoption is so low right now that it just hasn't been something people have complained about.

Not supporting custom events is pretty much the same as not supporting web components. What if you use a third party web component that has dozens of events? The goal should be interop with no additional plumbing required.

There was a time when React literally just didn't support web components, so I don't think that's really fair. Yes, it would be nice if it worked completely free, but if you're only listening to 2 or 3 events on a component, it is definitely a fair price to pay for being so bleeding edge.

But Angular is a glorified templating engine, where react is really about FRP and rendering from data. The React components you write are essentially web components that use DOM; as long as there are standard building blocks for web components in the future, you could easily port it to React.

Yes, but now you're requiring that developers go through the work of porting every single third party web component they might want to use in their project. That's the current pain we're all going through today with Angular, React, Ember, etc, which are basically glorified web component polyfills when it comes down to it. The whole point of Web Components is portability.

While this was true a few releases ago, with React.createElement() things have changed.

How exactly does that solve the problem of consuming custom web components with their own internal state and events?

People are already trying it.

https://github.com/Wildhoney/ReactShadow

Reply on news.ycombinator.com