Deprecating is a weird decision as there is nothing wrong with the "request" module. It doesn't lead to bad code, bugs or security risks.
It would be better to say this is the last version, except for security upgrades. These upgrades can be done by other maintainers that are assigned to the project.
"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.
The maintainers claim that the community would be better off without the package. Someone has to stick around to do security fixes for it, and that's time that could be spent making more innovative contributions to the Node.js package ecosystem.
This, I use it for all Node.js backend requests. Personally I think we need to move to isomorphic solutions and work to unify backend and frontend JS development as much as we can. This one's a no-brainer
Thanks! You can use the extension in a CI setup by first installing the remote-browser extension, and then using it in your tests. You can check out remote-browser's own tests for an example of integrating the project with CircleCI [1].
The "hipster hacks" are things you not necessarily use but are fun things to try. Some of these are for fun (like #1) and others (like #2) are day to day life-savers.
Amazon is amazing at creating scaleable and reliable services, but their UX and the way they announce new products is awful.
There's room for startups to wrap these services into something more usable. There are already good examples: netlify, graph.cool, dashbird and others.
Hopefully someone at AWS is reading this, and/or they are already working on it. I like AWS and have used it since the first days, but....
The AWS web console is terrible UX/UI, and when they do update an area, eg s3 they almost make it worse.
Please hire a few of the best UX/designers you can an do a top down refresh of the AWS console with consistent navigation.
I am moving new and existing projects to Google Cloud based on the some slight different product offerings, sustained use discounts, and in very large part on the better web console.
Thanks for the dialog. Worse than AWS? What areas? I don't think Google Cloud console is amazing as far as dashboards go, but it is way better (to me) than AWS web console.
I think so, yes. For example: You can browse BigQuery tables you have access to in a tab, but have to open a new tab to your project where you have billing attached to actually query those tables. So if you're part of a large organization with multiple divisions with their own billing, there is no way to see your tables and query them in the same view.
Most of the console feels to me like the people who build it don't actually use it.
Vertical sucks. You have to scroll down to somewhere different each time to find the thing you want. Also, the search box doesn't have all results cached so you type in, e.g. endpoints and it pauses for a few seconds until it displays a link to the menu. The GCP console sucks.
When you see mistakes or things that aren't clear, please use the feedback button on every page. Every time I've submitted something eventually it gets fixed, surprisingly it seems like people actually read that inbox.
I still think there is HUGE room for a service company that will wrap Amazon services in an economic way.
The value proposition here is incredible, you can save so much money for companies.
At my previous company, I changed one of the data ingestion architecture and saved 250,000$ in YEARLY AWS bill.
Of course, there are many problems with this, but I still think there is room for this. Right now, this knowledge is in silos in companies. Lots of companies should benefit from this.
Thanks a great point, avitzurel! This will be exactly one of the core offerings what we're currently working on at Graphcool.
AWS provides great building blocks but using them efficiently is a major challenge (especially for smaller teams). Like in your case, there is an enormous potential in better resource utilization!
Cloud brokerage? The key is that they don't just wrap Amazon, but rather multiple cloud providers, and offer some degree of abstraction to enable multi-cloud architectures.
I am not talking about reselling or just wrapping it in a different package. My point is that a lot of companies are over paying Amazon by a lot. There is room to improve this.
This is a classic service company, but the service it provides can be quantified and measured in a great way
