What about a more ambitious example like this: https://github.com/erikras/react-redux-universal-hot-example

> conventionalizing app boot and figuring out how to run multiple instances concurrently

I am a software engineer who usually develops also for the client side and I follow and experiment with the JS trends because I find them interesting. However, I don't understand what you mean by these. Could you please be more specific? Thank you.

Author of the simple React example here – Tom says there's a "huge gulf", but forgot to mention there's literally an example[1] of an asynchronous routing and data fetching app linked to in the first section of that page that's a logical progression of the first. (and others have pointed out much more complex examples you can achieve with React if you so wish)

The goal of those small examples is to illustrate that you don't need complex frameworks to achieve server-side rendering with data fetching and routing.

I have no doubt that FastBoot was a huge undertaking, and I think a large part of the reason for that is that it's aiming to fit into a very comprehensive existing framework, with pieces for routing, fetching data, "application instances", etc – there's a lot more work involved in that (for the framework author I mean, not the end user) than there is starting off with just a view library and adding your own pieces around that.

1: https://github.com/mhart/react-server-routing-example

Honestly, it comes off pretty poorly for you to downplay the work of your competitors.

It might be easier to get server-side rendering working with React, but pretending that it's not the same thing is just condescending. There are dozens of examples out there showing how to render React pages on the server, including fetching the necessary data for that rendering.

The mechanisms you use might be different, but pretending they're not analogous is duplicitous at best. Both let you ship a fully rendered first view to the client.

Hi, Tom!

> do it concurrently

Does ember renders concurrently?

> There is a huge gulf between "synchronously render a component in Node" and "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently."

I dont think it is fair to say it that way. React implementation doing all this (except async/streaming rendering) is man-week at worst in existing medium sized project, and man-day for a new project with no pre-existing code.

Touché. I reckon I should have read 'analogous' a bit more strictly.