中国人有个毛病，爱看热闹。街边吵架了必然扫上一眼看看ko结果。 

　　职业能改变人的思想，顺便牵扯点作为人的行为。咱就是搞java应用开发的也就好这口。有什么新鲜玩意都要试把试把。有些时候真的不是因需要而去应用，就像去街边看人pk突个新鲜。近来吵的很火所以很多中国人也都愿意以身试法。试图参透其奥妙所在。新鲜嘛！但这种激情往往使人忘记了理智。激情是要建立在理性的基础上才能发挥其最大作用。这点思想如果忘却，不失为大错。 

　　其实你选择他如果自己做实验或玩玩几个小case还是可以，也是比较让人赞同。这说明你这个人有探索精神。有进取心，是个人才。总比很多一无事处的混混强得多。而如果不分青红一贯的应用于真实的高用户高并发量的系统项目中，恐怕是个不明智之举，仅代表个人意见。因为我也是参照其作用、利用其长处、杀敌人于无形。孙子是个很厉害的人为什么人家研究兵法多少年都不会落伍。那是因为他抓住了事物的本质。就像我们做软件应用业务原型就对系统建模型一样。因为其稳固必然长久，这是道理。我们想让自己的项目不至于最终落魄到只能大范围架构级的重构，不如选择放弃。因此当做决定前应该尽量想到前因后果，方之上上策。 

　　你要看热闹，是什么驱动你去看这次热闹。这需要分析。如果根据场景不同你发现打架的人是你的朋友亲戚。你必然参与这次活动。 

　　你要使用，是什么驱动你去使用它。我们分析。我们不是为了用而用。而是为了发挥其作用而用。如果将其作用发挥到我们的业务中，这才是次有意义的活动。 

　　我们设计，在什么地方应用。不能一味的应用。选择性的应用发挥其长处、弊其短处应该是好的选择。 

　　以下为应用设计时的参考资料： 

　　【导读】本文简述了技术适用场景、不适用场景的具体情况以及应用时候存在的一些问题。 

　　适用场景

　　1.表单驱动的交互

　　传统的表单提交，在文本框输入内容后，点击按钮，后台处理完毕后，页面刷新，再回头检查是否刷新结果正确。使用，在点击sunmit按钮后，立刻进行异步处理，并在页面上快速显示了更新后的结果，这里没有整个页面刷新的问题。

　　2.深层次的树的导航

　　深层次的级联菜单（树）的遍历是一项非常复杂的任务，使用JavaScript来控制显示逻辑，使用延迟加载更深层次的数据可以有效的减轻服务器的负担。

　　我们以前的对级联菜单的处理多数是这样的：

　　为了避免每次对菜单的操作引起的重载页面，不采用每次调用后台的方式，而是一次性将级联菜单的所有数据全部读取出来并写入数组，然后根据用户的操作用 JavaScript来控制它的子集项目的呈现，这样虽然解决了操作响应速度、不重载页面以及避免向服务器频繁发送请求的问题，但是如果用户不对菜单进行 操作或只对菜单中的一部分进行操作的话，那读取的数据中的一部分就会成为冗余数据而浪费用户的资源，特别是在菜单结构复杂、数据量大的情况下（比如菜单有 很多级、每一级菜又有上百个项目），这种弊端就更为突出。

　　如果在此案中应用后，结果就会有所改观：

　　在初始化页面时我们只读出它的第一级的所有数据并显示，在用户操作一级菜单其中一项时，会通过向后台请求当前一级项目所属的二级子菜单的所有数据，如 果再继续请求已经呈现的二级菜单中的一项时，再向后面请求所操作二级菜单项对应的所有三级菜单的所有数据，以此类推……这样，用什么就取什么、用多少就取 多少，就不会有数据的冗余和浪费，减少了数据下载总量，而且更新页面时不用重载全部内容，只更新需要更新的那部分即可，相对于后台处理并重载的方式缩短了 用户等待时间，也把对资源的浪费降到最低。

　　3.快速的用户与用户间的交流响应

　　在众多人参与的交流讨论的场景下，最不爽的事情就是让用户一遍又一遍刷新页面以便知道是否有新的讨论出现。新的回复应该以最快的速度显示出来，而把用户从分神的刷新中解脱出来，是最好的选择。

　　4.类似投票、yes/no等无关痛痒的场景

　　对于类似这样的场景中，如果提交过程需要达到40秒，很多的用户就会直接忽略过去而不会参与，但是可以把时间控制在1秒之内，从而更多的用户会加入进来。

　　5.对数据进行过滤和操纵相关数据的场景

　　对数据使用过滤器，按照时间排序，或者按照时间和名称排序，开关过滤器等等。任何要求具备很高交互性数据操纵的场合都应该用JavaScript，而不是用一系列的服务器请求来完成。在每次数据更新后，再对其进行查找和处理需要耗费较多的时间，而可以加速这个过程。

　　6.普通的文本输入提示和自动完成的场景

　　在文本框等输入表单中给予输入提示，或者自动完成，可以有效的改善用户体验，尤其是那些自动完成的数据可能来自于服务器端的场合，是很好的选择。

　　不适用场景

　　1.部分简单的表单

　　虽然表单提交可以从获取最大的益处，但一个简单的评论表单极少能从得到什么明显的改善。而一些较少用到的表单提交，则帮不上什么忙。

　　2.搜索

　　有些使用了的搜索引擎如Start.com和Live.com不允许使用浏览器的后退按钮来查看前一次搜索的结果，这对已经养成搜索习惯的用户来说是不可原谅的。

　　现在Dojo通过iframe来解决这个问题。

　　3.基本的导航

　　使用来做站点内的导航是一个坏主意，为什么不把时间放在让系统程序作的更好上呢？

　　4.替换大量的文本

　　使用可以实现页面的局部刷新，但是如果页面的每个部分都改变了，为什么不重新做一次服务器请求呢？

　　5.对呈现的操纵

　　看起来像是一个纯粹的UI技术，但事实上它不是。它实际上是一个数据同步、操纵和传输的技术。对于可维护的干净的web应用，不使用来控制页面呈现是一个不错的主意。JavaScript可以很简单的处理XHMTL/HTML/DOM，使用CSS规则就可以很好的表达数据显示。

　　存在的问题

　　1.用JavaScript作的引擎，JavaScript的兼容性和DeBug都是让人头痛的事；

　　2.的无刷新重载，由于页面的变化没有刷新重载那么明显，所以容易给用户带来困扰?D?D用户不太清楚现在的数据是新的还是已经更新过的；现有的解决有：在相关位置提示、数据更新的区域设计得比较明显、数据更新后给用户提示等；

　　3.中间过程不能被bookmark。解决方法：GoogleMaps通过在页面上提供一个”link to this page”的办法来解决。另外，还可以通过url链接中加无效的?^标记来解决，但还未验证。 我觉得ibm开发者论坛中有个老大不记得什么名字了说的不错 跟j2ee的现有成熟表现层框架结合使用是比较好的一个选择。因需而用不会给自己断掉很多后路。一味的尝试或许就有苦果等待、诱惑、刺激、引导你失去理智。