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 runtime > library. The compiler automatically includes the functions that you use in > the generated output, and discards the functions that you don't (for both > Elm and native JS code). > > And the output should be compatible with Closure Compiler to allow you to > make your output even smaller. In fact Elm has advantages in this regard > because any communication with the outside world has to be explicit (ie. > ports) and the rest of the code can be rewritten and shortened by Closure > Compiler. > > At that point elm-html could easily be added to the standard library, we > could let main's type by Html, and no one would be negatively impacted by > including the code they don't use. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
