"Deprecated" to me means the author says you shouldn't use it, or with more nuance, that "you shouldn't start using it now, and you should switch out of it ASAP if you already are a user, because it will very possibly stop working within the lifetime of you own project".
"A better alternative" is not enough of a reason to not use another alternative, because "better" is not an absolute value and choices tend to have many axis to balance (for example, prior experience).
Well, looks like your only difference is on that ASAP part.
Deprecated functions within a module will surely stop working in the near future, but deprecated modules probably won't. It's not great that we see the same warning for both, and we should not treat both the same.
If the alternatives are better, then devs will choose those solutions and "request" will fade over time. It doesn't have Promise support, so new projects will likely not choose it.
request is very simple and straightforward library that solves a very common issue.
Deprecating it causes a lot of work for every project out there. Either using request directly or indirectly.
I have a lot of respect for the maintainer, and he can choose to do whatever he wants with this module. That's his privilege.
However, the fact that he got "bored" with this solution, doesn't mean he needs to deprecate it. He can just stop working on it, and give ownership to someone else.
If it had a security issue and he is not going to ever update it, then that would deserve the deprecation so people should be warned.
> However, the fact that he got "bored" with this solution
That's a horrible mischaracterisation. There's a clear ecosystem-wide shift to async/await instead of nested callbacks, putting a project that depends heavily on callbacks into maintenance mode rather than releasing a new, entirely incompatible version that uses async/await is completely reasonable.
Also worth pointing out is that the same person who posted the maintenance mode announcement also released a request library that does use async/await: https://github.com/mikeal/bent
While this isn't really the place to discuss this, that your most complex example is a simple waterfall of three nested async functions doesn't do much to sell the superiority. Start mixing in conditional async calls with downstream async branching. And look at the Promise-based solutions to async.js (https://caolan.github.io/async/v3/), a library nobody misses. Still not sure if your blog post is a joke or not though, frankly. If it's a serious post, then it seems troll-y to inject such a fringe opinion any time someone casually mentions promises being good.
fwiw they actually did mark their package as deprecated on NPM which means that all installations will see a warning that urges the user to consider other software.
It's kind of like if you were to maintain your own promise implementation, then the Promise is added to stdlib. You wouldn't say that your project is "done", you'd want to encourage your users to use the native promise.
Request was created back when all we had was the stdlib `http` module.
> Request was created back when all we had was the stdlib `http` module.
What stdlib module supersedes `http`? Browsers have `fetch` and there's `node-fetch` and `axios` modules, but it's sad that core node hasn't updated the core http module.
Node has an http2 module as well, but it's still pretty low level. I don't think there's anything wrong with the stdlib module being lower level than the third-party ones.
