Facebook has been using React in production since 2011. Polymer is a "developer preview", aside from the Material Design presentation, I haven't heard of anything public-facing that Google's actually done with it yet.

React is backwards compatible to IE8. Polymer? Not so much. Unless you live in that mythical world of evergreen browsers, Polymer is sort of just a really great demo.

http://facebook.github.io/react/docs/working-with-the-browse... http://www.polymer-project.org/resources/compatibility.html

I haven't worked at a place that has cared about IE since 2009. Besides old versions of IE Polymer works everywhere. Worrying about being backwards compatible with old browsers is a thing of the past with constant updates to Chrome and Firefox. If you're developing a mobile site you can't use any of the newest things until Safari updates (about once a year, seriously) but you should be otherwise ok.

I work at a site where about 20% of traffic comes from IE8. Many are users on corporate machines with no alternatives. I really appreciate that React runs on older browsers and is decently performant without a huge payload. All this with a well designed API and a nice development experience... I think it's hard to beat!

Anyway the more traffic your site gets, the harder it becomes to ignore certain cohorts.

But Polymer depends, for example, on Shadow DOM, which is currently only supported by Chrome, Opera (Chrome-based) and Android browser - not even by Firefox yet (http://caniuse.com/#search=shadow%20dom). There are pollyfills but they're too slow to treat them as a viable solution.

In my experience, React has been a better realization of the concept behind Polymer ("reusable web components"), without the non-sense. I don't even consider server-side rendering the killer feature.

makes sense to me

James Long from Mozilla has his answer for this:

Aren't you tired of having to query the DOM tree and manually manage the structure to create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the work. The problem is that building apps is building components, so you inevitably are forced back into the manual DOM management to create your app-specific components (like how you constantly have to create directives in Angular). You also need to jump into JavaScript to configure and wire up any Web Components you used. It's a very messy abstraction, and fools you into desiring a pure HTML-based declarative way to write apps, which is like wanting steak but eating liver.

See http://jlongster.com/Removing-User-Interface-Complexity,-or-...

I too struggle with the choice. Polymer/web components _might_ be an easier sell to my boss as it doesn't require as much framework specific knowledge and would make it easier to get new teammates up and running.

However, the polyfills + ammount of http requests in a very modular project don't inspire the confidence that Polymer is ready for prime time.

My thought is that when web components lands in browsers natively, and if some of the request problems are smoothed over, it would be easier to translate a react project than a project in another framework. You could replace things piecemeal. But by then, who knows how much more compelling react might be.

This is not the best React feature. React solves a bigger problem: nested components. You'll never find other framework that solves it.

You can have nested components with AngularJS. That's what transclusion is for.

If the name for their solution is so pompus and factoryProxySingletonBean like, such as "transclusion", I'd hate to see the code behind it...

You cannot pass state down to transcluded elements. They can only get their state from factories, just like... jQuery. Or no framework at all.

What I gathered is that Polymer, at this time, is simply not ready or even intended for production use; it's an experimental technology aimed to implement the Web Components standard, which at this time is still heavily under development. Polymer is aiming at the future, and as such will only become usable in the future.

It's also not intended to support older browsers; I'm okay with that.

I'd love to know what you love about Polymer so we can make React better. :)

Well, as unhelpful as this.. I love everything about Polymer, except the possible HTTP request spam and lack of serverside rendering.

Polymer is sort of React Components "To the extreme" (to me). They represent everything i love about React Components, with encapsulated JS, CSS, and HTML. Meaning that i can pull in someone elses Polymer component, or use one from another project, and it "just works".

Granted, the HTTP spam scares the hell out of me. Vulcanize may help with that, but i have yet to really figure out the whole process for my workflows.

Having to load an html wrapper, do clientside routing, load the data into the clientside templates and render templates all for the first page load just scares me with Polymer. React solves this by letting me do it all serverside, and it is wonderful at that.

I really do love React. I'll likely stick with React for another project or two, unless i conceptually have an "ah hah" moment with Polymer.. but until i can render Polymer serverside, i'll always be longing for React.

edit: Come to think of it.. If someone could bake html imports and shadow dom into React, i may be in heaven.

React already can render into shadow roots, and eventually we could add a mode that tosses aside server rendering in favor of shadow DOM. However, if all you want is style encapsulation, you can get that with conventions.

What I like a lot about polymer is that you can isolate css per component. And that you can also apply styling on your new element names..

I'm not terribly experienced with React, but from briefly using it, I definitely prefer polymer's simple vanilla html+js declarative data-binding approach over react's JSX + element injection, from a basic usage perspective.

React has Virtual DOM diffing which turns it into a very fast rendering layer over the DOM.

I think they solve two different problems. Polymer I see as useful for creating atomic UI elements while React.js is better for stringing the UI elements together into a cohesive experience.

Not to mention, that react side-steps the entire issue of heavy DOM reflows/rerendering as individual components update. I don't see Polymer doing anything but make that issue worse until browsers support it natively, and even then it will take some changes to the way browsers handle rendering to improve performance there.

I do think that long-term (5+ years) something like Polymer will become the preferred solution. For now, imho, React is about as good as it gets for componentized web applications.

I disagree; I think the weakest part of React is the lack of a true controller mechanism.

Everything is a view, even components that are structural more than visual. You achieve an MVC-like separation by designating some components as being owners of data, but it feels awkward.

Facebook's Flux looks like it may be a good solution, but I haven't tried it out yet. At any rate it is more about data flow than high-level application orchestration.