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.
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?
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?
About AMD, yuno is 1Kb minzipped and it resolve dependencies with parallels
downloads so you might be interested in having a look.
br
On Mon, Jan 16, 2012 at 7:33 PM, Mariusz Nowak <
medikoo+mozilla....@medikoo.com> wrote:
>
>
> Mark S. Miller-2 wrote:
> >
> > On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
> > medikoo+mozilla....@medikoo.com> wrote:
> >
> >> rauschma wrote:
> >> >
> >> > For incrementally migrating old code bases, it would make a lot of
> >> sense
> >> > to allow ES.next modules to import AMDs and vice versa.
> >> >
> >>
> >> -1
> >>
> >> I'm not sure if I understood this correctly, but trying to support
> >> backwards
> >> what was never a standard is probably not good idea, and AMD didn't get
> >> that
> >> much momentum to make exception for that, for many it's still
> >> controversial.
> >
> >
> > While I agree that ES.next modules do not need to worry about AMD if it
> > does not establish itself as a widely used de facto standard, I think we
> > would all be better off if (the core subset of) AMD did become a wild
> > success and ES.next felt the need to figure out how to manage the
> > transition.
> >
> >
>
> It's very subjective, for example I don't see any added value in AMD (also
> subjective). I work with complex JavaScript (on client-side) applications,
> and AMD is not for us. Let me explain:
> The point is that there are two ways of thinking of modules, first is fine
> grained, when you care about DRY then your modules are rather small, it
> means that with AMD you would need to load hundreds of such modules
> asynchronously it wouldn't work even in dev environment. You may say - ok
> but you may pack it with [your favorite AMD packer] - then I ask, what's
> the
> point of using AMD when I don't need to load my modules asynchronously ?
>
> Other way of thinking is bigger picture: it's about modules that are larger
> packs of small modules that are loaded on demand, and this is when AMD can
> be useful, however again I don't see a point of using AMD just for that,
> implementations of AMD that I looked at are heavy and over-bloated for such
> simple need.
>
> If you look at the most complex JS applications in a web Today (e.g. Google
> +, Facebook) most of them are built exactly that way, fine grained modules
> packed into larger packs that are loaded on demand. Facebook even has
> they're own CommonJS style modules packer.
>
> So @axel saying that AMD is already a browser standard and it's just
> Node.js
> users that don't like it, is overstatement. I don't see a need for AMD in
> ES5.next and I'll be happy to refactor my CommonJS style modules for
> Harmony
> implementations when it will become a reality.
>
> --
> Mariusz Nowak
> twitter: http://twitter.com/medikoo
> github: https://github.com/medikoo
>
> -----
> Mariusz Nowak
>
> https://github.com/medikoo
> --
> View this message in context:
> http://old.nabble.com/Harmony-modules-feedback-tp33125975p33149500.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.com.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
