Hmm, compare uglify with google closure is really misleading .. ( I am not a fan of google or even remotely close, but as a compiler engineer , we should respect basic facts) On Thu, Jan 26, 2017 at 7:37 AM Robin Heggelund Hansen <[email protected]> wrote:
> I was mostly talking about size. I know Closure very well, and I'm well > aware of what code must look like in order to get the most out of advanced > opts. The way Elm is compiled makes it easy for uglify to get the same > results in mangling and dead-code elimination, but of course it won't do > inlining. Still, there is a very small difference between uglify and google > closure with advanced_opts. If Elm had been compiled into modules, then > uglify would have done much worse. > > > torsdag 26. januar 2017 02.37.59 UTC+1 skrev Bob Zhang følgende: > > Not really, closure has very very advanced optimizations that uglify does > not even come close . If you feed bad code to it , of course it won't help > too much. There are limitations to closure and its limitations are > documented unclearly, so you have to be very careful > > On Wed, Jan 25, 2017 at 8:09 PM Robin Heggelund Hansen <[email protected]> > wrote: > > 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 a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
