WARNING: This server is unstable and will be retired in the next days. If you want to keep this forum available, please request immediately a migration on the Nabble Support forum. Forums that don't receive any migration request will be deleted forever.

 « Return to Thread: Harmony modules feedback

Re: Harmony modules feedback

by Andrea Giammarchi-2 :: Rate this Message:

| View in Thread

I have posted about a "better approach" to load modules too talking about an early state library that already works like a charm:
http://webreflection.blogspot.com/2012/01/y-u-no-use-libraries-and-add-stuff.html

AMD is good in theory but as far as I can see it fails miserably when it comes to JS packages.
For JS packages I mean those files where more dependencies are included, rather than loaded on demand.

Regardless the "Y U NO" funny name I chose for my tiny library ( it fits in 1Kb once minzipped ) there are best parts from all other proposals, except the sandboxed nature which is not implemented for browsers right now, but that can be easily implemented in both CommonJS and AMD logic.

The semantic API is also a plus, I don't think I need to explain what are arguments for ... example

yuno.use(
  // multiple requires allowed
  "core",
  "namespace.Generic",
  "other.Whatever",
  "myNMSP"
).and(function (
  // arguments passed as it is for AMD
  core, Generic, Whatever, myNMSP
) {
  // add reflects Object.defineProperty method
  yuno.add(myNMSP, "moduleName", {value: function () {
    // cool stuff here
  }});

  // since "and()" is fired via yuno object
  // old code can be simply used as well
  // so this is possible too
  myNMSP.moduleName = ...

});

// if the module has no dependencies
// we can either juno.add() to define 
// the module or simply 
// myNMSP = .... whatever ...

The main difference from CommonJS world is that the module could receive already defined namespaces in its context
The main difference from AMD world is that module define explicitly what it is about, rather than export.
This makes scalability with pre-compiled JS packages possible, something I am struggling right now with current implementations: synchronous in CommonJS require implemented via node, and not easy to understand runtime with AMD proposal.

If AMD is able to solve this problem too, well ... I will change "yuno" accordingly to make it AMD like ... right now it loads as much as possible in parallel for browsers, and it can be easily implemented for node.js too ( as I have said, it's an early stage )

Best Regards

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

 « Return to Thread: Harmony modules feedback