TFA's example doesn't work for server-side fetching, and kind of dismisses the issue... the reality is that one should use methods that work for both, if you're going to have universal rendering, so you don't have weird complicated code to do the same thing in two places.
Two things I always try to enforce in code reviews are the use of map/reduce instead of for-loops when practical, and returning early from functions...
// instead of
fn() {
if (foo) {
//really long code block
} else {
//really short code block
}
}
// this
fn() {
if (!foo) {
// really short code block
return ...;
}
// less nested code case
}
It tends to happen a lot, and the function becomes much more clear when you can get out of it asap instead of deep nested blocks.
Interesting, though would be nice if it were a keyboard character used... it always irks me when frameworks choose an obscure character for things like this.
Glad to see extensible end points for webpack, babel (pending) will also be pretty nice. It's a minor niggle, because there are an ever decreasing number of features outside stage-3 that I'm using.
Very nice deck outlining some performance improvements for recent v8 versions... will really be nice to see node@8 with all the new shiny features... async/await is about the last thing I'm using babel for on the server side.
Yeah, I tried to use tape at first, but it was just too slow.. about 5x as slow as mocha, and that's without any actual tests in place. Right now all it does is hit the main test which loads all the js files (force coverage), all the others are empty... tape/tap took like 30+ seconds, compared to about 2 with mocha. Haven't touched jest though.
Not so much going for code splitting as separating the latest FF/Chrome (maybe edge) from the rest... since most of ES2015-2016 is supported in the browser, no need to transpile those features. So the bundle size can be quite a bit smaller.
One more thing I'm doing with the final output is building with preact instead of react, though may revert that in practice, since preact uses real-dom, which may be too slow for some use cases.
Two things I always try to enforce in code reviews are the use of map/reduce instead of for-loops when practical, and returning early from functions... // instead of fn() { if (foo) { //really long code block } else { //really short code block } } // this fn() { if (!foo) { // really short code block return ...; } // less nested code case } It tends to happen a lot, and the function becomes much more clear when you can get out of it asap instead of deep nested blocks.