Thanks for pointing this out, I'm always glad to see people taking responsibility for the quality of their contributions to the web and finding tools that enable good work.
Are there any real world combinations of real time frameworks like Derby, Meteor, SocketStream, Mojito, or even Firebase+MVC with a pre-rendering engine like Polymer or Famo.us?
>This means you can render your initial request on the server, and pass markup down to the client
That's how derby works too.
// When I say
<IconButton
link-to = "home"
src = "home.svg
/>
// give me
<a
class = "IconButton"
href = "/"
>
<img src = "home.svg" />
</a>
Flux lets you cheat around that: Since you're using require statements, you can make an action and `require()` it in both the component it's dispatched from and the one that's listening to it.
// Traditional event bubbling
child.dispatchEvent(...) ----> parent.addEventListener(...)
// Reflux
child:action() ----> store.listenTo(action) ----> store.trigger(data) ----> parent.listenTo(store)
Honestly, I'm murky on the utility of the Store and even less confident in the utility of the Dispatcher. That's why I'm using Reflux instead of FBFlux, and I'm still tempted to skip the store and just listen to my actions from the parent component.
The best part is, thanks to React & Flux I'm building a large scale web app without jQuery for the first time in my life :)
Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together could very well be the future of web development. Unfortunately, it's still a bit immature to use commercially.
Hence, I chose React. It's idempotent, which is a fancy way of saying the markup it outputs is a strict function of the inputs it's given - no side effects, no externally-mutable state. This means you can live-edit your markup in your favorite editor without having to reload the browser on every save (using a tool called the Webpack Dev Server with the react-hot package). Using Webpack also means your dependencies are explicitly declared with `require` statements. It has all the benefits of Angular's Dependency Injector without all the boilerplate.
Finally, and perhaps most importantly, it has 0 dependency on the DOM. This means you can render your initial request on the server, and pass markup down to the client that's indistinguishable from what you'd traditionally get from Flask/Django/Rails/PHP. There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots, which is in turn safer for SEO. It also means your view is already rendered when it reaches the client, which is important in a world where many clients are phones with underpowered JS capabilities. You get both the benefits of a single-page-app (slow client rendering is still faster than slower network requests, and network requests are smaller if you don't have to also send down the template every time) and those of a server-side one (SEO is maintained, and the client can display your page without waiting to execute the JS first).
I should disclaim that I haven't seriously considered Ember since it's been rebranded from SproutCore; however, I have worked on a few Angular apps; and even forgoing the above benefits, React is just easier to work with.