Split off AMD? (was Re: [CommonJS] New amd-implement list)

[James Burke]

On Tue, May 17, 2011 at 3:45 AM, Tom Robinson <tlrob...@gmail.com> wrote:
> You've forked CommonJS modules with your AMD effort (and cleverly named "RequireJS"). I'm just suggesting renaming your spec and leaving CommonJS alone. Your new mailing list is a good start.

Thanks for the clarification. There was a message Kris Kowal sent a
while back that reminded me there are some cultural differences with
the founders/early members of the ServerJS/CommonJS list and the
supporters of AMD.

The CommonJS founders wanted to work out a module syntax that could be
implemented in existing JavaScript but may not work most optimally in
the browser, with the hope that some pathways would be possible for it
to be used in the browser and there would be some uplift in browser
technology for it to work better in the browsers in the future.

At least that is how I understand it. If I have it wrong, someone
please correct me.

The AMD folks want something that works well in the async environment
of the browser today that would also make sense in the future, because
the existing mechanisms in the browsers to support traditional
CommonJS modules were not robust enough to build large applications
that can easily be debugged and optimized for performance.

Unfortunately, the way the AMD proposal came into being was
contentious: badly named and the processes were not clear, and the
cultural differences between the two groups exacerbated the issue.

I would like to bridge the gap if possible, but I also appreciate that
some lists have a certain culture they want to keep. So if it is
preferable by the founders of this list that AMD be removed from the
CommonJS wiki, I am open to it. It is preferable to have two groups
being productive instead of both butting heads on one list.

However, I think it would be possible to bridge the gap.

The main technical sticking point is eager vs lazy dependency
evaluation. CommonJS modules 1.1 do lazy evaluation. AMD uses eager
evaluation.

The patterns that lazy evaluation encourage with computed dependencies
are hazardous in async environments like the browser, where a
callback-style require call is best to use for those cases. Eager
evaluation is a more terse API for a callback-style require too.

ES Harmony Modules [1][2] operate more like eager evaluation, the lazy
evaluation patterns will not work with it. In addition, the Harmony
Module Loaders [3] Loader.load API looks more like the eager
evaluation style used in callback-style require calls common in AMD
loaders.

So for me, new information was gained while trying to support
traditional CommonJS modules in an async environment in the browser,
and given how harmony modules have progressed since the first CommonJS
modules APIs, it makes sense to go with eager dependency evaluation
for a wrapped format.

If the CommonJS founders feel this is not enough motivation to
consider a change, the culture of the founders is just too different,
or if they feel I and other AMD supports cannot be trusted to operate
in good faith, then it is probably best to split off the AMD work.
Although if it is an issue of good faith I would prefer to fix that,
and I am willing to take steps to rectify it.

I would like to hear from other CommonJS founders/early members, like
Kevin Dangoor, Kris Kowal, Wes Garland. I apologize if I left anyone
out, speak up if you fit in that category. If the general vibe is to
split off AMD by removing it from the CommonJS wiki and using another
list for its discussion, then I will work with the other AMD
supporters to do so.

Tom, I get the impression you were one of the early people too. Based
on your comments above, it seems you are in the "split off AMD" camp.

[1] http://wiki.ecmascript.org/doku.php?id=harmony:modules
[2] http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples
[3] http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

James

[Kris Kowal]

AMD has been in proposal status for a long time without convergence.
It isn't a CommonJS specification because it hasn't received a
near-unanimous blessing from this community. It seems more likely to
me that something on the lines of Wes Garland's work on Modules 2 is a
more logical successor for CommonJS modules in the wild than
RequireJS. The approaches are not reconcilable and migratable. It's
a reboot, not an evolution.

At this time, regardless of any efforts we make to attempt
unification, and regardless of the large overlap of interested parties
in both projects, they are very different projects and housing them
under the same roof is confusing and misleading to newcomers.

RequireJS has grown its own wings and can live and grow without using
CommonJS as a buzzword. Our differences will inevitable be resolved
under Harmony; it doesn't make sense for CommonJS modules to migrate
to RequireJS or vice versa since modules will land in the language
soon. It does make sense for us to add support for define(function
(r,e,m) {}) boilerplate, but RequireJS is that and a lot more. The
overlap will have to be enough to support those few of us who need to
straddle the divide.

So, yes. I'm in favor of redirecting AMD to RequireJS.

Kris Kowal

[Christoph Dorn]

On 11-05-17 11:41 AM, Kris Kowal wrote:
> RequireJS has grown its own wings and can live and grow without using
> CommonJS as a buzzword. Our differences will inevitable be resolved
> under Harmony; it doesn't make sense for CommonJS modules to migrate
> to RequireJS or vice versa since modules will land in the language
> soon. It does make sense for us to add support for define(function
> (r,e,m) {}) boilerplate, but RequireJS is that and a lot more. The
> overlap will have to be enough to support those few of us who need to
> straddle the divide.
>
> So, yes. I'm in favor of redirecting AMD to RequireJS.

+1

I see AMD as a subset of CommonJS. I do not need to load individual
modules into the browser as my primary criteria. That is what Harmony
modules will be for from what I understand. I only need to be AMD
wrapper and evaluation compatible which I can be within a CommonJS
environment [1].

In my view CommonJS is much more than AMD or Harmony. With the packages
and mappings specifications we are heading into the program composition
space which I believe is essential for the goals of CommonJS.

Developers not only need a way to build applications out of modules
(that is how I view AMD), they also need an ecosystem of tools and
libraries to make complex applications out of modules possible in a sane
fashion. This ecosystem is built on a few standards in the right areas:

+ modules
+ packages
+ programs
+ io
+ binary
...
== JavaScript everywhere

On a practical and immediate note. If you want to "straddle the divide",
i.e. use RequireJS modules/packages with CommonJS Modules 2 today you
can use the following project which is the result of my desire for doing
that and more:

https://github.com/pinf/loader-js

Christoph

[1] - https://github.com/cadorn/ace-extjs

[Wes Garland]

> It's a reboot, not an evolution.

I that, in a nutshell, is easily the best characterization of how AMD trie[ds] to fit in vis a vis CommonJS I have ever seen.

Kris is right, of course, that these things will eventually merge when the browser makers give us Simple Modules.

You have probably all noticed, due to your light inboxes ;) that I have been quiet on the list lately -- it's a very busy time here! FWIW, we are accruing lots and lots of experience writing ES libraries that operate both client and server side.  We are using BravoJS on the client side, and GPSEE on the server side. GPSEE is monkey-patched to implement a subset of Modules/2.0d8 on top of Modules/1.1.1 (so both styles work), whereas BravoJS stays the course as a Modules/2.0d8-only package. 

If anybody is curious about the GPSEE monkey-patch, I blogged it about it a few months ago here: http://gpsee.blogspot.com/2010/12/wrapped-modules-with-gpsee-02-gsr-10.html

Wes

--
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.

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

[Tom Trenka]

I am a long-time lurker and not a commentator, so take this as you

will. That being said:

> I see AMD as a subset of CommonJS. I do not need to load individual
> modules into the browser as my primary criteria.

*You* may not need to load individual modules because you are focused
on the server, but that happens to be the primary use and need at the
moment (i.e. within a client). I can entirely appreciate JS-on-the-
server (that is where I learned JS primarily) but at the same time you
can't just ignore the primary usage in favor of your own efforts,
efforts with Node (/me golf claps) notwithstanding.

