Hacker News Reader

Comment by whstl | Hacker News Reader

This cynicism is several years out of date.

The current dominant toolchain has been very stable for years now, and is much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc.

The only problem is that NOW there are too many separate different tools that aren't bundlers, so in addition to Vite one also has to configure Prettier, Eslint, Vitest, Typescript, Husky, Lint-Staged, Playwright, DotEnv, what else?

A unified toolchain might not replace each and every tool above, but it will simplify a lot of this process.

It will also simplify migrating between tools that it doesn't intend to replace, like migrating between Typescript and Typescript-Go. Etc.

This is already the reality in Go, Rust and other languages.

View on HN

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.

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.

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.

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.

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.

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.

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.

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.

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

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!

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.

I'm not even a JS dev, I support the CI pipelines and Docker images and whatnot. It's something else every week. When I get it to work eventually, it's brittle as hell. I just want the madness to stop. I don't even care any more.

Anecdotal, but I switched our webpack configs with vote a few years ago and haven't had to touch it since.

Didn't have to touch the webpack stuff either. Perhaps the issues you're having are due to something else?

If you support the CI pipelines, you can put some conventions that you expect to run npm ci, npm build and then npm unit-tests-run and you don't care what they use as long as it returns without errors and puts the deployable artifact in ./dist/public/ or whereever you expect it. If you are bold enough you can ask to write makefiles too -- let them have it.

Why should it even be your problem.

Take a look at Rails 7+. They shifted to just using import maps and abandoned the build step entirely. Simplifies everything.

They also abandoned performance!

Are there any negative performance stories that came from the move? I can't imagine any negatives outside of "1st load"?

At this point, I don't want unified tools. I want stable ones. I'm fine with using a separate linter/formatter/transpiler/bundler/..., but why can't they just stay stable for a bit.

The only two tools I like in the JS world is `yarn` and `prettier`. They're focused and do what they do well. But you add eslint and any of the others and their configuration is a full fledged turing machine. Even autotools feels nice in comparison to that mayhem.

What's not stable about Vite, ESLint, Typescript, Prettier? Apart from Vite itself, those have been standards for 8-10 years, and Vite itself has successfully replaced a huge mess of other tools.

I agree that ESLint can become a mess, which is why I'm ok with a new competitor that doesn't require the extra configuration. Sure: they're also replacing Prettier (unnecessary) but everyone can keep using Prettier and change if Oxfmt ever becomes better.

All the other tools here are either existing, or drop-in replacements.

Eslint did a massive breaking change with it's config format not too long ago, and still doesn't seem like it knows what it wants to be when it grows up (I was happily using eslint for things prettier does...)

Fine, updating 8 to 9 sucked for you, and I believe you. I did mention that ESLint is the "problematic" one, that people are working hard to replace. If so what's the problem? What about the other tools?

"Ok you directly addressed one of my hand picked examples, clearly showing your point and why my example wasn't a good one. Now address all my other ones before I consider your perspective might be valid!"

This is like the comment version of the gish gallop.

No, that's an answer to a cherry-picked reply. It was one package that had a version migration. I don't necessarily agree but I'm trying to move the discussion forward rather than staying at the "it's all shit" lane.

And I gave three other examples, and I can give others: React itself has been around for 12 years, leading. Vue has been super stable too.

Migrating versions of frameworks is several magnitudes harder than migrating the ESLint config, and ESLint is optional. Migrating versions of previous tooling like Babel or Webpack is several orders of magnitude more complicated than ESLint.

I'm not even against you in general but "react for 12 years" is another really bad example with the complete paradigm change from classes to hooks. I even think hooks are better, but I'm not going to sit and tell people their fatigue isn't valid when even your argument is "some of these aren't as bad as babel or webpack".

The paradigm change you mention happened once, it was piggybacked on an existing and very popular concept (functional components), and the previous paradigm was "deprecated" by the community itself.

Sure it would be better if people had gotten it right the first time, but the fatigue problem isn't really due to React.

And my argument isn't that "X is better than Y". It's that the number of new tools showing up is WAY smaller than it was when those complaints started. Today it has become a meme here in HN, often by people outside the frontend community.

In my opinion, because there’s no core principles behind anything. jQuery was nice because it presented a nice API on to of the DOM. There was just this single layer that both your code and the libraries rely on.

But now there’s no unifying principles behind anything. No conventions. It’s just incantations to get thing working nicely together. It’s all preprocessing and post processing, code generation an what not.

For us non stable things were sass and Tailwind. Lost a lot of dev work just to upgrade those with no visible benefit at all.

Everything else is smooth and silk

Ohh, yes eslint 8 => 9 migration were also a big pain to handle.

> eslint 8 => 9 migration were also a big pain to handle.

Still not resolved. Their main recommended config is still not updated for 9.

ESLint and stable do not belong in the same sentence.

> What's not stable about [] ESLint

Like, their decision to change configuration format in a way that breaks all and every plugin, tutorial, project in existence as a giant "fuck you" to the whole ecosystem and all web developers of the world - isn't that a reason good enough to never come back at this tool ever again?

>What's not stable about Vite, ESLint, Typescript, Prettier?

