HTML在被创造出来的时候，只是用来描述文本信息，以及文本之间的关系的，Tim Benas Lee也不会预料到Internet时代的热潮。不论人们后来在Browser上面附加了多少功能，Javascript也好，Applet也罢，ActiveX(Flash)，都没有从根本上面改变HTML交互能力弱的问题。其实大部分人都意识到了，不彻底改变当前的HTML，就没有办法改变Browser的弱点。然而彻底改变HTML的方式的前提就是Broswser功能的扩充，考虑到Windows操作系统和IE浏览器占据了绝大部分市场份额，这个功能最有希望完成的也只有MS公司了。在MS下一代表示层技术Avalon中，XAML将取代HTML，Browser的功能被扩充，页面不再是扁平的，而是立体俄，事件处理代码不再是Javascript，而是C#。然而考虑到Longhorn在2006年上市，到普及推广，我觉得可能要到2010年前后，XAML才有可能全面取代HTML。那么在此之前，仍然会是HTML/Javascript的方式。在过去，Browser端的主流是HTML/Javascript，在将来，Browser端的主流是XAML/C#，那么当前一些富Javascript技术的Browser方案是否会成为过渡时期的主流呢？我的看法是没有成熟的开源框架的情况下，是不会的。我们过去也曾经比较多运用DHTML实现一些方便的页面操作，例如在一个页面里面隐藏很多层，当点击某个信息，察看明细记录的时候，层显示出来，层里面的内容也俨然像一个窗口一样，并且模仿Windows的桌面窗口，有关闭按钮，有标题栏什么的，还可以像Windows桌面窗口那样拖来拖去，把很多客户都骗了。并且可以在一个页面里面做很多的工作。但是Javascript/DHTML是有很多缺陷的：1、复杂的Javascript事件处理相当的消耗CPU资源，有时候甚至很惊人
2、Javascript本身语法简单，很难做到类似面向对象语言的扩充性，复用性，因此无法大面积复用
3、Javascript的触发严重依赖页面元素对象，因此很难抽象出来高度复用的代码，很难降低Javascipt和DHTML元素的耦合性
4、Javascipt的可视化效果是最差的，如果过多运用Javascript来控制页面显示的话，美工根本对页面无从下手，甚至程序员在没有把页面运行起来之前，也无法判断页面显示出来的样子。
5、Javascipt/DHTML在不同的浏览器，在浏览器不同版本之间的表现差异很大
6、一个富Javascipt/DHTML的页面开发效率是很低的，我的经验是，如果可以使用服务器端状态控制完成的需求，我用好几个页面，加上少量的服务器端代码可以在半天时间完成的工作，那么我如果单纯用Javascript来完成，可能一天都搞不定这个页面的控制(也许Javascript高手例外)
7、大面积运用Javascript，页面很难维护，甚至无法维护因此，我个人是不赞成使用富Javascript的浏览器端技术的。我的主张是贫Javascript的浏览器端技术做为这几年的过渡。Javascript可以有限的运用在数据输入校验，页面跳转，数据选取，Area编辑，日历控件，动态菜单，树状显示等等方面，而不宜以Javascript为核心构建浏览器端解决方案。HTML这种方式的本身就和传统的Desktop操作流程有所不同，非要勉强的通过富Javascript技术的方式来实现一些传统的Desktop的操作流程，我认为是代价比较大的。既然你运用了HTML，就应该接受多写一些页面，多一些流程跳转的这种Browser操作方式，而不是类似Bindows那样企图把所有状态控制都在一个页面搞定。回想过去我们用Delphi/VB/PB写Desktop程序的方式，拖拉出来控件，然后给控件的事件编写响应代码。MS webforms在这方面迈进了一步，然而仍未摆脱HTML的桎梏，于是搞出来一个XAML，扩充操作系统和浏览器，摆脱HTML的限制，真正实现Desktop那样方便的事件响应式编程，同时又保留了Browser方式用简单的标记来描述窗口元素布局的优点。这样看起来HTML/Javascript方式将来总归会被淘汰(至少在2010年以后吧)，其实不是Javascript有什么错，而是HTML太弱了，如果HTML被淘汰，Javascript也只好被淘汰了，这就是我对Javascript未来发展的一个预测。所以我自己不想在Javascript方面投入更多的学习成本，我原来搞Javascript的底子还在，我更愿意多关注一下XAML。最后我要声明的是，我不是一个Javascript反对者，我在2000到2001年也下狠功夫钻研Javascript过，我也认为当前的Web开发人员必须掌握足够的Javascript编程知识，不能忽视Javascript的作用，我只是不赞同把Javascript/DHTML抬高到浏览器端解决方案核心地位的观点而已。
转:http://www.javaeye.com/topic/8630
2、Javascript本身语法简单，很难做到类似面向对象语言的扩充性，复用性，因此无法大面积复用
3、Javascript的触发严重依赖页面元素对象，因此很难抽象出来高度复用的代码，很难降低Javascipt和DHTML元素的耦合性
4、Javascipt的可视化效果是最差的，如果过多运用Javascript来控制页面显示的话，美工根本对页面无从下手，甚至程序员在没有把页面运行起来之前，也无法判断页面显示出来的样子。
5、Javascipt/DHTML在不同的浏览器，在浏览器不同版本之间的表现差异很大
6、一个富Javascipt/DHTML的页面开发效率是很低的，我的经验是，如果可以使用服务器端状态控制完成的需求，我用好几个页面，加上少量的服务器端代码可以在半天时间完成的工作，那么我如果单纯用Javascript来完成，可能一天都搞不定这个页面的控制(也许Javascript高手例外)
7、大面积运用Javascript，页面很难维护，甚至无法维护因此，我个人是不赞成使用富Javascript的浏览器端技术的。我的主张是贫Javascript的浏览器端技术做为这几年的过渡。Javascript可以有限的运用在数据输入校验，页面跳转，数据选取，Area编辑，日历控件，动态菜单，树状显示等等方面，而不宜以Javascript为核心构建浏览器端解决方案。HTML这种方式的本身就和传统的Desktop操作流程有所不同，非要勉强的通过富Javascript技术的方式来实现一些传统的Desktop的操作流程，我认为是代价比较大的。既然你运用了HTML，就应该接受多写一些页面，多一些流程跳转的这种Browser操作方式，而不是类似Bindows那样企图把所有状态控制都在一个页面搞定。回想过去我们用Delphi/VB/PB写Desktop程序的方式，拖拉出来控件，然后给控件的事件编写响应代码。MS webforms在这方面迈进了一步，然而仍未摆脱HTML的桎梏，于是搞出来一个XAML，扩充操作系统和浏览器，摆脱HTML的限制，真正实现Desktop那样方便的事件响应式编程，同时又保留了Browser方式用简单的标记来描述窗口元素布局的优点。这样看起来HTML/Javascript方式将来总归会被淘汰(至少在2010年以后吧)，其实不是Javascript有什么错，而是HTML太弱了，如果HTML被淘汰，Javascript也只好被淘汰了，这就是我对Javascript未来发展的一个预测。所以我自己不想在Javascript方面投入更多的学习成本，我原来搞Javascript的底子还在，我更愿意多关注一下XAML。最后我要声明的是，我不是一个Javascript反对者，我在2000到2001年也下狠功夫钻研Javascript过，我也认为当前的Web开发人员必须掌握足够的Javascript编程知识，不能忽视Javascript的作用，我只是不赞同把Javascript/DHTML抬高到浏览器端解决方案核心地位的观点而已。
转:http://www.javaeye.com/topic/8630
它将服务器上代码都转化为html和javascript，用ajax与服务器进行交互
但是做出来的作品虽然简单，但是却也简单地不让人感到乏味
google的很多服务，应该都是用类似gwt这种工具开发的，但是大家又觉得那些服务差吗？web我想更重要的速度快与功能的强大才能实现理想状态（个人电脑没有硬盘,整个系统就只是一个brower），而非更强的表现力个人遇见 ~~莫见怪~~
把“富/贫”改成“胖/瘦”可能符合习惯点
任何语言都有自己的优点，C，C++等语言的效率高，但使用不当，给出的结果也是惊讶的2、Javascript本身语法简单，很难做到类似面向对象语言的扩充性，复用性，因此无法大面积复用
换种思维方式，JS本身语法简单没错，这也是应这个时代而产生的，没有什么人愿意写JS时和写C++一样。
扩充性和复用性，一定就要面向对象？况且JS也富有OO的一些特点，成熟的framework已经基本实现OO。
且JS2.0已经具备了OO的特点。
JS的class这个关键字预留出来也应该是有一些道理的3、Javascript的触发严重依赖页面元素对象，因此很难抽象出来高度复用的代码，很难降低Javascipt和DHTML元素的耦合性
这一点和第二点有相似，但也不能以这来说明JS的好坏，JS原本存在只是为HTML增加色彩，而现在JS在这点上的确与现阶段的应用有些脱离，大面积的JS应用意味着需要比其它语言要更好的设计。因此，框架技术大片的出来也有这些原因--复用，跨浏览器，以及OO。
4、Javascipt的可视化效果是最差的，如果过多运用Javascript来控制页面显示的话，美工根本对页面无从下手，甚至程序员在没有把页面运行起来之前，也无法判断页面显示出来的样子。
美工管美工的事，jser管jser的事，界面与编码分离不是我们所追求的吗
5、Javascipt/DHTML在不同的浏览器，在浏览器不同版本之间的表现差异很大
按w3c的推荐标准做，差异也不是很大，只是各有各的一些特点，应用程序也有跨平台，大家都一样，一般情况下，兼容都是程序员要考虑的问题6、一个富Javascipt/DHTML的页面开发效率是很低的，我的经验是，如果可以使用服务器端状态控制完成的需求，我用好几个页面，加上少量的服务器端代码可以在半天时间完成的工作，那么我如果单纯用Javascript来完成，可能一天都搞不定这个页面的控制(也许Javascript高手例外)
7、大面积运用Javascript，页面很难维护，甚至无法维护设计良好的代码还是很好维护的，而现在也有调试很方便的调试器，如果你大面积的运用（企业级），为何又不考虑用framework呢？现在成熟的框架很多。至少开发效率低的问题，第1，2点已经说明了。
把运算抛给用户终端，这种做法永远会存在，因为这是不同用户不同口味的需求，除非服务器硬件网络带宽已经达到我们没话说的阶段。那么用户终端就是一浏览器和某些个性化设定的参数存储器，数据通过网络传递给用户，通过用户的个性设定的参数来格式化输出，这些参数可能就是一个帐号解决问题，所有数据操作全部网络化，永远都不用考虑自己的电脑需要繁琐的重装系统，只要记住帐号密码，任何一个终端都是自己的电脑。在这之前每个家庭都会有一台中心服务器，处理着家庭私人的各种数据，包括空调当前的温度，未来中心服务器运营商才是家庭服务器的终结者。扯远了...
说的极是
谁叫我们选择了这行，没办法，只能多学习，学多了没有坏处，哪怕是过段时间淘汰了，程序思维还是可以借鉴的。
不要忘了，HTML之后还有XHTML，XHTML之后还有XML，
INTERNET是有惯性的，就像TCP/ip协议不是最好的传输协议，但却是最成功的技术，并且它也是不可能取代他的，只能兼容他，
所以像XHTML+CSS+DOM+JS这样的客户端技术是会以兼容的方式淡出市场，而不是被XX取代，那是不可能的，只能是它的扩展。如果真的RIA完全成功了，和传统的操作一样，那还要传统的操作干吗？那要Windows干吗？传统的操作系统照楼主的思维推断，也不要了。你直接去开发下N代的操作系统，看谁使用啊。
最后RIA的解决方案最终要被市场认可，不是哪一个人说的算的。也并不是哪个公司说的算的。
XHTML之类技术要淡出市场，这是一个非常长的过程。