Decide whether to provide the option of bundling the development vs production React .js files

[myitcv]

Related to #28 but not dependent on it; this issue is relevant so long as github.com/myitcv/gopherjs/react continues to offer the option of bundling React's .js files

Picking up on discussion in https://github.com/gopherjs/gopherjs/issues/611, specifically from this comment

Facebook have two versions of the React .js files:

• development - has some extra runtime warnings/checks etc to warn against probably incorrect behaviour (they mainly have to do this at runtime because there are no static analysis tools that can achieve this)
• production - no additional sanity checks

The development version is somewhat analogous in my mind to the race detector mode of the Go toolchain.

We currently (as of f51106b7ade5da288a9b798bb6c700d59032b0a0) bundle the prod version by default; the development version is enabled via --tags debug.

As the Facebook docs make clear, the runtime behaviour of these two versions is different.

The question is: should we provide the option of bundling one vs the other?

Points to consider:

• The runtime behaviour is, as stated, different between the two. This is a negative
• Without static analysis tools these checks currently provide a useful check (for example it catches cases where you try and nest <p> elements)
• ...

[mpl]

When you say the runtime behaviour is different, does it mean that some code could run correctly (i.e. as intended) with the dev version, but not with the prod version?

If that can't happen, I don't really see the runtime difference being a negative.

[myitcv]

When you say the runtime behaviour is different, does it mean that some code could run correctly (i.e. as intended) with the dev version, but not with the prod version?

The React team or docs would be the definitive answer on this.

But I raise the question here really because really there should be no difference between development and production; it's tantamount to having a -test flag where your code behaves different in one "environment" vs another. It's something that Rob Pike rightly, in my opinion, calls out as bad practice.

But in this situation, as I mentioned in the description, I think the situation is slightly different. Because good static analysis is very hard, the option of the development vs production version is more akin to the -race mode of the Go toolset. So I can see that it has merit (particularly if you consider an app that combines GopherJS React code with other non-GopherJS React components)

So really an opportunity to opine on these various points.