They're only similar in that they're both for building component based DOM UI.
Polymer is tied into the WebComponents standardization effort (also driven by google-related people). Pieces of the DOM are managed by relatively small, contained objects that maintain their own internal state and keep the DOM in sync. It achieves component state synchronization via data binding like Angular or Ember and some sort of KVO mechanism (eventually Object.observe if they're not using that already, I haven't looked at their code in a couple months).
When you write code for React, on the other hand, you basically pretend the DOM is stateless and write your code as if you're writing server side templating code and rendering the entire page from scratch. The framework takes the data structure that the render process builds and efficiently forces the DOM to match what was rendered. At least that's the central concept. There are plenty of caveats.
If anybody has more specific questions, I'm happy to answer them.
As much as I want to like web components, Google's behavior with this new "standard" has been very suspect. The "intent to ship" thread from February this year is something everyone should check out.
Here is Maciej Stachowiak's response to Google's irresponsibility on the intent to ship announcement:
Shoehorning more and much junk into HTML, a markup language with only two types, strings and children, will likely result in bad juju. It may be great for setting things up declaratively, but not for controlling something with state that changes over time. It will serve to reduce what's possible instead of enabling others to explore ideas on the web that are currently only possible in native.
What we need is a low-level retain mode scene graph with a JavaScript API. DOM is a pretty inadequate replacement for a real scene graph. DOM is simply too costly to manipulate and re-arrange and I don't see what WebComponents does to fix that problem.
This might delay the crisis the web feels relative to native, but will just punt the problem a few years down the road at best.
Lastly, some required reading for anyone who wants to educate themselves on the Shadow DOM:
Haven't tried it but you can integrate React with pretty much anything. Looking at the Polymer lifecycle methods[1], I'd start by trying a `React.renderComponent` in Polymer's `domReady` callback for an element and then setState/setProps/forceUpdate in the `attributeChanged` callback.
That said, I don't expect it to be common since you'd basically be building a React component with a Polymer shim and getting almost no leverage out of Polymer. I suppose you could write some code to parse out the html template and turn it into React.DOM equivalents but that seems like a lot of effort.
All React integrations I've seen are the result of introducing React into a legacy codebase or they're using React on a component that's rendering a very large DOM subtree and taking advantage of React's O(N_view) instead of O(N_model) scaling and batched updates for perf wins over current KVO techniques.
Completely agree that the Polymer Material "look and feel" is really nice and well thought out. The WebComponents ideas it is based on gives me the jibblies though.
You could do the polymer look and feel with the react update model via famo.us (disclaimer: I work for famo.us). Famo.us also plays pretty nicely with Ember.js (tutorials coming soon) and React.js.
That's not really doable. I'm building a React based component/widget system for work and assuming all goes well and I can OSS it there's a reasonable chance I'll build out a Material/Paper widget set since I really like this set of design guidelines.
Mixing them both together would be nasty (components are central to both APIs, it'd be counterintuitive), but using React as a fallback layer doesn't sounds so bad
Polymer is tied into the WebComponents standardization effort (also driven by google-related people). Pieces of the DOM are managed by relatively small, contained objects that maintain their own internal state and keep the DOM in sync. It achieves component state synchronization via data binding like Angular or Ember and some sort of KVO mechanism (eventually Object.observe if they're not using that already, I haven't looked at their code in a couple months).
When you write code for React, on the other hand, you basically pretend the DOM is stateless and write your code as if you're writing server side templating code and rendering the entire page from scratch. The framework takes the data structure that the render process builds and efficiently forces the DOM to match what was rendered. At least that's the central concept. There are plenty of caveats.
If anybody has more specific questions, I'm happy to answer them.