Web development is about to emerge to a new golden era π
Gone will be the days of countless dependencies, long build times, and endless configuration files. The major shift will come from Void(0) and Vite tooling. But it's not the only character in the play π΄οΈ
Hello world! We are on a mission to build a next-generation toolchain for JavaScript that is unified, high-performance, composable, and runtime-agnostic. We are excited to announce our $4.6m seed funding led by @Accel - read more in the blog post: voidzero.dev/posts/announciβ¦
This is how I envision my apps (in 2025 already?) π
Do you remember the pain of Webpack?
It wasn't long ago that I was working on a codebase using a custom Webpack configuration (it was 2021 indeed).
First week of onboarding on a new project, npm run dev
, and 30 seconds later the app was ready on localhost. That's right, 30 seconds of waiting for the first dev build. Then, the app would do a full refresh with each change (no HMR), each around 4 to 5 seconds.
If you used Webpack back in the days you know how it works:
- Long and unreadable
webpack.config.js
file, handling all sorts of html, css, and whatever - Infinite number of dependencies for all sort of plugins and loaders
- No one willing to touch or update the configuration least the app breaks or slows down
Vite: the light at the end of the tunnel
It wasn't long before I took on me the responsibility of migrating to Vite. And it made a staggering difference:
- No more than 1 second first load
- 500 milliseconds average HMR reload
Developer productivity skyrocketed to new levels!
Note: the original 30 seconds may have been a misconfiguration in webpack. Regardless, Vite solved every problem, with a single and simple configuration file, and fewer dependencies.
This week the newly announced Void(0) project promises an even brighter and unified future for javascript tooling.
Check out Even's talk at ViteConf for a preview of how the future will look like with the upcoming tooling around Vite πͺ
Linting is great (but not always)
I used to be a strong advocate of linting as much as possible, in every project.
I would scroll long lists of ESLint plugins, pick 10 of them, add them to a project, and have fun cringing at the unbelievable amount of new linting errors.
The codebase would become unbreakable, no mistake was allowed anymore, no one in the team could fail. Well, yes, but over time no one could succeed either π€¦
The linting configuration and its strictness became so bad that the codebase was littered with eslint-disable
comments.
I still appreciate linting, but right now some of my projects don't even have linting configured at all. It slows down too much π
Prettier anyone?
Another key component is having consistent formatting. Prettier became the standard here. Another tool on top of countless others.
Using ESLint at the same time? Well, you need a specific configuration to handle them both together. Then you enable format on save, and some files are Prettier-formatted and other ESLint-formatted π€¦
If you are not used to javascript tooling, this is the standard even today π
Void(0): for a unified tooling experience
The promise of Void(0) is enchanting for anyone working on typescript. A set of unified and fast tools, all based on Vite, with a shared configuration:
- Build tool (Vite)
- Bundler (Rolldown)
- Test runner (Vitest)
- Linter, formatter, resolver, parser and more (Oxc)
Imagine a single vite.config.ts
with sensible defaults and plugins shared by the whole ecosystem, all based on the same underlying tooling.
That's sound cool indeed π«‘
Back to plain CSS: tailwindcss v4
Another worth mention is Tailwind CSS v4.
For years "CSS wasn't enough", so they invented tools like less and sass to make it more powerful. Then CSS-only wasn't enough, and they invented CSS-in-JS.
Full circle to today, and the promise behind tailwindcss v4. Everything comes back to "plain" CSS:
- No more
tailwind.config.js
- All styled defined inside CSS as css variables (
@theme
) - All working on top of Vite π―
Ah, there is also Effect
Quick mention of Effect as well π
Whereas Effect has nothing to do with tooling, it has everything to do to make your project easier to maintain and configure. It allows to remove many other dependencies that become unnecessary when you use Effect.
One huge positive result of using @EffectTS_ in your app is the reduction in number of packages installed π₯ Effect is a full standard library for typescript, with data structures and util functions included Less dependencies to maintain π
I see way too much negativity around javascript, javascript tooling, and "vendor lock-in" ππΌββοΈ
Take a better look, the future is bright for the developer that uses the right tooling when necessary, or no tooling at all when it's not
See you next π