For me, on Firefox 30, I can see the basic structure of the page immediately, then my browser freezes for ~1.5 seconds, and I see the rest. I checked out the front page in FF's devtools, and could only see two uncached network requests, both to youtube.com. So I am assuming that Polymer itself isn't hitting the network. Furthermore AJAX doesn't freeze the browser, so I can only conclude that it's the actual JS that is causing that lag.

On Chrome 35 the freeze is for a much smaller duration but I can still feel it.

I'm currently on my (fairly beefy) desktop, so I imagine it's even more noticeable on an older laptop or phone.

EDIT: indeed, from a cold cache, it's even slower, and wow there are a lot of HTTP requests.

I also made a gem for rails called Emcee that does inlining and concatenation: http://github.com/ahuth/emcee.

It also let's you use CoffeeScript or SASS (or anything else that Sprockets recognizes).

I'm intrigued by your statement. When I read the word "orthogonal" I'm thinking of two key concepts:

* No functionality overlap in primitives

* Composability of primitives

How do Polymer and React as primitives fulfil said properties ? There's certain overlap in functionality. Composability is not guaranteed.

Did you mean to convey a different idea by "orthogonal" ?

Hi, I'm on the Dart team and spoke at IO this year. Remember what? :)

You have to remember that Polymer is a library that helps you implement Web Components. The APIs for Web Components are being integrated directly into the browser. Chrome already has them, and Firefox is landing them now. Even Microsoft is interested.

This is not another framework.

edit: Check out http://jonrimmer.github.io/are-we-componentized-yet/ for a summary of the progress on the Web Components standards.

People keep confusing this it seems. What Google is doing here is NOT like what Microsoft did. Google is merely implement many new HTML5 features ahead of Microsoft (which is usually the most behind in HTML5 support) and others.

So it's not that they are "built for Chrome". It's that they are built for "new HTML5 specs" and only Chrome happens to support them right now. Point me to where Silverlight was an HTML spec?

Now, things like NaCl on the other hand are a lot more similar to what Microsoft used to do, but there's still a major difference, and that is that what they are building is open source and everyone can do their own implementation of it. You could never do that with ActiveX or Silverlight. Plus, you could also say Firefox is doing the same as Google with asm.js, which nobody else has adopted so far.

These things are a little more like that, but at least they are open source. The HTML5 features, though, just happen to be implemented faster by Chrome.

Regarding performance: it will get much better once browser have implemented http://www.w3.org/TR/2014/WD-shadow-dom-20140617/. Shadow DOM is not easy to polyfill (especially because of some issues in how the browser's C++ objects were presented to JavaScript as prototypes.)

Regarding IE failures -- do you have any more information? All of the elements should be cross platform. It would be great to file these issues at https://github.com/Polymer, if you haven't already.

Try ractive. You get simple mustache templates, but the speed of a virtual DOM like React.

I've done projects in both Angular and React and I find the latter to be much simpler to reason about. Scopes, transclusions and directives are often confusing. React is just nestable Polymer-like components of encapsulated markup and behaviour.

A React component at its most basic is just an object that implements a render() method that is responsible for rendering markup. See the React home page for examples http://facebook.github.io/react/index.html.

Since React is just a view layer though, you're left to your own devices for everything else. So if you're evaluating it from the perspective of a whole SPA, then it becomes more complicated.