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.
Thanks... I wanted to try and create a clean starting structure. Though it's a bit more verbose than many, and I've opted for my own scripts over gulp or similar, I find it makes it easier to figure out what's going on when you need to... I still have a bit to finish up, then will probably attempt to move to webpack2 as a step towards a dual-output for dist/.
the dist/ output has everything needed to run, translated/built with a more minimal package.json, and the tests are configured with 100% requirements with pretest and load checking to ensure all files are tested. Although I haven't really written any tests yet, it's been in a making it all work phase.
To this day one of my biggest niggles with jQuery is events use the context for the item the event handler is bound to... you can't use fat-arrow functions with jQuery events.
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.