Uglify essentially removes functions that are not added to objects (how you export functions from "namespaces"). Since Elm adds all functions to a single local-scope, and then only exports ports and the main function, it's very easy for uglify to see what functions are unused, and can therefore remove them. Google Closure can do the same thing but, as you said, breaks on advanced compilation. Fortunately, advanced optimization doesn't give you that much in Elm due to the way it compiles to JS. The difference between uglify and google closure (w/advanced opts) was perhaps 3-4kb last I checked. Advanced opts breaks because of four lines in Elm's runtime that checks for a specific key in certain cases (string tagging). More information here: https://github.com/elm-lang/core/pull/734
onsdag 25. januar 2017 16.56.12 UTC+1 skrev OvermindDL1 følgende: > > I use browserify for some code via brunch, rollup for others, I run both > of those through uglify + closure when building a 'prod' release. > browserify and rollup and both blazing fast in compile time with very > large bases of code, but rollup prunes based on functions called (meaning > it can break on dynamic name access, but that is rare) and browserify just > prunes based on module importing (which can break on dynamic module name > access, but that is also rare). uglify is just a minimizer but it does few > optimizations but runs fast, however Google's closure runs *very* slow, but > optimizes well, however higher optimization levels will ruin any code that > does any kind of dynamic key access that is not dict-like (it breaks elm > pretty hard last I tried it, but it works on my bucklescript code 'so far'). > > > On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote: >> >> >> >> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote: >>> >>> Sent too soon. >>> >>> Also, uglify is a minimizer, it does a *lot* more than tree shaking. >>> >>> >>> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote: >>>> >>>> Tree Shaking as implemented by Brunch and Webpack default setups at >>>> least only prune based on if a module is accessed or not (which is also >>>> why >>>> it is easy to fool if you use a non-static string for the name). I've not >>>> seen any tree shaking yet that does otherwise. Although the fascinating >>>> rollup.js does a lot better by pruning functions very effectively, I need >>>> to try that one with Elm. :-) >>>> >>>> >>>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund >>>> Hansen wrote: >>>>> >>>>> >>>>> Actually tree shaking will do absolutely nothing for Elm code as Elm >>>>>> compiles everything into a single module that all highly indirectly >>>>>> references itself. It would help with bucklescript as it outputs >>>>>> modules, >>>>>> but bucklescript already tree-shakes as part of its compiler >>>>>> optimizations >>>>>> anyway. >>>>>> >>>>> >>>>> This is false. You are correct that Elm compiles everything into a >>>>> single module, but this means that tree-shaking becomes *easier*, not >>>>> harder. It also makes name-mangling much easier, as everything is >>>>> local-scope. With Elm code, tree-shaking can be done with Uglify.js. Just >>>>> tell uglify to warn you when it removes a function, and you'll see it >>>>> removes *a lot* of code. >>>>> >>>> >> I see there is the old Google Web Compiler, Browserify, Uglify, Rollup >> and I don'e know how many others. Has anyone compared them all and has any >> recommendations on which to use? If some such as Uglify and Rullup do so >> much more than just Tree Shaking, what are the disadvantages in their use, >> speed of "compilation"? >> > -- 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.
