Hello, Elm community.
We at ContaSystemer AS reached 20k lines of Elm code. A total is 42k LoC including generated Elm code. Here are some stats for us.
- We have 74 Elm modules with a total of 20.7k LoC
- The biggest Elm module has 2.5k LoC
- The next biggest file has 2k LoC (This file manages the shared state between pages and some common functionality for Elm pages)
- We have 6 generated Elm modules with a total of 21k LoC
- The biggest generated Elm module has 7.2k LoC (All the application routes)
- The next biggest generated Elm module has 5.7k LoC (All the translations)
- We have 22 direct dependencies and 4 indirect ones
- We are reusing existing functionality made in JS with custom elements which speed up development process quite a lot
- We have a custom Elm linter based on elm-syntax
- It takes 18s to generate and compile all Elm files with Webpack (4s is spent to run headless Chrome to generate all the app routes)
- It takes 2.2s to compile all Elm code
- It takes 9s to compile and minify all Elm code
- It takes 4.9s to compile all Elm code with elm-stuff removed
- It takes 11.5s to compile and minify all Elm code with elm-stuff removed
- Not optimized Elm code size is 1043554 bytes (1.04 Mb)
- Optimized Elm code size is 974322 bytes (0.97 Mb)
- Minified not optimized Elm code size is 250504 bytes (250 Kb)
- Minified optimized Elm code size is 198846 bytes (199 Kb)
- Gzipped minified not optimized Elm code size is 75267 bytes (75 Kb)
- Gzipped minified optimized Elm code size is 64549 bytes (64.5 Kb)
Stats for JS files.
- We have 966 JS files with a total of 95k LoC
- The biggest JS file is 864 LoC
- Bundled JS file size is 3459816 bytes (3.46 Mb)
- Bundled minified JS file size is 1361165 bytes (1.36 Mb)
- Bundled minified gzipped JS file size is 308909 bytes (309 Kb)
0.18 - 0.19 upgrade path
It was very smooth for us because we prepared in advance. We followed the advice of the core team and didn’t use native code. Well, we had a native code but we abandoned it at an early stage. We used special functions instead of
toString so we don’t have to change it at the upgrade stage. We wrote “future” functions to work with dates to have a smooth upgrade (Thank for @justinmimbs date package). The only obstacle in our way was time to wait until all the dependencies are updated. The conclusion is if the future plan is known and the advice of the core team is followed then upgrade is straight forward.
Thank you @evancz, the core team and the community. It’s a pleasure to work with Elm and to be a part of the community.
We use a slightly modified version of an outer message a.k.a. shared state, a.k.a Elm taco technique to manage common/shared functionality between pages. It’s really great. Please comment below or add a like if you would like us to share more about it.