About bundle size, I’ve not been able to develop a proper static analysis tool, yet. It is still above my skills. But I made a silly experiment.
I used elm-scripting to compile a simple “hello world” program to a script that can be executed in the terminal.
module Hello exposing (main)
import Html exposing (text)
main = text "hello world"
On this generated code, I tested multiple minifiers: uglify, rolldown, rollup and google closure compiler. All are supposed to perform some sort of dead code elimination or tree shaking. But the result on are quite deceptive. I could elaborate more on the results if it arouses any interest.
So I wrote a python program that removes statements and check if the script is still working. Under the hood, it uses tree-sitter javascript parser to manipulate the code.
It targets the elm app code (hardcoded path), then it iterates over all statements.
For each statement, it remove it from the code, then run the code using QuickJS to see if it fails or succeed. If it fails, it restores the statement, else it keep the removal, then moves to the next.
There are 509 statements in the sample app. It would not be possible to test all the combinations (2^509), so statements are iterated in the order.
I get much better result when going bottom to top than top to bottom since statements tend to depends on other statements located above them not bellow them.
Here are the results:
| LoC | size (B) | time (ms) | |
|---|---|---|---|
| before | 4188 | 85262 | 20 |
| after | 138 | 2843 | 4.6 |
| factor | 30x | 30x | 4.37x ± 0.53 |
Of course, this is a contrived example. Real Elm applications use a much larger portion of the runtime. However, I feel Elm could push its strengths further in terms of bundle size and speed.