upvote

points

by anematode18 hours ago |
comments
upvoteby Slothrop9914 hours ago|
next
[-]
Maybe I didn't look hard enough, but there's no obvious switch to "just turn off all the legacy stuff, thnx".

Also, there has been a huge amount of churn on the tooling side, and if you have a legacy app, you probably don't wanna touch whatever build program was cool that year. I've got a react app which is almost 10 years old, there has to be tons of stuff which is even older.

reply
upvoteby vkou13 hours ago|
parent|
[-]
> Maybe I didn't look hard enough, but there's no obvious switch to "just turn off all the legacy stuff, thnx".

There is. Break compatibility for it, and whatever poor bastard that is still maintaining software that is targeting a PalmPilot is free to either pin to an older version of your library, or fork it. Yes, that's a lot of pain for him, but it makes life a little easier for everyone else.

reply
upvoteby josephg10 hours ago|
parent|
next
[-]
This is my philosophy too. If the nodejs project doesn't support node 18, why on earth should I?

Here's the schedule, if anyone hasn't seen it. Node 18 is EOL. Node 20 goes EOL in a bit over a month.

https://nodejs.org/en/about/previous-releases

reply
upvoteby Pxtl16 hours ago|
prev|
next
[-]
It's just an excuse to not change things.
reply
upvoteby fragmede18 hours ago|
prev|
next
[-]
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.
reply
upvoteby anematode18 hours ago|
parent|
next
[-]
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.

reply
upvoteby Dylan1680717 hours ago|
parent|
prev|
next
[-]
A quick search tells me that firefox 143 from 6 months ago supported android 5 (Lollipop).

So that's my cutoff.

reply
upvoteby dfabulich17 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby kennywinker16 hours ago|
parent|
[-]
3.9 billion android users, means that 0.8% is 31 million people - and for a very small number of developers most of their users will be from that slice. For most of them… yeah go ahead an assume your audience is running a reasonably up to date os
reply
upvoteby oflebbe14 hours ago|
parent|
[-]
Websites built with tons of polyfills are likely not run on these devices anyway, since they will run out of RAM before, let alone after they will only load after sone minutes because of CPU limitations on top of not being loaded because their x509 certs are outdated as well as the bandwith they support is not suitable to load MB sited pages
reply
upvoteby hsbauauvhabzb18 hours ago|
prev|
[-]
I’ve been very lost trying to understand the ecosystem between es versions , typescript and everything else. It ends up being a weird battle between seemingly unrelated things like require() vs import vs async when all I want to do is compile. All while I’m utterly confused by all the build tools, npm vs whatever other ones are out there, vite vs whatever other ones are out there, ‘oh babel? I’ve heard the name but no idea what it does’ ends up being my position on like 10 build packages.

This isn’t the desire of people to build legacy support, it’s a broken, confusing and haphazard build system built on the corpses of other broken, confusing and haphazard build systems.

reply
upvoteby anematode16 hours ago|
parent|
next
[-]
Honestly, Vite is all you need. :) It's super flexible compared to the status quo of require vs. import etc. For example, I recently wanted to ship a WASM binary along with the JS rather than making it a separate download (to avoid having to deal with the failure case of the JS code loading and the WASM not fetching). All I had to do was import `a.wasm?url` and it did the base64 embedding and loading automatically.
reply
upvoteby Maxion15 hours ago|
parent|
[-]
This sentiment is all well and good, but when you end up in a new-to-you JS codebase with a list of deps longer than a Costco receipt using some ancient Webpack with it's config split into 5 or so files, then no-one is letting you upgrade to vite unless the site is completely down.
reply
upvoteby tankenmate10 hours ago|
parent|
next
[-]
It's almost like Churchill's quip "He has all the virtues I dislike and none of the vices I admire". In other words, in some ways the JS ecosystem rushes to all the tech debt inducing "shiny shiny" and avoids all the tech debt reducing "hard work of refactoring and wisdom". It's almost like a large chunks of the JS ecosystem thrives on "the dopamine hit". Santayana's wisdom whispers behind every import.
reply
upvoteby anematode15 hours ago|
parent|
prev|
[-]
Sad but true...
reply
upvoteby CoderLuii16 hours ago|
parent|
prev|
next
[-]
this is exactly where i landed too. i build docker images that bundle node tooling and every time i think i understand the build system something changes. require vs import, cjs vs esm, babel vs swc vs esbuild, then half your dependencies use one format and half use the other. the worst part is when you containerize it because now you need it all to work in a clean linux environment with no cached state and suddenly half the assumptions break.
reply
upvoteby conartist617 hours ago|
parent|
prev|
[-]
Yes, yes to all of that, but there is still hope.
reply
upvoteby hsbauauvhabzb16 hours ago|
parent|
[-]
This fancy new build tool with emojis will fix it!
reply
upvoteby kennywinker16 hours ago|
parent|
[-]
This fancy new vibe coded build tool with emojis
reply
upvoteby hsbauauvhabzb13 hours ago|
parent|
[-]
Built in rust
reply
upvoteby conartist69 hours ago|
parent|
[-]
Mmmmhm. But not all the people building devtools got distracted by a pretty butterfly.
reply