NBD: A popular HTTP-fetching npm code library used by 48,000 other modules retires, no more updates coming After eleven months of planning, the npm-distributed request module has been deprecated, meaning the popular JavaScript code library for making HTTP requests is no longer supported and won't receive further updates. The almost 48,000 other npm modules that include request as a dependency won't see any immediate effect, other …
...and the code patterns at the heart of request are out of date
I do understand the urge to do everything in the most fashionable modes all the time. However, if it ain't broken, don't fix it. The JavaScript ecosystem made the same mistake as the Java ecosystem. It has become a complexity and dependency hell. A wakeup call should have been the recent downing of an npm package.
Yes, new paradigms and design patterns are a good thing. But being a bit conservative is also a good thing for longevity and maintainability. Complexity is hidden down the line of libraries and ripple up through the dependency chain. It is a nightmare to inherit unmaintainable old code with a blend of discontinuous paradigms and design patterns mixed. It should have been maintainable. It reminds me of the good old "Good, Cheap, Fast" choice. You still only can pick two, however, the "cheap" part is getting more and more expensive, the "fast" part is slowing down and the "good" part becomes a rather relative expression.
"I do understand the urge to do everything in the most fashionable modes all the time. However, if it ain't broken, don't fix it. The JavaScript ecosystem made the same mistake as the Java ecosystem. It has become a complexity and dependency hell. A wakeup call should have been the recent downing of an npm package."
The problem is with this mantra is that it doesn't make web agencies money, and it doesn't tickle the ego of the developer. They WANT the latest and greatest for their own benefit, not for the customer. They WANT the complexity it brings because it means they can charge the client more hours and get more money.
You can sit there and argue that things should be simple, if it isn't broken don't fix it, return to the idea of KISS. But if your boss or team leader is a w****r the idea won't fly. Yet it won't be them trying to work out why a dependency has failed or why the software is no longer supported by an open source project they don't contribute to.
</rant>
This one sounds like a legit case for change: It was developed when the framework was very new, and not that well explored. People have since discovered better ways of doing certain things, and trying to interoperate with the old ways just leads to piles of boilerplate. Stability can be good, but sometimes cutting your losses and moving on is better.
11 months notice seems a bit optimistic to me.
Python 2 had it's EOL extended by five years, yet there were still people complaining about it's EOL earlier in the year because they hadn't started using Python3 for new projects (or porting old code over).
I don't overly blame the guy for ending support (you've got to at some point), but I think even his caveated position is a little overly-optimistic on how long it'll take for people to move to something else. As long as request works, people'll continue using it because they're familiar with it (path of least resistance).
At some point there'll probably be a short-sharp shock as some bug/vuln is found and people start to actively realise what it means to introduce unsupported dependencies into a project
"I don't overly blame the guy for ending support (you've got to at some point), but I think even his caveated position is a little overly-optimistic on how long it'll take for people to move to something else. As long as request works, people'll continue using it because they're familiar with it (path of least resistance)."
Then people would just use the request code indefinitely.
Surely there are multiple HTTP handler libraries available that implement the same functionality? If your code relies on this module and you can't replace it in one full year or so then I think the problem is with your resource management.
Is there a reason why this request code can't be forked or maintained by someone else?
If your code relies on this module and you can't replace it in one full year or so then I think the problem is with your resource management.
You could say exactly the same about Python 2 <-> Python 3. And with that you at least don't have the issue of some module you use also relying on the deprecated module.
The world just doesn't work that way, even if it should.
A lot of businesses won't pay for refactoring of something that's currently working, and devs often won't go out and learn a new library if they've got one that works just fine (now) that they're very familiar with.
None of this is the problem/fault of the requests maintainer of course, I was simply commenting on the fact that I think he's still somewhat underestimated the inertia.
It's a node thing.
Quite some time back, builds started breaking because a dev withdrew his modules.
The biggest breakage - left-pad - a module to pad the left hand side of a string with zeros/space, very much a built in for strings in most other languages.
It was at that point that NPM realised they needed to prevent devs from removing their code, otherwise breakage is near certain.
There's certainly an argument to be made for putting things like this into the standard library. It doesn't prevent 3rd party libs from offering alternative / better / finegrained ways of doing the same, but it reduces the amount of dependencies that are required for code that just wants to do something straightforward.
Languages like Golang have adopted this "kitchen sink" approach to their libs. Even Java has a pretty extensive http support in its runtime but you can always use Apache Http instead if you want.
"Developers using *INSERT SOFTWARE NAME* today are often including layers of indirection in order to port those old patterns to new ones," he said. "This shows up in bundle sizes, performance, and debuggability, and there are numerous newer libraries that don’t have these problems."
Applies to nearly everything. Windows. Linux. Office. You name it, it's a cesspool of legacy fixes, edge case hacks, and backwards-compatibility kludges. Let's put a strict time limit on all software - ten years of active development, five years of LTS - followed by not just a rewrite, but a completely new product every decade.
So, you are suggesting to reinvent the wheel every ten years. However, the wheel is always round and has exactly the same function. Yes, bells and whistles may change, but the core remains. The computer hasn't changed that much either. It still is a simple machine manipulating ones and zeroes. Yes, faster, bigger, parallel, more shiny, more bells and whistles, etc. But the core remains.
Why change a working system? Just for the sake of change? Or are you suggesting the ultimate employment strategy, where each younger generation is forced to abandon the previous generation's knowledge and strategies? Maybe ten years is too long. Hardware is replaced more often. Why then not force each hardware generation to be accompanied by its own software strategies? That'll create the ultimate amount of work. Lets abandon compatibility and let divergence rule... sigh.
I will happily rewrite that working software for you, from scratch.
You provide the requirements, and user stories, I'll put together the spec, and cost it up for you.
Specification time is chargeable in advance.
What do you mean, you want me to do it "for exposure"? What am I? A jobbing musician (who also won't work for free, but is used to this sort of thing)?
If you get the dependencies for any Node project that's older than a month or so, you'll see at least half a dozen 'deprecated' messages for direct or indirect dependencies. I wouldn't expect any project that's older than 11 months to even run any more, even if you can hit on the right NodeJS runtime version. This is fun when you're doing embedded JavaScript work (yes, it's a thing...) and have to update a two-year old app.
If there's anything that this news shows, it's that Node/NPM isn't a framework, but just whatever scraps of JavaScript one can dig out of the skip that's parked outside of NPM HQ.Else it would have an actual standard API for basic functionality like this.
"The JavaScript ecosystem is simply too large, and the dependency graphs too interdependent, for anyone to get an accurate picture of how much of the remaining dependence on request anyone should actually be concerned about."
This brought to mind the old saying - "if architects built buildings the way programmers build code, the first woodpecker to come along would destroy society" - or something like that.
While I could rag on Javascript specifically, there's no need as it's far from unique in this regard. We're cruising for a fall...
Thing is, Node.js API remains, it is stable and it is usable.
You don't need request, or anything else. You never did. I wrote much of my code for Node v0.12/v4.0 almost 5 years ago. Everything still works perfectly. I am productive and I deliver business value every day.
Your code should rely on what is truly stable and proven, even better - properly standardised. Everything else is just a distraction. Unless you just build throw-it-away proof-of-concepts.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
