Change:
"dependencies": { "commoner": "^0.10.0", "esprima-fb": "^6001.1.0-dev-harmony-fb", <del> "jstransform": "^6.2.0" </del> <ins> "jstransform": "^6.3.2" </ins> }, "devDependencies": { "benchmark": "~1.0.0", <del> "browserify": "^4.1.10", </del> <ins> "browserify": "^6.1.0", </ins> "coverify": "~1.0.4", <del> "envify": "^2.0.0", </del> <ins> "derequire": "^1.2.0", "envify": "^3.0.0", </ins> "es3ify": "~0.1.2", "es5-shim": "^4.0.0", "grunt": "~0.4.2", "grunt-cli": "~0.1.9", "grunt-compare-size": "~0.4.0", <del> "grunt-contrib-clean": "~0.5.0", "grunt-contrib-compress": "^0.9.1", </del> <ins> "grunt-contrib-clean": "^0.6.0", "grunt-contrib-compress": "^0.12.0", </ins> "grunt-contrib-connect": "~0.6.0", <del> "grunt-contrib-copy": "~0.5.0", </del> <ins> "grunt-contrib-copy": "^0.6.0", </ins> "grunt-contrib-jshint": "^0.10.0", "gzip-js": "~0.3.2", "jasmine-tapreporter": "~0.2.2", "jest-cli": "~0.1.5", "lodash": "~2.4.1", <del> "microtime": "^0.6.0", </del> "optimist": "~0.6.0", "phantomjs": "~1.9", "platform": "^1.1.0", "populist": "~0.1.6", <del> "recast": "^0.6.10", </del> <ins> "recast": "^0.7.2", </ins> "sauce-tunnel": "~1.1.0", <del> "semver": "^2.3.0", </del> "tmp": "~0.0.18", "uglify-js": "~2.4.0", "uglifyify": "^2.4.0",

Discussion:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed.

Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond