Reduce JS beyond tree-shaking. Quickboot.js is an experimental tool to reduce JS code size beyond tree-shaking. It uses runtime tracing, eval(), and sync XHR with non trivial trade-offs
This is an experimental tool developed by Naru. Please expect bugs / breaking changes. You can follow me on future updates.

The key idea is that around 40% of your JS code might not be needed when booting your app (YMMV). And if we can figure out which part is actually needed, we can remove "probably unused" parts out of the initial JavaScript file with fallback behavior, which uses eval() and synchronous XHR to continue the execution even the actual execution path hits the removed part of the JS file. Check out the following video (it was initially announced in this X (Twitter) post, where you can see some discussions) :

(better textual / visual explanation of things like "motivation" / "how it works" / "limitations" will come here in the future)

See the live demo

I created a simple demo using React and framer-motion. Without Quickboot.js, it's impossible to reduce the JS size smaller than react-dom.

You can compare the JS sizes loaded before the animation starts using your web browser's network inspector. Here Quickboot.js reduces the JS size needed to start the animation by more than 40%. This size is smaller than react-dom package alone.

Try Quickboot.js with your own app

So far Quickboot.js only offers CLI to try to optimize JS bundle size needed to "boot" statically deployed apps. Note that Quickboot.js is meant to be used for JS assets built by "production mode" of your bundlers such as Webpack. There are several assumptions for the optimization target:

To use Quickboot.js CLI, please follow the following instructions:

  1. Run npx quickbootjs trace /path/to/your/target.js and follow the instruction to save the runtime execution trace
  2. Then running npx quickbootjs optimize /path/to/your/target.js should produce the optimized JavaScript file
  3. Then you can test the behavior of your app (I would appreciate if you could share the result on Twitter/X if it works or it does not work)

Note that this tool is highly experimental and you should NOT use it in production since there can be bugs or non obvious tradeoffs.

For example, we know that the usage of eval() slows down the runtime execution but we are not sure how much this could impact the actual observable application performance. Also, considering this tool is to improve the "boot time" of the application for the first visitor, if you ever want to deploy this to production, probably you should implement some logic to use the original JS bundle for the revisitors with some preloading logic so that revisitors can just use the original JavaScript code, which is more performant and has predictable behavior.

However, depending on your use case, Quickboot.js could bring more benefit than its potential drawbacks. If you are interested in deploying this to production (maybe under feature flags?). I am really interested in the use case so do not hesitate to contact Naru.

Known issues and next steps

Replacing unused code with eval is not as trivial as it seems and there are several bugs already. My next step is to create test cases to reliably reproduce the issues and fix them along with other obvious issues such as error handling.