Vite and related projects

Towards the very end of 2023 I dipped my foot in the water of the Vite ecosystem by trialling out Vitest, and it was honestly a significantly better experience than Jest. I’ve been getting more into an ESM-only future for a while now, and Jest was one of the largest hurdles that I had encountered. Seeing both how well it was able to parse very legacy code, and just how fast it was compared to basically everything else made me want to try out the rest of the Vite ecosystem.

So far, I’ve been loving Vite, and am generally trying to use it in place of Webpack. There are still a few blockers preventing me using it absolutely everywhere, such as a few plugins that aren’t available yet or the inability to specify custom TSConfig files without hacky workarounds. I’ve also noticed that Babel plugins especially are rarely available natively for Vite, however it has a Babel plugin as a fallback that in my experience doesn’t degrade build speeds much at all, so it’s not a hard blocker for using Vite. I’m hoping that throughout 2025 this project continues to mature, the plugin ecosystem expands, and ideally the Babel fallback can be used less.

Knip

Knip is a project that I really love at this point. I’d used prior tools like ts-prune to trim down on unused code, but Knip takes it a step further. Finding unused code, dependencies, and more. It’s been especially helpful to tame large monorepo setups and enforce strict dependency listings in each workspace. Something I’d love to see from this project in 2025 is further integration with even more tooling and libraries, especially for some of the more modern JS projects.

React Compiler

The React Compiler is something I’ve long awaited, and having a chance to finally try it out this year has been interesting. While I’ve set it up on this website, a mostly static website is not really where it shines best. My attempts to set this up on more complex projects so far have ran into stability issues, some that are caught by React strict mode, but others that appear to be bugs in the compiler. While it seems very promising, it definitely doesn’t feel like it’s 100% ready just yet. I’m hoping to continue watching this project throughout 2025, hoping for eventual stability and a full release. The ESLint rule for the React Compiler is a helpful midway point at least, making it easier to prevent regressions in codebases that can’t yet have it running full time. It’d also be great to have an official Vite plugin, to reduce the dependency on Babel.

Gatsby

Gatsby is a project that I used to love. I’d contributed numerous times, received a few pieces of merch, and used it for a few projects including a prior rendition of this website. As mentioned above, I recently rewrote this website with Vike. Whilst the project does appear to actually be dead at this point, even if it wasn’t it would need some significant improvements to be something I’d continue using. I feel bad about this due to how fond of the project I was, but I do feel my criticism of it is justified and I wish it was in a better state.

If you add Gatsby to a project, it will significantly pollute your dependencies. This isn’t just a matter of a larger lockfile and slower package install times (my yarn lockfile is 7% of the size it used to be when Gatsby was installed, and yarn installs take only 5% of the time they did before!), this includes archaic integrations with tooling such as ESLint that can actively break your linting setup if you don’t include a menagerie of package resolutions to force newer versions. Gatsby does not integrate well with monorepos or other projects, it wants you to do everything the Gatsby way. And the Gatsby way is stuck deeply in the past. If the project does end up surviving, I can’t see it being a contender for new projects unless they deeply rework many of those fundamental integrations.

Webpack

Tying into my usage of Vite, I’m hoping to leave behind Webpack in the new year. Webpack is starting to feel like Gulp/Grunt did before becoming mostly superseded. I’m not someone who likes just jumping to the “new cool framework”, I generally need a compelling reason for it. Just like with Gulp/Grunt, Webpack works, so at this stage I don’t feel it’s necessary to migrate away from it for existing projects unless there’s something that the project could benefit from in Vite or similar, but I will definitely not be starting anything new with it.

Over time it’s become fairly evident to me that ESM is very much the future, and Webpack to this day still does not flawlessly support it as an output format. It can output it, but it’s an experimental feature and fairly prone to issues with more complex setups. With browser features like modulepreload, which can have a surprisingly large impact on launch performance in some web app architectures, Webpack’s failure to fully support ESM as a stable feature can start to actually impact the end user.

I’ve also spent significant time learning about Webpack’s internals to assist in optimising bundle outputs and speeding up builds, and not all of this knowledge is necessarily transferrable. Part of leaving Webpack behind to me, is gaining the same level of familiarity with other tools. While I’m fine using Vite, I’d definitely not be able to debug bundling issues as effectively as I could with Webpack at this stage.