Methodology for the asset sizes reported with Elm 0.19

asset-size-methodology.md

Notes on Comparing Asset Sizes

In the blog post Small Assets without the Headache, I compare the Elm RealWorld App asset sizes to some of the other popular implementations.

Richard figured out how to get asset sizes in a reasonable way. We use the implementations created by the communities themselves, allowing us to compare "the common case" rather than hand-tuning one and not others. The rest of this page is his lightly edited documentation of how he got the asset sizes and which aspects were a bit awkward.

NOTE: The blog post talks about asset sizes in kilobytes. A kilobyte is 1024 bytes. This document gives sizes in bytes. This is why there are "slightly different numbers" in the graph in the blog post.

Methodology

Elm

1. git clone https://github.com/rtfeldman/elm-spa-example/ elm
2. cd elm
3. git checkout 0.19
4. elm make src/Main.elm --output=elm.js --optimize
5. uglifyjs elm.js --compress 'pure_funcs="F2,F3,F4,F5,F6,F7,F8,F9,A2,A3,A4,A5,A6,A7,A8,A9",pure_getters,keep_fargs=false,unsafe_comps,unsafe' | uglifyjs --mangle --output=elm.min.js

This is the standard way to crush projects as described here. The result of cat elm.min.js | gzip | wc -c outputs 29862 bytes on my machine.

React-Redux

1. git clone https://github.com/gothinkster/react-redux-realworld-example-app react-redux
2. cd react-redux
3. npm install
4. npm run build
5. cd build/static/js/
6. rm *.map

You will now be in a directory with an uglified main JS file. After all these steps, running cat main.b9912889.js.gz | gzip | wc -c gave me 78616 bytes.

This uglification process is the one performed by create-react-app, which is built by the React team, so it seems safe to assume Uglify was properly configured for React here.

Vue

1. git clone [email protected]:gothinkster/vue-realworld-example-app.git vue
2. cd vue
3. npm install
4. npm run build
5. cd dist/static/js/
6. rm *.map

Now you're in the directory with all the JS assets.

They are doing code splitting, but we are trying to measure the total size. So to disable code splitting, edit build/webpack.prod.conf.js and add this to the beginning of plugins:

  plugins: [
    new webpack.optimize.LimitChunkCountPlugin({
      maxChunks: 1
    }),

Then re-run the above steps starting with npm run build.

This will produce three JS files (main, manifest, and vendor) and on my build, they produced byte counts of 15837, 86836, and 853 respectively. I know main and vendor should be counted, but I don't know what manifest does. The total is either 103526 or 102673 depending on whether you count it, and I went with the lower one to be safe.

Angular

1. git clone [email protected]:gothinkster/angular-realworld-example-app.git angular
2. cd angular
3. npm install
4. npm run build
5. cd dist/
6. rm CNAME *.txt *.css *.ico *.html

Now you're in the directory with all the JS assets. It looks like there may be code splitting happening on this project, but we were uncertain how to disable it. (Neither of us is familiar with the build process.) We ran a little bash script to get the sizes of everything:

for file in $(ls)
do
  echo "$file $(cat $file | gzip | wc -c)"
done

1.7a0d0a2ab21b7f817c02.js          9653
2.ccbe11438360ed43ce1d.js          2653
3.3a3954a411b35700c35a.js          2201
4.b6a4731d6feb46048203.js          2373
common.a94722c78e5ae221e1c5.js     787
main.f3d8bb64fb27f07f3590.js       95061
polyfills.74c949fb901fde2a61b1.js  31405
runtime.9c71f4baf75d5a9a2e77.js    1070

We just counted main.js at 95061 though we had trouble getting it working without the polyfills file. Seems like we should count the best case scenario nonetheless.