Harmony modules feedback

Mariusz Nowak medikoo+mozilla.org at medikoo.com
Tue Jan 17 02:57:36 PST 2012

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

Mariusz Nowak

View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153281.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.

More information about the es-discuss mailing list