I would almost (not quite, but almost) suggest that if you are going
to use the moniker "CommonJS", then you *might* consider interop when
it comes to server and client workings--including scripting in such
Adobe products as Acrobat. It seems to me that the spirit of the
CommonJS effort is to attempt to unify the use of the language on
*various* platforms, not just the server. If your real interest is in
the work that you do on a normal basis, that's ok...but don't dismiss
the efforts that others (LOTS of others) are trying to do/have to do
simply based on your own interests.

The point of creating the AMD list is to remove the noise from this
one because there's some real practical efforts under way in working
out the kinks, based on server needs and client-based needs. I'm glad
that you approve of not having more noise but I'm saddened by the idea
that you would be promoting something "common" without clearly
considering how JS has been primarily used in the past 8 years. If
you seriously want this to be "Common", then don't dismiss browser-
based efforts. If you don't, however, then I'd humbly suggest you
consider revisiting the name of the current effort.

Regards--
Tom Trenka

PS. Christoph: my apologies, I am not targeting you personally. I've
been a lurker on this list for quite some time, and I have been
dismayed more than once by the "server prejudice" that has been
displayed. Your message kind of pushed me over the edge a bit (to the
point where I felt I finally needed to engage) but that in no way
reflects a viewpoint of the work you may or may not have done.

[Kris Kowal]

On Tue, May 17, 2011 at 1:10 PM, Tom Trenka <ttr...@gmail.com> wrote:
> I am a long-time lurker and not a commentator, so take this as you
> will.

Thanks for joining the conversation and sharing your opinion.

The eventual addition of declare(function (r,e,m){}) to the
specification would be sufficient to ensure interoperability between
client and server-side loaders, ensuring that CommonJS is common. The
remaining differences between RequireJS and CommonJS formats will then
be reduced to differences in taste. At this point, it is clear that we
will have separate but overlapping communities with separate but
overlapping specifications, so separate and cross-linking homes for
those efforts is the proper way to communicate the situation to our
communities.

Folks, let's please avoid a long series of heated replies. NOur
priority in this thread is to get a show of hands. Let's let the globe
spin a bit so we can hear from Kevin, Kris, Hannes, and all.

Kris Kowal

[Wes Garland]

On 17 May 2011 16:10, Tom Trenka <ttr...@gmail.com> wrote:

*You* may not need to load individual modules because you are focused
on the server, but that happens to be the primary use and need at the
moment (i.e. within a client).  I can entirely appreciate JS-on-the-
server (that is where I learned JS primarily) but at the same time you
can't just ignore the primary usage in favor of your own efforts,
efforts with Node (/me golf claps) notwithstanding.

I don't understand where this comes from, however, if you believe that we are not interested in interoperable JS, then you are quite simply mistaken.

Speaking only for myself, what I am not interested in is platforms which do not interoperate well with existing CommonJS implementations and libraries.

Wes

[Tom Trenka]

I'll reply to two at once, I hope you guys/gals don't mind =)

---

The eventual addition of declare(function (r,e,m){}) to the
specification would be sufficient to ensure interoperability between
client and server-side loaders, ensuring that CommonJS is common. The
remaining differences between RequireJS and CommonJS formats will
then
be reduced to differences in taste. At this point, it is clear that
we
will have separate but overlapping communities with separate but
overlapping specifications, so separate and cross-linking homes for
those efforts is the proper way to communicate the situation to our
communities.

Folks, let's please avoid a long series of heated replies. NOur
priority in this thread is to get a show of hands. Let's let the
globe
spin a bit so we can hear from Kevin, Kris, Hannes, and all.

---

My apologies: I was goaded by Christoph's reply, and Wes's had been
happening while I was composing my email. To be clear, I am not
advocating wholesale adoption of RequireJS as a specification; I am
reacting to what I have seen as a "server-side prejudice" in terms of
the definition of the specification. Having been involved in quite a
few aspects of application architecture, I've seen a lot of mistakes
made (in terms of "seeing the trees instead of the forest") and while
I applaud and support the efforts of the CommonJS community, I guess
I'm just kind of tired of seeing the browser-based versions of this
being treated as second-class.

(For the record, I am one of the primary people behind the current
effort to turn the Dojo Toolkit into a real-world example of CommonJS
specs. We'd love to be able to share what we've done in a way that
will NOT conflict with current development efforts.)

Thank you Kris for showing some levity =)

> I don't understand where this comes from, however, if you believe that we
> are not interested in interoperable JS, then you are quite simply mistaken.
>
> Speaking only for myself, what I am not interested in is platforms which do
> not interoperate well with existing CommonJS implementations and libraries.

Wes, I entirely agree, except for the "existing" part. CommonJS as it
stands now is a decent but immature specification; the primary efforts
behind it have been focused on what amounts to a single application
(i.e. server-side). I would submit that we as a community stand at a
crossroads, where there's a real effort to bring something designed
primarily for the browser into the CommonJS fold.

More practical applications of the specifications will help to refine
it, IMHO--and to date not a lot of effort has been put into that kind
of refinement in a browser environment. What I'd like to promote and
see is a little more respect for that environment, and a little less
dismissal of the importance of that environment...which kind of sums
up the reason for my initial response. If there's things that happen
purely because of browser environments, that's a bad thing. If there
are specifications developed because they have only been practically
implemented in a server environment, that's bad too. Typical chicken-
or-egg problem =)

Recognizing that most of the people that participate on this list tend
to operate on the server side, I'd (again) submit that maybe things
like the AMD spec need to take browser environments into account. If
the participants on this list feel that this is not a priority, I'm
happy to step aside and shut my piehole =) But if that happens to be
the case, I'd again ask that maybe "CommonJS" is not the right term.

Regards--
Tom Trenka

[Wes Garland]

On 17 May 2011 17:12, Tom Trenka <ttr...@gmail.com> wrote:

Wes, I entirely agree, except for the "existing" part.  CommonJS as it
stands now is a decent but immature specification;

I agree that it's immature; I tried to address what I consider shortcomings when I drafted the Modules/2.0 strawman proposal last year.  This immaturity does not mean, however, that we should be willing to throw out Modules/1.1.1 compatibility just because it suits some discussion participants to do so.
 

the primary efforts
behind it have been focused on what amounts to a single application
(i.e. server-side).

I'm flattered to hear that you think only my platform is worth mentioning, however besides GPSEE there is also Node.JS, v8cgi, Flusspferd, Narwhal, Mozilla's JetPack, RingoJS, Wakanda, CouchDB, Persevere, Joyent's Smart Platform, EJScript, and others which are seeing use in industry.
 

 I would submit that we as a community stand at a
crossroads, where there's a real effort to bring something designed
primarily for the browser into the CommonJS fold.

Who wants to design primarily for X?  I refuse to believe that we cannot have a platform designed to work well everywhere.
 

More practical applications of the specifications will help to refine
it, IMHO--and to date not a lot of effort has been put into that kind
of refinement in a browser environment.  

My time sheets show approximately 6 man weeks in FY2010. I consider that more than "not a lot".

Wes

[Christoph Dorn]

Just a quick note. I have been a factor in encouraging the CommonJS
discussions about browser considerations and am working with CommonJS in
the browser 80% of the time at the moment.

