+++ This bug was initially created as a clone of Bug #1035655 +++ Right now we're using the development version of React in Loop. What we'd really want is: - use the production version for the user facing application (standalone-only, desktop done in original bug) - default to using the non-production version in dev builds so we get extra console warnings - run tests using both development and production versions, so that we get the benefit of the extra warnings during failures, but we also test the production code paths.

This will be simplified once we have a real build process for the standalone client. One which uses grunt is coming in bug 1035655, so depending on that.

Until we get this bug, the standalone client won't be optimized for fast download/startup. I think we want this to block whatever version removes the beta tag. Nominating for Fx35, assuming that we're still planning to remove the beta tag for that version.

(In reply to Dan Mosedale (:dmose) - not reading bugmail; needinfo? for response from comment #2) > Until we get this bug, the standalone client won't be optimized for fast > download/startup. I think we want this to block whatever version removes > the beta tag. Nominating for Fx35, assuming that we're still planning to > remove the beta tag for that version. I believe Product and our partners have agreed to keep the Beta tag on through Fx36 (i.e. plan to remove it in Fx37). That said, I'd be happy to see this done sooner than Fx37, but I don't know that we have the bandwidth before then. (Note: Development for Fx37 starts the week of Nov 24).

Moving this to P2 based on our new priority definitions.

Removing the [tech-debt] tag. This is really to improve standalone performance.

dan and mark talking to ops guys on how to move forward.

Dan, I think we're doing most of the originally intended items today. The only other thing I think we'll want to do is make it so that functional tests run against "built" or "dist". What do you think?

Mark: we might also want to run unit tests against either target as well, in case uglify has some bug that one of the unit tests might pick up. This seems low priority if it's worth doing, though. Otherwise I agree.

(In reply to Dan Mosedale (:dmose) from comment #8) > Mark: we might also want to run unit tests against either target as well, in > case uglify has some bug that one of the unit tests might pick up. This > seems low priority if it's worth doing, though. Yeah, I wondered about that case. At the moment, we'd have to do some work for the unit tests to change which scripts are packaged etc. This would be easier when we have a module system. I think like you say its low priority, and I think its reasonable that we ignore it for now, and if something starts to bite us then we'll deal with it then. Hopefully functional & other testing will find the issues for us.