12

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.)

Jeff Hammerbacher
  • 4,226
  • 2
  • 29
  • 36
  • 1
    The libraries you mention all wrap the DOM api. I don't understand the question of re-using those libraries on the server, when the server does not incorporate an actual DOM like what the browser provides. I'm maybe not being imaginative enough? – Crescent Fresh Jan 04 '10 at 15:03
  • @Crescent Fresh you are right it would be useless but maybe he likes to use functions like jQuery.each ? – JCasso Jan 04 '10 at 15:08
  • The Native component of MooTools augments some built-in constructors to give them increased functionality unrelated to the DOM (http://github.com/mootools/mootools-core/tree/master/Source/Native/); I was wondering about bringing that sort of stuff into SSJS. – Jeff Hammerbacher Jan 04 '10 at 15:09
  • 1
    http://stackoverflow.com/questions/1909615/why-would-i-want-to-use-server-side-javascript/1910089#1910089 answers alot of question people might have about SSJS. I use JS server side with ASP. Works like a charm and I can't recommend it enough. No DOM stuff but you can write some very clean, sexy code with it. Mootools now do a server side only download too with extensions to Array, String, Function, Events (yes server side events work!), Class, Hash etc. Well worth a look. – Pete Duncanson Jan 05 '10 at 11:13
  • 1
    For more on how MooTools plans to incorporate CommonJS, see http://groups.google.com/group/mootools-users/browse_thread/thread/7c117cae98607ab6 – Jeff Hammerbacher Jan 06 '10 at 00:53

8 Answers8

5

Here's my take (I'm a YUI Developer):

It seems like there are two angles to your question.

One is about module packaging and reuse formats (CommonJS) and the other is about the general idea of client side JS libraries and their applicability to server side development.

I'm not really the right person to answer the packaging angle, other than to say that YUI 3 inherently has used a formal module system for encapsulating and delivering code since day one, and it's been integral to it's design. Providing an adaptor or build step to deliver/translate these modules to CommonJS is something we've been discussing. Other folks in the YUI community who have been involved in this area may have more valuable information to add here.

On the second angle, I can tell you that the server is a first class target environment for YUI. It is just as applicable on the server as on the client. There are a set of modules which only make sense in one environment or the other of course, but a large chunk of the library, can be used on both sides of the fence and it is consciously built to do this.

For example, a large chunk of the modules in YUI provide infrastructure and utilities which are just as applicable to app development on the server as on the client (Custom Event, Attribute, Base, Intl, Handlebars, IO, YQL, DataType, DataSchema, JSON etc...).

That's really been the design goal from the start - It's a web (for lack of a better term - I'm referring to the JS/HTML/CSS technology stack) application development library, not just a DOM Abstraction Library, or just a Widget Library.

Dav Glass has a blog post with some great content on the subject:

http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/

You can also check out the 3.5.0 PRs:

http://stage.yuilibrary.com/yui/docs/yui/nodejs.html

Satyen Desai
  • 51
  • 1
  • 1
4

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
  • 1,588
  • 11
  • 10
3

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
  • 10,343
  • 1
  • 41
  • 43
2

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
  • 897
  • 1
  • 8
  • 14
2

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
  • 528,062
  • 107
  • 651
  • 834
  • 1
    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 Jan 05 '10 at 12:49
2

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
  • 183
  • 2
  • 4
  • 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 Feb 08 '10 at 03:35
0

There is a case for using CommonJS along with the DOM when you're talking about *non-*browser GUI applications, where operating system access would not need to be as restricted. For example, this would be very useful for developing an application using Mozilla Chromeless.

user4815162342
  • 2,058
  • 3
  • 18
  • 23
0

Just a quick update to say, looks like the long awaited (er, fabled) mootools 2.0, aka milk, aka prime (last name for it for now) has moved over to CJS.

https://github.com/mootools/prime

this is not to say it will remain as such, the first iteration of mootools 2.0 came about nearly 2 years ago.

Dimitar Christoff
  • 26,147
  • 8
  • 50
  • 69