Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

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.

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)

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.

> 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)

Just because people are using it doesn’t automatically mean people enjoy using it.

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!

> 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"

Doesn't this library also predate the semver spec, and wasn't just such major alterations the purpose of the major version number back then?

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

Reply on news.ycombinator.com