Ajax的兴起，给Javascript带来了新的生机，大量的javascript框架(Javascript Framework)层出不穷，一些框架来至于开发人员项目经验的总结和提炼，也有一些框架来至于商业公司，同时以开源和商业两种方式发布。借助这些框 架，可以大大加速Ajax项目的开发速度，但同时也面临不同的学习曲线，以及架构扩展性等等问题。如何选择Javascript框架，成为开发人员和架构 师头痛的一个问题。如果你正面临这样的问题，希望下面的几个建议对你在选择javascript框架上会有所帮助。

你的项目需求是什么

首 先要问自己这是一个什么项目，具体的需求是什么，是一个普通类型的网站还是一个在线的web应用程序，是否需要处理大量的键盘和鼠标事件，是否需要给用户 各类高级的ajax特性，还是说只要实现一个简单的异步页面刷新和一些简单dom操作，如果是后者，则可以选择一个相对简单的javascript框架， 封装基本的xmlhttprequest操作和dom操作就足够了。

浏览器的支持情况

不 同的框架兼容的浏览器会有所不同，尤其是一些高级的javascript框架，对低版本的浏览器都不支持，还有一些框架只支持ie和firefox，对其 他浏览器如opera、safari不支持。所以在框架的选择上还要考虑到系统的目标用户，如果目标用户都只使用ie6.0以上浏览器，那么在框架的选择 上余地就更大了。

框架后面是否有一个核心的开发团队

很多框架往往都是个人在业务时间开发的，随时可能停止更新，而如果后面有一个团队，则可以在一定程度上保准代码的更新，对bug和一些问题的及时响应，同时在代码质量上也相对有保准。

框架的成熟度

如果一个新的框架刚刚发布，使用的人往往不多，如果你贸然采用，在使用过程中遇到问题，可能要找个能帮你解决问题的人或者在网上找资料都显的很难。所以在这方面也要有所考虑。

框架的发布更新频率

一个框架有很高的发布更新频率说明新的功能在不断加入或者bug被fix的速度很快，反之一个框架半年都不出一个版本，基本可以说明这个框架已经不被开发者重视，很难得到新的发展。

文档的友好性

一个框架尤其是相对比较复杂的框架，如果没有充分和友好的文档，学习曲线会比较高，使用者在使用过程中往往需要通过阅读代码和其他外部的文章来学习怎么使用和解决一些问题。所以文档也是很重要的一个因素。

是否有个活跃的社区

一些成功的开源框架背后往往有一个社区在支撑，大家在里面交流使用经验，互相帮助解决使用过程中遇到的问题。任何问题，只要在这类社区中寻求帮助，往往很快就可以得到他人的帮助。这样的框架，即使一开始不是很成熟，也会很快发展起来。

框架的扩展性

在 实际的项目过程中，往往一个特定的框架是很难直接满足你的所有需求的，这就要求你需要去做一些定制和扩展的工作，如果一个框架没有很好的扩展性，则你可能 在项目后期为了实现某个特定的需求，不得不采用另一个新的框架，大大加大了项目的成本。所以选择一个有很好扩展性，如支持plugin等机制的框架，对你 今后系统的扩展会有很大的帮助。

性能和网络环境

不同的系统在性能和功能的侧重上会 有所不同，比如一个基于互联网的项目，可能考虑更多的是要求在保准性能的前提下，再来讲功能，很多高级的javascript框架往往在性能上不能让人满 意，一部分原因是封装了太多功能，导致js文件会非常大，在互联网环境下，下载这个js文件就会耗去不少时间，还有就是为了保准如框架的扩展性，往往做了 多层封装和抽象，在某种程度上其实是以牺牲部分性能为代价的。所以这样的框架可能更适合一些intranet内部的项目，而不是基于互联网的项目。

在IE环境下，如果要通过innerHTML给select元素附加options，往往会无效，这是ie的一个bug。

所以如果要通过innerHTML来生成select元素，可以在外面加个div，然后把innerHTML附给这个div。或者通过编程的方式来生成select。可以有以下三种方式：

function fill_select1() {
	for(var i=0; i < 100; i++) {
		select1.options[i] = new Option(i,i);
	}
}

function fill_select2() {
	var sOpts = "<SELECT>";
	for (var i=0;i<100;i++)
	{
		sOpts += '<OPTION VALUE="' + i + '">' + i + '</OPTION>\n';
	}
	select2.outerHTML = sOpts  + "</SELECT>";
}

function fill_select3() {
	for(var i=0; i < 100; i++) {
		var oOption = document.createElement("OPTION");
		oOption.text="Option:  " + i;
		oOption.value=i;
		document.all.select3.add(oOption)
	}
}

在应用Ajax技术的过程中，往往面临一个选择，即前后台应该传递什么数据，可以有以下几种选择：HTML代码、JSON对象、 javascript代码、XML数据。在具体的项目中，如何来选择传递什么类型的数据，是架构师必须确认和统一的。从BlogMethods的开发过程 中总结了一些经验，加上自己的一些理解，简单谈谈这几种类型分别适合在什么情况下适用。

1.HTML代码：如果只是需要从服务器端取出内 容，然后显示在客户端，比如局部刷新页面上的一块内容，则可以直接在服务器端生成HTML代码，然后直接传递到客户端，通过innerHTML属性来显 示。毕竟在服务器端可以通过模板技术很轻松的生成HTML代码，而如果在客户端用javascript来动态组装一段HTML代码还是略显麻烦的。

