Re: Harmony modules feedback

Andrea Giammarchi-2 wrote:

You are underlying my points too .. I am dealing on daily basis with highly
dependent little modules and the build procedure takes care of packing
everything together before deployment.

However, we are using a synchronous version of require, similar to the one
used in node.js but that does not scale the day we would like to go
asynchronous in order to lazy load on demand only needed code.

On our side we're using version of require that's exactly same as in Node.js (we also use Node.js and some modules are used on both sides) and asynchronous loading in our case would rather be on package level not module level (Node.js thinking) but even not exactly that way. It's more about packs of modules that are needed to run other functionality (that we prefer to load on demand) and those modules may come from various packages. That's the approach we currently feel is right. We're using modules-webmake [1] for client-side builds, but it's still limited as it doesn't support yet "intelligent split" so modules are not duplicated in two different packs, however we plan to address that soon.

Andrea Giammarchi-2 wrote:

Specially on mobile HTML5 applications where the manifest file is included,
the lazy loading is handled by the browser itself and the module will be
almost instantly available once required later on if this was present in
the manifest.

What is missing is simply a common way that scales across all requirements
and I am sure you are using similar approach we do, stripping out requires,
used only to order file inclusion before minification, using synchronous
loading on demand during debug ... isn't it?

We don't strip out requires, we were thinking about that, as it would produce bit shorter and cleaner code (thinking one file) but the more we work with Node.js style modules the more we acknowledge it may be quite hard to achieve (unless you stick to some strict simple rules) but still I don't see it as big deal, footprint that is currently added by modules-webmake[1] is only 55 lines of code, and so far we don't feel it affects performance of our applications.
We debug with not minified version of generated file, output from webmake is very clear, and modules that were concatenated are not changed and usually not big so it's easy to get around.

Andrea Giammarchi-2 wrote:

This is OK as long as your requirements won't change and, talking about
google, they do lazy load on demand many parts of their namespace too in
different applications 'cause a core of 1Mb does not simply scale over 3G
connections ... if you don't need that functionality instantly then why
creating such big package?

var module = require("module");

is totally fine but

require("module", function (module) {
  // is totally fine too
});

latter could be synchronous in node.js and asynchronous in the web, who
cares, as long as it scales for all scenarios ... don't you agree?

Personally I don't like the need of extra closure. I want to be able to write my code directly in a file. It may be a picking, but it's like introducing to each of your modules extra maintenance code which has nothing to do with logic of that module, I tend to avoid that as much as possible.

Andrea Giammarchi-2 wrote:

About AMD, yuno is 1Kb minzipped and it resolve dependencies with parallels
downloads so you might be interested in having a look.

I looked at that with interest right when you published it, but currently I really like the way modules work in Node.js, I'm fine with modules-webmake, and I think it's currently the closest you can get to what will be introduced in future with Harmony, so I plan to stick to that.

[1] https://github.com/medikoo/modules-webmake

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo