Compiled out process.env.NODE_ENV for Rax and React benchmarks

[aickin]

This is a new version of #5, built on top of #7. It compiles out process.env.NODE_ENV in both the Rax and React benchmarks, in both the renderToString and server versions. It cannot compile out process.env.NODE_ENV in Vue because Vue's server renderer is not webpack-compatible.

For more background, read #5, #6, and #7.

On my machine, before this PR, I get:

-----------compare renderToString----------
Rax#renderToString x 93.54 ops/sec ±3.63% (65 runs sampled)
React#renderToString x 58.27 ops/sec ±1.49% (58 runs sampled)
Vue#renderToString x 205 ops/sec ±4.16% (72 runs sampled)
Fastest is Vue#renderToString

And after:

-----------compare renderToString----------
Rax#renderToString x 93.09 ops/sec ±4.20% (58 runs sampled)
React#renderToString x 140 ops/sec ±1.29% (74 runs sampled)
Vue#renderToString x 207 ops/sec ±4.22% (72 runs sampled)
Fastest is Vue#renderToString

[imsobear]

@aickin Could we avoid compile server-side code to assets? Under normal circumstances, the server-side code is not required compile.

[imsobear]

And in real project, I think most people won't use this directory specification to works.

[aickin]

@imsobear I disagree here. The right way to deploy React SSR to production is to compile out process.env.NODE_ENV on both server-side and client-side code. And to be clear, you were compiling the app code for server-side already, right?

[imsobear]

About SSR, my ideal way is that don't change the code way both in server-end and front-end. But the truth is front-end must do some change, we can't avoid that. And now for this problem, we need compile the routes or controllers code to assets. I think it is strange and ugly as a Noder.

Maybe there is a better way to solve this problem. :)

[imsobear]

We preferentially try to solve the renderToString benchmark problem. And ignore the qps comparition temporarily.

[aickin]

OK, so you want me to stop compilation of the controllers and remove the qps benchmark?

[imsobear]

Yes, don't compile the controllers and ignore qps benchmark temporarily. And we just solve the problem that how to require('react-dom/dist/react-dom-server.min') in benchmarks/renderToString.js.

[aickin]

we just solve the problem that how to require('react-dom/dist/react-dom-server.min') in benchmarks/renderToString.js

I'm pretty sure this won't work (and I know it isn't a supported way to use the library). Didn't you try it already and have problems?

[imsobear]

Yeah, It can't works. In my opinion, if this way could greatly improve React SSR performance. React should support this ability or a best practice. I don't agree with use many hacks for this feature.

Thanks for your guidance. And I have learned a lot from your video. 😅

[yyx990803]

I tend to agree that "compiling server side code with webpack to remove access to process" is not what Node developers would typically do, and likely many React users are not even aware of this possibility. So the current results are probably more representative of React SSR perf in the wild. However, it can also be a bit unfair to not show React's perf with full optimization.

Maybe we can add this optimization as a separate entry in the benchmarks? (preserve /react, add /react-optimized).

P.S. I've seen on Twitter that the React team is considering exporting a pre-compiled bundle for ReactDOMServer if process.env.NODE_ENV === 'production', which should eliminate the need for this workaround in the future.