First of all, I agree with all your main points. The size and scope of the
runtime should not be dictated by the number of bytes it takes up. Also,
the compiler does have more flexibility if it was all in JS.
However. As long as the target language is JS, I don't think DCE should be
a priority, as we already have minifiers that provide this service for us.
This also means that there is no reason to include a 'prod' or 'dev' mode
to the compiler (at least not for this) as a 'prod' mode is simply adding a
minifier step to your build configuration.
The elm compiler already outputs JS in a way that makes it very simple to
remove dead code, and to minify well. The only 'problem' with the current
way of things, is that the elm-runtime is written by hand, and thus not
written in such a way that makes it easy to minify well and remove dead
code. Re-writing more of the elm-runtime in elm should mitigate this
further. In fact, I believe Elm already beats other languages like
ClojureScript quite well in size, even though CLJS uses google closure for
minification. The main advantage cljs has over Elm, is that cljs' runtime
is written in cljs.
I also don't believe that elm-html should be a part of the standard
library. While it might makes sense today, it makes less sense in the
distant feature when someone has come up with a new, revolutionary and
soon-to-become de-facto HTML library. It also wouldn't make sense if Elm
ever becomes a backend or scripting language. It should be noted however,
that my interpretation of what a standard library is, is a library that
provides functions you would likely use in any app, and which are unlikely
to do better any other way. The current standard library is, IMHO, fine the
way it is when it comes to scope, while there are certain functions I would
love to add to certain modules (like List.find). You're interpretation may
be different. In any case, there is no reason to discuss the size and scope
of the standard library here, I just thought I would voice my opinion that
just because we have DCE, that doesn't mean should be uncritical with what
we put in the standard library.
I would also like to point out that while optimizing for Google Closure is
a good thing (tm), it should not come at the cost of hampering other
minifiers like UglifyJS. UglifyJS already removes all dead code (except
dead code in native code) quite well in my applications, and I would love
for that to still be a thing in the future without swapping out Uglify with
a Java application.
So yeah, my 2 cents essentially boils down to:
1) Move more runtime code from native to pure elm.
2) Explore a way to make native code as easy to minify/DCE as compiled Elm
code.
3) Should the Elm compiler ever support another target in the future, spend
resources on DCE.
torsdag 16. oktober 2014 16.12.46 UTC+2 skrev Laszlo Pandy følgende:
>
> Currently elm-runtime.js works like any JavaScript library: you include it
> with your page and your generated Elm code use the exposed functions. In
> fact you could even use it from hand-written JS code. But a language
> runtime is not the same thing as a JS library.
>
> Recently many people have brought up two issues:
> - should elm-html be in the standard library?
> - why is elm-runtime.js so big?
>
> And here are two stories which indicate which direction Elm should be
> heading in:
> 1. Since Haxe started, they were always concerned about compiled JS size.
> They believed that JS devs wouldn't switch to Haxe if a hello world was 10K
> of JS. So they kept the standard modules small. There was a class String
> with a few functions, and StringTools[1] with many more. StringTools would
> not be included if you didn't import it.
>
> Later on, Haxe implemented function-level dead code elimination. After
> that it didn't matter how big String was. All the parts you didn't use
> would be deleted from your output. Now StringTools is just API baggage that
> shouldn't exist.
>
> [1] http://api.haxe.org/StringTools.html
>
> 2. Just like Elm's runtime is written in JS, Go's runtime is written in C.
> But how there is a big project rewrite much of it in Go[2] to take
> advantage of the compiler's stack layouts. But even if we are talking about
> Elm and JS, there would be many advantages to having most of the runtime
> written in Elm:
> - inlining, and other optimizations
> - function-level dead code elimination
> - less code maintenance (ie. if Elm changes its data structures)
>
> [2]
> http://dave.cheney.net/2014/09/01/gos-runtime-c-to-go-rewrite-by-the-numbers
>
> What we see is:
> - dead code elimination decouples the runtime size from the API design.
> This is a good thing
> - the runtime should be a collection of functions, not a self-contained
> library to enable dead code elimination
> - the compiler has more flexibility if more functions are in Elm instead
> of JS
>
> The direction Elm should be heading in is to have no separate
