

CommonJS effort sets JavaScript on path for world domination - baxter
http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars

======
cbetz
Javascript is my favorite language, but building very large systems composed
of interdependent modules is still very tricky and everybody does it
differently (especially when you leave the browser and talk about the various
server-side JS offerings).

The problem is that various ECMAScript standards committees never really
considered "programming in the large". The CommonJS project is important
because it aims to fill this gap and create a real JS ecosystem by:

1) Creating a standard for interoperable modules that handles scoping (i.e.
module X can't mess with module Y) AND dependency resolution. 2) Attempting to
define a set of standard APIs for binary data, files/sockets [streams], and
anything else that you might want in a good standard library.

I encourage everyone who writes a lot of JS to join the CommonJS discussion
group. Currently, the module API spec is mostly complete (and there are a good
number of working implementations). The hot topic now is the Binary data API,
which is extremely important because it will be used as a base for all
subsequent modules that want to manipulate binary data.

~~~
Maciek416
You bring up some good points. The next ECMAScript standard seems to be aiming
for some programming-in-the-large goals (though the new features may not be
enough to satisfy everyone).

A couple months ago I saw some discussion about CommonJS on es-discuss which
signaled that there is actually some influence flowing from CommonJS towards
the new ECMAScript standard, with Brendan Eich briefly mentioning some of
CommonJS' features. The ES committee is watching and learning from what is
going on in the wild, and there is some overlapping consensus now on how JS
can improve with regards to programming-in-the-large. This is a very good
thing.

I'm curious how well and how quickly all these new server-side JS systems
(nodejs, commonJS, V8, etc) will react to the upcoming new ES5. It now seems
likely that JS coders will get to try out ES5 a lot sooner on the server-side
than on the client-side, given how long it will take (forever-ish) for ES5 to
be adopted in browsers.

~~~
kriskowal
CommonJS is tracking ES5. For the time being, we vaguely suggest that all
compliant implementations must support all features of ES5 that are
implementable or stubbable with existing JavaScript features. For example,
Object.freeze can be implemented as a stub no-op so people are free to use the
API in their modules, and get the feature when it's supported. The intent is
to eventually make ES5 compliance a requirement.

------
jerf
The biggest problem with "Javascript on the server" right now is that
Javascript has no concurrency story whatsoever. You could easily hack in
shared-state threading, but there would be no faster way to turn me off of
Javascript forever than to do that. You could hack in message-passing, but it
won't be clean and you're still going to have terrible fun trying to not pass
mutable references, which, again, if you leave that in I will run screaming.
STM isn't exactly going to be easy to stick in either.

(I say I will "run screaming" not merely because I don't want to deal with it,
but because I don't want to deal with yet more libraries based on shared-state
concurrency. No. I've left that behind and I'm not going back, and certainly
not in a space where I've got an abundance of languages to choose from.)

Without a solution to that problem, I see this as a terribly, terribly wrong
move, and a terrible time for JS to try to be picking up the server. Servers
are _in_ the multicore age and have been for a couple years now.

(And if your answer is "well, we'll just keep all the tasks simple and we
won't need multiple threads", I would remind you that you're running _on the
server_ , which often needs to do, you know, _actual work_. A language that
can't do that may have a small niche, but it's going to be an uphill battle
against entrenched competitors.)

~~~
rictic
One solution that will almost certainly get implemented is WebWorkers. From
that you get string-only message passing (though it'd obviously be easy to do
json-encoding of data in messages) between js processes.

That, combined with event based non-blocking apis for managing multiple tasks
neatly covers more or less everything you can do in many other mainstream
languages like Python and Ruby (excluding some magic in native code
extensions).

~~~
jerf
That makes some sense. I would agree that it should be optimized to specify
that JSON-able objects should be passable in such a way that it is if they are
being fully serialized out to strings then deserialized again, giving the
implementation the ability to do some optimization (which may or may not be a
good idea but you'd have to try it to find out, best not to write yourself
into a corner), but actually doing that in a library would be easy enough.

Given the way that JS performance has been moving, that would indeed be able
to take on quite a workload, if you can run a decent number of "webworkers" at
a time.

------
tmikew
This is kind of cool, but who is going to digest all of it? The techno folks
may have some technology pieces working, but nobody out in the main world
would be able to figure it out. I got a little dizzy just looking at all the
links to all the pieces in just this one article. Let alone actually reading
them all.

I like Java script but I think making it go server side is backwards. Why not
make Python or Perl or Ruby go client side instead? (I am sure plenty of folks
smarter than me have already thought about and probably worked on it.) Those
languages already have all the parts they need except a connection to the
browser dom. Java script has a connection to the dom and practically nothing
else. These other languages have been getting tweaked for years on the server
side. It just seems like such a big byte to get Java script to work as a
regular language like the others. It also ignores some of the things that are
lurking like Erlang and Clojure. It sounds correct that there are lots of Java
script programmers. However are there lots of Java script _only_ programmers?
I doubt it. While it is compelling to write one language every where, I dream
about it sometimes, we aren't close yet.

So embedding the Perl, or whatever, interpreter into the browser is probably a
chore, but it is also probably doable, the browser should be able to deal with
multiple languages. I think it is just that the people that are capable of
doing that job looked at it and said. "Crap! I will just learn Java script."
So the reality in my mind is that programming in two or three or four
languages is just easier than doing all that other work. Everybody does it. In
fact we say I know Java, or Python, or Java script, but that is just a word to
give us a frame of reference when we communicate with each other. In fact what
we really know is how to program computers and Python is a subset of the total
global programming skill that I have. It is a like speaking English in some
specific domain. There is jargon everywhere, one can speak English but one
tends to get easily lost if one listens to lawyers speak to each other or
doctors, and one is also not a doctor or a lawyer. Does that mean we should
create a generalized English that both doctors and lawyers can use in each of
their specific domains? Seems a little silly when one thinks about it. Is
making Java script work everywhere is really buying all that much?

~~~
sant0sk1
Going the other direction (moving server-side languages into the browser) is
simply not feasible with the current rate of browser development and adoption.
It would be at least 5 years with a concentrated effort to accomplish such a
task.

~~~
boucher
Disagree. Every month we're seeing a new "X to JavaScript" compiler, and
increasingly they are being written natively in JavaScript.

------
shimon
What I want is an extension for my web framework that transparently pre-
renders certain Javascript-generated parts of the page, and then sends the
browser a serialized version of that page that includes not only DOM structure
but fully wired-up event handlers.

This should be possible using HTML and <script> tags, but will take some
serious work to become plausibly cross-browser. But if that work happens,
there will be a way to automatically provide the usability/speed benefits that
previously required dual client & server implementations without the attendant
cost. And that will drive a lot of people to using whatever standards those
tools are built on.

------
pquerna
I'm glad the JSGI spec is fleshing out, the web connector API will allow many
more frameworks to get started easily, rather than forcing Javascript
programers to hack on java or C to build a webserver first.

Once JSGI is done, it really will allow the experimentation you see from Rack
and WSGI in the respective Ruby and Python worlds.

I guess its about time to update my old mod_v8 to support jsgi :D
<http://news.ycombinator.com/item?id=408707>

------
emilis_info
The CommonJS module system is really a step forward.

For the last two months I've been developing a webapp on Helma NG and I like
it very much. Parts of the framework fit together nicely. The community on IRC
is very helpful and provides answers in the rare cases where source code and
documentations is not enough.

I also want to praise the project developers for their code quality -- even
though I use a version from git I haven't had a single problem with frequent
updating and re-building it.

------
azgolfer
Funny that no one seems to mention that IIS runs JavaScript (aka JScript) on
the server, and has since the beginning.

~~~
swolchok
No one seems to _care_.

~~~
kamau
Too bad. I guess we'll just reinvent the wheel again simply because we don't
like who invented it last time.

