On Wed, Feb 18, 2015 at 8:58 AM, Khalid Jebbari <[email protected]> wrote:
> Haven't tried yet the new modules compilation strategy, but I know a very > good strategy available in the JS world with Browserify and its plugin > factor-bundle. Basically, factor-bundle analyses all the emitted code and > put in a single file every single module (written like node modules) that > appears twice or more in the various emitted files into a single file. So > there's never duplication of code. > In ClojureScript we generally don't have code duplication issues and never have. This type of dedupe pass is unnecessary. > Example: module A requires module B. module C requires modules B & D. You > compile A & C. Browserify would output 3 files : A.js, C.js and another > (custom name) common.js that would include modules B and D. It handles > automatically the exposition of B and D so that anyone can "require" them. > To be clear Google Closure Modules is a very overloaded use of the term `module`. `module` in this context really means some bundle of namespaces that you want to keep together even through advanced compilation. In ClojureScript any namespace not enumerated in an explicit :entries will get moved into the base (common/shared) module. But this isn't as bad as it sounds because Google Closure supports cross module code motion at the function and method level. That is any code (even a single function) in the base module only used by some dependent module will get moved into only that dependent module. This type of optimization isn't about `modules` or `namespaces` the user actually wrote. Its about partitioning an advanced compiled artifact into an set of optimal N pieces using a precise granularity of analysis. The modules you end up with may have nothing to do the original organization of the program - and that's desirable from a page load speed perspective! As far as I know Google has been employing this feature for years now, so I suspect it works as well if not better than advertised since ClojureScript programs are almost entirely written in terms of small composable units - functions. I think the idea is awesome, especially since it requires almost no > configuration. Factor-bundle manages to find all common code by analysing > the dependency graph. Since Google Closure Modules / CLJS namespace also > create a dependency graph I'm pretty sure it's somehow possible. No ? Again the Google Closure Module dependency graph is not the module dependency graph you actually wrote. I think people need to actually experience the type of optimal builds :modules gives you. I also suspect having a simple explicit way to lock a namespace to a Google Closure Module when you need to will trump any algorithm we may devise. So that's a long way of saying we're not going to pursue a configuration-less :modules system in the near future until people have seen what they can accomplish with the existing system :) David -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
