我为什么选择mootools,抛弃了prototype. (mootools与prototype 核心代码分析)

我为什么选择mootools,抛弃了prototype. (mootools 与 prototype 核心代码分析)


===========================================
前言
===========================================

最近喜欢上了mootools(相见恨晚啊),在公开表示了对他的偏爱.
很多朋友都问我为什么要移情别恋,其实理由还是蛮多的.

今天在这里打算列举出一部分.让更多的朋友能够了解一下mootools,也希望有更多的朋友喜欢上他.


文章的标题注定了我会更多的讲述 mootools比prototype好的地方,
希望大家不要被我的误导,以为mootools处处都比prototype好.
mootools还是有一些不足的.


本次对比针对 mootools 1.11版 和 prototype 1.51版,
只比较了一些核心代码,其他的工具方法,辅助函数不再本文讨论之内.


开始前,再次重申一遍:我曾经很爱prototype,而且我将永远都会用"伟大"来形容它.


好 下面对比正式开始 (
mootools以下简称moo.
本文所引用的代码, 只是起到说明作用,不保证他们都可以被正确的执行.
同时为了使本文简洁一些,引入的 一些 moo和prototype的代码也只是片段或是伪代码.
)

===========================================
一. 类机制
===========================================


js里的类实际上就是function.
如果不使用任何框架和组件,那么想创建一个自己类也不是难事,方法如下:

var PersonClass=function(name,gender){
	this.name=name;
	this.gender=gender;
	alert("My name is "+this.name);
}

var myGirlFriend=new PersonClass('Vickey','female');

执行 后, 会创建一个PersonClass类的实例myGirlFriend, 并执行function内的语句.
那些语句可以理解为是类的构造函数.



Prototype
现在来看看在prototype的帮助下如何去定义这个类:

var PersonClass = Class.create();

PersonClass.prototype.initialize=function(name,gender){
	this.name=name;
	this.gender=gender;
	alert("My name is "+this.name);
};

var myGirlFriend=new PersonClass('Vickey','female');

//如果想给类增加属性和方法时使用 
PersonClass.prototype.XXX=...;
//或者是使用 prototype提供的 
Object.extend(PersonClass.prototype, {...} );

(关于Object.extend稍后在对比继承机制时再细说.)


再来看看prototype是实现类机制的核心代码.

var Class = {
  create: function() {
    return function() {
      this.initialize.apply(this, arguments);
    }
  }
}

通过看代码不难看出,prototype的Class实际上只是帮助我们抽象出了"类的构造函数".
而当我们在prototype的这种机制下进行类的定义时,实际上带来的好处是非常有限的.
prototype的Class只是从结构对我们的类进行了重新规划. 而这样的规划意义并不是很大.
而且prototype带有强制性,即, initialize 是必须要定义的.
实际上这里存在一个缺陷, Class应该提供一个默认的initialize(一个空函数就好),
或者是在create返回的function里进行必要的判断.
(prototype1.6的类机制变化比较大,但是还没仔细研究过,所以不敢轻易评论).


Mootools

现在来看看在 moo的帮助下如何去定义一个类:

var PersonClass = new Class( {
	initialize: function(name,gender){
		this.name=name;
		this.gender=gender;
		alert("My name is "+this.name);
	}
});
var myGirlFriend=new PersonClass('Vickey','female');

其中类的 initialize 不是必须的.
如果你想给 PersonClass 增加属性和方法,你可以在new Class的参数里直接以 json方式定义.
也可以使用 如下方式

PersonClass.implement ({ 
	age:0 ,
	getName : function() {return this.name;}
} , {...}, ..... );

implement支持多个{}.关于implement稍后在对比继承机制时再细说.


在来看一下moo类机制的一些核心代码.

var Class = function(properties){
	var klass = function(){
		return (arguments[0] !== null && this.initialize && $type(this.initialize) == 'function') ? this.initialize.apply(this, arguments) : this;
	};
	$extend(klass, this);
	klass.prototype = properties;
	klass.constructor = Class;
	return klass;
};

Class.prototype = {
	extend: function(properties){
		var proto = new this(null);
		for (var property in properties){
			var pp = proto[property];
			proto[property] = Class.Merge(pp, properties[property]);
		}
		return new Class(proto);
	},
	implement: function(){
		for (var i = 0, l = arguments.length; i < l; i++) $extend(this.prototype, arguments[i]);
	}

};

代码的具体原理就不细说了.大家在moo的Class里看到了 extend 和implement,那下面就来具体说一说moo和prototype的 继承机制吧.


===========================================
二. 继承机制
===========================================

Prototype
prototype提供的继承很简单.

Object.extend = function(destination, source) {
  for (var property in source) {
    destination[property] = source[property];
  }
  return destination;
}

他只是把source里的属性赋给destination,同时会覆盖destination里的同名属性.
他可以用于对象,也可以用于类,当要实现类的继承时,destination要使用 MySubClass.prototype.

prototype的继承机制可以说是非常薄弱的.


Mootools

moo提供了三种继承机制:

首先他也提供了简单的继承机制:
Objcet.extend (注意,不是上面代码中 Class 里的 extend)
他的代码如下

var $extend = function(){
	var args = arguments;
	if (!args[1]) args = [this, args[0]];
	for (var property in args[1]) args[0][property] = args[1][property];
	return args[0];
};
Object.extend = $extend;

他的使用方法和 prototype 完全一样.

但是大家可能注意到了 这句 if (!args[1]) args = [this, args[0]]; 这句的纯在使得下面的代码写法成为可能.

var myObjcet={....};
myObjcet.extend=$extend;
myObjcet.extend(objA);
myObjcet.extend(objB);
myObjcet.extend(objC);

简单的一句话,让extend的用法增加了更多的灵活性,不得不赞一个了!!!

下面说说重点, moo的类里的extend和 implement
先说 implement,之前已经说了一些了

var MyClassA = new Class();
MyClassA.implement( { methodA : function() {... } }  );

执行后 MyClassA 将拥有 methodA.

implement用来向类中添加属性和方法(会覆盖同名属性和方法),相当于
Object.extend (MyClassA.prototype , {... } )
但是Object.extend 不支持多个source,implement可以,示例如下:
MyClassA.implement( objA , objB, objC ... );


下面来看看moo的Class.extend.
moo的Class.extend才是我们期待的真正的"类继承",看一下官方的示例

		var Animal = new Class({
			initialize: function(age){
				this.age = age;
			}
		});
		var Cat = Animal.extend({
			initialize: function(name, age){
				this.parent(age); //will call the previous initialize;
				this.name = name;
			}
		});

看那个parent() !!!!
通过moo的Class.extend实现的继承提供一个关键的方法 parent().
使用他你可以调用父类中的同名方法,好像java里的super一样.
这个示例已经可以说明一切了.


关于prototype和moo的类机制和继承机制的对比就到这里,孰优孰劣大家心里应该有数了吧.

===========================================
三.抽象对象
===========================================


再来看一看"抽象对象". 这个虽然对于开发人员来说用处不大,但还是对比一下吧,小细节也能看出作者的用心.

Prototype
prototype的抽象对象很简单
var Abstract = new Object();
具体的意义不大.


Mootools
moo的的抽象对象相对更完善一些.

var Abstract = function(obj){
	obj = obj || {};
	obj.extend = $extend;
	return obj;
};

支持自定义抽象(以参数形式传入),同时会为抽象对象自动添加extend方法.


===========================================
四. 关于 $()
===========================================

Prototype
prototype的$大家都比较熟悉了, 工作原理就是
通过id取得一个页面元素(或者直接传入一个页面元素对象),然后给他增加一些prototype提供的方法和属性,来方便开发人员对页面元素的使用.


Mootools
moo在这方面做的差不多.
不同的主要有两点, 首先moo为页面元素增加的方法和属性与prototype的不同(这个稍后会介绍),另外一个不同是moo的$兼具了对象管理的一个功能.
他引入了一个  Garbage 类, 来对页面元素进行一个统一的管理和回收(主要是回收).
可以更好的减少js(或浏览器)造成的内存泄露等问题.

