CSS chunking is an absolute nightmare. In js, bundler has a pretty explicit understanding of execution order. CSS is basically all side effects. Also if you lazy load things with css chunks or navigate to another page, append and remove order matters
Getting JS chunking right is already incredibly hard. Getting CSS chunking right is even harder—another classic case of the correctness vs. performance trade-off:
https://t.co/zB1WTx6WnX
BTW, Tobias Koppers’ talks are some of the best resources out there for learning about bundling:
https://t.co/XOd3be1oYq
@BleedingDev Trace decay but I wanna try doing similar for rstack. Would be nice if whole stack feedback was available in lsp. Also webmcp into the devserver
You can write language server plugins for Claude code. Totally hijacked the protocol and integrated active memory, test, lints, and surrounding concurrent edits into a LSP plugin. Code graph context engine served as a language server to ides and agent harnesses
Once i release RR8 support, I’ll ask them to list the plugin on their docs/send a pr, pretty sure we planned to put it on the doc site. I have all their repo test cases in that pr. I believe I even unskipped several failing test cases they have in theirs because Rspack has ways to make them pass. Then it’ll support RSC and everything framework mode supports.
Yuku really is an excellent alternative to Babel—it seems to be the only native parser that also provides a JavaScript transform API. About a month ago, I replaced both esbuild and Babel with it in rsbuild-react-router https://t.co/rt3JHPYQBa and saw a huge performance improvement.
I also built yuku-loader https://t.co/eSK2N6z9I7 as an optional alternative to babel-loader and swc-loader, and even experimented with porting Yuku to Rust. The only tricky part is designing an ergonomic Rust transform API for it—especially one that supports in-place mutation cleanly.
@JimmayVV@HashemKhalifa What’s wrong with the docs. I mean I can get it mentioned on RR site and “blessed” so long as it works and they don’t have to maintain it.
lol my colleagues ask me as well.
React router team hates bundlers. Only want to build framework. So they put it in vite, because it had to be on something. They don’t wanna maintain the build side. On the flip side tho, it’s pretty easy to tell codex to go port all the test cases from RR repo and catalogue all build capabilities and replicate it. Adding RR8 support, RSC support etc was done in like a day. Perf took longer because Rspack has faster conventions to do the same thing vs all in js transforms. But porting the vite transform implementation to rsbuild APIs was trivial.
You can parallelize babel tranforms on other workers. But if you need tranforms to share some state (like in route loader) you end up with contention in the main thread. There’s also startup cost of worker. Pulling in babel is huge js to parse on top of worker. Especially when you’re trying to keep up with rust which could likely complete all the work in the time it takes a worker to boot. Js tranforms very painful
Swc great as long as you don’t need custom transforms. When you need custom transforms, you have to write rust wasm. Which is painful to ship and maintain within another plugin. Yuku a great escape hatch where doing simple transforms won’t completely wreck performance like dragging babel in
Granted I blew billions of tokens a day to develop TraceDecay so that I could have agents reach into multiple codebases at once without blowing context windows.