6 ms·

As the post explains, Javascript has changed significantly since request was first created, and that left them with 3 real options: 1. Try to make massive brea

As the post explains, Javascript has changed significantly since request was first created, and that left them with 3 real options: 1. Try to make massive breaking changes to the request module to make it more easy to work with in the current javascript landscape (promises, new streams, async generators, etc...). This is a problem because then the millions of blog posts, comments, stack overflow answers, and more are all now outdated and wrong. And as the author explained, it would basically be a completely new library. 2. ignore it and become a thorn in the side of devs everywhere (oh, i can use new streams and promises in 99% of my codebase, except for a few old modules that we still use or have to code around until they get removed as they are difficult to work with) 3. Deprecate request, and make a new module under a new name which can adapt to the current landscape. So if you value non-breaking changes over developer experience and complexity of integration, then it's a good thing for you. If you value tools which work with the language as it exists now rather than against it, it's also a good thing for you since the new "request by a different name" will work much better in current javsascript. This is the opposite of what Angular did. Angular 1 vs 2+ were basically different libraries. Rather than take the angular route and just increment the number and keep the name, they are trying something different. They are throwing away the name and starting fresh.

HatchedLake721 8y ago
I'll start from bottom options: 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) 1) "there are a lot of google results with solutions that the new breaking changes will make obsolete" - that's what semver and major versions are for. "We'll break Stack Overflow answers" doesn't feel like a valid reason. jQuery has had its fair share of breaking changes in the last 12 years, and we know the numbers if we compare `jQuery` vs `request` questions on Google/Stack Overflow, so again, it doesn't feel like a valid reason.
- codetrotter 8y ago
  > 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. The new package doesn’t have to start from zero — it can start from where the old package left off. In terms of version control history it could even start life as a copy of the old git repo. The developers having worked on the old version for that long certainly know what will be best for them I should hope. Whether that means reworking the old code for the new package, or taking some parts of it with them, or rewriting everything. As long as they don’t fall for the temptation of implementing new features in the rewrite, or at least not any significant number of new features. > 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) Just because people are using it doesn’t automatically mean people enjoy using it.
- Klathmon 8y ago
  As another commenter answered 3 and 2 (and I agree with them), i'll answer 1: There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Like for instance AngularJs 1.x vs Angular 2+, or what seems like every major version of react-router, or various other examples of this that come back around and bite people. The only difference with those is that they don't have literally 10 years of documentation, blogs, SO answers, and more with no version numbers on them. This isn't an instance where dogmatic application of the "rules" is a good idea. This is one where choosing to make a new library under a new name is the lesser of 2 evils. The hope is it will cause less problems, less confusion, less difficulty for both new and old devs, and be better for everyone. I don't know about you, but i've absolutely spent ~30 minutes on multiple occasions trying to figure out why some documentation seems to be wrong, or a feature isn't working in a library only to realize that i'm not on the latest version or the docs don't have an easy way to go back through old versions, and it's a big timewaste as well as a source of bugs. This move is trying to prevent that!
pbreit 8y ago
Wouldn't there be a 4th option of adding support for the newer patterns without breaking the old?

HatchedLake721 8y ago

I'll start from bottom options: 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) 1) "there are a lot of google results with solutions that the new breaking changes will make obsolete" - that's what semver and major versions are for. "We'll break Stack Overflow answers" doesn't feel like a valid reason. jQuery has had its fair share of breaking changes in the last 12 years, and we know the numbers if we compare `jQuery` vs `request` questions on Google/Stack Overflow, so again, it doesn't feel like a valid reason.

codetrotter 8y ago
> 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. The new package doesn’t have to start from zero — it can start from where the old package left off. In terms of version control history it could even start life as a copy of the old git repo. The developers having worked on the old version for that long certainly know what will be best for them I should hope. Whether that means reworking the old code for the new package, or taking some parts of it with them, or rewriting everything. As long as they don’t fall for the temptation of implementing new features in the rewrite, or at least not any significant number of new features. > 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) Just because people are using it doesn’t automatically mean people enjoy using it.
Klathmon 8y ago
As another commenter answered 3 and 2 (and I agree with them), i'll answer 1: There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Like for instance AngularJs 1.x vs Angular 2+, or what seems like every major version of react-router, or various other examples of this that come back around and bite people. The only difference with those is that they don't have literally 10 years of documentation, blogs, SO answers, and more with no version numbers on them. This isn't an instance where dogmatic application of the "rules" is a good idea. This is one where choosing to make a new library under a new name is the lesser of 2 evils. The hope is it will cause less problems, less confusion, less difficulty for both new and old devs, and be better for everyone. I don't know about you, but i've absolutely spent ~30 minutes on multiple occasions trying to figure out why some documentation seems to be wrong, or a feature isn't working in a library only to realize that i'm not on the latest version or the docs don't have an easy way to go back through old versions, and it's a big timewaste as well as a source of bugs. This move is trying to prevent that!

pbreit 8y ago

Wouldn't there be a 4th option of adding support for the newer patterns without breaking the old?