Relevancy of CommonJS (Re Mikeal's trolling post)

[Kris Walker]

Quoting Mikeal:

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.

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?

/endquote

Following and participating in this list from time to time has helped
me wrap my head around a cross platform module loading framework
better than I ever could have on my own. This is not about forcing
things down developer's throats, but about working together to think
through common problems.

I understand the reasoning behind the core Node.js community pushing
hard to do what is best for that platform. I'm working hard on a
network infrastructure based on Node.js and I really appreciate the
work of Ryan and the Node.js devs for making this possible.

However, in a World where browser based clients are getting thicker,
mobile devices are networked, and Node.js can implement a workable
HTTP push architecture with very little effort, I've been increasingly
surprised with the amount of code sharing between server and browser.
Also, as @Issacs mentioned on the Node.js list, it requires a lot less
brain power to use the same programming environment on both sides of
the network. I loathe working with Django, Rails, or Drupal these
days.

So, for the work I'm doing I have my own module loader for Node.js
which will load Modules 1.1 or Modules 2.* based off of Wes' work. I
also have a build process driven by Node.js which lets me require my
scripts from within a browser, and then it compiles a singular JS
minified blob for production. This works great, because the same
Node.js server works for both the development environment and
production cluster.

And, can people please stop complaining that the browser is a second
class citizen? The people who actually believe that are far and few
between. For the most part we all care tremendously about the
browser... without it most of our products would never be used!

Is this list irrelevant? Well, it is *not* to me. Thanks everyone for
being so willing to share your thoughts so openly on cross platform
JS. It has helped me tremendously and I hope to be pounding this
wonderful architecture with millions of customers and contributing
back here and to Node.js all along the way.

[Mikeal Rogers]

the work is relevant, but the work is happening outside of this list.

binary and better numbers, for example, are being worked on by a collection of people from node.js, mozilla, TC-39 and the v8 team. not to mention a bunch of experimental projects on GitHub that are driving it forward.

Modules, outside of AMD, are where they need to be for most people and continue to be implemented. But, non-standard additions like module.exports are being implemented widely, which was added by node. The CommonJS list tried to standardize that addition and hit a dead end.

i don't know what value this list is providing by "standardizing" new proposals. the work is important which is why it's happening, but the relevant work is happening elsewhere which makes me ask the question "does a proposal like AMD or better binary gain more or less traction and adoption by being hashed out on the CommonJS list?".

a standardization process usually balances a collection of implementors and users to create a formal specification that, at some point, is *finished*. the relevant parties are, unfortunately, no longer at CommonJS and are doing this work out in the great javascript community. also, the CommonJS list has resisted all attempts at formalization which makes "finished" specification impossible.

organizations rarely decide to shut their doors regardless of how far they drift from the problem space they were created to solve so i doubt this list will ever stop doing this work, but the question of relevance is an important one for anyone who wants to bring new work here.

the discussions here are fiercely academic and move significantly slower than the experimental implementations we see on GitHub. there is a thiving javascript community that is doing great work, it's speed is unrivaled by almost any other community i know of. in *that* community the question of relevance is a prerequisite and the proposals gain prominence by their adoption rather than buy in from a small collection of stake holders on a mailing list.

after reading my previous email i'm afraid i came off as though i was trolling AMD, i'm not, i'm questioning the relevancy of CommonJS as an organization, not the work it's attempting to take on which is obviously important.

a common set of tools and apis for javascript across platforms will emerge, but in order for it move forward in a speedy and healthy way it's going to happen elsewhere.

[Wes Garland]

> i'm questioning the relevancy of CommonJS as an organization, not the work
> it's attempting to take on which is obviously important.

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.

Maybe I'm just not tall enough to see as far as I'd like to, without standing on the shoulders of giants.

Wes

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

[Mikeal Rogers]

together implies that the relevant parties are here to work with, i contend that they are not precisely because the structure and incentives of doing the work at CommonJS are out of alignment with the rest of the javascript community and those parties are finding it more productive to do the work elsewhere.

we *are* working together. there is a reason i invited Alex Russell to the NodeCommit meeting and had Brendan come up on stage for the panel at NodeConf. we're building bridges and working together, CommonJS just isn't a part of it.

[Wes Garland]

Great!

What is the mailing list I need to get on to help design the APIs I'm interested in?

Or am I just not cool enough to be allowed to help?

[Mikeal Rogers]

I don't think there is a place for a list to discuss APIs without implementation. I think that growing experimental implementations, iterating on them as they are used and incorporating feedback from as wide an audience as possible. But that audience needs to be using them, not commenting on the idea of them.

The way to create the future is not through endless bikeshedding on a mailing list by people who are not using or implementing anything. That may sound harsh, but I know that you can write code to express your ideas. You certainly have the ability to do more than reply on an email list Wes.

[Wes Garland]

> I know that you can write code to express your ideas. You certainly have the ability
> to do more than reply on an email list Wes.

Are you actually implying that this is all I do?

In case you are, to be clear, I am a working programmer and spend a significant proportion my time working on or with JS, often in very non-browser environments. And I have been working as a programmer for a very long time.

And yet, I still find it useful to confer with others in order to try and arrive at a standard way to do things across our platforms.  I consider portability to be a very important piece of the overall puzzle.

[Vlad Dascalu]

Our aim is similar with the task W3C had when developing the HTML
standard, so we can learn from their history. When IE was basically
the market incumbent with 90%+ marketshare, the W3 folks might have
felt the same way about their work, mainly because there were little
incentives for players to obey standards (the MSIE folks had no
interest in them and the other folks were too little to matter) -
http://www.w3.org/History.html .

As competition and new players emerged, the interest for standards
spiked. I think a similar thing will happen with SSJS.

Besides waiting the right spot in the timeline of things, there are
other actionable things we can do in order to improve our
effectiveness:

-> create and promote compatibility tests. There's nothing even
closely equivalent to ACID tests in SSJS, and there's nothing more
popular and brand-effective for W3 standards compatibility than the
ACID tests. What's even better, these kind of tests are used by
vendors as badges, which promotes the standardization and works as a
social indicator for people choosing a no-lockin vendor platform.

-> merge existing systems instead of designing new ones. We want to be
the Torvalds, not the Minixes of JS. Writing academic emails about the
best way to get something done which is modular, allows several ways
of being used and interfaced with etc is great, except for one thing:
no implementation will exist when the spec is done, and nobody will be
able to use it. Let's follow the success we had with things like JSGI:
find a working example, find parallelisms in other working solutions,
contact those people, aim for merging their production specs and
produce a unified standard based on working systems.

-> aim for the leaders. Let's spend some time writing comparative, 2-
column articles about how things work in RingoJS and NodeJS. Let's see
the differences, let's see where things are done the same way. Ignore
event-driven versus multithreaded, that's not going to change since
Ryan and Java folks just see things differently there. But there's so
many other things we can implement. Make the dream of running SSJS
code unmodified on both RingoJS and NodeJS true, and the specs will
emerge from there. How do you do files I/O? How about SQL? The answer
is already in the working implementations out there, it just needs to
be standardized. That's where our efforts should be spent.

It might be more grungy work that way rather than designing clean
things from a blank sheet of paper. But I think there's no greater joy
than writing a SSJS CommonJS module and seeing it run in NodeJS and
RingoJS without modifications, not even when it's compared to
designing new clean things without any working implementation.

My 2 cents
Vlad - http://www.erbix.com

[Mikeal Rogers]

No, i'm saying *you* were implying that this was all you do by suggesting that losing a mailing list would mean you have no place to drive the work forward.

This list is not the only place to confer with your peers. I you want to confer about portability it's better to confer with users of other environments, which are increasingly *less* represented here.

I appreciate the work you do Wes, I just think all of it would be more successful without this list.

[Wes Garland]

On 19 May 2011 16:30, Mikeal Rogers <mikeal...@gmail.com> wrote:

This list is not the only place to confer with your peers. I you want to confer about portability it's better to confer with users of other environments, which are increasingly *less* represented here.

I appreciate the work you do Wes, I just think all of it would be more successful without this list.

While it's true that there are people on this list whose input I generally do not value, there are some members whose input I value greatly.

If I ever find that this list has a negative effect on my overall productivity, I will unsubscribe. I don't need you to tell me when that is.

Wes

[Mikeal Rogers]

this is an interesting metaphor if you expand the historical record a bit.

after HTML4.1 was finished the W3C did a *ton* of work and almost all of it has faded in to obscurity. they created spec after spec with very few implementors, in particular browser vendors, involved. they faded so far from the reality of the web that the vendors nearly abandoned them entirely.

then the WHATWG started, which was a collection of *implementors* who were essentially comparing implementation notes in order to define interoperable standards. this grew and grew until it became HTML5 and the W3C asked that the work return there and created a few groups that were far more open than the traditional W3C working groups in order to appease the WHATWG members.

what I'm trying to say is that CommonJS has become a lot like the W3C in those days. as much as there is *talk* of interoperability the actual implementors seem to be lacking.

[Mikeal Rogers]

that's fair. after this thread is concluded i'll remove myself from the list and stop bugging people doing additional work here.

but i won't be stopping the work that i'm doing with regards to interoperable javascript, and i'll continue to build bridges between communities to further that work.

this whole outburst comes from my own frustration with realizing that one of those bridges can't be CommonJS because relevancy is so undervalued, which puts it at odds with other communities.

[Dean Landolt]

Can you elaborate on this a bit? I too would like to see moar codez and all, but I don't see that as a CommonJS problem. What do you think an appropriate solution looks like? What does your WHATWG look like? I'd love to know, and I'll help any way I can to bring this about. But would Ryan even give a damn? I sincerely doubt it. And that's alright -- it's part of node's charm.

Ryan continues to maintain that it's too early for standards. Perhaps he's still right. But when he's not what will the landscape look like? I know I can write interoperable code today -- it's a PITA and I don't expect everyone to bother walking that minefield. But I don't think things will be any better when I have to target a handful of frankennodes and their inevitable idiosyncracies.

So maybe the name CommonJS is a misnomer. Maybe it's an impossible goal. But it's not a goal I'd want to give up any time soon. If you have opinions or suggestions about how to further that goal, speak up. Either here or in some other forum, but I'm unaware of another such forum.

[Tom Robinson]

On Thu, May 19, 2011 at 12:12 PM, Kris Walker <kixx...@gmail.com> wrote:

> Is this list irrelevant? Well, it is *not* to me. Thanks everyone for
> being so willing to share your thoughts so openly on cross platform
> JS. It has helped me tremendously and I hope to be pounding this
> wonderful architecture with millions of customers and contributing
> back here and to Node.js all along the way.

Agreed. Many good ideas have been prototyped or built into useful
projects, and personally I've learned a *lot* from participating.

The original idea of CommonJS spec-ing out tons of APIs on a public
mailing list was probably flawed, but I believe it has at least gotten
people talking, and if there are more appropriate places to finish the
work then great. I care about the end result, not whether CommonJS is
considered "irrelevant".

That said, I think modules one area we can and should continue to
pursue. It's the one thing that *every* JavaScript platform needs.
ECMA is slow to standardize stuff, browsers are slow to implement it,
and users are even slower to upgrade their browsers. Eventually it
will be replaced by ECMA/Harmony/Simple/whatever modules, but I don't
see that happening soon.

If what Mikael says is true about Node disregarding CommonJS modules
completely and making incompatible changes, well, that sucks. I hope
there are people in the Node community who think interoperability is a
worthy goal and can act as ambassadors.

-tom

[Mikeal Rogers]

If we continue Modules work here, where does it go? What does it like look when it's finished?

Is it done now? Probably not, but we don't have any process to know when "done" is. The answers are more obvious when you're talking about code and adoption, but here they are aren't.

For instance, your own arguments against AMD suggest that you feel, and I agree, that the basic module format has solidified and, for better or worse, can't be changed at this point in a reverse incompatible manor. But there is nothing stopping those kinds of changes because "finalizing" a CommonJS proposal and getting a version number doesn't really mean much.

So of course people think they should bring up new proposals that break compatibility, why not? The fact that it's unlikely to be adopted isn't a factor here.

Node has solidified it's module format, it won't take breaking changes at this point. Breaking changes still appear to be on the table at CommonJS.

Node is making additions to the API offered for modules based on what the perceived needs of it's users is. That's healthy. Why would they do that here? Why would they listen to stakeholders so far away from their users? CommonJS can't even agree on a good solution to module.exports, why bet the future on node modules on this list? It's not that node doesn't care about interop, it just doesn't think that the best route to it is this list, so they will drive forward on improving modules for their users and consider changes that help interoperability at the behest of those communities (browser frameworks, RingoJS, etc), not CommonJS.

Other implementations seem to be tracking the additions made by node so they are probably doing something right.

[Dean Landolt]

On Thu, May 19, 2011 at 5:39 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

If we continue Modules work here, where does it go? What does it like look when it's finished?

Is it done now? Probably not, but we don't have any process to know when "done" is. The answers are more obvious when you're talking about code and adoption, but here they are aren't.

For instance, your own arguments against AMD suggest that you feel, and I agree, that the basic module format has solidified and, for better or worse, can't be changed at this point in a reverse incompatible manor. But there is nothing stopping those kinds of changes because "finalizing" a CommonJS proposal and getting a version number doesn't really mean much.

This is a very good point.

 

So of course people think they should bring up new proposals that break compatibility, why not? The fact that it's unlikely to be adopted isn't a factor here.

Node has solidified it's module format, it won't take breaking changes at this point. Breaking changes still appear to be on the table at CommonJS.

Node is making additions to the API offered for modules based on what the perceived needs of it's users is. That's healthy. Why would they do that here? Why would they listen to stakeholders so far away from their users? CommonJS can't even agree on a good solution to module.exports, why bet the future on node modules on this list? It's not that node doesn't care about interop, it just doesn't think that the best route to it is this list, so they will drive forward on improving modules for their users and consider changes that help interoperability at the behest of those communities (browser frameworks, RingoJS, etc), not CommonJS.

Other implementations seem to be tracking the additions made by node so they are probably doing something right.

Do you have any examples offhand? I suspect other implementations won't adopt be adopting the node_modules convention any time soon :-/

[Mikeal Rogers]

agreed, i doubt node_modules will be adopted outside of node. but, as the spec stands now, the way names are resolved to modules is not specified. we're stayed away from that on purpose so that systems that don't have a filesystem can be supported (like CouchDB).

module.exports is widely used. it's in CouchDB and a few others i've seen.

[Tom Robinson]

By "pursuing" modules I really mean we should try to drive adoption of
what we already have, maybe making the occasional tweak or addition to
reflect the needs of platforms and users of those platforms.

I agree with many of the issues you mentioned. Personally I was pretty
content with Modules 1.1.1. I am against those breaking changes in
both CommonJS and Node, unless there's a good reason that everyone
agrees on.

This is another reason I believe AMD should be a "transport format"
that has no bearing on the basic module spec. It's causing these kinds
of problems. If it were merely a transport format Node and every other
non-browser platform could ignore it completely.

I think there is significant overlap between the people interested in
CommonJS and Node users. I'm one, as are many others. Chances are if
Node needs a new feature in modules then other platforms will too,
thus we should work with them to add it to the specs.