undefined | Better HN

0 pointsYuukiRey5mo ago0 comments

No it's not out of date. It's very much the reality. Every new tool is just one more thing added on top. When I have to do something in a JS/TS repo at work it's always a surprise which epoch of JS hype stuff I find. Today I fix ESLint warnings, tomorrow it's Biome errors, then I need to figure out how to override dependencies in pnpm, but oh no there's a some bug in Bun now. Did I forget the 10249120491412e12 config options of Jest? Ah no wait, this one is Vitest.

For NextJS, do you remember the runtime used for middlewares? What was this swc thing again?

It never ends. Every year new things are added and they never really replace anything, it's just one more thing to learn and maintain.

If every technology causes exactly 1 issue per week then you quickly spend 50% of your time fixing bugs that have absolutely zero to do with what your company is actually doing.

---- EDIT

And it doesn't even stop at issues. Every one of those technologies regularly goes through breaking changes. In the process, plugins are deprecated, new ones have completely different APIs. You want to upgrade one thing for a security fix, then you're forced to upgrade 10 other things and it spirals out of control and you've spent entire work days just sifting through change logs to change `excludeFile` to `excludedFile` to `includeGlob` to `fileFilter` to `streamBouncer` to I don't know what.

0 comments

whstl5mo ago

If your complaint is that there are too many problems in too many different tools, then you sound like the perfect target for a UNIFIED tool that abstracts over others.

Because of Vite, there was a total of ZERO work from my side involved in changing from Rollup to Rolldown, or from babel to Esbuild to SWC.

The Rust/Go/uv model is the one to go. This is ONE step in this direction.

YuukiReyOP5mo ago

Lets assume Vite+ ends up working super well. Then projects using it could very well end up being a delight to work with. But that's a big IF. They'd have to resist the urge to integrate with the many other parts of JS and basically say no to a lot of requests.

But many projects won't adopt it. There are so many competitors all with their own little ecosystems. So in the end, I'll still have to fix all the issues I fix right now PLUS the issues that Vite+ will add on its own.

The only chance I see for something like this actually working is if something like Node/NPM decided to add a default formatter, linter, and so on.

avhception5mo ago

My complaint is that there is too much tool churn in the JS space specifically.

I haven't experienced nearly as much brittle build and dev tooling with other ecosystems, PHP or Python for example. Sure, they have their warts and problems and their fair amount of churn. But the sheer amount of JS tool and framework churn I experienced over the last few years was insane.

It might have cooled down somewhat by now, but I'm burned out. So reading about more churn to fix the churn just rubbed me the wrong way.

avhception5mo ago

I very much feel what you're saying. I could spew out quite a few of these sediment layers from our projects as well - lerna comes to mind, for example. We still have that lerna monorepo that somehow still needs to chug along. Just the thought of having to touch that CI pipeline gives me PTSD, something something EFILTER and I don't know what it was any more, yarn workspace, lerna.json: conventionalCommits yadda yadda.

And as I wrote in another reply: of course other technologies are not without issues and have their churn and warts and problems, but the sheer amount of JS hype and tool and framework churn I experienced over the last few years was insane.

It might have cooled down somewhat by now, but I'm burned out. So reading about more churn to fix the churn just rubbed me the wrong way.

Uehreka5mo ago

Greybeard (35) here.

When these cynical takes were crafted, Angular, AngularJS, Aurelia, Backbone, Ember, Knockout, React and Vue were all competing for mindshare, with new members joining/leaving that group every month (anyone remember OJ.js and Google FOAM?) being compiled by traceur, 6to5, the Google Closure Compiler and others from (Iced) CoffeeScript, TypeScript, ES6, Atscript, Livescript and Closurescript. We had two fucking major package registries (npm and bower) for literally no reason and we’d use both in every project. We had like 4 ways of doing modules.

Today the stack has stabilized around React and Vue, with a couple perennial challengers like Suede in the background. Vite and Webpack have been the two main build toolchains for years now. We discarded all of those languages except for TypeScript (and new ES features if you want them, but there are fewer changes every year). There are a couple package management tools, but they’re cross-compatible-ish and all pull from the same registry.

