Beautiful RIA [20]
同时，开发者在这个平台上可使用的工具也越来越好。当 GWT出现时，我认为它是革命性 的。而几周前我们刚刚发布了 GWT 1.6，它比最初的 GWT，甚至比一年前的 GWT更强大。 你可以看到，它的内部其实还是那些东西，只不过随着它的成熟而增加了一些工具。
因此我认为还有很大的发展空间。
InfoQ：有人建议使用另一种客户端语言，例如 Ruby。您认为 JavaScript目前是否足够强大？ 是否需要做出大的修改？是否应该使用更多的 DSL技术？
Dylan ：我想我们很可能会看到 DSL，甚至在服务器端也会有 JavaScript。有一个服务器端 JavaScript讨论组对此有着 极大的兴趣。JavaScript本身并不是问题所在，真正的问题是浏览 器对 DOM和 JavaScript交互的实现方式，以前的 JavaScript引 擎比现在 Mozilla、Google、
虚拟座谈：HTML5来了，JavaScript框架会如何发展
Apple和 Opera都要慢很多。我曾经认真考虑过如果 Python或 Ruby成为客户端语言意味着 什么，坦白 说我觉得这并不能解决问题。
Matt & Eric：JavaScript在 ECMA 3.1中做出了彻底的改变，这就是目前我们真正需要的。
浏览器可以自行选择实现其它的脚本引擎。不过既然它们按照规范实现了 DOM API，使用什 么脚本语言也就无所谓了。一些人——包括 Yahoo的Douglas Crockford－曾经争论过将来的 Web是否需要一种新的内建安全机制的语言。
Andrew ：完全的语言替换是不会发生的－JavaScript背后的力量很强大。我喜欢已经流产的 ES4提案中的很多新特性——运算符重 载、Ruby风格的 catch-all methods等等。不幸的是， ES4包含的太多了。我很庆幸在“妥协”后，ES3.1包含了 getter和 setter。但是我认为ES 3.1 做的还不够。简单来说，我觉得应该尽量让 JavaScript更加动态。
Thomas ：是的，我觉得 JavaScript就应该是现在这样。它不应该成为一个“真正的面向对象 编程语言”，它强大的基于原型的机制已经很好了。这可以让我们使用不同的开发风格，并 根据个人喜好进行定制。JavaScript和 Ruby有时候非常相似（JavaScript框架 Prototype中的 某些部分就是在向 JavaScript中添加 Ruby风格的元素）。更多的 DSL将会很好——我最希望 未来在 JavaScript中 能有两样东西，一样是捕获未定义函数名（就像是 Ruby的 method_missing），另一样是内联函数（blocks）以避免总是需要写 function(){...}。
David ：JavaScript是这个星球上最成功的编程语言之一。尽管有些语言没有那么多的问题（我 们知道 Valerio喜欢写 Lua代码，他已经爱上 Lua了 ），JavaScript真正的问题一直是浏览器 的实现。框架为我们解决了其中的大量问题，但是显然 JavaScript规范应 该得到更新。框架 的目的有 3个：
1） 抽象出浏览器的不同，并支持老版本浏览器；
2） 提供丰富的、更方便的 API；
3） 提供规范中没有的功能（例如效果、可 排序表格、图册）。
对于浏览器的错误实现，我们需要 1），对于仍不好用的 API，我们需要 2），对于规范无法 提供丰富的功能，我们需要 3）。我们只是没有发现这些东西在近期有任何改变。
Scott & Joel ：我认为 JavaScript作为一种语言非常强大，甚至有些时候太强大了。你有 64位 整型数或为金融程序而内建的 BigDecimal，但是 JavaScript面临的最大挑战在与如何构建和 管理庞大的手写源代码库。当我们最初创建 GWT时，我们打赌 JavaScript为人们喜欢的巨 大灵活性也可以使它成为一个优秀的编译器目标语言，因此也可以将它当成是 Web上的某
虚拟座谈：HTML5来了，JavaScript框架会如何发展
种汇编语言。
你可以在 JavaScript frameworks和 Rich Internet Applications找到更多信息。
原文链接：http://www.infoq.com/cn/articles/js-for-h5
相关链接:
虚拟研讨会：HTML5的新JavaScript框架
JavaScript多线程编程简介
使用JsUnit和JSMock的JavaScript测试驱动开发
HTML 5案例研究：使用WebSockets、Canvas与JavaScript构建noVNC客户端 HTML5 Web Sockets与代理服务器交互
RichClient/RIA原则与实践
作者 陈金洲
作者根据自己参加的多个不同的 RichClient项目的开发工作，总结了自己在使用/尝试过 的语言包括 Java Swing、Flex/Adobe Air、.NET WinForm/.NET WPF等，对于不同平台之间 的种种体会。对自己的富客户端开发的实践和原则进行了总结。
Web 领域的经验在过去十多年的不断的使用和锤炼中，整个开发领域的技术、理念、缺陷 已经趋于成熟。JavaEE Stack, .NET Stack, Ruby On Rails等框架代表了目前这个技术领域的所有 经验积累。这样我们在开始一个新的项目的时候，只需要选择对应语言的最佳实践，基本上 不会犯大的错误。例如，如果使用 Java开发一个新的 Web应用，那么基本上 Spring/Guice+Hibernate/iBatis/+Struts /SpringMVC这种架构是不会产生重大的架构问题的； 如果使用 RoR那么你已经在使用最佳实践了；系统的分层：领域层，数据库层，服务层， 表现层等等；为了保证系统的可扩展性，服务器端应当是无状态架构，等等。总而言之， web开发领域，它丰富的积累使得开发者逐渐将更多的精力投入到应用本身。
来看富客户端，或者富互联网应用。在我看来，今天的 RichClient与 RIA已经没有分别：只 要代表着丰富界面元素和丰富用户体验，需要与服务器进行交互的应用都可以称为 RichClient或者 RIA，虽然感觉上 RichClient更“企业化”一些（服务器往往在企业内部），RIA 更“个人化”一 些（服务器往往处于公网）。从最小的层面来说，我现在正在使用的离线模式 的 GoogleDoc就是一个 RichClient应用──虽然它没有那么 Rich，采用和 microsoft office一样 土的界面; 我现在正在听音乐的 Last.fm客户端显然是一个非常典型的 RIA──它所有的个人 喜好信息、音乐全都来自远在美国的服务器。本地的这个界面，只是提供收集个人和音乐信 息，以及控制音乐的播放和停止；目前拥有 1150万玩家的魔兽世界，则是一个挣钱最多的， 最“富”的客户端，10多 G的客户端包含了电影 品质的广阔场景，华丽的魔法效果和极其复 杂的人机交互。
如今的用户需求已经达到了一个新的高度，那些灰色的，方方正正的界面已经逐渐不能够满 足客户的需求。从我们工作的客户看来，他们除了对“完成功能”有着基本的期待外，对于将 应用做得“酷”，也抱有极大的热情。我工作的上一个项目是一个 CRM系统，它是基于.NET Framework 3.5的一个 RichClient应用。它的主窗口是一个带着红色渐变背景的无边框窗口， 还有请专业美工制作的图标，点击某一个菜单还有华丽的二级菜单滑动效果。我们在这个项
RichClient/RIA原则与实践
目中获得了很多，有些值得借鉴，有些仍然值得反思。我仍然记得我们在项目的不同阶段， 做一个技术决定是如此的彷徨和忐忑：因为在当时 的 RichClient企业开发领域，几乎没有任 何丰富的经验可以借鉴，我们重新发明了一些轮子，然后又推翻它；我们偏离了 UI框架给 我们提供的各种便利而自己实现种种基础特性，只是因为他们偏离了我们所倡导的测试性的 原则。在写下本文的时候，我尝试搜索了一下，仍然没有比较深入的实践性文章来介绍企业 环境下 RichClient开发。大多数的书，如 Swing、JavaFX、.NET WPF开发等等，偏向于小规 模特性介绍，而在大规模的企业应用中，这些小的技巧对于架构决策往往帮助很小。
我的工作经历应当是和大多数开始进行 RichClient开发的开发者类似：有着丰富的 Web开发 的经验之后开始进行 RichClient开发。加入 ThoughtWorks之后参加了多个不同的 RichClient 项目的开发工作，使用/尝试过的语言包括 Java Swing, Flex/Adobe Air, .NET WinForm/.NET WPF. 对于不同平台之间的种种有些体会。在这里我将这些实践和原则总结如下。例子很可能过时， 毕竟华丽的界面框架层出不穷，但原则应当通用的。使用和遵循这些原 则将会帮助你少犯 错误──至少比我们过去犯的错误要少。如果你拥有一定的 web开发经验，那么这篇文章你 读起来会很亲切。
这些原则 /实践往往不是孤立的，我尝试将他们之间用图的方式关联起来，帮助你在使用的 过程中进行选择。例如，你遵循了“一切皆异步”的原则，那么很可能你需要进行“线程管理” 和“事件管理”；如果你需要引入“缓存与本地存储”，那么“数据交互模式”你也需要进行考虑。 希望这张图能够帮助读者理解不同原则之间的