I approach this whole portable JS problem from a purist perspective
which is why I resonate with CommonJS. For me, theory comes before
implementation where I find AMD puts implementation first as it
overcomes a specific problem limited to one deployment target (the browser).

In hearing the concerns about browser compatibility on this list and in
my desire to use all kinds of modules within a CommonJS environment I
have written a loader based on Wes's CommonJS Modules 2 draft (which
address browser loading) that will allow me to bridge all these gaps so
I can run 100% pure CommonJS in the browser using a very efficient
development process.

The loader is here:

https://github.com/pinf/loader-js

And a project (that runs in the browser) that is built on top of this is
here (it actually imports several packages designed to run under RequireJS):

https://github.com/cadorn/ace-extjs

I am not trying to push my work, I am asking you to take a serious look
at what is possible if you leverage all the latest CommonJS work. Sure,
it requires a development server, but this approach to writing
JavaScript applications allows me as a single developer to maintain
several complex applications running on server, in browser and in
browser extension using dozens of libraries from all over.

I don't think it is a questions of CommonJS or AMD. We need to share
information and build our respective communities ensuring there are
loaders, tooling and documentation in place to allow users to use
modules from both in the same runtime/sandbox/application. I am doing my
part in making AMD style modules available in a seamless/native fashion
within a pure CommonJS environment. As long as I can load a module and
have it work I don't care if it had to undergo a wrapping step that is
transparent to me and only required during development and at build time
so I say go ahead and write in AMD. I prefer CommonJS style modules.

Christoph

[Mikeal Rogers]

I haven't commented in quite a while but I figured this might be a good time.

I'm not trying to be a dick or anything but this list is in great danger of becoming entirely irrelevant.

node.js is breaking off and doing it's own thing (based on CommonJS Modules 1.0). It's unclear whether those changes will bring it out of compliance or not, but node.js will never implement AMD.

TC-39 is moving forward with Harmony Modules, which are solving the problem AMD is attempting to solve in regard to performance but in a much better way because of the obvious advantage of an in-browser implementation.

IMO, the old dojo module system and similar module systems that do server side bundling to reduce IO roundtrips solve the same problem AMD is trying to solve but in a much better way.

Between node.js and newer Modules 1.x compliant bundling systems (ala dojo) we have a wide implementation set where breaking out in to many small files/modules and deep dep chains are encouraged and have very little noticeable overhead. Even with the improvements AMD brings to IO roundtrips it's still a concern in heavily aggregated module usage.

In short, why does this matter? Why isn't this just a project on GitHub instead of a spec? How many people do you really think are going to use and implement this?

[James Burke]

On Tue, May 17, 2011 at 3:03 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
> In short, why does this matter? Why isn't this just a project on GitHub
> instead of a spec? How many people do you really think are going to use and
> implement this?

Your feedback is all over the map and contain some factual
inaccuracies. If you want better answers to why AMD or how it fits in
with the future, feel free to ask on the amd-implement or the
requirejs list.

I would appreciate if people refrain from responding to Mikeal's
specific comments as it will likely just muddy the waters. He raises a
question of relevancy that may be interesting but best discussed in a
separate thread.

As to the question at hand Mikeal seems to be a +0 based on his
relevancy comments.

I am hoping to hear from the rest of the CommonJS founders, but it
does seem like it is best to split out AMD from the CommonJS
list/wiki.

James

[Mikeal Rogers]

factual inaccuracies about AMD or the rest of the world?

[Wes Garland]

On 17 May 2011 18:59, James Burke <jrb...@gmail.com> wrote:

I am hoping to hear from the rest of the CommonJS founders, but it
does seem like it is best to split out AMD from the CommonJS
list/wiki.

I think we should at the very least have links from CommonJS -> AMD.  The two projects are closely aligned in goals, even if they are not completely interoperable. It is more healthy to have a well-documented inclusive ecosystem than it is to have either poorly-labelled projects or to pretend other work does not exist.

I echo your sentiments re. Mikeal's post, relevancy is another thread for another day.

Wes

[Nathan Stott]

For what it's worth I'm -1 on the split. It's not as though this list
is overburdened with traffic and the projects are geared at a similar
/ overlapping audience.

[Dean Landolt]

On Tue, May 17, 2011 at 10:09 PM, Nathan Stott <nrs...@gmail.com> wrote:

For what it's worth I'm -1 on the split.  It's not as though this list
is overburdened with traffic and the projects are geared at a similar
/ overlapping audience.

Same here. They're also at least somewhat interoperable with some boilerplate.

[Kevin Dangoor]

On Tue, May 17, 2011 at 2:20 PM, James Burke <jrb...@gmail.com> wrote:

ES Harmony Modules [1][2] operate more like eager evaluation, the lazy
evaluation patterns will not work with it. In addition, the Harmony
Module Loaders [3] Loader.load API looks more like the eager
evaluation style used in callback-style require calls common in AMD
loaders.

I asked Dave Herman (author of the Harmony Modules spec) about this at JSConf and I'm thought the answer was that Harmony modules are lazily evaluated (assuming I'm not getting mixed up by the "lazy" terminology here). In other words if you have a module like this:

module q = import Q


the "Q" module is loaded before this module is run, but its code is not actually run until it hits the import statement here.
 

I would like to hear from other CommonJS founders/early members, like
Kevin Dangoor, Kris Kowal, Wes Garland. I apologize if I left anyone
out, speak up if you fit in that category. If the general vibe is to
split off AMD by removing it from the CommonJS wiki and using another
list for its discussion, then I will work with the other AMD
supporters to do so.

I am -1 on a split. This whole thing reminds me of what I believe was a Monty Python sketch (which I can't find now...) Two people were talking about which church they were a member of and they went down several levels of church hierarchy entirely the same until they finally arrived at one being from the north branch and the other being from the west branch (or some such). Then the first yells out to the other: "Heretic!"

We're now in a spot where we have two de facto standard module formats (plus the traditional JS mechanism of hooking on to globals). We have an incoming "ratified standard" module format that will ultimately make all of this moot and those of us who have moved to using modules will want to switch to using those. I consider it very likely that Firefox will support modules in a release this year.

I am inclined to think that despite the division in module formats that we have today, there is enough commonality and common purpose that the conversations will be useful to people in either camp.

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Kris Walker]

Initially I was all for the split of AMD.

After hearing the last argument regarding common audience I'm changing
my mind. I don't want to watch another mailing list.

-1