具体的大家可以看一下代码,在这里就不详细说明了.


===========================================
五.关于 Array Enumerable Hash
===========================================


prototype 和 moo 都提供了集合迭代方法 (each)
这个网上已经有一篇不错的对比文章,我就不在这里重复了
http://blog.fackweb.cn/?p=50.


moo的 forEach/each方法: function(fn, bind){..}
那个bind 结合代码 和 上面那篇文章, 大家应该可以很好的看出来prototype和moo的不同与优劣.


prototype里面有 Enumerable 的概念,moo没有.
但是我个人一直觉得 Enumerable 比较鸡肋.
在实际开发中,很少使用.
Enumerable的功能完全可以 用普通json对象 或者是 Hash来实现.
moo的作者也许同样这么认为.所以 不再 设置一个 鸡肋的 Enumerable类.
但是请大家放心, Enumerable 能做的事情, 在moo里也能完成.

可以理解为

moo的 Array +  Hash +{} 完全可以接替 prototype的 Array + Enumerable + Hash +{}
当然对于一些工具方法两者提供的都不太一样,不好比较,但是那些方法都是附属品.
我们完全可以自己来实现,所以不在这次的比较范畴之内.


===========================================
六. 关于 Element
===========================================

两者的 Element 从作用上看类似.都是一种对页面元素的包装,为页面元素添加了一些诸如 addEvent remove style之类的方法.
但是大家通过看代码可以发现 moo的实现明显更简洁 更OO.

同时还有一个关键的不同,prototype又提取出了一个Form对象,里面包含了很多表单相关的方法.
同时还衍生出了 serializeElements Method 等等很多类和方法,代码瞬间变得异常复杂和难以琢磨.


而moo中没有Form对象,在moo中,Form本身就是一个Element 他没什么特别的,这样的思想类似components模式
普通Element具备的方法 Form 都应该具备, Form具备的方法 Element也都应该包含.form 和 其他页面元素没什么不同.
form元素只是一个包含了 input select textarea等子元素,同时拥有action target等属性而已.
一个div 一个span 一个td... 同样可以包含input select textarea子元素,同样可以拥有.action target属性.
浏览器处理他们的方式可能不同,但是在moo面前,大家完全平等.


其实prototype里 form和普通页面元素几乎也是平等的,但是问题就是,既然是平等的,又何必硬生生的造出Form以及那么多的衍生物呢?



===========================================
七.Ajax
===========================================

