views:

572

answers:

5

JavaScript frameworks like Prototype, jQuery, YUI, MooTools, Dojo, et al. all seem to target client-side developers, with the focus on enabling common user interaction patterns to be implemented more efficiently and with less code.

With the emergence of server-side JavaScript, do these frameworks intend to incorporate the CommonJS standards to enable reuse of their library functions for server-side JavaScript, or will they allow alternative frameworks like Node and Narwhal to handle the server-side use case?

(I realize that this question is dangerously close to one which can be discussed but not answered, but I presume the Stack Overflow community can actually answer the question with specific references.)

+4  A: 

Since most of those libraries specifically target the DOM and are designed to simplify browser APIs and cross-browser issues, I'm not sure what advantage this would give.

CommonJS support is not expected in jQuery 1.4. It is also not on the jQuery 1.5 Roadmap.

Dojo does endeavor to be more all-encompassing and has an issue open about adding support for CommonJS in Dojo but it is marked as future.

In general, I wouldn't count on it.

Michael Greene
+1  A: 

Like everyone has already said, most JavaScript libraries are wrappers on the DOM for the most part.

However, I would not consider CommonJS only for server side. I think there will be a place for it on the client side, especially as Javascript moves towards an improved security model that would greatly benefit from a CommonJS approach to modularization.

Kris Walker
+2  A: 

Most of the CommonJS APIs are server-oriented features you simply wouldn't be able to implement in browser JS. Of the current modules, io, fs, system, sockets and worker plus JSGI et al are unimplementable by their basic nature.

encodings would need enormous data tables that you wouldn't want to build into a library (except for the basic built-in encodings that you can already handle quite well as it is). Other features can't be supported simply because they would need language features like getter/setters that can't be used in the browser yet due to poor support.

All those discounted, I'm not sure if there's really anything much left. The require plumbing?

bobince
To me, one point is to be able to share business logical (model objects and their validation, etc.) between client and server. That pretty much just requires the modules support.You're certainly correct that most of the standard does not apply to the browser.
Kevin Dangoor
+1  A: 

The way I view what we're doing with CommonJS is that we want to be able to make modules that are part of larger systems that run both client side and server side. I've already personally worked with two different client side CommonJS module loaders, and it works just fine.

In the browser, you can use whatever DOM manipulation library/client side toolkit you want, and that won't really interfere with the ability to also re-use CommonJS modules from the server.

Reusing the client side utilities on the server may actually still work as well. CommonJS modules all have their code run in a closure, so that each module is something independent of the other modules. Browser-based libraries tend to work with namespaces that are populated globally. Thus far, every CommonJS platform on the server can still use globals in one fashion or another.

As long as the library itself is made to support environments without a DOM (such as Rhino), it should be possible to make it work in a typical SSJS environment, albeit not in CommonJS-modules.

Kevin Dangoor
A: 

I can't find the source, but I've heard jQuery 1.4 is going to have all plugins in its packaged as CommonJS packages (http://wiki.commonjs.org/wiki/Packages/1.0). This doesn't mean they will all be CommonJS modules, but it's a step in the right direction and a sign that things are moving that way.

There is a Narwhal package that implements a subset of Prototype: http://github.com/smith/prototype-asp/tree/narwhal-global. It also runs on other SSJS platforms.

There's a ticket open on the Dojo Trac to add CommonJS Module support: http://bugs.dojotoolkit.org/ticket/9349

SproutCore, the framework that has Bespin and MobileMe, among others, will also support CommonJS: http://wiki.sproutcore.com/Tiki, and 280 North, the makers of Cappuccino, employ some of the main Narwhal developers.

So, there's still lots of fragmentation between different frameworks and between client and server, but it's early and things are moving in the right direction. I predict sometime in the future all major JS frameworks will have some CommonJS support on the client, server, or both.

Nathan L Smith
http://groups.google.com/group/commonjs/browse_thread/thread/39dcdede35edcddd is the source you were probably referencing. jQuery 1.4 and 1.4.1 have already been released without any CommonJS structure -- but the team running the jQuery plugins site seems to have put their weight behind CommonJS for packaging.
Michael Greene