> But I have zero clue what those other tools are.

The incorporated tools are actually really amazing:

- vitest, an ultra fast test runner. After using a lot of others, including jest and node's built in one, I love vitest.

- oxlint, replaces eslint but is compatible with its file format and ultra fast, since it isn't written JavaScript. I tried biome, but I found oxlint to have more rules and the eslint compatibility was nice.

- oxfmt, replaces prettier and is faster since it isn't written in JavaScript.

- rolldown, replaces rollup and is compatible with it but it is much faster since it isn't written in JavaScript.

The above are my go-tos in new projects anyhow since they are killer good and fast.

I'm currently experimenting with a stack combining assistance, ASP.NET Razor Pages, and htmx, specifically to avoid dealing with the complexities of the modern frontend stack.

AI eliminates a lot of the tedium, grinding tasks, while HTML partials and htmx complement each other perfectly.

Not having to manage frontend framework, SSR states is incredibly liberating. Sprinkle in some vanillla js and redraw specific parts of the page as needed... done

the other tools are for testing, bundling, linting and formatting. Previously you would use different tools from very different open source projects for these things, with different configurations, update cycles etc. Now it's all covered by one simple toolchain. Vite+ is basically the "boring but works" stack, while also being more performant and with less configuration required.

That's what I liked from Bun's proposition. A single binary that just works. Hopefully the others take notice.

> Vite, Vitest, Rolldown, tsdown, Oxlint, and Oxfmt

You already use the first, the second you should be using and has existed for years - it's a jest-compatible runner integrated to Vite.

Rolldown is a part of Vite already (since version 8, alongside other implementing tools like lightnincss).

The ox* suite are native replacements for eslint and prettier. The longer has existed for years. Both of them aim to be drop-in compatible soon.

This is a boring stack.

FWIR, prior to the purchase by Vercel (or was it Cloud flare?), Vite+ was going to be a convenient, no fuss, low movement way set up projects that they sold to businesses for funding.

This is the latest emerging "boring but works" stack.

I guess I'm just an old man pumping my fist and yelling at the clouds at this point, but I think compartmentalizing every possible aspect of development and then making each one of those as complex as possible lead AI in the bureaucratic deterioration of the trade.

> I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade.

I believe VoidZero has been acquired by Cloudflare [1], so money should not be an issue. Question is if Cloudflare will be willing to continue letting these people work on Vite and Vite+ features that benefit all cloud platforms, not just Cloudflare.

1. https://blog.cloudflare.com/voidzero-joins-cloudflare/

Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR.

If you only focus on the front-end and remove Typescript from the equation it becomes easy enough. We'll have to see if Vite+ helps for the more complex cases.

> Sure beats opening some ancient project and seeing some mix of Vite, Vitest, Oxlint and Oxfmt and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).

> Version 3 => 4 => 5 => 6 => 7 => 8.

I did the migrations and they were not horrible. A few breaking changes but they were relatively isolated. And the speed and improvements over these versions had been quite significant.

Echoing another person, but we did all those major version migrations without any breakage / churn. What were the breaks you ran into?

I've followed all the main migrations and I've say they where really quite smooth, can't remember having any major issues and each time it tended to be worth it.

The churn is the product.

I went from 4 to 8 in a single step. I had to change 5 lines of config.

Can we please stop the incessant belly-aching over problems that don't exist. I have to question if you even use these tools?

Trust me you don't want to work with Laravel Livewire and Alpine.js, that would still require keeping up and for a less than satisfying result.

I feel ya, we're slowly phasing out our Laravel monolith for python lambdas. I miss those beautiful Laravel 6 days!

you actually don't have to keep up, whatever you were using still works

It uses Vite so the same limitations as Vite. However, I have been using Vite for my NestJS servers without any problem with `vite-plugin-node`. See example at https://github.com/leosuncin/nest-vite-example/blob/master/v...

Here is my particular incantation for targeting node that is working very well: https://pastebin.com/ynz4B5X0

Essentially you pretend to be a library

I am using Vite+ for CLIs as well, yes. You don't use Vite as dev server then but lint, format, task running and caching is still there!

I'm always curious of the use case when someone proposes Node code bundling. What's the advantage? Obfuscation in SEA?

Surprised to see this is the only uv reference in the comments!

Feels like an obvious comparison to me, and a very welcome development for the JS ecosystem.

uv made me actually _enjoy_ working in Python again.

Says:

"It is fully open source under the MIT license"

My first thought too. "$name+" is strongly coded now as "subscription service for $name"

I think that used to be the idea but then they got acqui-hired

Naming is worrisome!

Then he'd love this. Like Unix, Vite+ is a collection of programs that do one thing well.

I am actually pushing our frontend devs to remove more and more dependencies and leverage LLMs to just write the code instead of all the dumbass packages in hellscape of supply chain attacks via node/npm.

How do you bundle web workers that import dependencies? iirc the issue in esbuild for that is still open and users are manually building their workers as separate entry points, which is very fragile.

I'm not very familiar with Rust, but doesn't cargo pull a lot of external dependencies for most projects? I really like how Go can do everything with just the standard library, but I wasn't aware Rust was similar. For typescript we've moved our stuff to bun. It has it's own risk management perspective compared to node, but at least it's now possible to build web services without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them.

Some barbarian without a grasp of the Dutch language knee-jerked the down-vote button so I'll add a Swedish version which adds an important attribute.

   Imse vimse spindel klättra upp för trå'n.
   Ner faller regnet, spolar spindeln bort.
   Upp stiger solen, torkar bort allt regn.
   Imse vimse spindel klättrar upp igen.

Here's how to interpret this saga of the ever-climbing little spider in the context of web development. It climbs up its tread (klättra upp för trå'n) 'cause that new framework will sure make catching those flies (clicks/jobs/likes/whatevers) easier. And then the rain starts (the CVEs start piling up, the corrupted packages come flooding in) and the hapless spider gets thrown off its web (Pwned!) until the sun comes back and dries away the rain (a new framework, yay, this will solve all problems) upon which the spider climbs up its thread again.

I think web development does not need that many layers. Usually there is a clear purpose for each layer. I think most problems in web are self-created.

vp + sv seems to work very well, when I tried it. And oxfmt supports svelte now too!