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.

Also polyfills are separate thing from polymer - they are reused by ALL other frameworks including vuejs for example, so I'm not sure what you meant by that comment.

Most apps will have their core data loaded into nice JavaScript objects and class instances. With react the transformation of that data into DOM is a one step process. With polymer you have to first map that data to javascript primitives which are consumed by expressions which then generate the DOM.

I guess ultimately it's my preference to having types (I use TypeScript) which can be used inside the rendering code to ensure correctness. With polymer you lose some of that because everything ends up in these untyped expressions.

It's also true that React is "monolithic" in the way that other frameworks are: they don't naturally interoperate, or do by cumbersome adapter libraries that require wrapping widgets and marshaling between data-binding techniques. They interfere with normal DOM usage, and tend to break if other code modifies a component's DOM (granted Shady DOM has made this trade off temporarily), and they aren't "just elements" - getting a node controlled by React out of the DOM doesn't get you the component itself, no useful API is added to the node.

You simply don't see many applications that mix and match React, Angular and Ember because of this. This Polymer difference is that it's deigned to help you create "just elements" so that they're interoperable with other frameworks, plain JavaScript or just HTML. Users of Polymer elements should never have to know that they were made with Polymer.

Needing to use Shady DOM APIs is an unfortunate exception to this, but an site can choose to use the full Shadow DOM polyfill if the performance fits their needs.

Equating the fact that Polymer PROVIDES a declarative ajax element with the inevitability that any project you build will be fraught with bad code factoring and memory bloat because you MUST use it is like saying that because jQuery UI provides a Tab View, all of your jQuery UI's will be horrible because you must build them only out of Tab Views. Polymer just provides the sugar for minting your own custom elements, as well as a solid reference set of pre-built elements (core-, paper-); which ones you choose to use is up to you.

Most of this discussion largely misses the point and elegance of what Web Components generally and Polymer specifically are gunning for: The ability to create, reuse, and share well-factored, arbitrary pieces of web functionality (which may or may not include presentation) that have a well-defined imperative API (instance properties, methods) as well as a familiar, serializable declarative syntax (HTML) that can be manipulated imperatively after the fact (DOM), that will (one day, fingers crossed) be consumed natively by all browsers, without today's existing framework-based silos (React components, Angular directives, etc.). When it makes sense in your application (i.e., when you determine you get more use out of factoring it as a reusable element), then promote that functionality to an element; otherwise, you're free to embed that functionality (including ajax requests) as imperative JavaScript inside the component using the techniques you use today.

As for why you might be interested in a declarative <ajax> element: Polymer also provides declarative property binding and templating, which makes this possible (and absurdly simple, and very cool IMO):

    <select value="{{department}}">
      <option value="eng" selected>Engineering</option>
      <option value="sales">Sales</option>
      <option value="hr">Human Resources</option>
    </select>

    <core-ajax url="/{{department}}.json" handleAs="json" response="{{employees}}" auto></core-ajax>

    <template repeat="{{employee in employees}}">
      <div>{{employee.name}}</div>
      <img src="{{employee.avatar}}">
    </template>

Time will tell how developers apply this new component model, and Polymer is doing a lot of experimentation in the open to try and push those boundaries and see what sticks.

A problem with HTML/JS/CSS pre-shadow DOM is that it was impossible to actually build a component as described above. There was no way to sandbox the HTML/JS/CSS that's used to build the component from the application. There was always the possibility for contamination.

What the specs that Polymer is intended to polyfill permit is a combination of this sandboxing capability along with other means of permeating this sandbox with the functionality needed for such sandboxed components to be truly useful (how useful is something you embed in your page then can't access/talk to at all?). This includes data binding, events, allowing parent CSS to apply to certain things (in a very explicit, named way, which allows the parent application to style the component in a manner the component creator deems appropriate, and not in a way that will break the component), etc.

These standards, in effect, define features that once implemented will permit true web components to be built.

For more: http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.

Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.

My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.

Poylmer doesn't simplify UI development like React does, the components have to be statefully managed, and always will be because creating/destroying polymer/web components is expensive. The beauty of virtualdom is the previous state doesn't matter in deciding what the new UI should look like, or if a component should be added/removed. Simply render off the current state, which is cheap, and then the previous & current virtualdom is diff'd and applied to the real DOM.

Web components are exciting, and React can leverage it to do CSS sandboxing, though people are already effectively doing this [1]. And the cool thing with declarative programming is we can swap out implementations with more performant ones.

[1] https://github.com/gajus/react-css-modules

personally, i don't like seeing stuff like this in Polymer:

    <roster-list persons='[{"name": "John"}, {"name": "Bob"}]'></roster-list>

Performance is better with browsers which support it natively.

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?

Why? You can use Polymer and not its data binding. In fact you can use its polyfills and deal with mostly the standard based APIs. X-Tags and many others also use Polymer's polyfills.

DOM APIs are awkward as hell. But you can create Web Components and handle the data binding yourself. It's actually pretty easy to roll your own data binding. Now whether you should is another matter.

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.

React and its 1 billion clones run off of the assumption that the DOM API is not to be trusted, and that lets you target more browsers, even non browsers. I mean have you ever tried to get Polymer stuff to work in Firefox? It's not Pretty.

The API for web components isn't that bad. You have to stamp DOM templates yourself using whatever process, you have to handle attributes and properties yourself, and that's about it. Lots of boilerplate, but a library like Polymer can take a simple, opinionated approach to handle it for you.

From my experience Web Components have been pretty pleasant to use with or without Polymer, it's just a matter of wiring everything up if you go vanilla.