Worth noting that this uses monaco, the same core editor as VS Code. I'm not quite sure why this couldn't be a set of extensions to VS Code itself, given the number of other extensions... cool result though.
Soem issues with this, just on the Features/tech list...
Mocha/Chai/Supertest... just use Jest, it includes test/assertion/coverage in the box, very flexible and faster than the selected options. I like mocha a lot, and prefer chai's expect syntax, but Jest just does the work better.
React-media and PostCSS... I'm a big proponent of moving towards react-jss (css in js) for styling, you can use themes, template out, reuse and all in JS, including prefixing.
makefile... really, just use npm tasks already, and if you need scripts, make them in js, use shelljs if needed... Yes, the makefile works, but it's simply alien to the JS/Node environment.
I've read most of them... I'm hoping that at least one of them sees a really good ES2017 update including all the added goodness of today's JS. Possibly including a babel/webpack setup walkthrough.
It's not great for those learning JS, but would be very useful to those to whome JS is a second language... hell there's a great name for a JS book, "JavaScript As A Second Language" (JSL)
Like many of these types of articles, it really feels like most of the ng2 v react articles are written by people who are mostly used to angular and moving towards 2, while looking into react.
As to DI.. really, the context that gets passed down is the convention for this, as needed. It's how the react-redux injects the state and actions from the store, how router passes itself down to routes/links, and how tools like material-ui access theming information.
Beyond those cases, you really shouldn't *need* DI, there are tools like rewire for babel, and others (proxyquire, etc) that provide injection for testing purposes.
React + Redux + fetch, are pretty much all you need in terms of "framework", there's also webpack, babel, and some css solution (react-jss, sass-loader, or similar) ymmv.
It's funny, but the specification for JS says that it's supposed to use UCS16/UTF16 for it's internal string representation. This means that anything over 16 bits uses a set... I kind of wish they'd just switched to UTF-8 around EcmaScript3, before it was too big of an issue, now we're effectively stuck with it.
It would still have interesting lengths, but would at least be slightly more predictable... String's .normalize is an example of all that is wrong in this space... it's really wild.
It's also really important to be aware of this stuff and normalize before doing password hashing for your applications.