Husband / Father of two / Founder
voidzero.dev / Creator
@vuejs.org &
@vite.dev[Not loaded yet]
-
View full thread
For context, this is what is currently needed for that
github.com/TanStack/con...https://github.com/TanStack/config/blob/main/packages%2Fvite-config%2Fsrc%2Findex.js
After couple of days looking at *.cpuprofile's, I think it's getting closer to stable v1 release. The ~3MB checker.ts from Typescript repo is perfect benchmarking reference for tools that process source code. When generating coverage for 'vuejs/core' repo, speed is close to original v8-to-istanbul.
Finalizing rewrite of AST-aware v8-to-istanbul. This will provide accuracy of Istanbul coverage for V8 coverage reports. I've intentionally kept this tool unopinionated so that it's not strictly tied to just
@vitest.dev - it should be usable with Jest, C8, Playwright and node:test too.
Very cool!
Super excited about this - Vite is all about DX. Who'd be the better person to work on Vite Devtools other than
@antfu.me ?
[Not loaded yet]
Vite plus itself is just a toolchain that you install and run, like today’s Vite. There might be related cloud services in the future but the toolchain itself will not have hard coupling with cloud.
In order to better integrate with tsgo, we are going to rewrite Rolldown and Oxc in Go.
[Not loaded yet]
It’s happening
[Not loaded yet]
Yes, on multiple runs they are now very close to each other
[Not loaded yet]
Note this is from my local branch, not released yet and obviously not in the benchmark repo yet
Rolldown-vite ecosystem CI progress!
- Total: 24 (excluding ones currently not passing with Vite main branch)
- ✅ passing: 14
- ⚠️ passing with minor issues: 5
- ❌ failing: 5
Progress: 79% (19/24)
npm download stats are back and
@vite.dev just crossed 20M/week!
Ongoing work for
@rolldown.rs :
- Rolldown-Vite ecosystem CI (~60% passing)
- Full bundle mode HMR
- Incremental build
- Module Federation (built-in support)
- oxc minifier improvements (built-in, already with better compression ratio than esbuild and 6-9x faster than swc)
[Not loaded yet]
Rolldown | Rust bundler for JavaScript
Fast Rust-based bundler for JavaScript with Rollup-compatible API
Also, already implemented:
- webpack-style advanced chunk splitting
Mixed Vapor / VDOM component tree achieved with working props and slots
@rolldown.rs wasm story is just brilliant
[Not loaded yet]
I probably did, didn’t check the selected mic at all 😅
COMING SOON: Experimental
@vite.dev Environment API support in React Router v7.
Check this out — a single `vite build` command can co-ordinate a full client + multi-server build. Previously this was only possible via the `react-router` CLI.
We're “just a Vite plugin” again 😎
Beautiful
[Not loaded yet]
I always try to give React team benefit of the doubt that they just genuinely believe the framework-dependent patterns they are pushing for the at the best interest of all React users, but after a few years the elephant in the room just grows bigger: what if they were… actually wrong?
Happy new year! Spent a week snowboarding in Hokkaido and heading back home today. My body is slammed but my mind is pumped for what’s coming in 2025. Let’s go!
release: v1.0.0-beta.1 (#3232) · rolldown/rolldown@713b181
Fast Rust bundler for JavaScript/TypeScript with Rollup-compatible API. - release: v1.0.0-beta.1 (#3232) · rolldown/rolldown@713b181
[Not loaded yet]
Keep blowing my mind!
Will be giving these out at future conferences and events I attend in person
[Not loaded yet]
I had a few from VueFes Japan but yeah I should make more of those
[Not loaded yet]
Will be there!
[Not loaded yet]
Thank you for all the great contributions! You got multiple nominations from team members 🙌
Rolldown's wasm build just got significantly faster in browsers thanks to
@broooooklyn.bsky.social!
One challenge of native bundlers is that they have to ship and run as wasm in browser environments. Some bundlers like rspack doesn't even support this due to the complexity it involves.
-
View full thread
As a result, Rolldown is now the fastest possible bundler you can run in the browser. Here are the numbers when bundling a benchmark app with 2.5k modules:
- esbuild: 22.19s
- Vite (via Rollup): 4.52s
- Rolldown: ⚡️613.43 ms
Try it out yourself on StackBlitz:
stackblitz.com/~/github.com... The reason why I am very excited about this is because this means every framework building on top of Vite will have blazing fast DX in browser environments - on StackBlitz, via
bolt.new, etc.!
For example, I was surprised to find out that esbuild's wasm build is actually significantly slower than Rollup in web containers. This may have to do with Go wasm compilation and de-optimized parallelization.
Rolldown suffered from this too, and we've been wanting to tackle this because we want it to run fast in every use case.
Yesterday at the team offsite in Shanghai, our friend
@Brooooook_lyn finally solved this by implementing proper worker thread pooling / reuse in napi-rs.
Moreover - the biggest perf advantage of native bundlers comes from parallelization, but in browsers we'd have to simulate threads using web workers. Without proper optimization, native bundlers can end up being slower than JS bundlers in browsers!
I've always said Vite's dev server is like a normal HTTP server on steroids.
index.html + a plain js file over native ESM, but with auto reload. No config needed even if you want to later move to TS or import CSS with HMR.
[Not loaded yet]
A vite plugin can add any connect/express compatible middleware to the dev server:
vite.dev/guide/api-pl...
Plugin API
Next Generation Frontend Tooling
[Not loaded yet]
I vote for both because I'm in both versions (jk)
In all seriousness - I like the right version better.
I've always said you can start using Vite as a plain http server but on steroids :)
A single index.html is a valid Vite app
[Not loaded yet]
-
View full thread
TL;DR:
- Rolldown's built-in minify is still WIP and both the perf and compression quality will get a lot better in the future
- Rolldown's minifier implementation is intentionally different from esbuild's, in which we sacrifice a bit of perf for better potential cross-module optimizations
- Parcel's perf number is from a cached build
- It's better to clarify how the numbers are measured and provide a script to do it
I left some thoughts here:
dev.to/yyx990803/co...
There are some notable issues that need to be p... — DEV Community
Introduction Over the past 15 years, the JavaScript ecosystem has expanded rapidly,...
State of JS 2024 is out and... what a year for the projects I work on!
-
@vite.dev and VoidZero ecosystem projects sweep almost all the awards (again)
-
@vuejs.org had a strong comeback year!
More details in thead👇
-
View full thread
Really proud and thankful to all the users and support from the community.
The best part is, we haven't even shipped the things that will make Vite even better yet.
There will be some exciting news coming at the end of 2024, and more progress to be made in 2025 - stay tuned!
And here is the link to the survey results if you want to check it out:
2024.stateofjs.com
State of JavaScript 2024
The 2024 edition of the annual survey about the latest trends in the JavaScript ecosystem.
In addition: Vite is the most loved library overall (56% of all surveyed devs have positive opinion of it regardless of whether they used it or not)
Vue.js, in its 10th year, shows resilience and had a strong comeback year!
In addition to holding on to #2 spot in both usage and awareness, it went back up noticeably in rankings across interest, retention and positivity
And also got the #3 most loved library overall!
Vite ecosystem does it again!
- Adoption growth: Vite (#1), Vitest (#2)
- Highest retention: Vitest (#1), Vite (#2), #3 Astro is also Vite-based
- Highest interest: Rolldown (#1), Vitest (#2), Vite (#3)
- Most Write-Ins: #1 Analog is Vite-based
Just managed to make the base component instance type shared between vdom and vapor runtimes. Now Vue Vapor mode can reuse all rendering agnostic APIs from runtime-core!
This is an important step towards mixed vapor/vdom component graph.
[Not loaded yet]
-
View full thread
For Svelte and Solid I just created boilerplates with npm init vite@latest - each rendering a component with two props in a 100k length for loop.
Solid using its For component, Svelte with standard each block
[Not loaded yet]
All comparing prod builds.
To put it in context, this is slightly slower than Solid (~65ms) and faster than Svelte 5 (~90ms), and more than 3x faster than current Vue 3.5 (~230ms)
