5 ms·

A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, packa

• userbinator 7mo ago
  The newer version is often even more bloated. This whole article just reinforces my opinion of "WTF is wrong with JS developers" in general: a lot of mostly mindless trendchasing and reinventing wheels by making them square. Meanwhile, I look back at what was possible 2 decades ago with very little JS and see just how far things have degraded.
  • michaelchisari 7mo ago
    A standard library can help, but js culture is not built in a way that lends to it the way a language like Go is. It would take a well-respected org pushing a standard library that has clear benefits over "package shopping."
  • halapro 7mo ago
    > WTF is wrong with JS developers Don't confuse "one idiot who wants to support Node 0.4 in 2026" with "JS developers". Everybody hates this guy and he puts his hands into the most popular packages, introducing his junk dependencies everywhere.
    • Maxion 7mo ago
      The other problem is that this is a bit of a circular path, with deps being so crap and numerous, upgrading existing old projects become a pain. There are A LOT of old projects out there that haven't been updated simply because the burden to do so is so high.
    • userbinator 7mo ago
      Then I wish there were more of these "idiots who want to support Node 0.4 in 2026". Maybe they're the ones with the common sense to value stability and backwards compatibility over constantly trendchasing the new and shiny and wanting to break what was previously working in the misguided name of "progress".
      • Griffinsauce 7mo ago
        You wouldn't if you look more deeply at this. He doesn't push for simplicity but for horrible complexity with an enormous stack of polyfills, ignoring language features that would greatly reduce all that bloat. .
        • userbinator 7mo ago
          That's also a problem. I've written JS that would work on any browser from the latest ones all the way back to IE5, and I'm not even a professional JS developer. It's not hard. Maybe "professional" is the problem: they're incentivised to make work for themselves so they deliberately add this fragility and complexity, and ignore the fact that there's no need to change.
      • deleted 7mo ago
        [deleted]
      • josephg 7mo ago
        NodeJS has a clear support schedule for releases. Once a version of nodejs is EOL, the node team stops backporting security fixes. And you should really stop using it. Here's the calendar: https://nodejs.org/en/about/previous-releases https://nodejs.org/en/about/previous-releases Here's a list of known security vulnerabilities affecting old versions of nodejs: https://nodejs.org/en/about/eol https://nodejs.org/en/about/eol In my opinion, npm packages should only support maintained versions of nodejs. If you want to run an ancient, unsupported version of nodejs with security vulnerabilities, you're on your own.
        • userbinator 7mo ago
    • saghm 7mo ago
      If everyone hates him and thinks his dependencies are junk, why would anyone let him introduce them to popular packages? Clearly there are at least some people who are indifferent enough if the dependencies are getting added elsewhere
      • halapro 7mo ago
        OSS is not a democracy. If he controls packages with millions of downloads, you either follow what he does or fork the packages, which is what the article is about. And even then the vast majority of people will continue to use his packages because they don't care or don't have time to investigate bloat.
        • saghm 7mo ago
          > OSS is not a democracy. If he controls packages with millions of downloads, you either follow what he does or fork the packages, which is what the article is about. My point is that in order for any other package not controlled by him, there needs to be someone choosing to depend on them (either by adding it themselves or merging a change that adds it). Whoever that is clearly doesn't seem to hate it as much as you claimed. > And even then the vast majority of people will continue to use his packages because they don't care or don't have time to investigate bloat. So in other words, you were grossly exaggerating when you said "everyone" hates the junk dependencies. By your own words, the vast majority of people don't seem to really care enough about it to do anything.
    • albedoa 7mo ago
      [flagged]
  • prinny_ 7mo ago
    I believe if you read this article https://www.artmann.co/articles/30-years-of-br-tags https://www.artmann.co/articles/30-years-of-br-tags your "wtf is wrong with js developers" question will be answered.
  • jazzypants 7mo ago
    Literally nothing has degraded. What in the world are you talking about? All of this stuff is optional.
    • userbinator 7mo ago
      Looking at the state of things, it sure doesn't seem that way. Literally nothing has degraded Trying to gaslight others into thinking everything is just fine is not working anymore.
      • jazzypants 7mo ago
        What has degraded? Name one single thing specifically. Every aspect of web development is easier and better than it was two, five, ten, or twenty years ago. Entropy is a fact, but whining about it without solutions doesn't help anyone.
        • userbinator 7mo ago
          As I write this comment, this happens to be at the top of the front page: https://news.ycombinator.com/item?id=47480507 https://news.ycombinator.com/item?id=47480507
          • jazzypants 7mo ago
            Yes, that's a single website that is fixed with an ad blocker. You have proven absolutely nothing. You are very bad at crafting arguments.
