The one point that rings true to me is "Focusing on poor metrics such as “issues closed” or “commits per day”"...
I was on the verge of being fired (I moved on to another position before that happened), because my issues list didn't have as many closed items as other developers.
Despite the fact that I'd literally removed over 20kb of code from the project (the prior month) with mild refactoring, using better techniques and all the code I did refactor/add was 100% tested. I also helped a lot of the other developers in the group, and had to participate in the meetings for two teams. But no, the issues closed ruled the roost so to speak.
Mistake towards the top, in the second code segment...
someModule(param, (result, error) => {
should be
someModule(param, (error, result) => {
Node-style CJS async methods should *always* have error first in the response... those few API interfaces that don't cause issues with other libraries.
I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise.
I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code.
const foo = () => new Promise((res,rej) => {
someCbFunction((err, result) => err ? rej(err) : res(result);
});
There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.
The only thing I'm unclear on, is in the example, what is `module`, is it the default export (`import module from 'url'`), or is it the full exports like (`import * as module from 'url'`)
Interesting idea, aside from MaxArt's points.
Regarding the original framework, I'm starting to feel like there are a lot of "me too" JSX frameworks popping up, and while I appreciate a more purely functional approach, I'm not sure that it's necessarily strictly better over static render components.
Back on topic, I've similarly wanted to see a more formal guild form around software development, but it just seems like a huge undertaking.
I keep thinking it would be nice if TS was an extension to Babel, so it could work with other presets/tooling in that space. Avoiding the double-ast cost when going through TS + Babel, just so you can get async functions and a handful of other goodies.
Mistake towards the top, in the second code segment... someModule(param, (result, error) => { should be someModule(param, (error, result) => { Node-style CJS async methods should *always* have error first in the response... those few API interfaces that don't cause issues with other libraries.I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise. I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code. const foo = () => new Promise((res,rej) => { someCbFunction((err, result) => err ? rej(err) : res(result); }); There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.