Compiler: Elm generated files are quite large

[MixmasterFresh]

Using the latest version of elm, even the simplest of apps come out to greater than 7000 lines and 100kb of generated javascript. This seems to be because all imported libraries are included regardless of whether or not they are used, and upon digging into the generated code, it would seem that it would not be completely unreasonable to leave about half of that code unused even in larger projects. If elm employed some sort of pruning strategy to find and remove unused code at compile time, then thousands of lines could be removed from the generated javascript. There are a couple ways to go about this as far as I can see.

The first would be to have a sort of lazy including strategy, which would build a sort of dependency tree as function calls are detected. This method has the advantage of being quick and more aware of the elm compilation process(being a part of the basic compilation process), which could lend to it being more extensible.

The second strategy is to build the javascript as it is already done. Then make a few passes with another tool and remove dead code from the file in that fashion. This method might be slower, but it would not interfere with the current compilation process.

If there is already a good reason this isn't being done, feel free to close this issue, but if the javascript files were smaller, it would definitely make elm a more attractive language.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[robinheghan]

UglifyJs strips out dead code as it minifies (you can tell UglifyJS to log every statement that is removed). While Uglify is not as good at this as Closure, the way Elm compiles code to JS makes it as easy as possible.

Also, 100kb isn't that bad. I recently re-wrote a React app to Elm and went from ~800kb to ~300kb after minification.

[MixmasterFresh]

Don't get me wrong. 100 kb is not that bad, and I certainly would not see this as a super high priority. The possibility is that if it could be incredibly small at compile time, it would be incredibly practical to embed elm apps everywhere(even multiple in one page, potentially). If the compiler was responsible, it would likely be much more efficient than UglifyJs(given the nature of JS) at dead code removal and the option to run through Uglify is still available. If I am a business and you tell me that I can save 90% on CDN costs and cut page load time in half(just in terms of download time) by switching to elm, that could be an incredibly convincing argument.

So just to recap, I think this would be a "nice to have" feature that really should be a part of the compiler to be done right.

[robinheghan]

Agreed.

You shouldn't, however, expect an enormous difference between dead-code-removed Elm output, and the current output run through UglifyJS. Elm outputs Javascript that is extremely easy to dead-code-remove. Everything is defined as vars in a single scope, there are no objects-as-namespaces or anything like that. The sole exception is native code (not compiled with Elm compiler), but the Elm compiler wouldn't be able to remove dead code from native code anyway (I think).

[jvoigtlaender]

All this isn't really material for the issue tracker here. The issue tracker is predominantly for bugs. Even very specific feature requests are not much welcomed here, and even less so broad discussion. Just saying. I'm not deciding that, about closing issues etc.

To be more productive: Discussions like this are supposed to happen in a community forum. @TheAustinSeven, if you aren't away of options/possible venues, see here: http://elm-lang.org/community. Maybe better bring your concern up on the mailing list (and close the issue here). Even better yet if you first do some research in the mailing list archive (https://groups.google.com/forum/?fromgroups#!forum/elm-discuss) about what has already been discussed concerning dead code removal in the past. You are definitely not the first to bring this up.

[jvoigtlaender]

@TheAustinSeven, you may also want to check these two previous comments by Evan on related issues:

• https://github.com/elm-lang/elm-make/issues/85#issuecomment-205985392
• https://github.com/elm-lang/elm-make/issues/91#issuecomment-205984891

[MixmasterFresh]

Thank you for pointing me to those issues and discussions. I am going to close this and open it up, or join an existing discussion, in a more appropriate location.

[MarkDBlackwell]

Perhaps you did actually open (or find) a discussion on this topic in another location. If so, would you please consider supplying for readers here a (direct) link to it? :)