Modules/Async/B

[Vlad Balin]

Hello.

I would like to discuss proposal for Modules spec. The first draft
spec is here.
http://wiki.commonjs.org/wiki/Modules/Async/B

These modules feels in much like modules in mature languages. I'm
using this style of module definition (chained functions) about a year
in different AJAX applications (one of them quite large), and my
experience shows that this approach is superior to AMD.

Well, that's my experience. What do you say?

[Wes Garland]

> Well, that's my experience. What do you say?

Sorry for commenting before review, but I have two questions:

1 - Have you had a chance to review the current state of other proposals,
2 - Is it possible to run Modules/1.1.1 modules in this environment without semantic changes
3 - Does this proposal require a server-side component, or a module boilerplate?

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Vlad Balin]

> 1 - Have you had a chance to review the current state of other proposals,

Yes. I'm active user of RequireJS from the middle of 2010, and I'm
looking at the CommonJS proposal changes from time to time.

I wrote this proposal because I have not noticed any proposal based on
call chaining. I believe this approach is quite interesting to be
mentioned in proposals.

> 2 - Is it possible to run Modules/1.1.1 modules in this environment without
> semantic changes

Reference implementation I have is able to handle CommonJS AMD, since
it's currently the wrapper around RequireJS library. It can't handle
path shortcuts, however. So, I believe, yes, it should be possible,

> 3 - Does this proposal require a server-side component, or a module
> boilerplate?

No. Module definitions can be loaded with <script> tag injection as
is, without modifications. They are asynchronous, and doesn't pollute
global namespace. Other options are not interesting.

[Vlad Balin]

Answering shortly, it would be strange for me to place proposal on CommonJS wiki, to name it Modules/Async/B with link from main Modules spec page, and to loose the chance to read other proposals.

Looking forward for your comments after review.

[Vlad Balin]

[Florian Traverse]

Your proposition is more or less what I proposed about a year ago, and
Wes made in a incredible time (less than an hour, with tests and
publishing) a version of bravojs for implementing it.

I globally agree with your api and I'm in favor of such an api to be a
commonjs module 2.0 spec. It brings new features to modules such as an
official way to load other than modules files even on the server (I
could think of a support for yaml config files for example).

I guess it's not modules 1.1.1 compatible but loader which will
support this, would, if they want to, support 1.1.1 as wellsemver is
our friend here

2011/8/10 Vlad Balin <gape...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "CommonJS" group.
> To post to this group, send email to comm...@googlegroups.com.
> To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
>
>

[Vlad Balin]

> Your proposition is more or less what I proposed about a year ago, and
> Wes made in a incredible time (less than an hour, with tests and
> publishing) a version of bravojs for implementing it.

Sounds good. Because good ideas never come in single head. It doesn't
mean by itself, that this proposal is good, though. :)

The core principle behind proposal is simple and obvious. require({ a:
"a", b: "b" }).define( function( _ ){...}) instead of
require(["a","b"], function(a,b){...}). That's it. And it's really
strange that no proposals based on this principle present on CommonJS
wiki.

At the late 2010 I've published my wrapper around require.js based on
this principle. https://github.com/gaperton/include.js, which I have
used in my projects (there are several articles from me in Russian on
this topic, unfortunately I'm not as good in English).

This proposal is "iteration 2", based on quite deep experience with
"include.js".

> I globally agree with your api and I'm in favor of such an api to be a
> commonjs module 2.0 spec. It brings new features to modules such as an
> official way to load other than modules files even on the server (I
> could think of a support for yaml config files for example).

Sounds very good. Besides new features, there's one more important
difference. This proposal is declarative module definition, while
others are "imperative". For declarative definition it's enough to
read it to understand, for imperative you need to execute program in
your head. The last is not suitable not for humans nor for build
tools.

[Vlad Balin]

Added reference implementation as RequireJS wrapper.