On Tue, May 17, 2011 at 3:45 AM, Tom Robinson <tlrobin...@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.
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.
> 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:
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:
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.
> 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
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@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
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.
On Tue, May 17, 2011 at 1:10 PM, Tom Trenka <ttre...@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.
On 17 May 2011 16:10, Tom Trenka <ttre...@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
-- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
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.
On 17 May 2011 17:12, Tom Trenka <ttre...@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
-- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
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.
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.
> 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.
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?
On Tue, May 17, 2011 at 3:03 PM, Mikeal Rogers <mikeal.rog...@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.
On 17 May 2011 18:59, James Burke <jrbu...@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
-- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
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.
On Tue, May 17, 2011 at 6:11 PM, Wes Garland <w...@page.ca> wrote: > On 17 May 2011 18:59, James Burke <jrbu...@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
> -- > Wesley W. Garland > Director, Product Development > PageMail, Inc. > +1 613 542 2787 x 102
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
On Tue, May 17, 2011 at 10:09 PM, Nathan Stott <nrst...@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.
On Tue, May 17, 2011 at 2:20 PM, James Burke <jrbu...@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.
> On Tue, May 17, 2011 at 2:20 PM, James Burke <jrbu...@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.
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
On May 18, 3:47 pm, Kris Walker <kixxa...@gmail.com> wrote:
> 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:
> > On Tue, May 17, 2011 at 2:20 PM, James Burke <jrbu...@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.
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
On Wednesday, 2011-05-18 at 23:54 , Eugene Lazutkin wrote: > 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
> On May 18, 3:47 pm, Kris Walker <kixxa...@gmail.com> wrote: > > 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:
> > > On Tue, May 17, 2011 at 2:20 PM, James Burke <jrbu...@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.
> -- > You received this message because you are subscribed to the Google Groups "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to commonjs+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
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).
-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:
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.
> 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
-- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
(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.
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.
Wes
-- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
