现有的JavaScript框架是否会包含CommonJS?

以下是我的观点(我是YUI开发人员):

你的问题似乎有两个角度。

我并不是回答打包角度的合适人选,除了说yui3从第一天起就使用了一个正式的模块系统来封装和交付代码,而且它已经成为它的设计的一部分。提供适配器或构建步骤来将这些模块交付/转换为CommonJS是我们一直在讨论的问题。在YUI社区中参与过这个领域的其他人可能有更多有价值的信息可以在这里添加。

在第二个角度,我可以告诉你服务器是YUI的一级目标环境。它同样适用于服务器和客户端。当然,有一组模块只在一个或另一个环境中有意义,但是库的很大一部分,可以在围栏的两边使用,而且它是有意识地构建的。

从一开始,这就是设计的目标——它是一个web应用程序开发库,而不仅仅是一个DOM抽象库,或者只是一个小部件库。

Dav Glass有一篇关于这个主题的博文,其中有一些很棒的内容:

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

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

我对CommonJS的看法是,我们希望能够制作出模块,这些模块是同时运行客户端和服务器端的大型系统的一部分。我已经亲自使用过两个不同的客户端CommonJS模块加载器,它工作得很好。

在浏览器中,您可以使用任何您想要的DOM操作库/客户端工具包,这不会真正影响从服务器重用CommonJS模块的能力。

在服务器上重用客户端实用程序实际上也可以工作。CommonJS模块的代码都在一个闭包中运行,因此每个模块都是独立于其他模块的。基于浏览器的库倾向于使用全局填充的名称空间。到目前为止,服务器上的每个CommonJS平台仍然可以以某种方式使用globals。

只要库本身是为了支持没有DOM的环境(比如Rhino),就可以在典型的SSJS环境中工作,尽管不是在CommonJS模块中。

jQuery1.4不需要CommonJS支持。它也不在 jQuery 1.5 Roadmap .

Dojo确实努力做到更全面,并且有一个问题是公开的 adding support for CommonJS in Dojo 但标记为 .

一般来说,我不会指望它。

正如大家已经说过的,大多数JavaScript库在很大程度上都是DOM上的包装器。

,我不会只考虑服务器端的CommonJS。我认为js的安全性将从普通的js模式中得到很大的改进。

大多数commonjsapi都是面向服务器的特性,您根本无法在浏览器JS中实现。在当前模块中, io , fs , system sockets 和 worker

encodings

所有的折扣,我不确定是否真的有什么剩余。这个 require 管道工程?

我找不到源代码,但我听说jQuery1.4将把所有插件打包成CommonJS包( http://wiki.commonjs.org/wiki/Packages/1.0 ). 这并不意味着它们都将是CommonJS模块,但这是朝着正确方向迈出的一步,也是事情朝着这个方向发展的迹象。

http://github.com/smith/prototype-asp/tree/narwhal-global . 它也运行在其他SSJS平台上。

Dojo-Trac上有一个问题需要添加CommonJS模块支持: http://bugs.dojotoolkit.org/ticket/9349

http://wiki.sproutcore.com/Tiki 卡布奇诺的生产商North 280,雇佣了一些主要的独角鲸开发者。

因此,在不同的框架之间以及客户机和服务器之间仍然存在大量的碎片,但这还为时过早,事情正在朝着正确的方向发展。我预测将来某个时候所有主要的JS框架都会在客户端、服务器或者两者上都有一些通用JS支持。

Mozilla Chromeless .

只是一个快速更新说,看起来期待已久的(呃,传说中的)mootools 2.0,又名牛奶,又名prime(现在的姓)已经转移到CJS了。

https://github.com/mootools/prime

这并不是说它将保持原样,mootools2.0的第一次迭代大约在2年前。