- Kris (Kris #3)

On May 18, 9:59 am, Kevin Dangoor <k...@blazingthings.com> wrote:

> those. I consider it *very* likely that Firefox will support modules in a

[Eugene Lazutkin]

I agree with Kevin and Kris W., and Wes, and Dean, and Nathan --- we
have enough of synergy in all environments to try to forge a common
API especially in the light of language-based modules coming "real
soon now".

Given all that I am -1 on the split.

Cheers,

Eugene

[Irakli Gozalishvili]

Maybe it's not very relevant here, but it was mentioned that there is some overlaps between pure commonjs modules and AMD I would be very happy if we could focus our efforts on this overlapping sweet spot!


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

[Chris Zumbrunn]

On Thu, May 19, 2011 at 00:46, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> Maybe it's not very relevant here, but it was mentioned that there is some
> overlaps between pure commonjs modules and AMD I would be very happy if we
> could focus our efforts on this overlapping sweet spot!

The overlap is a transport/package format, not an authoring format, in
my opinion, but I don't really see it as a terrible thing if
"CommonJS" would become just that. Some people would no doubt still
write code directly in that format, but I for one would then see
CommonJS as a build target, which would allow us to define something
more elegant and boilerplate-free for authoring and local execution
(and in the process back-paddle on many of the compromises that were
made in that department with the existing Modules 1.x spec).

Chris

[Claus Reinke]

-1 on list split. +1 on spec split. If there is no agreement on
a common spec, let there be two specs, as long as both try
to support the whole user community by making it possible
to exchange and load modules. There are implementations
of both specs, let the users decide which one they want.

The discussion has profited both camps, and both have
made adjustments to cover more use cases. What neither
camp wants is to abandon its own work wholesale. Which
is where the friction seems to come from. I know which
kind of module I prefer, but I can accept that others have
different preferences. As long as I can use their modules,
and they can use mine (no module lock-in), does that matter?

I hope for what the ideal "CommonJS" implies, but for that
to come to fruition, there need to be useable API specs with
real and multi-platform implementations.

Modules are a baseline/stepping-stone for that. I admit that
it was fun implementing a loader myself, and I can see that
I am not alone in appreciating that much control over basic
infrastructure. But ultimately, it is more interesting to have
good libraries to load, offering mostly the same APIs, no
matter what platform I'm on.

James has done a great job of popularizing module loaders,
adapting his library to cover more use cases, and trying to
find consensus among different API camps. In trying to be
accommodating, he has added so many features to his library
that it is no longer the simplest loader in the game. But his
work is still an example of what bystanders like me would
like to see from CommonJS: reuseable and visible software.

Some of the CommonJS contributers build (and use, in their
own projects) a lot of useable software, but that does not
seem to translate into more generally reusable libraries/
APIs on the CommonJS list or website. Remember, that is
an outsider's view - from someone still trying to decide
whether there is something to take home from CommonJS.

> I'm flattered to hear that you think only my platform is
> worth mentioning, however besides GPSEE there is also
> Node.JS, v8cgi, Flusspferd, Narwhal, Mozilla's JetPack,
> RingoJS, Wakanda, CouchDB, Persevere, Joyent's Smart
> Platform, EJScript, and others which are seeing use in industry.

Node.JS has won the popularity contest - that doesn't mean
it is the best or only game in town, it doesn't even mean that
this popularity will last; but it does mean that people listen
when the Node.JS creator says that CommonJS is irrelevant:

http://www.reddit.com/r/node/comments/h1m2o/i_am_ryan_dahl_creator_of_nodejs_ama/c1ry6oc

Moving successful-in-practice efforts of those who _want_
to work with CommonJS to separate lists seems to be
exactly the wrong kind of response to such statements.

Claus

[Wes Garland]

But ultimately, it is more interesting to have
good libraries to load, offering mostly the same APIs, no
matter what platform I'm on.

Hear, hear.

This is where I start complaining for the Nth time that we can't even portably write "hello, world" in CommonJS yet.  We need to get back to the work we were doing in 2008-2009; figuring out sockets, streams, byte-strings, and concurrency models!

[Tom Robinson]

(James, to answer your question, yes I've been involved since the
beginning. Admittedly I have been less actively lately)

My thoughts/opinions/summary:

* Almost everyone (self included) is in favor of some form of
"asynchronous module definition" format for loading modules via script
tags.

* Many original CommonJS participants (myself included) absolutely ARE
interested in interoperability between browser and server-side
JavaScript. This is one reason the name was changed from ServerJS to
CommonJS.

* If you are in favor of AMD as an "authoring format" (I like Chris'
name for it) you are not prioritizing interoperability. AMD imposes an
implementation detail on developers that make no sense for
environments other than the browser.

* People who don't care about interoperability with non-browser
environments have no place being involved with CommonJS.

The divide here is between people who see AMD as a "transport format"
that should be generated by a build tool or server, versus an
"authoring format" that should include hand-written async definition
boilerplate.

* From what I understand the argument for AMD as an "authoring format"
boils down to this:

- Some browsers have problems reporting filename and line numbers
for exceptions and during debugging for code though "eval"/"new
Function()" that they don't have with code evaluated though script
tags.
- In some cases you might want to load a module using a script tag
without having to minify/wrap/bundle it.

* My arguments for AMD as a "transport format" (and I believe many
people agree with me) are:

- We may be stuck with this module spec for awhile (5+ years until
ECMA specs modules, browsers implement them, and the vast majority of
users upgrade?), so it should be forward-looking, not held back by
legacy issues with browsers that are rapidly going away.
- It should be suitable for both browsers and server-side environments.
- A tool or server should be used to minify, wrap, and bundle your
client-side code for deployment anyway.
- Boilerplate sucks and should not have to be written by hand. It
should be considered an implementation detail.
- The features browsers offer for asynchronously loading and
evaluating code without using script tags are "good enough" for
development, and they're improving.
- Any issues with the browsers should be considered bugs in the
browser as they are likely common problems for web developers, and
they should be fixed in the browser.

I see a few scenarios that would maximize interoperability that I'd be
happy with (in decreasing order of my happiness):

* We agree that AMD should be a transport format only. Browser loaders
like RequireJS can implement only AMD, but they should not encourage
users to hand-write the AMD boilerplate.

* We agree that implementations that implement AMD should also
implement basic CommonJS 1.x modules (or whatever the future iteration
is).

* We agree that all implementations should implement both AMD and
CommonJS 1.x modules.

Regardless of the outcome, I also think RequireJS should change their
name and/or implement CommonJS 1.x modules. I absolutely hate that it
has co-opted the name "require" and are confusing developers about
CommonJS modules.

-tom

[Wes Garland]

Tom;

You missed one important point in your post.  AMD, as it stands today, also has a requirement to initialize modules eagerly. This is semantically different from Modules/1.0, which requires lazy module initialization.

This is not an implementation detail, it is an actual breaking change in module semantics, and it and has no bearing on the underlying JavaScript engine or concurrency model; it is merely a preference of the specification author.  It is for this reason that AMD cannot be considered a CommonJS module transport format.

[Nathan Stott]

Great post, Tom

[johnjbarton]

On May 19, 1:25 pm, Tom Robinson <tlrobin...@gmail.com> wrote:
> * If you are in favor of AMD as an "authoring format" (I like Chris'
> name for it) you are not prioritizing interoperability. AMD imposes an
> implementation detail on developers that make no sense for
> environments other than the browser.

I'm unclear on what implementation detail you mean here.
...

>
> The divide here is between people who see AMD as a "transport format"
> that should be generated by a build tool or server, versus an
> "authoring format" that should include hand-written async definition
> boilerplate.

I don't agree with this characterization. A build tool is completely
off the table for me. I would not consider any module loading scheme
that requires a build tool. So for me the divide is build too or no
build tool.

>
> * From what I understand the argument for AMD as an "authoring format"
> boils down to this:
>
>     - Some browsers have problems reporting filename and line numbers
> for exceptions and during debugging for code though "eval"/"new
> Function()" that they don't have with code evaluated though script
> tags.
>     - In some cases you might want to load a module using a script tag
> without having to minify/wrap/bundle it.

Any build step is unacceptable during development.

>
> * My arguments for AMD as a "transport format" (and I believe many
> people agree with me) are:
>
>     - We may be stuck with this module spec for awhile (5+ years until
> ECMA specs modules, browsers implement them, and the vast majority of
> users upgrade?), so it should be forward-looking, not held back by
> legacy issues with browsers that are rapidly going away.

In the many discussions about CommonJS Wes defended the opposite. He
wants legacy going forward and would not budge on this issue.

>     - It should be suitable for both browsers and server-side environments.
>     - A tool or server should be used to minify, wrap, and bundle your
> client-side code for deployment anyway.
>     - Boilerplate sucks and should not have to be written by hand. It
> should be considered an implementation detail.

What is this boilerplate thing you are talking about ? The list of
modules?

Ok it sucks that the the modules names are not JS argument names. So
we have to list the module names *and* the argument names. But really
its not that big of deal.

>     - The features browsers offer for asynchronously loading and
> evaluating code without using script tags are "good enough" for
> development, and they're improving.

Script tags are implementation detail. I ported require.js AMD to
Mozilla gecko using evalInSandbox and it would have worked if the
Mozilla platform worked.

>     - Any issues with the browsers should be considered bugs in the
> browser as they are likely common problems for web developers, and
> they should be fixed in the browser.

Yay, something to agree on!

....

> Regardless of the outcome, I also think RequireJS should change their
> name and/or implement CommonJS 1.x modules. I absolutely hate that it
> has co-opted the name "require" and are confusing developers about
> CommonJS modules.

Ironically we use AMD and don't need the word "require" at all. So
here I agree!

jjb

[Tom Robinson]

On Thu, May 19, 2011 at 8:44 AM, Wes Garland <w...@page.ca> wrote:
>> But ultimately, it is more interesting to have
>> good libraries to load, offering mostly the same APIs, no
>> matter what platform I'm on.
>
> Hear, hear.
>
> This is where I start complaining for the Nth time that we can't even
> portably write "hello, world" in CommonJS yet.  We need to get back to the
> work we were doing in 2008-2009; figuring out sockets, streams,
> byte-strings, and concurrency models!
>
> Wes

I agree it's a travesty we can't even do a portable "hello world".
However, my opinion on which things we should be working on has
changed. We were very eager and I think we bit off more than we could
chew at the beginning, which was part of the problem.

If I were to do it again, I'd be very careful about what we worked on
and when. Starting with things that don't make too many assumptions
about the underlying platform is key.

I'd be super happy if we (*including Node*) could agree on the following:

* modules (CommonJS modules 1.1.1 are fine)
* console output (can't we all agree on "console.log" at this point?)
* fixed-length mutable binary buffers (just use Typed Arrays maybe?)
* command line arguments and environment variables (I'm split on the
global object like "process" in Node vs. a module like CommonJS's
"system")

Then I'd do synchronous file reading/writing, which even Node has.
After that there's not really anywhere to go without tackling the sync
or async IO debate (and the resulting promises vs streams vs whatever
debates). I'd like to spec both, clearly separated, but in a way that
was complementary to each other.

Also, I think test suites would be key. Platforms should declare which
specs they implement, then we could run the test suites and
automatically generate a matrix showing which platforms implement
what, and whether they're currently passing the test suite. That would
be huge.

Anyway, those are just my random thoughts. If we seriously want to
consider rebooting CommonJS's work on that stuff I have a lot more
thoughts on it.

-tom

[Nathan Stott]

I don't get why any build tool is off the table for development. Have
you never worked with a language you have to compile? Is this really
such a burden? Apparently it is, but this attitude is still foreign
to me. I'll trade not having to write boilerplate by hand for having
a build step or having to run a special dev server.

[johnjbarton]

On May 19, 4:21 pm, Nathan Stott <nrst...@gmail.com> wrote:
> I don't get why any build tool is off the table for development.  Have
> you never worked with a language you have to compile?

Yes, a few, like Fortran, C++, C, and Java. Build tools are a relic of
the past.

 Is this really
> such a burden?  Apparently it is, but this attitude is still foreign
> to me.  I'll trade not having to write boilerplate by hand for having
> a build step or having to run a special dev server.

What boilerplate?

jjb

[Patrick Mueller]

On Thu, May 19, 2011 at 18:55, johnjbarton <johnj...@johnjbarton.com> wrote:

I don't agree with this characterization. A build tool is completely
off the table for me. I would not consider any module loading scheme
that requires a build tool. So for me the divide is build too or no
build tool.

...

Any build step is unacceptable during development.

This is a common refrain, I've heard the same statement from other people.

But I'm a "pro-build" guy.  For any significant project, and some insignificant ones, I run continuous builds.  If it's a HTML/JS/CSS project, the continuous build is applying Transport/D-like wrappers to my modules, and copying all the files to an output directory.  Takes like, a second, runs whenever I change a source file.  Being able to author in, and directly reuse existing "CommonJS" modules, is a big win for me.  Specifically, not having to add Transport/D-like wrappers to modules in their source format is well worth the cost of setting up, and depending on, a "build".

--
Patrick Mueller
http://muellerware.org

[James Burke]

On Thu, May 19, 2011 at 1:25 PM, Tom Robinson <tlrob...@gmail.com> wrote:
> * If you are in favor of AMD as an "authoring format" (I like Chris'
> name for it) you are not prioritizing interoperability. AMD imposes an
> implementation detail on developers that make no sense for
> environments other than the browser.

This statement is definitely a cultural one. Which is fine, and I
think a good reason to not continue detailed AMD discussion on this
list. FWIW, AMD as an authoring format works better and more
consistently across all JS environments. That is interoperability that
actually matter to developers. But again, this is a cultural
difference.

> * People who don't care about interoperability with non-browser
> environments have no place being involved with CommonJS.

Right, that seems like a no-brainer. Not sure you needed to mention it
unless you meant to imply something else about my motivations. All the
work I have done works in non-browser environments.

> The divide here is between people who see AMD as a "transport format"
> that should be generated by a build tool or server, versus an
> "authoring format" that should include hand-written async definition
> boilerplate.

So, if there is a standard transport format, it seems reasonable for
server implementations to support it too, since it also allows easy
transport of multiple modules in one file, even for use on the server.
It can be a legitimate way to pass around modules.

So if the server also understands the transport format, what does it
matter if a tool or a person authors the format?

As you indicate, having the server understand the transport format is
not the most palatable solution for you, which brings up the main
point.

My main issue is that by treating something like AMD as "just a
transport format", it makes it easy to avoid thinking about the real
issues with async loading in the browser, no matter if there are
special tools/upgrades in the browser to handle them.

Like the issues with lazy evaluation, and how that also affects a
callback-style of require, where it seems silly to use lazy evaluation
for that kind of callback API. The direction of harmony modules is a
data point that confirms this.

You can hope the transport format is just a patch until better
capabilities come in the browser, but those better things will likely
just be harmony modules support. So the implementation choice for
today should work in today's browsers. Which also happens to work on
the server.

Anyway, flame off. This is definitely a cultural issue, and I'm fine
saying that the CommonJS list has a culture that matches what you
outlined.

> Regardless of the outcome, I also think RequireJS should change their
> name and/or implement CommonJS 1.x modules. I absolutely hate that it
> has co-opted the name "require" and are confusing developers about
> CommonJS modules.

The goal with RequireJS was to be able to provide an effective wrapper
around CommonJS module concepts. The issue with lazy vs early
dependency evaluation did not crystalize until later. For the small
number of modules that actually depend on that difference there can be
a problem, but there would likely be an issue anyway, particularly
with the computed require cases.

But the vast majority of CommonJS modules can be loaded by
AMD/RequireJS given a wrapping. I have even gone to extents to support
both module.exports and module.setExports, although at this point
setExports looks like a dead end.

CommonJS does not have special ownership of 'require'. I support the
CommonJS concept as much as it makes sense for an async environment,
and in a way that is more future compatible, so I do not plan on
changing the RequireJS name.

You'll need to get over the RequireJS name, and I'll need to get over
wishing this list had a different culture than what its name initially
implies.

So I think the next steps would be:

* Move the bulk of AMD discussions to another list.
* Copy the AMD API that is on the CommonJS wiki to another area.
* Leave the AMD API page on the CommonJS wiki, but update it to
mention its further development is at the other place and mention the
small edge cases where it cannot handle CommonJS modules.
* Post back to this list if/when there are common concerns that might
affect both groups.

Hopefully that would be enough to assuage your concerns about AMD
causing confusion with traditional CommonJS Modules 1.1, and free this
list up to discuss other things.

James

[johnjbarton]

On May 19, 4:58 pm, Patrick Mueller <pmue...@gmail.com> wrote:

But you "have to" make require() calls. I don't. You "have to" do a
build. I don't.

I think you are misunderstanding AMD if you think it has
"boilerplate".

jjb


>
> --
> Patrick Muellerhttp://muellerware.org

[Tom Robinson]

On May 19, 2011, at 4:38 PM, johnjbarton wrote:

> On May 19, 4:21 pm, Nathan Stott <nrst...@gmail.com> wrote:
>> I don't get why any build tool is off the table for development. Have
>> you never worked with a language you have to compile?
>
> Yes, a few, like Fortran, C++, C, and Java. Build tools are a relic of
> the past.

Are you saying you don't minify and concatenate your JavaScript files when you deploy client-side JavaScript? I pity your users.

> Is this really
>> such a burden? Apparently it is, but this attitude is still foreign
>> to me. I'll trade not having to write boilerplate by hand for having
>> a build step or having to run a special dev server.
>
> What boilerplate?

Question: what is the bare minimum code necessary in a JavaScript file for that file to be loaded using an AMD loader?

That is boilerplate.

[Tom Robinson]

On May 19, 2011, at 3:55 PM, johnjbarton wrote:

> On May 19, 1:25 pm, Tom Robinson <tlrobin...@gmail.com> wrote:
>> * If you are in favor of AMD as an "authoring format" (I like Chris'
>> name for it) you are not prioritizing interoperability. AMD imposes an
>> implementation detail on developers that make no sense for
>> environments other than the browser.
>
> I'm unclear on what implementation detail you mean here.
> ...

Wrapping modules in an anonymous function that gets passed to another function is 100% an artifact of the requirement that you be able to use script tags to load lazily executed modules. Fact.

Show me one other language that does anything remotely similar.

>> - The features browsers offer for asynchronously loading and
>> evaluating code without using script tags are "good enough" for
>> development, and they're improving.
>
> Script tags are implementation detail. I ported require.js AMD to
> Mozilla gecko using evalInSandbox and it would have worked if the
> Mozilla platform worked.

Of course you *can* implemented AMD without script tags, but as mentioned above, AMD was designed specifically for the script tag use case.

>> - Any issues with the browsers should be considered bugs in the
>> browser as they are likely common problems for web developers, and
>> they should be fixed in the browser.
>
> Yay, something to agree on!

I'm saying any issues with using XHR+eval are browser issues, not spec issues. I don't suspect you'd agree with that.

> ....
>> Regardless of the outcome, I also think RequireJS should change their
>> name and/or implement CommonJS 1.x modules. I absolutely hate that it
>> has co-opted the name "require" and are confusing developers about
>> CommonJS modules.
>
> Ironically we use AMD and don't need the word "require" at all. So
> here I agree!

Great! Change it to define.js or whatever.

-tom

[Wes Garland]

> Anyway, those are just my random thoughts.

These are good thoughts.  We're pretty much on the same page, really. 

I'd like streams returned from fs-base's open function, with both blocking and non-blocking read/write functions.  GPSEE has done quickie-prototypes of the blocking ones; just as much as we needed to do our work.  Passing a file handle to a constructor for a stream type might give us some API options.

I'd like to see us drop the words "sync" and "async". They are not really descriptive. Block and non-blocking aren't right, either. I'm open to suggestions. "with and without callback APIs" or something might be better.

Process vs. system, I don't care, but these aren't necessarily the same thing. I also don't want to see breaking changes on ratified specs if we can help it, changing system to process would be a breaking change.

Console.log is a stupid API name for "print", but it makes sense a debugging interface.  That is, libraries should use "Console.log", but the help for a program should be generated with something else.  That gives us some flexibility.

And, you nailed it, test suites are key.

[johnjbarton]

On May 19, 7:54 pm, Tom Robinson <tlrobin...@gmail.com> wrote:
> On May 19, 2011, at 3:55 PM, johnjbarton wrote:
>
> > On May 19, 1:25 pm, Tom Robinson <tlrobin...@gmail.com> wrote:
> >> * If you are in favor of AMD as an "authoring format" (I like Chris'
> >> name for it) you are not prioritizing interoperability. AMD imposes an
> >> implementation detail on developers that make no sense for
> >> environments other than the browser.
>
> > I'm unclear on what implementation detail you mean here.
> > ...
>
> Wrapping modules in an anonymous function that gets passed to another function is 100% an artifact of the requirement that you be able to use script tags to load lazily executed modules. Fact.

I don't know whether your assertion is correct or not, but let's
assume it is. So what. Browsers work really well with script tags. I
think it prudent engineering to leverage the strongest platform
technology when you are building on top.

>
> Show me one other language that does anything remotely similar.

No other language is relevant. It's not CommonRemotelySimilar.

>
> >>     - The features browsers offer for asynchronously loading and
> >> evaluating code without using script tags are "good enough" for
> >> development, and they're improving.
>
> > Script tags are implementation detail. I ported require.js AMD to
> > Mozilla gecko using evalInSandbox and it would have worked if the
> > Mozilla platform worked.
>
> Of course you *can* implemented AMD without script tags, but as mentioned above, AMD was designed specifically for the script tag use case.

Well I would say AMD allows a number of reasonable and important
implementations. I'm totally puzzled as to why this is bad. All APIs
involve tradeoffs and expose implementation issues. The CommonJS
Modules 1.0 was designed specifically for synchronous loading. Of
course you *can* implement Modules 1.0 asynchronously, but as
mentioned all over this newsgroup, the result is ugly. I just can't
see how AMD using script tags counts is any different.

>
> >>     - Any issues with the browsers should be considered bugs in the
> >> browser as they are likely common problems for web developers, and
> >> they should be fixed in the browser.
>
> > Yay, something to agree on!
>
> I'm saying any issues with using XHR+eval are browser issues, not spec issues. I don't suspect you'd agree with that.

I have no clue why this is important to the subject.

>
> > ....
> >> Regardless of the outcome, I also think RequireJS should change their
> >> name and/or implement CommonJS 1.x modules. I absolutely hate that it
> >> has co-opted the name "require" and are confusing developers about
> >> CommonJS modules.
>
> > Ironically we use AMD and don't need the word "require" at all. So
> > here I agree!
>
> Great! Change it to define.js or whatever.

Sorry, "we" here means Firebug team, we use but don't define
require.js.

I don't think require.js is great. But it works. No one else came
along with a better implementation. We can argue about APIs all day
long, but in the end implementation counts.

From what I've seen Burke has done a lot of reaching out. That
includes using 'require'. It make just as much sense to me for the
server folks to go back to ServerJS as it does for AMD to leave
CommonJS.

I certainly can say I learned a lot from the conversations here,
despite (because of?) disagreements.

jjb

[johnjbarton]

On May 19, 7:38 pm, Tom Robinson <tlrobin...@gmail.com> wrote:
> On May 19, 2011, at 4:38 PM, johnjbarton wrote:
>
> > On May 19, 4:21 pm, Nathan Stott <nrst...@gmail.com> wrote:
> >> I don't get why any build tool is off the table for development.  Have
> >> you never worked with a language you have to compile?
>
> > Yes, a few, like Fortran, C++, C, and Java. Build tools are a relic of
> > the past.
>
> Are you saying you don't minify and concatenate your JavaScript files when you deploy client-side JavaScript? I pity your users.

I am saying that I don't couple deployment choices to my development
model. The Firefox version does not download and it's already in one
file, so minify is not valuable. (You can still pity my users, there
are plenty of other reasons ;-).

>
> >  Is this really
> >> such a burden?  Apparently it is, but this attitude is still foreign
> >> to me.  I'll trade not having to write boilerplate by hand for having
> >> a build step or having to run a special dev server.
>
> > What boilerplate?
>
> Question: what is the bare minimum code necessary in a JavaScript file for that file to be loaded using an AMD loader?
>
> That is boilerplate.

I suspect that you imagine that we wrap our code in
define(["require", "exports"], function (require, exports) {...});
However we do not use require or exports so the overhead is very
similar to Modules 1.0.
define(["beta", "gamma"], function (beta, gamma) { ... return alpha; }


jjb

[Nathan Stott]

jjb,

It is my understanding that the entire point of 'define(..)' syntax is
to support loading in a script tag. What advantages OTHER than
loading in a script tag does it provide in your opinion?

[Wes Garland]

On 19 May 2011 23:40, johnjbarton <johnj...@johnjbarton.com> wrote:

The CommonJS
Modules 1.0 was designed specifically for synchronous loading. Of
course you *can* implement Modules 1.0 asynchronously, but as
mentioned all over this newsgroup, the result is ugly. I just can't
see how AMD using script tags counts is any different.

My only disagreement here is that AMD's breaking change does not involve the use of script tags; it involves a module-evaluation semantic that is a personal preference.

My thinking on the matter is -- let's do Modules.Next which

1. addresses the *needs* of the browser community
2. maintains 100% backwards compatibilty (module one-time machine translation)
3. interoperates 100% with existing server-side loaders and modules, and
4. takes advantage of the change cycle to clarify ambiguities in the original spec

 AMD only addresses #1, whereas I believe #2 and #3 are equally important.

I certainly can say I learned a lot from the conversations here,
despite (because of?) disagreements.

That's certainly true for me, too.

Wes
 

[Wes Garland]

On 20 May 2011 00:12, Nathan Stott <nrs...@gmail.com> wrote:

It is my understanding that the entire point of 'define(..)' syntax is
to support loading in a script tag.  What advantages OTHER than
loading in a script tag does it provide in your opinion?

I won't speak for define(), but module.declare() -- which is similar -- has a another function: it formally declares the dependencies of the module.

I believe that dependency declaration is even more important than the ability to load in a script tag, as it gives the module system an unambiguous way to insure that all dependent modules are loaded before the module is initialized; on the browser, we can't just-in-time-fetch like we do on the server.

Wes

[Dean Landolt]

On Thu, May 19, 2011 at 11:06 PM, Wes Garland <w...@page.ca> wrote:

> Anyway, those are just my random thoughts.

Great list Tom.

These are good thoughts.  We're pretty much on the same page, really. 

I'd like streams returned from fs-base's open function, with both blocking and non-blocking read/write functions.  GPSEE has done quickie-prototypes of the blocking ones; just as much as we needed to do our work.  Passing a file handle to a constructor for a stream type might give us some API options.

I'd like to see us drop the words "sync" and "async". They are not really descriptive.

+1

 

Block and non-blocking aren't right, either. I'm open to suggestions. "with and without callback APIs" or something might be better.

That's not quite right either. You can block and still expose a callback-style API. ISTM it comes down to whether you expect a callback to execute or a value or promise returned. There are shades of gray here too -- you can mix both. For instance, execute the callback if provided or return a promise or value if not (configurable somehow in the call signature). It's not perfect -- you can't take a callback and return a promise on its completion (because you can't know when it's fully unwound), but it's Good Enough and could work as a nice bridge.

 

Process vs. system, I don't care, but these aren't necessarily the same thing.

Where do you see them as different? They house effectively the same information (information about the process itself). ISTM system is misnamed.

 

I also don't want to see breaking changes on ratified specs if we can help it, changing system to process would be a breaking change.

How so? You can still have a system module alias process.

 

Console.log is a stupid API name for "print", but it makes sense a debugging interface.  That is, libraries should use "Console.log", but the help for a program should be generated with something else.  That gives us some flexibility.

I disagree -- it's a very clear name for what it is: diagnostic output. "print", on the other hand, can mean that or writing to stdout. And there's the question of what to do with multiple args (print tends to be join(" "), puts is a join("\n") and console.* can use extra args for string interpolation (which I doubt we'd want on print).

 

And, you nailed it, test suites are key.

Amen.

[johnjbarton]

On May 19, 9:12 pm, Nathan Stott <nrst...@gmail.com> wrote:
> jjb,
>
> It is my understanding that the entire point of 'define(..)' syntax is
> to support loading in a script tag.  What advantages OTHER than
> loading in a script tag does it provide in your opinion?

The define() statement lists the modules we depend upon and their
local scope bindings.

define(array of module names, function (matching local scope bindings)
{ module code; return moduleDefn; };

jjb

[Dean Landolt]

On Fri, May 20, 2011 at 12:12 AM, Nathan Stott <nrs...@gmail.com> wrote:

jjb,

It is my understanding that the entire point of 'define(..)' syntax is
to support loading in a script tag.  What advantages OTHER than
loading in a script tag does it provide in your opinion?

Another advantage is bundling (multiple modules in the same file). Loading arbitrary resources, and with the plugin architecture, parsing and handling those resources. There are more I'm forgetting.

[Jacob Hansson]

Hey all, 

short time lurker, figure I introduced myself sufficiently in the original thread about the separate AMD mailing list. If you didn't read that, I am someone who responds to email lists without knowing what I'm talking about.

On Fri, May 20, 2011 at 12:55 AM, johnjbarton <johnj...@johnjbarton.com> wrote:

On May 19, 1:25 pm, Tom Robinson <tlrobin...@gmail.com> wrote:
> * If you are in favor of AMD as an "authoring format" (I like Chris'
> name for it) you are not prioritizing interoperability. AMD imposes an
> implementation detail on developers that make no sense for
> environments other than the browser.

I'm unclear on what implementation detail you mean here.
...

He means the fact that AMD is based on browser constraints instead of simplicity. 

I think he's right about the multiple module format thing, there is no reason to have several formats for defining modules, only pain. AMD works great as a solution to in-browser loading, but outside that environment it is unecessarily verbose, and doing backwards-incompatible things to the module spec will break all CommonJS modules created so far.

 

>
> The divide here is between people who see AMD as a "transport format"
> that should be generated by a build tool or server, versus an
> "authoring format" that should include hand-written async definition
> boilerplate.

I don't agree with this characterization. A build tool is completely
off the table for me. I would not consider any module loading scheme
that requires a build tool. So for me the divide is build too or no
build tool.

See below.

 

>
> * From what I understand the argument for AMD as an "authoring format"
> boils down to this:
>
>     - Some browsers have problems reporting filename and line numbers
> for exceptions and during debugging for code though "eval"/"new
> Function()" that they don't have with code evaluated though script
> tags.
>     - In some cases you might want to load a module using a script tag
> without having to minify/wrap/bundle it.

Any build step is unacceptable during development.

When I build Java apps I have build tools, my Rails projects benifit awesomely from auto-recompiling build tools, so does my Django projects, and when I build JS-apps I use a build stack that auto-compiles CoffeeScript and HAML, as well as run behaviour and unit tests for me.

Even the smallest projects need build tools to run their test suites. I can literally not concieve of a situation where I would not want an automated development and production build setup for a project.

Needing build tools for the dependency management in the browser will, in my mind, force even beginners to use build tools, which I think is a good thing.

 

>
> * My arguments for AMD as a "transport format" (and I believe many
> people agree with me) are:
>
>     - We may be stuck with this module spec for awhile (5+ years until
> ECMA specs modules, browsers implement them, and the vast majority of
> users upgrade?), so it should be forward-looking, not held back by
> legacy issues with browsers that are rapidly going away.

In the many discussions about CommonJS Wes defended the opposite. He
wants legacy going forward and would not budge on this issue.

>     - It should be suitable for both browsers and server-side environments.
>     - A tool or server should be used to minify, wrap, and bundle your
> client-side code for deployment anyway.
>     - Boilerplate sucks and should not have to be written by hand. It
> should be considered an implementation detail.

What is this boilerplate thing you are talking about ? The list of
modules?

Ok it sucks that the the modules names are not JS argument names. So
we have to list the module names *and* the argument names. But really
its not that big of deal.

Actually, (and this is just my personal experience), this has been one of the primary sources of bugs since I started using AMD. On a daily basis I end up misaligning the dependency list and the definition list, and the result bugs are sometimes extremely confusing.

 

>     - The features browsers offer for asynchronously loading and
> evaluating code without using script tags are "good enough" for
> development, and they're improving.

Script tags are implementation detail. I ported require.js AMD to
Mozilla gecko using evalInSandbox and it would have worked if the
Mozilla platform worked.

>     - Any issues with the browsers should be considered bugs in the
> browser as they are likely common problems for web developers, and
> they should be fixed in the browser.

Yay, something to agree on!

....

> Regardless of the outcome, I also think RequireJS should change their
> name and/or implement CommonJS 1.x modules. I absolutely hate that it
> has co-opted the name "require" and are confusing developers about
> CommonJS modules.

Ironically we use AMD and don't need the word "require" at all. So
here I agree!

+1

 

jjb

--
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.

--
Jacob Hansson
Phone: +46 (0) 763503395
Twitter: @jakewins

[rektide]

On May 17, 4:46 pm, Wes Garland <w...@page.ca> wrote:
"Speaking only for myself, what I am not interested in is platforms
which do
not interoperate well with existing CommonJS implementations and
libraries."


"So the question is: is it better to try and work together, or should
we all
go off and do our own thing and see what emerges as a common standard
N
years down the road.
Personally, I work better in a group than alone. The differing
perspectives
are very useful. "
-- Wes also

Wes, the impression that I get when comparing these two statements is
that you like working in a group, as long as the group agrees with
what's already been done, which, coincidentally perhaps in this case,
is work done by you.

This strikes me as stagnant stasis cruft. CommonJS ought be a group
for all people seeking formalization, & seeking to build common specs,
not just a group to reconfirm and pat each other on the back with the
specs they've already put out.

Modules is woefully insufficient as it stands. It's vile that anyone
would wish to kick people coming in and seeking to make the situation
better (AMD). It may not be the problem space you particularly
envisioned, but CommonJS ought be a banner for all JS people seeking
to bridge the gaps in JS, all implementations seeking to create
interoperable javascript application environments. AMD definitely
unquestionably falls under this banner, and it's repulsive that
CommonJS would be so hardline as to say they dont have a role,
particularly given the imminent possibilities of writing wrappers/
boilerplate for interoperation.

I've posted in the amd-implementer thread: Kriszyp's AMD module spec
ought be removed from CommonJS.org if you are unwilling to accept
incompatible specs. -1 from me on this specific change and this
general principle of inflexible stasism: the group dynamic would be
better served by being condusive to differing outside voices and
perspectives.

[Wes Garland]

On 23 May 2011 14:56, rektide <rek...@gmail.com> wrote:

Wes, the impression that I get when comparing these two statements is
that you like working in a group, as long as the group agrees with
what's already been done, which, coincidentally perhaps in this case,
is work done by you.

Actually, Modules/1.1.1 is largely *not* my work.
 

Modules is woefully insufficient as it stands.

This does not mean that it needs to be thrown out.  It means that it should it be improved upon.  I believe that this improvement must maintain backwards compatibility.

I have shown that it is possible to address the technical flaws in Modules/1.1.1 with a solution that maintains backwards compatibility. This solutions borrows work from AMD and other sources. I believe that such a solution (not necessarily the one I have proposed) is the right way forward.

Frankly, arguing over details of a module solution for CommonJS is a waste of time, IMHO. There is lots more important work to be done on top of the base. So, let's stick with the base modules system we have, address the technical flaws, and move on with the real work we started on.. You know, before we wasted the last year arguing about module systems.
 

It's vile that anyone would wish to kick people coming in and seeking to make the situation
better (AMD).  

If you believe that this is what has happened, then I suggest you need to re-read the content of this newsgroup.

1) James Burke is the one who suggested splitting off AMD
2) James Burke has been largely "my way or the highway".  (Not that there's necessarily anything wrong with that -- if he really believes that breaking change is necessary then this is the only vehicle he can use)
3) There is exactly one aspect of AMD that I am aware of that I believe makes it unsuitable as a module transport or CommonJS super-set.   That one detail, late- vs early-evaluation of modules is a compatibilty issue, and it is James Burke's personal preference that it is a breaking change.

It may not be the problem space you particularly
envisioned, but CommonJS ought be a banner for all JS people seeking
to bridge the gaps in JS, all implementations seeking to create
interoperable javascript application environments.

And why would we even *think* of promoting a specification which isn't compatible with... CommonJS?

Wes