• anematode 7mo ago
  The desire to keep things compatible with even ES6, let alone ES5 and before, is utterly bizarre to me. Then you see folks who unironically want to maintain compatibility with node 0.4, in 2025, and realize it could be way worse.... Ironically, what often happens is that developers configure Babel to transpile their code to some ancient version, the output is bloated (and slower to execute, since passes like regenerator have a lot of overhead), and then the website doesn't even work on the putatively supported ancient browsers because of the use of recent CSS properties or JS features that can't be polyfilled. I've even had a case at work where a polyfill caused the program to break. iirc it was a shitty polyfill of the exponentiation operator ** that didn't handle BigInt inputs.
  • fragmede 7mo ago
    Just how old an Android device in the developing world do you not want to support? Life's great at the forefront of technology, but there's a balancing act to be able to support older technology vs the bleeding edge.
    • anematode 7mo ago
      I like the sentiment, but building a website that can actually function in that setting isn't a matter of mere polyfills. You need to cut out the insane bloat like React, Lottie, etc., and just write a simple website, at which point you don't really need polyfills anyway. In other words, if you're pulling in e.g. regenerator-runtime, you're already cutting out a substantial part of the users you're describing.
    • Dylan16807 7mo ago
      A quick search tells me that firefox 143 from 6 months ago supported android 5 (Lollipop). So that's my cutoff.
    • dfabulich 7mo ago
      Android phones update to the latest version of Chrome for 7 years. As long as you're using browser features that are Baseline: Widely Available, you'll be using features that were working on the latest browsers in 2023; those features will work on Android 7.0 Nougat phones, released in 2016. Android Studio has a nifty little tool that tells you what percentage of users are on what versions of Android. 99.2% of users are on Android 7 or later. I predict that next year, a similar percentage of users will be on Android 8 or later.
• hrmtst93837 7mo ago
  [flagged]
• hrmtst93837 7mo ago
  [flagged]
  • ivanjermakov 7mo ago
    Not just web, gamedev is suffering this too, since ~2020.
• tgv 7mo ago
  > Ancient browser support is a thing And weird browser support. People use the oddest devices to do "on demand" jobs (receiving a tiny amount of money for a small amount of work). Although there aren't that many, I've seen user agents from game consoles, TVs, old Androids, iPod touch, and from Facebook and other "browser makers", with names such as Agency, Herring, Unique, ABB, HIbrowser, Vinebre, Config, etc. Some of the latter look to be Chrome or Safari skins, but there's no way to tell; I don't know what they are. And I must assume that quite a few devices cannot be upgraded. So I support old and weird browsers. The code contains one externally written module (stored in the repository), so it's only a matter of the correct transpiler settings.
• Tade0 7mo ago
  Sometimes it's a result of unforeseen consequences of design decisions. All pre-signal Angular code must be compiled down to JS which replaces native async with Promise. Why is that so? For a long time Angular's change detection worked by overriding native functions like setTimeout, addEventListener etc. to track these calls and react accordingly. `async` is a keyword, so it's not possible to override it like that. Signals don't require such trickery and also allow to significantly decrease the surface area of change detection, but to take advantage of all of that one has to essentially rewrite the entire application.
• streptomycin 7mo ago
  In practice there's this one guy who likes to support ancient JS engines, and this one other guy who likes making lots of tiny packages which depend on his other tiny packages. They both see what they're doing as features, not bugs. And they are both very prominent devs with a lot of popular packages. So unlikely to change unless everyone stops using their popular packages. Every now and again people get worked up and try to bully them about it, which is unfortunate because they seem like generally good people, and their arguments in favor of their positions are pretty well documented.
• shimman 7mo ago
  Any resource/blogs you'd recommend on writing "modern" JS beyond the usual es5 reccomendations?