It would be worth verifying that NODE_ENV=production is set during these benchmarks (I see no mention in either the article or the source repository.) Running in development mode has a significant performance impact.<p>Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. <a href="https://github.com/janit/node-templating-benchmark/pull/1" rel="nofollow">https://github.com/janit/node-templating-benchmark/pull/1</a>
Note that React doesn't do streaming HTML in the traditional sense. You can't send out initial HTML while you wait on an API response, for example. Instead only the serializer is streaming. Your app renders to a VNode synchronously and then the serializer traverses the VNode, synchronously, and streams the strings out as it goes. This is why streaming is only a little bit better in these numbers.<p>If/when React gets real streaming it will compete better with traditional templating engines, most of which <i>don't</i> do streaming. If you use Node.js and want a traditional templating engine that uses JS template literals and <i>does</i> do streaming, check out my project: <a href="https://github.com/matthewp/flora" rel="nofollow">https://github.com/matthewp/flora</a>
I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy.<p>You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good idea. But you don't need it right now if you're working on a SaaS product.
OK from single core $10 VPS you will be able to serve
1,080,000 unique initial loads per hour
and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
The author mistakes increasing concurrent request as being some sort of proxy for concurrent users. Once you have maximized rps or maximized cpu, increasing concurrent just artificially hurts your average latency.<p>Max RPS equals number of users you can serve per second. Concurrency should just be tweaked until you eliminate the network latency of your test framework.
So I thought the entire point of SSR was to speed up initial page load - if you pre-render all the static parts of the page, including what happens after routing, but before any API calls, so that your webserver can cache that static HTML for that route and serve it up. What this means is that the user immediately sees much more of a rendered HTML page, rather than seeing a blank page for 2 seconds and having to wait to download and run a massive JS bundle first.
For this reason, we don't use SSR for pages that change often, and turn it off completely for authenticated users. Some performance analysis showed it was actually <i>slower</i> in the average case than shipping the JS and having the client render it themselves, especially with a hot cache.<p>This still provides what we wanted anyway; the ability for pages to easily be viewable without JS and easily indexed by search engines.
These results are not surprising to me but it's great that they were published because people have been very quick to jump on the hype bandwagon for these kinds of projects.<p>I think that the idea of the isomorphic JavaScript app never actually worked in practice. MeteorJS already had a really good go at it.<p>Sharing JavaScript modules between the client and the server is great but when you start to pretend that the backend and the frontend are the same environment, you're bound to run into all sorts of problems and create inefficiencies.<p>The kind of performance penalty incurred by server-rendered React is bound to make your system vulnerable to DoS attacks or at best make it unnecessarily expensive to operate.<p>When programming abstractions shift too far away from the reality of the underlying architecture, you will start paying dearly and the cost won't be worth it in the long run.<p>In my opinion, the client-server divide is a fundamental aspect of multiuser applications and no amount of abstraction can make it go away.
<a href="https://github.com/walmartlabs/react-ssr-optimization" rel="nofollow">https://github.com/walmartlabs/react-ssr-optimization</a><p>React definitely needs work here and i think the right people are quite aware of the issues.
Could the performance be improved if you call React.createFactory() and then stream the factory call like this[0] code?<p>[0]: <a href="https://github.com/styfle/react-server-example-tsx/blob/4586f3431b4bfd424179da3aad2c6adbddb0de10/src/server.tsx#L12" rel="nofollow">https://github.com/styfle/react-server-example-tsx/blob/4586...</a>
If you're looking for DOM in the front, Strings in the back, check out Bel – <a href="https://github.com/shama/bel" rel="nofollow">https://github.com/shama/bel</a>
Did anybody try <a href="https://github.com/shakacode/react_on_rails" rel="nofollow">https://github.com/shakacode/react_on_rails</a> for this comparison?
I'd love to see a side-by-side comparison to Marko.js (<a href="https://markojs.com/" rel="nofollow">https://markojs.com/</a>). It has a lot of react-like features, but was built from the ground up for SSR speed.