Compiling Elm's ToDoMVC produces elm.js that is 207kb passing that through the Closure Compiler produces elm.min.js that is 66kb. gzip-ing that produces elm.min.js.gz that is 20kb.
DCE could shave some more but the bulk of what is possible to remove is already done in Elm by making the output of the compiler minify-friendly. DCE would take that even further and it would be awesome to have but its absence is in no way a show stopper. :) The real potential could come from generating CSS on the fly in Elm. :) Having that kind of code minified could produce some serious savings. Or it might not. I haven't seen this properly explored. On Tue, Aug 9, 2016 at 6:59 AM, Austin Horning <[email protected]> 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. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