It wasn't there X years ago and had changes to the config Y years ago that were very annoying time-consuming. One can believe that single digits of X and Y are "not stable enough" with a simple reason that you live in Decenarian Math.

If I stop working on a project for 3 years, will I still be able to compile it, without losing an unpredictablt amount of time to fixing the toolchain? If not, then its not really stable, is it?

> If I stop working on a project for 3 years, will I still be able to compile it

You will certainly be able to compile it. You might have hard time updating it though.

As someone who “owns” a framework at work that has been unfunded for several years, the answer is definitively yes. I haven’t touched the build toolchain in all those years and the project continues to build a dozen different JavaScript libraries with no issues across multiple Node.js upgrades.

The current version of webpack was released 5 years ago. You can keep using eslint 8 which was released 4 years ago. This really isn’t the constantly changing space it was in the 2010’s

With version pinning and lockfiles, sure.

Updating is a different matter, if you're using multiple tools, hundreds of packages and several configuration files.

Which is why a unified tool that doesn't require configuring 20 tools at once is a good idea IMO.

> Even autotools feels nice in comparison to that mayhem.

For all its warts and all the hate that it gets, at least autotools is stable and not introducing breaking changes.

> much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc.

What? That mess is still ongoing. Next.js for example (probably the most popular "out of the box" solution) technically uses SWC, but not quite, because it doesn't support `styled-components` so you need to use Babel for that. But wait, you might also need to use tailwind, and for that you'll need `postcss` which might also work with Babel with `babel-plugin-import-postcss` but not necessarily, could also just use it as a Next plugin, but that doesn't always[1] seem to work.

I don't think this mess will ever end unless we throw React/Vue, and all "reactive" frameworks in the dustbin and we'll get enough folks on board to re-invent the web starting from scratch. But no one really wants to do that (yet?), so even things like Bun or Deno will try to be as compatible as possible making continuous concessions that will lead to the ongoing spaghettification of toolchains.

[1] https://github.com/vercel/next.js/discussions/65625

React/Vue/Svelte/... are pretty nice ideas and the required tooling to make them work on top of CoreJS is not that extensive of an effort. The main issue is the complexity introduced by building everything and anything on top of each other as you described.

In the C world, most tools are orthogonal. The compilers don't need to know about the design of the package managers and the task runners don't care about either. Yes, we have glue tooling, but that is also and external project and the dependencies are interfaces instead of monkey-patching each other.

Fine, then, I'll amend: that mess is still ongoing outside people who choose to not use this toolchain for one reason or another.

So you're saying that we finally have a semi-stable toolchain (I disagree) and the correct path forward is to change it all again? Lol I think the cynicism is very much justified.

To be fair, the idea of the tools being standardized behind a single command like golang is nice, but this is largely what it all comes down to.

"Vite+ will be source-available and offers a generous free tier."

I'm also a developer ( sometimes ) and we need to eat. However, for me these tools are too low of a level of he stack to monetize, so I'll probably stick with my collection of free tools.

Evan You wrote on Twitter that source code will be accessible to everyone, but not under a full permissible license. He also wrote that they have no plans to sell any code licenses.

> they have no plans to sell any code licenses

Every for-profit is subject to being sold to someone with different plans. If the license is not fully open, it's not smart to expect the licensing terms to get worse.

Selling access isn't really helpful there. The target group (companies) have to care about licenses at some point, while it will be free for OSS, individuals and the community.

Every non-profit is subject to be neglected and overtaken by state sponsored psyops campaign from the GMT+3 timezone.

For the web development world, the answer seems a strong yes.

I remember gulp/grunt saga, I remember webpack 5 saga and the most recent pain with eslint 8 → 9 is a final nail in the coffin of anything stable for web building.

It doesn't seem like this project is intended to replace the existing tools, but rather combine them into a more convenient bundle.

On the other hand, with Node on the server we're now jumping into the ESM and nodenext/esnext mess with its .js imports.

This less a problem when your project is on the web though, because vite (and I think under the hood esbuild) transforms the imports gracefully.

>and is much better than the mess of Webpack/Rollup/Brunch/Grunt...

You do know that Vite uses a lot of these behind the scenes right? Vite in general has much better defaults so that you don't have to configure them most of the time, but anything a bit out of the box will still require messing with the configs extensively.

Not like OPs Vite+ changes anything regarding that.

Vite+ is built on top of the Rust stack (Rolldown / Oxc) developed by the same team and uses none of these.

Not "a lot of those".

It used Rollup.

And it does so transparently, while the alternative, Rolldown, was being finished.

To me this sounds like a more than acceptable compromise in the interim.

Not even Rollup. Vite+ uses Rolldown which is also developed from the ground up by VoidZero.

> very stable for years now

Especially eslint with their decision to change configuration format in a way that breaks all and every plugin, tutorial, project in existence as a giant "fuck you" to the whole ecosystem and all web developers of the world.

Still on v8 and won't upgrade. I would rather switch to Biome. It's annoying investing more time into tooling than actual work.

> This cynicism is several years out of date.

Jesus, it's bad enough I can't leave a js project for 6 months without it starting to rot. Now my cynicism has to be updated too?

Reply on news.ycombinator.com