[nodejs] CommonJS
Alexander Teinum
relationship to the CommonJS work that's going on. I'm not currently
involved with the development of either one, so there might be some
information that I have missed.
There's a discussion on this mailing list about what a variable should
be named in node.js that contains the directory name of a module. If
there's a goal for node.js to be CommonJS compliant, then it would be
a good choice to stick to what's in the CommonJS spec.
As I understand it, the spec is still being discussed, and if someone
doesn't like some of it, such as the directory name variable -- then
one could discuss that in the CommonJS mailing list.
I'm just asking if there's a goal for node.js to be as CommonJS
compliant as possible? Knowing that would make it simpler to make API
decisions.
--
Best regards,
Alexander Teinum
inimino
of official node policy...
On 2010-01-22 06:20, Alexander Teinum wrote:
> I couldn't find a post in the mailing list specifically about
> node.js' relationship to the CommonJS work that's going on. I'm not
> currently involved with the development of either one, so there might
> be some information that I have missed.
The people most closely involved with CommonJS are developers of
other SSJS projects. The ties between node and CommonJS are
weaker, but there are active discussions going on to bring node
and CommonJS closer together where that makes sense. There will
probably be more of this in the future than there has been to
date, as other SSJS systems adopt approaches pioneered by node
and as node matures and APIs start to stabilize.
> I'm just asking if there's a goal for node.js to be as CommonJS
> compliant as possible? Knowing that would make it simpler to make
> API decisions.
CommonJS compatibility is good, but "as compliant as possible"
would be an overstatement.
If a particular CommonJS spec has significant adoption then node
is likely to support it, but what is best for node and its users
always takes precedence.
Ryan Dahl
> I couldn't find a post in the mailing list specifically about node.js'
> relationship to the CommonJS work that's going on. I'm not currently
> involved with the development of either one, so there might be some
> information that I have missed.
I generally support the CommonJS idea, but let's be clear: it's hardly
a specification handed down by the gods (like ES5); it's just some
people discussing ideas on a mailing list. Most of these ideas are
without actual implementations.
If we can do something better, then we should. So, I'll take
CommonJS's ideas, and adopt them if it seems like the best idea, but
they're hardly time-tested or well thought-out. Implementations must
drive specifications - not the other way.
As for the directory name of a module - the reason for debate is that
I'd like to remove the global "module" variable. It's too common a
name, and I think we're already polluting the global namespace enough.
__filename, __dirname actually actually quite functional and nice - I
think the two underscores are a bit much though - one would be enough.
Alexander Teinum
Alexander
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Kris Kowal
> I generally support the CommonJS idea, but let's be clear: it's hardly
> a specification handed down by the gods (like ES5); it's just some
> people discussing ideas on a mailing list. Most of these ideas are
> without actual implementations.
>
> If we can do something better, then we should. So, I'll take
> CommonJS's ideas, and adopt them if it seems like the best idea, but
> they're hardly time-tested or well thought-out. Implementations must
> drive specifications - not the other way.
To be clear, CommonJS has various "efforts" that are in different
stages. Most of them are in "proposals" or "discussion", and those
are the one's you're going to hear about the most on the mailing list.
Others are "implemented" and "ratified". Generally ratification only
occurs when *all* of the participating CommonJS implementors have
implemented or are committed to implementing the proposal. That's why
there are so few ratified proposals (as of today, Modules/1.1,
Unit_Testing/1.0, System/1.0, Packages/1.0). Promises, Binary,
FileSystem, and many others have not achieved consensus so there's not
reason to target them, but there is plenty of reason to pursue,
iterate, and make new proposals.
NodeJS and CommonJS's goals are well aligned. We don't ratify
proposals if we don't think they're good for the users of every
implementation. We're all insightful, responsible, and passionate
people and generally the designs that we ratify are better than the
first proposals *and* existing implementations. Most implementors
started by implementing the first idea they had and lived with it or
iterated it until it's barely acceptable; that caused fragmentation
that hindered the sharing of code.
CommonJS is here to make it possible to have, for example, an md5
module using a common binary API, unit tests, and implemented in
pure-JavaScript that can be shared among implementations, irrespective
of all the ways that the various CommonJS engines opt to embrace and
extend. It's a strict subset of all participating projects. NodeJS
should participate. If it doesn't like a spec, someone involved with
Node needs to stick their nose out and make CommonJS
counter-proposals. It's a lot of work, but to do less would be
anti-social.
Whatever CommonJS has produced, or how little it has produced, the
success of CommonJS does not depend on what it has done, but by how
hard we are willing to work to make our systems interoperable. It is
not sufficient to have the best API. We create multiplicative value
for our users if they are not locked-in to any one of our engines.
Embracing CommonJS has already enabled code to flood into the NodeJS
ecosystem. I guarantee multiplicative benefits to users as we work
together going forward. I for one consider Ryan a citizen of
CommonJS, albeit our newest; if he or his representative vetoes a
proposal, it's not ratified. We can't do this without you.
Kris Kowal
George Moschovitis
> module using a common binary API, unit tests, and implemented in
> pure-JavaScript that can be shared among implementations, irrespective
> of all the ways that the various CommonJS engines opt to embrace and
> extend. It's a strict subset of all participating projects. NodeJS
> should participate. If it doesn't like a spec, someone involved with
> Node needs to stick their nose out and make CommonJS
> counter-proposals. It's a lot of work, but to do less would be
> anti-social.
+1
-g.
Neville Burnell
> I for one consider Ryan a citizen of
> CommonJS, albeit our newest; if he or his representative vetoes a
> proposal, it's not ratified. We can't do this without you.
+1
Nathan
mailing list members seem a bit hostile towards CommonJS. I don't
really understand it. Maybe it's just because I'm on the outside of
the community looking in. However, I look forward to using Node and
getting to know the community better.
Andy
> Embracing CommonJS has already enabled code to flood into the NodeJS
> ecosystem. I guarantee multiplicative benefits to users as we work
> together going forward. I for one consider Ryan a citizen of
I agree, since Narwhal and Node use the same module system, I have
been able to reuse code between the two quite easily. That's a big
accomplishment. Once packages converge a bit more, we'll be in even
better shape.
Thanks for all your work on CommonJS!
Andy
Kris Kowal
On Fri, Jan 22, 2010 at 5:20 AM, Alexander Teinum <ate...@gmail.com> wrote:
> There's a discussion on this mailing list about what a variable should
> be named in node.js that contains the directory name of a module. If
> there's a goal for node.js to be CommonJS compliant, then it would be
> a good choice to stick to what's in the CommonJS spec.
>
> As I understand it, the spec is still being discussed, and if someone
> doesn't like some of it, such as the directory name variable -- then
> one could discuss that in the CommonJS mailing list.
On Fri, Jan 22, 2010 at 10:05 AM, Ryan Dahl <coldre...@gmail.com> wrote:
> As for the directory name of a module - the reason for debate is that
> I'd like to remove the global "module" variable. It's too common a
> name, and I think we're already polluting the global namespace enough.
> __filename, __dirname actually actually quite functional and nice - I
> think the two underscores are a bit much though - one would be enough.
I'm favoring the approach of keeping "module" for the name space of
such things as "module.id" and "module.uri". I propose that we add
"module.path" and "module.directory" as optional properties in the
next minor revision of the modules specification.
* module.id // required
* module.uri // optional
* module.path // optional
* module.directory // optional
Alternately, we would have to break backward compatibility, probably
by advancing the semantic version to "2.0", removing the "module"
object and providing alternate facilities for:
* what is presently module.id (_id?, ID?)
* module.uri (_uri?, URI?)
* what could be module.path (_file?, __FILE__?)
* what might be module.directory (_directory, _dirname? __DIR__?)
* the (require.main == module) idiom we fought long and hard about.
In any case, I think that Modules/1.1 has played out well in the
Narwhal implementation at least and the "module" variable has not been
onerous. The objective advantage to keeping the "module" object
around is that we can feature test properties with simple property
getters instead of the typeof expression.
Kris Kowal
Benjamin Thomas
> As for the directory name of a module - the reason for debate is that
> I'd like to remove the global "module" variable. It's too common a
> name, and I think we're already polluting the global namespace enough.
> __filename, __dirname actually actually quite functional and nice - I
> think the two underscores are a bit much though - one would be enough.
I don't see how taking one global variable (module) and making it many
other global variables (__filename, __dirname) is a good solution to
not polluting the global namespace.
Personally, I think it makes sense for all properties about a module
to live under one namespace. If we are concerned about using 'module'
as this variable because people might want to use it then maybe it
should be _module? So, you'd say:
_module.filename
_module.id
_module.dirname
Then it is obvious exactly which scripts filename and dirname are
referring to. currently, you could think that __filename is the name
of the original script that was run. Granted it takes you all of 30
seconds to figure it out, this new way is much more obvious.
Kris Kowal
---------- Forwarded message ----------
From: Donny Viszneki <donny.v...@gmail.com>
Date: Sat, Jan 23, 2010 at 10:59 PM
Subject: Re: [CommonJS] Re: [nodejs] CommonJS
To: comm...@googlegroups.com
On Sun, Jan 24, 2010 at 1:13 AM, Kris Kowal <cowber...@gmail.com> wrote:
> On Fri, Jan 22, 2010 at 10:05 AM, Ryan Dahl <coldre...@gmail.com> wrote:
>> As for the directory name of a module - the reason for debate is that
>> I'd like to remove the global "module" variable.
>
> Alternately, we would have to break backward compatibility, probably
> by advancing the semantic version to "2.0", removing the "module"
> object and providing alternate facilities for:
>
> * what is presently module.id (_id?, ID?)
> * module.uri (_uri?, URI?)
> * what could be module.path (_file?, __FILE__?)
> * what might be module.directory (_directory, _dirname? __DIR__?)
> * the (require.main == module) idiom we fought long and hard about.
Moving the properties of the "module" variable to the top level module
scope is lame, and makes the namespace collision problem worse, not
better.
If the problem is namespace pollution, why don't we just commit to
putting everything under a single variable? Easy enough to import
variables you want.
> In any case, I think that Modules/1.1 has played out well in the
> Narwhal implementation at least and the "module" variable has not been
> onerous. The objective advantage to keeping the "module" object
> around is that we can feature test properties with simple property
> getters instead of the typeof expression.
Agreed. We need at least one variable we can call our own.
--
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
Jonas Pfenniger
> a specification handed down by the gods (like ES5); it's just some
> people discussing ideas on a mailing list. Most of these ideas are
> without actual implementations.
I'm happy you think that. A good example is the Module spec,
which isn't easily implementable in the browser. One promise of
CommonJS is to be able to share code between browser and server
but at the same time they seem eager to loose backward-compatibility
that browsers impose. I hope more effort will be put in that sense.
> As for the directory name of a module - the reason for debate is that
> I'd like to remove the global "module" variable. It's too common a
> name, and I think we're already polluting the global namespace enough.
> __filename, __dirname actually actually quite functional and nice - I
> think the two underscores are a bit much though - one would be enough.
In the cases you want a module variable, you can just alias the original
variable. If you remove module, where would you put all it's childs ?
--
Jonas Pfenniger (zimbatm) <jo...@pfenniger.name>
bryanwb
> Embracing CommonJS has already enabled code to flood into the NodeJS
> ecosystem. I guarantee multiplicative benefits to users as we work
> together going forward. I for one consider Ryan a citizen of
> CommonJS, albeit our newest; if he or his representative vetoes a
> proposal, it's not ratified. We can't do this without you.
>
> Kris Kowal
+1
I have been using narwhal for a while now for writing utility scripts.
Now i am just getting started w/ node.js. Being able to reuse tools
from narwhal w/ node.js is very, very compelling for me. Also, narwhal
has a really sweet package manager in tusk. I don't know if node has
something comparable.
Christoph Dorn
I generally support the CommonJS idea, but let's be clear: it's hardly
a specification handed down by the gods (like ES5); it's just some
people discussing ideas on a mailing list. Most of these ideas are
without actual implementations.
If we agree that *interoperability is a good thing* then we need a forum for implementers to discuss ideas. CommonJS is such a place where server-js implementers from various backgrounds and experience discuss ideas to arrive at the best possible solution for everyone involved. With sufficient discussion the fundamental elements of a given solution can be flushed out and consensus reached. This may look like a slow and tedious process, and at times can be, however the resulting consensus creates value well beyond the effort put in by participants.
I understand that NodeJS (Ryan et al.) has only recently started participating in CommonJS (not discounting the CommonJS folks who are participating in NodeJS). I am also a relative newcomer to the process. It has been a steep learning curve for me but my efforts are paying off big time now. I chose to build on top of narwhal to build firefox extensions. Many modules I use in the extension I also use on the server. At this time on rhino, but looking forward to moving to NodeJS once we have an engine for narwhal. Oh and some of the same modules can also deploy to the browser without modification. Together with a toolchain automation system I am building the CommonJS standards have allowed me to rapidly build a complex system without loosing oversight.
I have found CommonJS to be a well organized group of people with high standards and drive to get things right. Most questions get answered and backed up with posts from prior discussions if applicable in a timely fashion. New ideas that make sense spawn new discussions that compare and contrast to existing specs/proposals. An example of this is the "async all the way" case that NodeJS is making (correct me if I am wrong).
If we can do something better, then we should. So, I'll take
CommonJS's ideas, and adopt them if it seems like the best idea, but
they're hardly time-tested or well thought-out. Implementations must
drive specifications - not the other way.
I have designed many frameworks in the past and made many good and not so good decisions in the details. What I have learned is that it is better to have a few things important to you your way (assuming you can justify them) in a platform that is used by many people vs having many things your way in a platform you need to maintain yourself with a limited userbase. Compromises are inevitable but they also shift the burden of responsibility which allows you to focus.
May I urge that the same criteria, insight, diligence and effort used to judge internal solutions be used to evaluate/judge CommonJS accomplishments. A lack of understanding of the rationale behind solutions is no excuse for dismissing pillars of consensus arrived at in the past. You will find CommonJS solutions are justified and where they are not in light of new information they are open for a new round of discussions. That is the entire point of CommonJS.
As for the directory name of a module - the reason for debate is that
I'd like to remove the global "module" variable. It's too common a
name, and I think we're already polluting the global namespace enough.
__filename, __dirname actually actually quite functional and nice - I
think the two underscores are a bit much though - one would be enough.
Strictly speaking, multiple free variables pollute more than a single one. If the objective is minimal pollution then the least possible number of variables should be used. Also going from one variable to several by adding sugar (module.file -> __filename) makes for a cleaner design than the other way around. If an implementation such as NodeJS wants to pride itself by having useful variables available in the global scope I think the only responsible way to go about it is to offer it on top of a CommonJS base to allow developers to run NodeJS modules on other CommonJS platforms where the same sugar can be applied.
My 0.02 cents.
Christoph
[1] - https://mail.mozilla.org/pipermail/es-discuss/2010-January/010551.html