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.

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 latter 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.

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

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/

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.

Vite+ can improve and simplify what developers are already doing with ad-hoc collections of tools. Vite is already an industry standard, and Vite+ has a good chance of achieving that status as well.

Essentially you pretend to be a library

Adding stuff for SSR was a major improvement.

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.

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

You probably need to see a video or gif to get it.

Need another plus? Vite++

Although about 98%* of that is because ESLint keeps making breaking changes and getting everything else to work compatibly with ESLint requires 27,573* additional dependencies.

Things I work on have been moving over to Biome recently (mostly these are Vue projects rather than React these days) for formatting and linting and it's so much simpler and avoids all the "What ESLint-related package broke our build process this week?" discussions entirely.

*Some numbers here may be made up. Or they might not.

Instead of a stupid, broken and leaky node equivalent backend totally interlocked with code of the frontend.

   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.

Looks like they have been acquired by Cloudflare, and pivoted to fully open source, but they haven’t really tweaked their messaging to make that fully land with unsuspecting visitors.

It’s kinda like the reverse situation of open source projects that switch to a source available license, but keep the aesthetics of an open source project. Kinda funny!

I have been doing "modern web" things since essentially day zero (you kids with your fancy JIT compiled javascript interpreters!)

SvelteKit, and by extension, Vite, has been the single most productive webstack I have ever used. If this offers anything on top of that, I welcome it with open arms.

Far from being a meme!

I think the boring stack would skip the need for most of these. That is 5 different tools to write TypeScript in order to get some HTML, CSS and JavaScript for things that are not covered by modern web standards. Not including the frameworks itself which mostly have the same goal.

"It is fully open source under the MIT license"

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.

Go gives you a bunch of goodies in the standard library.

Rust provides things like your build system, testing, and package management all together, which is what I assume OP meant.

How about the dependencies Bun is pulling? How did you ever managed to pass security policies with Bun which has so many segfaults that nobody even bothers to write CVEs for them.

I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".

Yes, if your goal is to get HTML/CSS/JS in any form to a web client then you don't need this stuff.

If your goal is to ship a web app that stands a chance of surviving multiple devs, production traffic, etc then you need more tools. Testing behavior (vitest), enforcing code standards (oxfmt and oxlint), optimizing network calls (e.g. tree shaking from Rollup), etc. all go beyond what you describe.

This stack is as boring as it gets without literally using the tools it consolidates and replaces.

Calling tests has overhead. Also knowing how to schedule and parallelize tests with dependencies is not as "simple".

Still need tsx to do type checking

However vitest is still great! Selling points now are stuff like:

- shares config with vite

- works with ESM out of the box (I think Jest still doesn't)

- integrated browser testing mode that is very nice

- overall just has a ton of nicely integrated features

I have my 3000 test project suite completing in 15 seconds on my MacBook Air M3. It is pretty sweet with that setup.

Surely lacking features also creates demand for more tooling.

We already do cooldowns and disable preinstall and postinstall scripts on all packages except for ones that actually require it.

I bet if you looked at 70% of your dependencies pulled in, you would be horrified. I would rather have that capabilities via code in my repos at this point.

manually activating venv, inconsistent python and dep versions, duplicate files taking up space, slow and broken tools, fragmented configs, global state, all of that is gone now. if you never experienced it you have no idea how bad it was.

not all of it was uv specifically (pyproject.toml was a proposal for some time before) but they cleaned it up. its the only reason i even think about python as an option for new projects.

This is especially hairy when making a typescript library that is distributed non-compiled (without dist/) and is supposed to run in both browser and Node.

https://github.com/nodejs/node/issues/46006

https://github.com/microsoft/TypeScript/issues/16577

`allowImportingTsExtensions: true` (https://www.typescriptlang.org/tsconfig/#allowImportingTsExt..., useful if you're running `tsc` in noEmit mode as a linter)

`rewriteRelativeImportExtensions: true` (https://www.typescriptlang.org/tsconfig/#rewriteRelativeImpo..., useful if you're using `tsc` to compile TS files to JS.

This allows you to use fully-specified imports in TypeScript files, which works basically everywhere — NodeJS, TypeScript, bundlers, etc.

The exceptions are browsers (obviously, only normal JS syntax there), and packages inside `node_modules`, which NodeJS will not do any type stripping for. So if you're writing a library, you'll probably still need to distribute the compiled sources, rather than distributing the raw TypeScript files alone. Or you use the JSDoc syntax for TypeScript, which can do everything that .ts files can do, but is more verbose and idiosyncratic.

This way I could just use node --watch instead of tsx or nodemon.

  // ---- dev-ts-resolve.js
  export async function resolve(specifier, context, nextResolve) {
    try {
      return await nextResolve(specifier, context);
    } catch (err) {
      const isRelative = specifier.startsWith('./')
        || specifier.startsWith('../')
        || specifier.startsWith('/')
        || specifier.startsWith('file:');
      if (err?.code === 'ERR_MODULE_NOT_FOUND' && isRelative && specifier.endsWith('.js')) {
        return nextResolve(`${specifier.slice(0, -3)}.ts`, context);
      }
  
      throw err;
    }
  }
  // ---- dev-loader.js
  import { register } from 'node:module';
  
  register('./dev-ts-resolve.js', import.meta.url);
  // ----

  node --import ./dev-loader.js --watch-path=./src