So I wanted to compare various implementations of the RealWorld example app front-end implementations. Below are totals for the Javascript/WASM asset sizes.
Svelte: 41KB
Elm: 90KB
Angular: 552KB
Vue: 582KB
React/Redux: 1MB
Seed-rs: 1.27MB
This is a very rough comparison that I did quickly, so may be errors, but a few things stand out:
complied languages (Elm, Svelte) produce relatively compact output
Seed-rs compiles to WASM, and is quite large. Not sure why this is – perhaps optimizations like dead code elimination are still in their infancy.
I asked on the Elm Slack if anyone knew why the Rust/wasm version was so large – one response:
luke:
wasm binaries have to ship with basic stuff like an allocator and whatever is used in the rust standard library since none of that is provided by the platform. even things like json decoding add up - it takes a surprisingly large amount of code just to parse a float correctly
I was really excited when I first saw these results, but the RealWorld App is not that big. The Vue implementation is only about 2000 lines. So what about larger projects? We had a community member working on a 49,315 line application try the new version and he got 114kb after compilation, minification, and gzip. That is in the ballpark of the 100kb produced by the 2000 lines in the Vue implementation! So it looks like your projects need to get exceptionally large before you start running into the baseline issues you see in JavaScript.
The current Simple IoT frontend codebase is ~4K SLOC. It is not too likely that many applications SIOT is tragetting will reach 10x this size, but even then a 100K line project is still only 200kB – still not a huge deal for these types of applications where load time is not all that critical. And even then you could cache assets to make things load faster.
An article comparing a HyperScript implementation to Elm:
The result:
Code and bundle sizes
The Elm implementation, which tries to mimic the original HyperScript implementation (there is probably a more “functional” way to implement the Wordle game itself), is around 260 lines of code. Around five times the original HyperScript version.
I would argue that the Elm version is more readable and simpler to be expanded with additional features but here we enter into a biased territory caused by my knowledge of Elm.
The HyperScript version, in addition to what is in the source of the page, requires an HyperScript runtime library that is 86KB minified and 24KB zipped.
The Elm language compiles to JavaScript and it doesn’t need any separated runtime library as it is already included in the compiled JavaScript. The output of this Wordle implementation written in Elm is 33KB minified and 14KB zipped.
So this means that concerning the sizes of stuff to load, Elm is around half the size of HyperScript.
These simple metrics are interesting, but do not tell the entire story – for most projects less tangible factors such as developer productivity, app stability, and maintainability are also important to consider.
