Re: [amd-implement] Re: NodeJS AMD support (was Re: [requirejs] mootools future support to AMD modules!)

165 views
Skip to first unread message

John Hann

unread,
Jul 22, 2011, 3:54:50 PM7/22/11
to amd-im...@googlegroups.com
Thanks Rawld.  I am glad to be one of your "friends".  Seriously.

And thanks for creating this group, James!

</bromance>

FWIW, node.js is now buildable on windows. I've seen some screenshots even. :)

What you wrote still rings true, for the most part, anyways.  I'm doing my part to promote AMD and I think we've got a great chance of winning the hearts of the web app dev community.  

node.js/CommonJS seems like a nasty place to be atm.

Should we approach the Narwhal or Ringo committers?

-- John

P.S. I need to catch up on some of the standard plugin API stuff you guys wrote about.  Brian Cavalier and I just got finished deploying an AMD+IOC-based app and have some very interesting observations about plugins and how they could be adjusted a bit to better participate in the build process.  Looking forward to re-entering the discussion! 

On Fri, Jul 22, 2011 at 3:26 PM, Rawld Gill <rg...@altoviso.com> wrote:
I agree with James.

Also, since we're among friends...

While node is awesome, some of the design decisions they have made are naive
in the extreme. Chief among them are failing to provide native support for the
most popular (by a wide margin) OS...windows. It's clear to me that there is a
bit of an echo chamber in that community (and, even more so, CommonJS).

If RequireJs, Curl, dojo, bdLoad, and others are able to capture the browser
mind share, we will have at least an order of magnitude higher adoption than
node.

If someone else builds a node.js-like system that works universally across
platforms; they will likely eclipse node quite quickly.

Remember, the key advantage to node is V8...there's nothing particularly
enlightened or new about an event loop.

Lastly, we (us AMD implementers) could completely rewrite node's loader to
include AMD properly and completely; this could also be a route.

I think we're coming close to completing "AMD 1.0". We have a few decisions to
left to make. Then we can write a solid spec. Once that's done, we'll have
some really solid, implementations that are adopted in the large. It will be
hard for anybody that wants to remain relevant to resist that.

In many ways, we are like a start-up company. The way we get power is to build
a good product and get customers. If we just keep doing what we're doing...we
will win.

Best,
Rawld




On Friday 22 July 2011 11:53:07 James Burke wrote:
> On Fri, Jul 22, 2011 at 11:36 AM, busticated <itsbus...@gmail.com>
wrote:
> > fwiw, it seems like there's some desire to drop even the half-step
> > they took towards AMD:
> > http://groups.google.com/group/nodejs-dev/browse_thread/thread/c084c613c4
> > cb9363?hl=en
>
> I have thought about replying on that list, but think I will wait a
> bit, let them talk about it a bit amongst themselves, and I encourage
> the rest of us to do the same.
>
> The last thing they probably need at this point in the discussion is
> people outside their community trying to "vote it up".
>
> James



--
@unscriptable {
    .John {visibility: visible; height: inherit; width: inherit;}
    .John .phone::mobile { content: '617-797-7679'; }
}


Kris Zyp

unread,
Jun 20, 2011, 4:35:09 PM6/20/11
to requ...@googlegroups.com, amd-im...@googlegroups.com
Assume you saw that Node added limited support for AMD as well about a
week ago:
https://github.com/joyent/node/commit/9967c369c9272335bb0343558673b689725c6d7c
Note that with this NodeJS only supports AMD in the single argument
(factory) form, but still I believe that is huge step forward for
interoperability.
Kris

On 6/20/2011 2:28 PM, Miller Medeiros wrote:
> RT @unscriptable Oh nice! MooTools 2.0 on the road to AMD too! http://bit.ly/jTq3CW (via @astolwijk) #js #modules #yay
>
> as James said before: "AMD is winning" ( http://tagneto.blogspot.com/2011/04/on-inventing-js-module-formats-and.html )

busticated

unread,
Jul 22, 2011, 2:36:23 PM7/22/11
to amd-implement
agreed. i'd love to see node embrace AMD if only so i don't have to
worry about module formats and such (disclaimer: bit green on this
stuff).

fwiw, it seems like there's some desire to drop even the half-step
they took towards AMD:
http://groups.google.com/group/nodejs-dev/browse_thread/thread/c084c613c4cb9363?hl=en

On Jun 20, 1:35 pm, Kris Zyp <kris...@gmail.com> wrote:
> Assume you saw that Node added limited support for AMD as well about a
> week ago:https://github.com/joyent/node/commit/9967c369c9272335bb0343558673b68...
> Note that with this NodeJS only supports AMD in the single argument
> (factory) form, but still I believe that is huge step forward for
> interoperability.
> Kris
>
> On 6/20/2011 2:28 PM, Miller Medeiros wrote:
>
>
>
> > RT @unscriptable Oh nice! MooTools 2.0 on the road to AMD too!http://bit.ly/jTq3CW(via @astolwijk) #js #modules #yay
>
> > as James said before: "AMD is winning" (http://tagneto.blogspot.com/2011/04/on-inventing-js-module-formats-an...)

James Burke

unread,
Jul 22, 2011, 2:53:07 PM7/22/11
to amd-im...@googlegroups.com
On Fri, Jul 22, 2011 at 11:36 AM, busticated <itsbus...@gmail.com> wrote:
> fwiw, it seems like there's some desire to drop even the half-step
> they took towards AMD:
> http://groups.google.com/group/nodejs-dev/browse_thread/thread/c084c613c4cb9363?hl=en

I have thought about replying on that list, but think I will wait a

Rawld Gill

unread,
Jul 22, 2011, 3:26:02 PM7/22/11
to amd-im...@googlegroups.com
I agree with James.

Best,
Rawld

James Burke

unread,
Jul 22, 2011, 4:21:16 PM7/22/11
to amd-im...@googlegroups.com
On Fri, Jul 22, 2011 at 12:26 PM, Rawld Gill <rg...@altoviso.com> wrote:
> I agree with James.
>
> Also, since we're among friends...

I think Node is making good progress, particularly with Windows. I
certainly enjoy it.

I also appreciate that they want to make sure they have a minimum
amount of code to support, so adding AMD may seem like more of a
support burden than what they want to do, particularly since the
support they have now is a bit limited, and they could get continued
asks for more support. But I do believe supporting AMD in node does
continue to give them an advantage with server development since JS
web developers can transfer their code and knowledge easier.

While some of the more vocal people in the node community can see JS
dev through a narrow server-side bent, and I wish they could see more
of the larger JS picture, it is definitely within their right to limit
their outlook. For a server person that has sync IO in a homogenous JS
environment, I can appreciate browser loading looks scary and complex,
and easy to dismiss because of that.

Hopefully they will see some value in supporting some part of AMD, but
if not, as Rawld says, we just have to focus on solving the real
problems and pleasing devs. The requirejs r.js node adapter gives full
AMD + plugin support in node, and I know the Dojo loader can do so
too, so there are options for server side AMD.

To me the heartening part of that nodejs thread was that they added
some support because they keep being asked about it. I certainly do
not press the issue with them, and I do not believe the rest of the
AMD loader implementers do either, so my impression is the demand is
coming from real users. We just have to keep delivering, stay positive
if the node community asks for input, and it will take of itself.

James

Reply all
Reply to author
Forward
0 new messages