Change:
I ran a few benchmarks on the server (modifying to not use jsdom). The results were surprising, as the browserified was about 30% faster than the npm version, even with . The performance ranking (test run time) was < < < . I suspect is not a regular js object but perhaps a getter and thus carries a penalty when you test for everywhere. Also the minified version might still perform best of all, as at least some time ago V8 used function source length (including comments) as a heuristic for function complexity / compilation time and thus affecting chances for optimization in some cases, but the effect might be negligible.
is indeed not a regular object, but defined from the native side, so that may be the culprit for server rendering regression: and So this introduced a getter in quite time-sensitive places (around invariants etc) in your otherwise clean codebase. Can you reproduce the issue? /cc
Lately I have been simply using a wrapped module Works great. You could consider switching npm package to some such scheme if there are no downsides.
My first attempt was to just add to the top of every file, but unfortunately uglify isn't smart enough to do dead code removal then. I wonder if we should have essentially make two copies of the code -- one for dev, one for prod, so transforms into so we only pay the getter cost once (per module) at require time. Is doing this easy with recast? It's not obvious to me if interacts well with cloning the AST.
I would love to see this get some attention. 30% improvement out of the box would be awesome. Is there a lot of work to do here?
I think eventually we will want people to do a build step for server rendering, i.e. webpack's mode. Especially if people start expressing static asset dependencies as statements.
I'm using webpack and was enough to solve it for me. Is there no such thing in browserify?
For browserify there's transform which automatically activates for package. You just need to set before bundling: Thus browserify also can be used for bundling for server rendering.
Call me all crazy, just had a left field idea. Could the transformer that builds the npm module create 2 complete copies of react? one for dev and one for production? In the the normal version of react could you there look at the and swap which module is returned? This way on server you only get the performance hit once;
That's not too crazy. It's a bit annoying from a build process though. I'd love to know what's happening at a larger scale in the node community. It seems like we shouldn't be the first people to encounter this in a larger scale. A couple other ideas… What if we set in our main module and leave in our code everywhere else. There's some obvious bad behavior there (setting globals). So we could do variants. Only set it when it's not already set. Change to something more unique at build time () and then set that. If we switch to webpack for building the browser bundles, then the solution is super easy, and I'm sure there's a way to do this in browserify too. Another idea: Have a modules which memoizes . This is sounding like something node should do itself, but the code linked to uses ObjectTemplate (which if I'm understand a bit of V8 right doesn't do any caching because values can change). There would still be a lookup cost, but it would just be a property access, not a getter and not a call out to get current environment variables (). This one is trickier because it would mean more code and we won't do this internally. I'd prefer a different solution, even if it's more hacky. If all you're using is React and nothing from , then you could do something like mentioned above. We started shipping the browerified bundles in the npm package, so and will end up giving you the bundles which don't access .
I don't think we're going to do anything specifically for server rendering other than bundling the builds in like mentioned, but we might change the npm package eventually to be prebuilt using closure or similar.
just curious why and not ?
It was just an example. If that was the actual code I'd do the direct assignment like you suggested.
ah, ok - thanks :)
any movement on this?
No movement, though you can already require the builds from react/dist as mentioned above.
since you mentioned Webpack, do you use Webpack for server side code?
If you're already using babel on your server-side code (say, via or ), you can add the to get around this problem.
I wonder why react just can't export from for production env when react package ships with .
Because then results in a different copy of code, which will have issues. As long as that is remotely supported (and it's currently how and our addons packages work), we can't do that. we might do something like that in the future though.
true that it's not recommended to run babel on libraries? I've seen a few warnings about this. Have you tried the babel transform-inline-environment-variables plugin in production? Did it work?
Technically, you have to (which is slow) to get this to work. How do you feel about compiling not into in non-dist builds, but rather require() some module that caches the env? This is just a guess, but I believe will optimize well (function call vs. getter (which doesn't optimize in v8) + call to ). I found the babel plugin in I'll give it a try & profile.
thanks! However, I've seen a warning that is . I've only used on files in my app. I'm curious if people use it on node modules commonly in production.
The catch here is that people use envify to do dead-code elimination to remove non- blocks so changing our pattern here will force downstream changes.
Understood. I suppose it becomes a question of priorities unless we can think of something more creative. Unfortunately with the introduction of react-dom, it's not possible to use react minified builds on the server anymore unless you use a packager or the without duplicating , due to the new halfway-shimmed packages that directly.
should work, no?
Ah you're correct, since the deprecation notice will get taken out due to the production check.
Oh wait, you're right that react-dom does require react directly…
Hah got confused myself. You'd have to just require and pretend it was ReactDOM, knowing that the deprecation warnings would be removed. Doesn't seem portable to 0.15.
Initial bench results show a wider performance gap (last two runs) than the OP. In bench 4, I replace with , eliminating the getter.
I wonder if performance can just be improved in node core (by caching).
I've asked about that, but they're not interested because programs may be relying on catching ENV changes as it is possible to change the ENV of a running process. I've been able to manage a great improvement in server-side rendering (about 100%) by hosting to the top of the file as a , so it is only evaluated once. The best part is, when uglifyJS sees a const, it replaces the member in a condition, leaving which is then removed entirely. So we maintain the same code size, no backcompat hacks, and better perf. Only issue is that we may need to then post-process replace the for a in case of use with Browserify with old browsers.
Can I ask why this was closed? This is by far the number one bottleneck for us on the server-side. Having to change all code to , for example, is a leaky abstraction and very un-Node-like.
Technically you can fix the problem in your own code by doing , converting it from a live object that calls down a plain JS object. You'll get the same performance benefits, with the only downside that any code that was relying on live edits to the env (does anyone really do that?) will fail.
cool, good to know – neat idea! Still, massively leaky abstraction right? Like, suddenly React pollutes your entire app
Yeah. I've been working on , but it requires a change in UglifyJS to allow marking statements with an annotation (e.g. ) so it knows that it won't change and safe to eliminate dead code.
killer little hack btw – immediately increased our server throughput by 50% I'd still love for this issue to be reopened, or tracked elsewhere (will improve things for all React code?) should work on speeding it up as well (I believe they've made ), but having littered throughout hot code is just not ideal practice IMO – if not being able to hoist that up, cache it, memoize it, whatever, is prevented by build tools, then let's fix the build tools.
They're . is meant to be live.
oh for sure it is – I completely agree with that – I don't think it should be cached by Node either, just the current implementation has (or had) room for improvement.
As I mention in that ticket, this is the main problem: A annotation in UglifyJS will fix this.
That seems like a decent solution to me. I'm personally not a fan of the use of a global everywhere in the React code – again, it feels really build-tool specific. I'd prefer it be imported from a config file or declared in each module or something similar. Principle of least surprise and all that.
I would be happy to do that, but it is important that we have a way to eliminate dev-only code in prod builds and that users of React from npm have a way to do the same. Obviously we can use whatever tools we want for our stack easily but for npm currently we suggest envify/webpack.DefinePlugin. Not inherently opposed to changing that but we'd need a good proposal and reason.
yeah, I hear ya – there's a lot of code now in React that depends on that behaviour. Not sure I fully understand your comment "for npm currently we suggest envify/webpack.DefinePlugin" – what do you mean "for npm"? React code is compiled before it's published to npm, right? My general feeling is that it would be great if there were no FB/React-specific idioms in the code – so that it's treated as though, if v8 (or other engines) had all the ES2015/2016 features needed, then you could run the code on without even needing a compiler. Currently that's not really the case. (I'm sure you could do some sort of trick or something before requiring any React modules, but still, that would be a polluting hack) If there were a way such that was required, or declared, per module – and code elimination still worked as it does now for the builds – would you be amenable to a PR along those lines?
I mean: if you use webpack or browserify in conjunction with react from npm, you should be able to eliminate React dev-only code from your prod builds. envify lets us do that easily in browserify as it copies the NODEENV from when you make your build, and webpack.DefinePlugin lets you configure your build to replace with a constant which then can get constant-folded and minified out. This use case is important. Yes, if it works for the case of React devs using browserify/webpack too, not just our premade builds.
as an aside, just looking through the code now, and aside from the global , I haven't seen anything that's not supported out of the box in right now – is there a reason, aside from , that the non- code is even compiled and transformed into a different structure before publishing to npm?
Well, it does set up the team to move to ES6 for , which will be important in the near future. I've submitted a PR to UglifyJS2 as you can see above. If it's accepted this will solve the problem.
We'd still need everyone using React to upgrade to that version of UglifyJS so I can't promise that we'll take it…
Just everyone using React in combination with webpack or browserify and not using the build. Alternatively they could use the DefinePlugin to set to false to get the dead code elimination.
just to clarify, do you mean "everyone using React who also currently uses UglifyJS with it"?
Just so I'm clear, there are a few users here that I can think of. Those, on the browser: everywhere already, or as a global browserify/webpack + envify/DefinePlugin browserify/webpack + envify/DefinePlugin + UglifyJS browserify/webpack + plugin to transform to or So 1 and 4 are taken care of by the compilation in . What's the main reason for even supporting 2 and 3? Is it because of things like ?
2 and 3 are the most natural for many people. If you are using browserify then envify gets used automatically because of our config in Almost everyone minifies their code in prod. It is true that we could recommend instead for many cases, but it does fall apart in the case of requiring submodules. We don't support this for external users because we consider the modules private but the addons packages use this pattern. Various third-party projects (unsupported by us) also make use of this.
I think the only reason 2 and 3 are "most natural" is just because is used everywhere so you have to use something just to get it to even work out of the box. It would be equally easy to setup the config in to use or or whatever. I use 4 whenever I can and it's no more complicated than 2 or 3 for normal usage – I guess it's just a pity that users are encouraged to "reach in" to for various addons. Thanks for the clarification. So it's those doing 3 who are expecting their current UglifyJS setup to eliminate any code using that you're concerned about?
To clarify: we recommend users require or similar, which (currently) reaches into react but that's an implementation detail. Yes.
Ah cool, good to know.
We have been bitten by this one too. Would be great if some note about this behavior was present on , it's a large performance impact, and is hard to find this issue unless you have already done all the investigation work.
I would like to add that this issue also affects applications. Now the work arounds seem to be: Include the minified version of React globally via tag, it would only work in Electron and it isn't the node way, where one should be able to track every used object just seeing the . It also makes it difficult to switch between dev/prod. Use the to replace with a regular object. Not good, as we are forced to overwrite node api just because we want to use React. If using babel: ... by default babel doesn't transpile nodemodules, this can be configured but doesn't look like a work around. Note that replace every to isn't a solution because automatically requires from root, not from . Why is this issue closed? It seems to me that React should be able to initialize its configuration using , then rely on its own objects, and optionally offer a function to change the value later. Is there any reason why this wouldn't work?
Technically this could be fixed now as UglifyJS supports annotations, and it may be easier still as the team moves the build to Rollup in . In combination with Rollup, it would be simple to export a var from a constants file and have it effectively tagged by Uglify for dead code elimination in production mode.
Adding my two cents here, I was able to work around this by adding the following to the top of my I had previously wrapped React using local modules as was suggested above, but this caused a lot of issues with . This seems to get the job done without too much overhead or complexity.
For future reference, the above snippet is broken per:
Referencing which will fix this now that UglifyJS can properly eliminate dev code (even if it references a that never changes) with its new option, which is a default. See for more context.

Discussion:
componentWillMount() ``` <del> Invoked immediately before rendering occurs. If you call `setState` within this method, `render()` will see the updated state and will be executed only once despite the state change. </del> <ins> Invoked once, immediately before the initial rendering occurs. If you call `setState` within this method, `render()` will see the updated state and will be executed only once despite the state change. </ins> ### Mounting: componentDidMount