So does the fact that it’s not NEARLY as bad as it was in 2015 mean that people in 2025 aren’t allowed to complain? Yes. Yes it does.

YuukiReyOP5mo ago

Okay fair point, the various *Scripts predates my entry into the developer workforce somewhat.

But just in the repos at work I deal with: yarn, npm, pnpm, bun, NextJS, biome, Prettier, ESlint, Vite, Vitest, Jest, Turbopack and esbuild. At least those are the things I remember right now. They all have their idiosyncracies and issues. They all require learning slightly different configs. Nothing is compatible with anything else. I can't take one library and `npm link` it into another because their toolchains are completely different. Then you have the whole topic of exporting TS vs. JS, different module types, module resolution, custom module resolution rules to accomodate for how some outdated plugin somewhere works.

And this really is just the tip of the iceberg.

I wish these folks the best and I hope I'm wrong and in a few years all of this is replaced by `vite lint` and `vite build`. But my past experience tells me that I'll simple add one more word to this list.

Muromec5mo ago

My bet is the same -- this one looks like it will stay or at the very least will set the trend on consolidation under one or two vertically integrated toolchains. Vite itself is just better than all the previous things by a big margin and it promises that the whole zoo of auxilary tools will either perish or be nicely integrated into it.

rk065mo ago

nextjs and vite don't work together. same with non, pnpm & yarn. if your projects have different set of tools, thn your projects should have a readme file so people can manage working on them

collingreen5mo ago

Slightly older here although I don't see how that matters.

No, it doesn't mean people in 2025 can't complain. Hype based noise that gets in the way of people doing good work should be decried even if someone else somewhere (or somewhen) has it bad too.

This isn't a competition of badness.

Gates open. Come on in!

hombre_fatal5mo ago

Meh, you're just describing software. Especially complex client-side software build chains.

Opening up iOS or macOS app source code I haven't touched in years in the latest Xcode I just downloaded is a lot like that. There is anything from Swift errors to API changes to my build plist being invalid. And if I use any third-party tools, they probably don't work until I visit each one's latest readme.

And that's without even insisting on using the latest unstable tech (bun, biome, nextjs) like you did in your comment where you would expect that experience.

j / k navigate · click thread line to collapse

0 comments

whstl5mo ago

If your complaint is that there are too many problems in too many different tools, then you sound like the perfect target for a UNIFIED tool that abstracts over others.

Because of Vite, there was a total of ZERO work from my side involved in changing from Rollup to Rolldown, or from babel to Esbuild to SWC.

The Rust/Go/uv model is the one to go. This is ONE step in this direction.

YuukiReyOP5mo ago

The only chance I see for something like this actually working is if something like Node/NPM decided to add a default formatter, linter, and so on.

avhception5mo ago

My complaint is that there is too much tool churn in the JS space specifically.

It might have cooled down somewhat by now, but I'm burned out. So reading about more churn to fix the churn just rubbed me the wrong way.

avhception5mo ago

It might have cooled down somewhat by now, but I'm burned out. So reading about more churn to fix the churn just rubbed me the wrong way.

Uehreka5mo ago

Greybeard (35) here.

So does the fact that it’s not NEARLY as bad as it was in 2015 mean that people in 2025 aren’t allowed to complain? Yes. Yes it does.

YuukiReyOP5mo ago

Okay fair point, the various *Scripts predates my entry into the developer workforce somewhat.

And this really is just the tip of the iceberg.

Muromec5mo ago

rk065mo ago

nextjs and vite don't work together. same with non, pnpm & yarn. if your projects have different set of tools, thn your projects should have a readme file so people can manage working on them

collingreen5mo ago

Slightly older here although I don't see how that matters.

No, it doesn't mean people in 2025 can't complain. Hype based noise that gets in the way of people doing good work should be decried even if someone else somewhere (or somewhen) has it bad too.

This isn't a competition of badness.

Gates open. Come on in!

hombre_fatal5mo ago

Meh, you're just describing software. Especially complex client-side software build chains.

And that's without even insisting on using the latest unstable tech (bun, biome, nextjs) like you did in your comment where you would expect that experience.

j / k navigate · click thread line to collapse