4 ms·
All of Google, and most ClojureScript users would like to disagree with you. Google Closure has been successfully tree-shaking since it was released, in 2009.
by arohner 11y ago
All of Google, and most ClojureScript users would like to disagree with you.
Google Closure has been successfully tree-shaking since it was released, in 2009. ClojureScript uses Closure for an optimization path, so the majority of CLJS apps in production (CircleCI, Prismatic, to name a few) use tree-shaking on every deploy.
- Silhouette 11y agoIt's not as simple as you're suggesting. With Closure you sometimes have to rewrite otherwise correct and idiomatic JavaScript significantly to avoid it breaking during compilation.
- chrisoakman 11y agoFYI - the JavaScript output of the ClojureScript compiler is designed to be compatible with the Google Closure Compiler in Advanced mode. In other words, CLJS users don't have to do anything special to benefit from the power of Google Closure. It just works :)
- arohner 11y agoIf you design your app to use Closure from the start, it's not a problem at all, and as a sibling comment said, CLJS apps get it mostly for free. The entire JS toolchain lost five to ten years by not adopting Closure. I suspect that in a year or two, someone will release a webpack plugin that does the exact same thing Closure did, with the exact same constraints.
- stcredzero 11y agoGoogle Closure has been successfully tree-shaking since it was released, in 2009 One can still write code that breaks the tree-shaking. How does Google Closure solve that? Through its community and best practices. Arguably, this is where Smalltalk failed, and where other dynamic languages can take a useful lesson. (Being fostered by an environment like Google probably gave Closure a leg up this way.) ClojureScript uses Closure for an optimization path ClojureScript has an advantage, in that it's probably designed to not-easily produce code that breaks tree shaking.