Yep! Preliminary work for dead code elimination has been done for awhile <https://groups.google.com/forum/#!msg/elm-dev/ney653TeOmU/VIurd016AQAJ>, but finishing it has never been justifiable as the next priority.
I honestly doubt it'll be worth prioritizing in the next few months either...the thing is, it's the sort of thing most people want less than things like server-side rendering or better debugging capabilities. It'll be the most important thing someday, but probably not soon. :) On Monday, August 8, 2016 at 8:59:22 PM UTC-7, Austin Horning wrote: > > 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. > > 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. > > Has anyone considered implementing something like this? > -- 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.
