And, frustratingly, the line where Node ends and frameworks begin are too blurry. This is made worse by the fact that thousands of bloggers have a node server tutorial, essentially drowning out the good ones.
I also don't see how it could be possible to find the line between Node itself and frameworks ambiguous - unless the framework itself is invoking your JS files, in which case I would recommend moving to something lighter (i.e. something more designed for composition - where you call it, rather than it calling you)
The most challenging thing for me in Node right now it upgrading an application with my HTTP services to use HTTP 2 with binary streams.
Isn't that solved with a simple google search? Async/await makes the function return promises, so if you use an async callback in Array#map you end up with an array of promises, which you can use with Promise#all. Seems rather simple to explain and grok.
I'm a scala person, so I naturally tend to like promise style (and async/await is a nice sugar) but my experience interviewing a lot is that people that were not exposed a lot to callback style don't understand what asynchronous means, which is a good enough reason IMO to keep callbacks :) the fact that the std lib is also full of them (we are using node 12, I don't know what is the current status, but for now most of the std lib is callback only for us) does not make me want to do the switch at all.
Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model.
We also have a big project. we started during callback days, skipped promises (I never thought promises alone were an improvement over callbacks and async.auto). But as soon as async/await was in, we allowed them in the codebase.
So now the codebase is a mess, with some functions being callback style and some others promises, stiched together we promisify functions. Im hoping in a 2-3 years time frame all our callback style functions will be eventually phased out during small refactors and rewrites.
This migration plan is the only method i found that enables projects to move from A -> B without spending massive times rewriting the whole project and yet keeping up to date with technologies so they wouldn't need a rewrite every 10 years.
I used to ask candidates to implement async.map and I used to be baffled that the majority of JS devs are unable to do it. There are those who would say "I'm not used to callbacks, I use promises". I would then allow them to use promises (no Promise.all allowed, that's what we are trying to implement ^^). I have never seen one of those "promise only candidate" manage to do the exercise.
If you want to push it to the next level, ask them to implement async.mapLimit. You wouldn't believe how few people that are looking time professional JS devs, are actually able to do it properly (I actually used to ask that one, before realizing that it was too much to ask... )
All you would have had to do is make it so when you use the await keyword, you don't pass the callback, the runtime passes it for you, pauses the function and resumes it when the callback is called (returning values and throwing errors as you would expect). I implemented this here: https://github.com/bessiambre/casync but it would be even better with language level support.
Whenever I encounter JS beginners and they ask me about simple looping over asynchronous operations sequentially, I mention async/await, the discussion veers towards promises and then I have to mention the state machine and the caching layer for errors and return values, pending, fulfilled, rejected, settled states, reject/resolve callbacks and how it all fits together with 'then' chaining and 'dynamic replacement' by which point they just want to go back to Python or whatever.
With a callback based async/await, I could just say: Here, with this keyword, the function will pause until the callback is called. Just put your function taking a callback in a normal loop and await it. It would be cleaner, more functional, more stateless and faster.
The features of promises aren't even used with async/await. The point of promises, the caching layer and the state machine, is to be able to add the continuation later but with async/await, it is always just the next line in the function so it doesn't need to be added later. It's unnecessary performance penalty, complexity and statefulness on every asynchronous function call.
I did try to propose this as a language feature here: https://es.discourse.group/t/callback-based-simplified-async...
It didn't get much traction an I was too busy to push it further.
I still can't believe the nodejs universe doesn't have back pressure (eg caolan/async) baked into the stack. Those were some pretty difficult conversations. My teammates had no idea what I was talking about or why my fixes worked.
Absolute paths for importing modules (requires) still makes me laugh.
But criticizing nodejs, js, etc is rather pointless. Like PHP, it's fractally wrong.
You need to know the args, and it just seems "hacky". Like it's good to write something small when you know what functions you use etc... but just not stable for big stuff.
Also, it seems like your comment could be generalized to include all dynamic language runtimes, not just Nodejs.
You can set up most IDEs to get excellent auto completion - VS Code does a good job of that kind of thing.
IDEs do spoil people.
Makes scripting languages really hard for me to use as a consequence.
If anything, TypeScript sometimes feels like a nice middle-ground between C# and JavaScript (and Java?), and though it's not perfect, I do feel that it's pleasurable once you get the hang of it and the quirks of the ecosystem.