Will existing JavaScript frameworks incorporate CommonJS?

Question

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

Answer 1

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

Answer 2

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.