2.JSON 对象：如果你需要在客户端缓存一些数据结构，比如在客户端上下文中，你需要缓存User对象，标签列表对象等等，则可以按照一定的数据结构在服务器端动态 生成JSON对象，然后传到客户端，通过js代码保存到一个全局对象中，比如 window.client.user,window.client.tags等，这样这两个对象会缓存在浏览器中，你可以随时通过js代码访问和操作这 两个变量。对于一些需要经常用到的对象，可以通过这种方式一次取出来，而不用每次用到的时候再取一次。

3.javascript代码：很多 时候，如你要取出一个很大的List对象，然后在客户端轮训使用，这个时候如果你在服务器端先生成JSON对象，然后返回到客户端，你可能需要在服务器端 和客户端要分别轮训两次，在服务器端轮训生成JSON对象，然后再到客户端轮训JSON对象列表来执行一些逻辑，当列表过大的时候，往往会比较耗性能，这 个时候，其实可以在服务器端把客户端要执行的javascript代码都生成，然后到客户端调用eval函数即可，这样可以省去客户端的轮训。

4.XML 数据：xml作为全能的数据封装格式，可以封装各种数据，在服务器端把数据封装成xml格式，然后到客户端按照一定数据标准在把xml转换成html或者 json对象。采用xml数据格式的好处是数据格式统一，尤其是对SOA架构的程序来说，只要定义了XML格式标准，第三方程序可以很方便的与该应用交 互，不管是Ajax程序还是其它程序，同时也便于系统的扩展。当然这样带来的问题是服务器端需要花成本来生成xml格式的文本，同时客户端又要花成本来解 析xml，在开发量上和性能上有一定的损耗。一般适合于做外部访问的接口。

5.混合类型的数据：BlogMethods大量采用了这种方 式，因为往往一次request的时候需要更新客户端的一部分对象，同时又需要从服务器端取出一部分HTML代码来刷新部分页面，这个时候以上4种类型都 有一定的局限性，BlogMethods采用的方式是同时返回多类型的数据，每个类型的数据之间用一些特定的字符隔开，比如同时传递javascript 代码和html代码，先在服务器端用模板技术动态生成要返回的内容，然后传到客户端，用javascript代码分别split出两份代码，用eval执 行javascript代码，同时把html代码附到要更新元素的innerHTML属性上。这种模式效率极高，也相当灵活，推荐使用，但不要滥用。

Ajax技术的优势或者优点这两年已经众人皆知，开发人员纷纷在各自的项目中应用Ajax技术，BlogMethods的后台也架构在Ajax技术之上，这里谈谈在开发过程中遇到的Ajax的一些问题以及这项技术的局限性。

首 先，采用Ajax技术以后，开发量大大增加，因为要考虑到兼容各类主流浏览器，往往一段js代码在IE下有效，放到firefox下就不行，同时CSS style在ie下和firefox下也有一些不同之处，加上javascript的灵活性和没有好的调试器，导致了工作量大大增加。

第二 点，由于需要大量的javascript代码，在第一次加载系统的时候，往往由于js文件过大，加上第一次加载需要load好几个文件，导致进入系统的时 间往往比传统web页面慢。当然可以通过在客户端cache js文件来解决部分问题，但是在进入系统的时候往往需要初始化很多数据到客户端，这个问题在带宽有限的情况下会显得很突出，比如最近由于海底电缆的问题， 访问GMail往往会提示访问不成功，但用传统HTML视图勉强可以使用，暴露的就是这个问题。

第三点，客户端耗内存，因为要在客户端保留 大量的数据，会导致浏览器占用的内存过大，如果你的js代码存在内存泄露的问题，随着使用时间的推移，可能会耗去客户端所有的内存。这里有一个如何折中的 问题，哪些数据没必要保存在客户端，哪些数据适合保存在客户端，根据应用的不同情况而定。

第四点，比起C/S架构程序的用户体验，Ajax 技术还是远远落后，标准的Ajax技术不支持流媒体如视频和声音，协议也局限于http协议，比如要实现一个IM聊天程序，视频和语音如果不外加 ActiveX或者Flash控件，是不可能实现的，所有消息也必须通过服务器中转，而不能实现真正意义上的P2P。

对于像聊天室、在线IM这类应用，如果只是用ajax，还是有一定的缺陷，因为这些应用要求实时性很高，而传统的web应用都是基于请求-响应模式，所以需要不断的去定时刷新页面才能保准与服务器段状态的一致性，显然，对于这类应用来说，采用刷新的方式明显是在浪费资源。

有人提出了一种叫Comet的 概念，就是保持客户端与server端的http链接，这样服务器端有任何更新可以马上通过response推给客户端，可以通过设置http协议中的 keep-alive头来实现，已经有利用push技术实现的项目，如gmail中新增的在线gtalk，具体其是怎么实现还未有文档参考。

comet存在的一个问题是当在线人数太多，需要保持太多的http链接，这在性能上会带来很大问题，而且现在主流的web server都没有专门正对http push进行优化。

dojo据说已经支持comet，dwr也将在下一个版本支持。

参考资料：

• COMET: Socket Hungry AJAX
• http://www.javaeye.com/topic/28020?page=1
• http://www.zeali.net/entry/343