Prototype
prototype的ajax实现主要是靠一个 Ajax类 来实现.(但是这个类形同虚设,大家更多的是和 Ajax.Request 类打交道.


先来看一个prototype下一个简单的ajax提交实例:

var myAjax = new Ajax.Request( url,{parameters: myData , onComplete: callBackFunction } );

其中 myData 可以是字符 : "name=Vickey&gender=female";
也可以是对象 { name : Vickey, gender : female }


Mootools
moo首先在将ajax机制分层.提取出了一个基类:XHR.
目前XHR有两个子类, 一个是 Ajax ,另一个是Json.Remote.

在moo下一个简单的ajax提交实例:

 var myAjax =new Ajax(url, {data : myData , onComplete: callBackFunction  }).request();

大家可以看到request成为了Ajax对象的一个方法,这样的设计显然是更合理更自然 也更OO的.

而且关键的一点是,你可以提前创建好你需要的ajax对象.在需要发出请求时再发出请求.

 var myAjax =new Ajax(...);
.....
 myAjax.request();

同时还有一个重要特性, request是支持参数的,这个参数就是你要提交的数据.

也就是说,你可以在new Ajax时不指定数据或者指定一个默认数据.
在提交的时候可以提交另一个data.如.

myAjax.request(yourData);

其中data可以是字符串,可以是对象, 也可以是一个页面元素.

要用ajax提交一个form 或者一个 div下的所有表单元素,只是改变一下 myData.
var myData= $("formID");  // var myData= $("divID");
然后就和普通的ajax提交完全一样了.

myAjax.request(myData);

当然还有更oo的方式 :
myData.send({onComplete: callBackFunction });

用后一种方式的时候要保证提交的元素有action属性,没有你就赋一个 myData.action=url.
prototype里如何实现这一功能呢??


Prototype
Form.request($("formID") ,{ onComplete: callBackFunction });

当然prototype里也可以类似moo的做法 , 只要让myData=$("formID").serialize(true) 就可以了.
但是这一个小小的不同,反映出了设计上的差距.


Mootools
moo的Json.Remote类,简单,但是很实用:

	var jSonRemoteRequest = new Json.Remote( url , {onComplete:callBackFunction }).send({name: 'Vickey',gender: 'female' });

这个类和Ajax类的本质区别是,
他提交的是一个序列化后的 json字符串("{name: 'Vickey',gender: 'female' } "),而不是把 json对象转化成QueryString ("name=Vickey&gender=female");



===========================================
结束语
===========================================

写这篇文章不是要批评prototype,以我现在的水平还没那个资格.
只是和mootools对比后, prototype在设计上的不足立刻就显现了出来.

虽然prototype新版本变化很多,很多我上面提到的一些不足都改正了,而且也加入了很多以前不具备的新的特性.
但是prototype现在的发展停留在:"修补不足,增加功能"的阶段,而没有从设计上进行深层次的重构,所以我不认为他在mootools面前有足够的底气.

至于jquery我没有深入研究过,但是它的设计觉得完全是prototype风格的, 注意,我说的是设计风格,而不是代码风格.
代码上他可能写的更精妙,更有趣,但是设计上依然是prototype风格:薄弱的类机制,靠简单的extend支撑起整个系统.
JQuery在很多方面很出色,但是归根结底他和prototype走在一条路上,只是在有些方面他走的更快.


mootools并非完美无缺,但是至少现在他美的地方比prototype更多,缺的地方比prototype更少.

所以,我选择mootools. 你呢??

不要听评论,不要看介绍, 只要看看他们的源代码, 同时动手用他们写些东西, 你的答案自然会浮现出来.

评论

52 楼 jljlpch 2007-10-29  

有很多说jquery很好用。还行吧。当我仔细去了一下jquery。原来不过是mootools中$$.在开始看文档的时候，我一直弄不懂$$即是[],又是元素。看了jquery之后，对比两者的源码。发现jquery太乱了。

51 楼 fins 2007-10-20  

我也觉得还是用 super或superclass之类的更好一点 呵呵
不过 mootools的作者真的很聪明
他们能用 很简单的 甚至是毫无创意的方法 来轻松实现别人没有实现的功能.
你看看他们新版本里的 extends implements, 还有以前版本里那个创建页面元素的方法,都简单的不能再简单了.
看过mootools的代码后,我通常不会感慨他们的技术有多高超,而往往最先感慨的是:这么简单,我怎么就没想到,呵呵 佩服他们的智慧.

50 楼 差沙 2007-10-20  

<p>

引用

</p>
<p>下面来看看moo的Class.extend. <br/>
moo的Class.extend才是我们期待的真正的"类继承",看一下官方的示例</p>
<p> </p>
<div class='code_title'>代码</div>
<div class='code_div'>
<div class='dp-highlighter'>
<div class='bar'/>
<ol class='dp-j'>
    <li class='alt'><span><span>var Animal = </span><span class='keyword'>new</span><span> Class({   </span></span> </li>
    <li class=''><span>    initialize: function(age){   </span> </li>
    <li class='alt'><span>        </span><span class='keyword'>this</span><span>.age = age;   </span> </li>
    <li class=''><span>    }   </span> </li>
    <li class='alt'><span>});   </span> </li>
    <li class=''><span>var Cat = Animal.extend({   </span> </li>
    <li class='alt'><span>    initialize: function(name, age){   </span> </li>
    <li class=''><span>        </span><span class='keyword'>this</span><span>.parent(age); </span><span class='comment'>//will call the previous initialize; </span><span>  </span> </li>
    <li class='alt'><span>        </span><span class='keyword'>this</span><span>.name = name;   </span> </li>
    <li class=''><span>    }   </span> </li>
    <li class='alt'><span>});   </span> </li>
</ol>
</div>
</div>
<p>&lt;script&gt;render_code();&lt;/script&gt;</p>
<p> </p>
<p>看那个<strong>parent()</strong> !!!! <br/>
通过moo的Class.extend实现的继承提供一个关键的方法 parent(). </p>
<p>

</p>
<p>看到这里，我在想为什么ext要做的那么蠢，我们都知道ext要是想引用自己的parent类是多么的困难。</p>
<p>但是我觉得moo的做法是错误的，因为js不是java，java的Class机制很健全，而js只能在function基础上扩展。</p>
<p>如果像moo这么做的话，那我问你我的Class里面需要一个parent属性怎么办？Node Class肯定是有parent这个属性，怎么区分？？ 是不是要自己来hack一下，this._parent = this.parent， 但是如果我的Class里面还有_parent属性呢？ js的Class设计不仅仅要考虑方便，还要想想是不是给用户留下了陷阱。</p>

49 楼 jljlpch 2007-10-17  

不过源码是有点难理解。当你理解，你发现js世界原来可以如此奇妙。prototype源码是很直接的。但是对你有了对比，就会发现什么东西是好是坏。jquery听说很好用。不过Ext2.0倒是可以关注一下。

48 楼 jljlpch 2007-10-17  

在看楼主的这个文章，我花了一个星期的时间去分析mootools的源码。我又去看了一下prototype1.6的源码，发现prototype无论怎么改都改变不了本身的缺陷。
在设计中，mootools没有的说了。特别是plugin，和extend的功能太强了。做为基础lib是再好不过的。

47 楼 cryolite 2007-09-29  

hred 写道

楼主不厚道，题目写《我为什么选择mootools,抛弃了prototype. (mootools与prototype 核心代码分析) 》，却要扯上Jquery。

几个库，运行性能网上有一份测试，谁好谁坏看测试就知道。（貌似Jq拿下大部分性能第一）

这个测评是jQuery自己做的，客观性难说，有个反驳的，《为什么我不用jquery》
http://warpspire.com/tipsresources/interface-scripting/why-i-dont-use-jquery/

46 楼 InnocentBoy 2007-09-26  

关注中，不过不喜欢prototype.js的默认的编码是UTF-8，而且也不知道怎么改？

45 楼 fins 2007-09-21  

根本不是我要引到jquery上的,是回帖的网友把我引到jquery上的
而且事实上我几次三番的说过 我不了解jquery 我说的东西不够准确

唉 无奈了 都

另外我是最不爱读书的人 活书死书都不爱读 我就是喜欢看代码 然后把他们学来 用到自己的东西里

不过你不是我身边的人 也没和我一起工作过 不了解我也正常 呵呵

44 楼 hred 2007-09-21  

楼主不厚道，题目写《我为什么选择mootools,抛弃了prototype. (mootools与prototype 核心代码分析) 》，却要扯上Jquery。

几个库，运行性能网上有一份测试，谁好谁坏看测试就知道。（貌似Jq拿下大部分性能第一）

有两种方式构建软件设计，一种是把软件做得很简单以至于明显找不到缺陷；另一种是把它做得很复杂以至于找不到明显的缺陷。但是最终都是要解决某个实际问题。不管高深也好，简单也好，能够把问题在最少的时间内用最少的步骤解决就是最好的。

楼主研究代码的深入让人钦佩，却完全不顾各种设计思想，全然不顾系统性能而遑论优劣。稍有读死书的嫌疑。

43 楼 dogstar 2007-09-13  

dempire 写道

今天看了一下MOOTOOLS 感觉有些思想不错值得吸取 于是把自己的js框架的类创建方法又增加了一个阿MOOTOOLS那种的后来发现 这种方法很不直观，按照常理new 返回的应该是一个实例而不是一个类，我要得到一个对象得new两次，这种写法我实在不能接受，于是把代码里面好的东西整理留下了 创建类这种东西 个人觉得还是prototype直观一些，最起码大家一看就知道 那东西要干什么

可能是我太菜了吧 还没有达到各位大侠的那种 境界吧

这点确实有些怪怪的，另外，自己可以做点封装类似于prototype的形式。

42 楼 fins 2007-09-13  

1 如果你创建一个类 只要生成一个对象 那么确实 是"得到一个对象得new两次"
但如果 一个类只生成一个对象,那么还有必要用类吗?


2 如果你不喜欢new Class 那么你可以自己简单的再封装一个 Class.create的,这个应该不难吧


3 类 也是对象, new一个类也很正常吧 呵呵

41 楼 dempire 2007-09-13  

今天看了一下MOOTOOLS 感觉有些思想不错值得吸取 于是把自己的js框架的类创建方法又增加了一个阿MOOTOOLS那种的后来发现 这种方法很不直观，按照常理new 返回的应该是一个实例而不是一个类，我要得到一个对象得new两次，这种写法我实在不能接受，于是把代码里面好的东西整理留下了 创建类这种东西 个人觉得还是prototype直观一些，最起码大家一看就知道 那东西要干什么

可能是我太菜了吧 还没有达到各位大侠的那种 境界吧

40 楼 dogstar 2007-09-13  

赞同fins的意见。对css，xhtml，javascript还算了解。但是实际使用jquery的时候，感觉你写的不是javascript，有种被xx的感觉。prototype在javascript原有的基础上做了一个小小的封装，这种风格我喜欢，但是确实在基础上mootools是有比较大的差距。再加上selector就更爽了。

我觉得一个js框架，最好的是在js原有语义的基础上做一些功能的加强。提供方便。而不是，想jquery一样，$()返回的是jquery对象而不是dom对象本身。这样会增加学习曲线。而且会造成，写了很长时间javascript，但是对javascript本身一点都不了解的局面。

39 楼 fins 2007-09-13  

to Sam1860:

我最近怎么总是被卷入这样那样的争论中呢. 无奈了.
你喜欢jquery你就用呗 我只是说一下我不喜欢的原因.
你干嘛拿出一副声讨我的姿态啊,没必要那么激动的.
而且我都说了,我对jquery不了解, 我核心比较的也不是jquery啊 是moo 和prototype.
我更没说过:大家都别用prototype 和jquery了, 跟我一起用moo吧


另外我在比较 prototype和moo 时 一直是在拿他们都有的基础的功能去比的.
你干嘛老拿jq有而别人没有的功能来说啊. 这公平吗?

你说:
而不是像楼主那样把它作为一个OO框架，JQ不是用来写PersonClass的。你想在JQ上构建另一个类库，那明显是你选工具的思路错误了。

我就想找一个可以帮助我写出更高质量的JS代码的框架, 我这个想法有什么不可以的吗?
如果可以,那么我觉得必要的OO特性是必须的,因为我个人的习惯就是写一些OO的js代码,但是又不用太oo,那么我选择moo有错吗?

你说:
JQuery在这一点的优秀之处在于它比较别人更早提供大家需要的东西

早就一定好?

你说:
直的太优美了。不赞成的话用别的代码写写相同的功能对比一下吧

我举个例子哈.框架1 和框架2 都能实现一个功能.

框架1用了两个方法,是这样实现的:
function a : 3行. 其中有一行是调用b
function b : 30行.

框架2也用了两个方法,是这样实现的:
function a : 5行. 其中有一行是调用b
function b : 10行.

然后你拿两个框架的方法a做对比, 得出框架1 比框架2 简洁,这合适吗?

我自己封装过类似你例子中的那种折叠展开的代码, 封完了就一行:  toggleBar(a);
你能说我比jq moo 的作者都牛吗???

你说:
这就更加让人无语了。。。 

不是我的话让你无语了,是事实让你无语了.
我说: 冲突的概率很小 因为你很少会将多个js框架在同以页面中混合使用
这话不对吗?有谁会在一个页面中混合多种js框架? 就算有 这样的页面多吗?


我说: moo或者prototype的作者用意很明显,就是希望让使用者感觉不到js框架的存在,让大家把框架当作js语言本身的一部分.
这句话不对吗?请举反例.

我说: 这类相对低层的js框架, 他们不希望和竞争对手共存
这不对吗? 只有ext 那种相对上层一些的框架 才会渴望和更多的低层框架兼容共存呢.


3 当一个框架或是语言或是其他什么东西 足够强大足够出色,已经成为事实标准的时候, 使用者是会妥协的
这句话肯定是正确的,只是你认为用在这里不对.
当然,你可以有不同观点,但是你举的例子太不恰当了.

xml的namespace和java的package的存在, 是因为如果没有他们,那么代码之间的冲突将是不可避免的,

但是我这里所说的是有前提的:
由于有了"冲突的概率很小 因为你很少会将多个js框架在同以页面中混合使用",这条做保障,所以轻量级js框架中,package不是必须的.
ext dojo要有包的概念, 因为本身他自己的文件 自己的"类"就特别多, 分包便于开发和管理.


好了 不争论了

我的观点表达的很清楚了 你可以提出你的观点, 但是别一副声讨的姿态. 好吗 有话好好说呗

38 楼 笨笨狗 2007-09-13  

其实，不考虑运行速度的话，我感觉用prototype、jq还是moo都差不多，都是为了提高我们的开发效率

37 楼 Sam1860 2007-09-13  

fins 写道

radar 写道

fins 写道

"另外mootools的命名不是很好，为什么不用package的概念呢？"
因为他不想成为 又一个dojo 又一个yui吧
毕竟简单轻巧才是他最求的吧.

其实我觉得JS里搞命名空间实际意义不是很大 至少现在看来是这样.

因为我们一般很少会写太过复杂的js代码,而且很少会在同一个页面内同时使用两个以上的大型js框架

package怎么了？dojo的问题是package吗？
我指的是，mootools占用了太多的顶层变量名。
$extend
Ajax
$
fx
... ...

万一你不小心定义一个
$开头的变量呢？


可能这不是主要问题，如果都放到
var mootools={};下就没这个问题了啊！为什么不呢？

我明白你的意思.
我已经回答这个问题了.
prototype也是直接使用顶层的变量名 $ ajax Element等等
以前我写东西也很注意这些,但是后来发现意义不是很大.

1 冲突的概率很小 因为你很少会将多个js框架在同以页面中混合使用
而在每一个方法前加上moo或者mootools会解决一些问题,但是他也带来了麻烦,他解决的问题是不常遇到的,带来的麻烦却是人人都能感受到的.

2 moo或者prototype的作者用意很明显,就是希望让使用者感觉不到js框架的存在,让大家把框架当作js语言本身的一部分.
他们希望通过自己的努力来改变js的开发方式.


3 当一个框架或是语言或是其他什么东西 足够强大足够出色,已经成为事实标准的时候, 使用者是会妥协的.
举一个不太恰当的例子, 你有没有质疑过
"js里为什么不给 function加一个命名空间, 例如 JS.function, 这样我就可以自由的使用 function作为变量名了"
为什么你不会有这样的质疑? 因为他是规定 他是标准, 不喜欢? 那你可以不用js啊.

其实所有这类框架都有一定的排他性. 尤其是jquery prototype moo这类相对低层的js框架, 他们不希望和竞争对手共存.
你有"$()" 那我就要用我自己的 更好的"$()"打败你,道理就是这么简单.


而让各种低层框架能够互相妥协,能够共存是 更上层的框架去做的事, 例如EXT 和他的bridge.



当然,我从来不否认这样做的缺点,但是这些缺点目前看来不是问题的关键.

这就更加让人无语了。。。
特别是

引用

3 当一个框架或是语言或是其他什么东西 足够强大足够出色,已经成为事实标准的时候, 使用者是会妥协的

那xml的namespace和java的package都不用了，谁先发围谁作主好了。
人家JQuery就完全没有这种问题了。

阁下是太过情人眼里出西施了，把缺点都说成优点了，列出来的都是霸王道理。。。

36 楼 Sam1860 2007-09-13  

我觉得JQuery的优秀之处在于他把AJAX程序员所需的，都以最方便的方式提供给你了。例如：selector, XHR, event binding, dom manipulation

而不是像楼主那样把它作为一个OO框架，JQ不是用来写PersonClass的。你想在JQ上构建另一个类库，那明显是你选工具的思路错误了。就像在说“在struts上构建一个MVC框架太麻烦了，还不如我直接在servlet上构建呢”

在某一楼楼主说了一句很搞笑的话，什么JQuery可以提供的，其它框架也可以提供（原句我懒得去找了）。那MOOTOOLS呢？你凭什么觉得它的东西别人抄不到呢？ JQuery在这一点的优秀之处在于它比较别人更早提供大家需要的东西，例如像domready，不知道是我之前不知道什么是什么，反正就我所知JQ是第一个提供的，其它框架只是跟尾而已。
像PROTOTYPE从1。4之后就不见有什么新东西了，它在新的release notes里的东西基本上是在JQ早几版的release notes中出现过的。至于MOOTOOLS就不清楚了。

引用

$("#mmmmmm aaa.xxx").FFFFFFFFFFFFFF.....

其实你欣赏的是 对"#mmmmmm aaa.xxx"的支持 但是你确定你对他 .后面的那些FFFFFFFFFFFFFFFFFFFf...是喜欢的吗??

我的回答同样是，JQ不是给你写PersonClass的， 是给你写应用的。别人怎样我不知道，就我自己的使用感觉，JQ提供的接口真的很实用，在我做的为数不多的应用里，这些接口都觉得用得很爽
具体一点的说

$(document).ready(function(){     
       $(".fold .fold-button img").click(function(){     
             (".expand",$(this).parents("div.fold")).toggle();     
       });     
}); 

直的太优美了。不赞成的话用别的代码写写相同的功能对比一下吧

35 楼 fins 2007-09-13  

另外多问一句 我对selector的理解一直不到位
在我看来 selector只是一个帮助我们取得页面元素的工具
为我们取得页面元素提供了一个更好的 更灵活的手段.

我这样的理解对吗?

如果不对那么 他更深层次的用法还有什么呢? (别让我去google 因为gooogle过 可能是找的关键字不对,没什么收获)

如果我说的对, 那么出色的selector可以成为一个js框架的亮点,而不应该成为决定他优劣的根本.对吧? 所以我并不认为jquery有绝对的优势.

34 楼 fins 2007-09-13  

相对来说各个社群的开发者会更喜欢接近他们口味的js框架

这个观点我非常认同

但是我觉得 如果moo加入了强大的selector后 一定会比jquery出色.



对于jquery的一条语句来说 例如

$("#mmmmmm aaa.xxx").FFFFFFFFFFFFFF.....


其实你欣赏的是 对"#mmmmmm aaa.xxx"的支持 但是你确定你对他 .后面的那些FFFFFFFFFFFFFFFFFFFf...是喜欢的吗??


具体点

$(document).ready(function(){   
            $(".fold .fold-button img").click(function(){   
                $(".expand",$(this).parents("div.fold")).toggle();   
            });   
        });  

我也喜欢通过 (".fold .fold-button img") 取得对象的方式
但是后面的 .click(function(){  
                $(".expand",$(this).parents("div.fold")).toggle();  
            });  
你确定你第一眼就能知道他是做什么的吗?? 就算知道, 你确定这样的实现除了代码数量少之外 还有其他什么有点吗??

33 楼 hax 2007-09-13  

对于熟悉html/css/xpath的同志来说，jquery当然是不二之选。其实自cssQuery以来，各个框架都在拼命引进使用selector或query的方式。这其实很简单，因为它比传统的桌面编程模式先进和便利许多。这是我2005年的时候做了半年winforms开发深感痛苦得到的结论。

BTW，比较框架的时候，应该要看这个框架的设计思路和目的。例如prototype本意是轻量级的基础库，拿它直接跟ext去pk，就不是很好。

再有，framework的感觉与开发者本身所属社群有关，大体如下：

prototype：不用说了，ruby味道的
mochikit：正宗的Python味道
dojo：java风味
jquery：CSS/XPath的风味
jsvm：java味道
jsi：偏java风味
……

相对来说各个社群的开发者会更喜欢接近他们口味的js框架。