4 ms·
Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels lik
by jakeasmith 19d ago
Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.
- HackerThemAll 17d agoThe JavaScript world is littered with stuff comparing to which your patch seems like a complex project. See those examples: https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/is-whitespace-character https://www.npmjs.com/package/is-whitespace-character https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray
- JaggerJo 17d agowhat a broken ecosystem.. The crazy thing is not that the package exists, but that it is used by JS devs.
- yurishimo 17d agoThere’s a bit more nuance as to why. It’s not fair to say that the average JS dev is reaching for a package like is-odd/is-even. Years ago when npm was just getting started there was a lot of experimentation and land grabbing for packages. A few “prolific” developers were pushing these tiny utilities and then using them in their own projects which ended up being required as deps in other projects and then snowballed into is-odd being included in webpack at some point (I think I have that timeline roughly correct). It’s still a crappy problem for sure but it’s not fair to paint most JS devs with a brush so broad.
- junon 17d agoI feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isodd`/`iseven` are of course silly, things like `isarray` were not functions that existed back then (we didn't have Array.isArray). `typeof [] === 'object'` in JS, so e.g. my package `is-arrayish` checked for a similar structure to an array (whereas Id guess `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5. So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.
- b112 17d ago[flagged]
- zarzavat 17d agoYes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
- ChiperSoft 17d agoAdditional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
- wat10000 17d agoI don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be. It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
- junon 17d ago
- austin-cheney 17d agoEverything that touches JavaScript in the corporate world feels broken. Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways. That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
- dahart 17d agoThere’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high. I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved. It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
- shevy-java 17d agoPHP devs are happy that npm exists. That way there is always a worse ecosystem down below.
- domh 17d agoThese packages are basically memes at this point... Those download figures cannot be accurate for real production usage. I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.
- sumtechguy 17d agoI would not bet on that assumption. I have seen some wild code over the years from devs. With 'ai' type coding going on now too you may see them be used even more.
- domh 17d agoI would've actually thought AI would slightly improve upon this situation. At least in my experience claude seems to write a lot more little utility functions itself rather than reaching for a package from npm to do something. Requiring an `npm install` before getting something working risks triggering a permissions gate.
- brookst 17d agoOpus and fable both are pretty judicious about bringing in dependencies, at least for me. They often argue against and and write even decently large modules to avoid pulling stuff in.
- sire-vc 17d agoThey never install packages for me and love handrolling large amounts of e.g. parsing code where a library exists. I have to keep telling them 'look for a large popular dependency' when they start writing huge functions that obviously already exist. Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
- whywhywhywhy 17d agoMajor libraries used them so yeah the numbers are real, left-pad was in every react and babel install.
- vachina 17d agoWhenever I see a npmjs project I nope out of it. I’d rather spend $50 on tokens to reimplement whatever JS slop in Python or Go.
- JohnMakin 17d agois-even implementation: > 'use strict'; > var isOdd = require('is-odd'); > module.exports = function isEven(i) { > return !isOdd(i); > };
- d3Xt3r 17d agoI thought you were joking, but then I checked the code... holy shit, it is real. Surely the author's gotta be trolling, right?
- layer8 17d agoI’d say the deciding factor is that it has bugs where both fixing and not fixing them can have a negative impact. If there were no known bugs and there was no harm in using it, I’d probably just leave it there and not disturb anything, given that its use is so widespread, and instead merely note in the documentation that its purpose has become obsolete.
- dolmen 17d agoFrom the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load and risk of breaking an old codebase that so many users depend on. Deprecating the project is playing the open source game in an other dimension: tell the word that depending on this project was a bad idea in the first place and that everyone should move on. But releasing a fix on a deprecated project is fine too. So both actions are on different dimensions, this isn't a choice between 2 options.
- jjice 17d agoThe man released a fix twelve years ago for free. If someone is really depending on this, they can fork it themselves. I'd argue that that's the beauty of open source, rather than a downside.
- mech422 17d agoThe down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.
- lukeify 17d agoOthers would say pragmatic.
- iso1631 17d agoI think it shows a complete misunderstanding on what free software is.
- dspillett 17d agoFree software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.
- jmathai 17d agoI have written A LOT of PHP in my life. Not so much anymore but I only have fond memories of the community - thanks to folks like you. Kudos.