New amd-implement list
James Burke
JavaScript module loader that supports the Asynchronous Module
Definition (AMD) API:
https://groups.google.com/group/amd-implement
Follow that list if you have questions about implementing a JS loader
that supports AMD, or if you are interested in those types of
discussions. First discussions on the list will likely be around
relative ID module resolution and establishing a set of compatibility
tests.
I created a separate list since AMD has not been agreed upon on this
list, but there are enough implementers now that we need to coordinate
more, and I wanted to spare this list that noise.
James
Tom Robinson
> --
> 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.
>
James Burke
> Great. How about just removing "CommonJS" from the name of your spec and using "AMD" only?
Can you elaborate? I am not sure how to parse your comment.
The amd-implement list is for hopefully mundane implementation
questions that I thought would be noisy for this list. I can bring
back any API issues to this group for discussion. So far the API has
been stable.
If you think it best to have the amd-implement threads on this list, I
can point people over here.
James
Tom Robinson
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.
Jacob Hansson
--
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
Jacob Hansson
On Tue, May 17, 2011 at 12:45 PM, Tom Robinson <tlrob...@gmail.com> wrote:On May 12, 2011, at 7:10 PM, James Burke 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.
> On Thu, May 12, 2011 at 1:10 AM, Tom Robinson <tlrob...@gmail.com> wrote:
>> Great. How about just removing "CommonJS" from the name of your spec and using "AMD" only?
>
> Can you elaborate? I am not sure how to parse your comment.
>
> The amd-implement list is for hopefully mundane implementation
> questions that I thought would be noisy for this list. I can bring
> back any API issues to this group for discussion. So far the API has
> been stable.
>
> If you think it best to have the amd-implement threads on this list, I
> can point people over here.
I may be missing context here, so I apologize if that is the case.The landing page for CommonJS.org states, as I'm sure you know, "The intention is that an application developer will be able to write an application using the CommonJS APIs and then run that application across different JavaScript interpreters and host environments".It goes on to list a set of different environments, leaving out the main environment JS is used in.AMD is a proposal for an alternative module API that supports all environments. Why does it not deserve to be considered and discussed as a standard proposal on the same level as any other?
--
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
Wes Garland
AMD is a proposal for an alternative module API that supports all environments. Why does it not deserve to be considered and discussed as a standard proposal on the same level as any other?
The single most important building block of CommonJS is a common module system. You can't have multiple incompatible ways to load modules in a uniform environment.
We have considered Modules/1.1.1 at length. I, and many others in this group, are of the opinion that all (including future) CommonJS module systems must be able to interoperate with Modules/1.1.1 either directly, or via trivial machine translation (i.e. adding a declaration wrapper).
The whole point of CommonJS is to be able to create and share modules, and write portable programs. We cannot do either of these things with multiple, incompatible module systems.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
rektide
> Great. How about just removing "CommonJS" from the name of your spec and using "AMD" only?
Numerous people here seem to think its antithetical to have different
packaging formats (ignoring that they're easily wrapperable). If
CommonJS is "not interested in is platforms which do not interoperate
well with existing CommonJS implementations and libraries", the onus
is on CommonJS to reject and kick out the violating interlopers, not
on people trying to cooperate voluntarily leaving.
I'm very unhappy some trenchant stasists are trying to exclude people
seeking to join your organization, people seeking formalization and
spec'ing. Asking people to voluntarily leave is even more cowardly.
If you don't want AMD I think you need to kick them out by force, not
kindly ask them to go somewhere else. Remove AMD from the
CommonJS.org page please.
Mikeal Rogers
there isn't, it's a mailing list of volunteers without formal structure.
you're saying "kick them out", who exactly would be kicking them out?
rektide
Does anyone think the consensus is different?
Kris Kowal
> AMD just got voted off the island. I'll make the wiki edits myself.
> Does anyone think the consensus is different?
There is not consensus.
Kris Kowal
rektide
Tom Robinson
The problem isn't with AMD (at least not the older versions), it's the idea that AMD should be an authoring format. If you recall, AMD was originally called the "Transport" spec, and of course was intended purely as a transport format. Over time new people joined the list, made their modifications to make it suitable as an authoring format, and finally renamed it to AMD. I have always strongly expressed my disapproval with this direction, but it seems to have had zero effect. My comment was snarky and trolling, and I didn't seriously expect anything to come of it, but it seems to have had more effect than any of my previous arguments...
Tom Robinson
There will never be consensus in a debate that's open to new participants.
Can we call that Robinson's Law? Or maybe just CommonJS's Law.
The moment we think we have consensus someone new will arrive and debate the same points all over again. I've seen it happen dozens of times here.
khs4473
There will never be consensus in a debate that's open to new participants.
johnjbarton
On May 24, 1:02 am, Tom Robinson <tlrobin...@gmail.com> wrote:
> The problem isn't with AMD (at least not the older versions), it's the idea that AMD should be an authoring format.
rejection. I urge you to take an open mind.
I think AMD should be the authoring format. While it was proposed by
Burke, in my view this outcome was discovered by the CommonJS groups
collective action.I came into CommonJS expecting to use Modules 1.1,
but in the end, AMD is the solution that makes sense.
AMD supports module loading across platforms, the goal of a common JS.
The syntax is "declare-first", not boilerplate. The factory function
in AMD is just a function that returns the export. So all of the
module structure right at the top of the file where we declare the
dependencies and their local bindings. It's a very clear and straight
forward model.
If you have not written code using AMD (without require/exports/etc),
try it. Yes, it makes some module code incompatible and I don't know
the best path for that code. But for the vast amounts of script tag
code are yet to be converted to modules I think AMD is a good choice.
I believe new participants offer new solutions because the goal of the
group is so compelling and the divide is so obvious. Everyone wants to
find a way to the goal or produce the compelling argument that unites
the group. It's a noble goal, but one, I fear, that is out of reach.
jjb
Nick Carter
When this thread (and the other) started, I did feel as though J Burke was under some sort of attack, after having only recently started making use of RequireJS myself, and enjoying it. Just wanted to say I appreciate the perspective.