Hacker News Reader

Comment by Flow | Hacker News Reader

With ReactJS you get to code as if everything is a component, why use polymer now instead of that?

ReactJS is a solid solution if you need to ship something _today_, but I think the trend will continue towards WebComponents as they become standardized across vendors (if not Polymer then x-tags, if not x-tags then... etc). In that sense, it's better to familiarize oneself with the technologies that we'll be seeing more of in the future just as we did with new HTML5 elements a few years ago.

@jastanton phrased it nicely in another comment here: https://news.ycombinator.com/item?id=7971847

As I see it, the inside of Web Components still need a nice and structured way to function. I'd build my app using ReactJS now, and when I decide to use web components, I can transform each separate ReactJS component into a web component, ReactJS-tag for ReactJS-tag as I see fit.

It's much safer to do it this way than rely on polymer. IMHO. When web components really are here for everyone, you are still stuck with polymer libs and tools and all the code is bound to them. Who knows, polymer might be considered bloat then?

Polymer includes a Web Components polyfill, so you can write raw Web Components if you want to. Polymer is really just some syntactic sugar over that (and other specs thrown in, like html imports, templates, etc).

That said, these aren't really the same kind of libraries at all, so I'm not sure why this is such a x vs y thread. Ideally, react and web components are fully composable, and it doesn't really matter where the element came from.

It doesn't matter if they keep pushing a standard no one's using to actually ship. The only people I see excited about Web Components are Googlers.

Then you may not be aware of Mozilla's continued interest in WebComponents[0][1].

[0]: http://mozbrick.github.io/ [1]: http://www.x-tags.org/

Reply on news.ycombinator.com