1.该来的终究会来，出来混，总是要还的。
什么都不懂，也许过得还会快乐些，无须天天学习。:-)
2.思路和产品都是好的，但是只能运行在windows上的东西，难成气候。微软借鉴了很多开源社区的成果，开源社区也会学习，超越微软。
就像myan自己说的微软犯了战略错误，战略错误不仅在断了adobe的生意，更重要的是把自己囚禁在独立王国里，就像唐朝以后的中国，依旧辉煌，依旧领先，却不属于世界。
微软老了。
3.
以开发者的视角看，这项技术的确让人激动。
以用户的视角看，这要求：
* 我们安装WPF的runtime
* 以微软一贯的伎俩，这个runtime最多向前支持到XP，而2000之类将被抛弃
* Vista内置runtime，不过从XP 2001年推出到现在，仍是2000和XP对分天下的局面来看，Vista的用户基数增长不是很乐观
* 最核心的问题是：WPF这项技术提高用户体验、提高系统交互性能否超越HTML+CSS+AJAX还是个问题，说实在的优秀的CUI(Console UI)程序的交互性比GUI程序的交互性强了去了。
结论：5年后我们再看，不过五年后变数仍是未定。
Google现在是致力于打造自己的超级计算服务器端，MS从一种邪恶的角度来收拢对开放者的控制权，一个内修，吸引用户，一个外张，控制开发者，鹿死谁手，再看吧……
总之，现在越来越不喜欢MS，强迫大家升级硬件和操作系统，硬件升级带来的好处都被操作系统占了便宜，CPU和内存都被OS用了去，这样用来解决用户问题的资源就少了，邪恶阿！！
4.
诚然，从纯技术的角度来看，我们也早就认为XUL/XAML一类使用XML来描述界面组件和布局的技术肯定是Web界面开发技术的发展趋势。W3C今年成
立了一个工作组，希望将XUL、XAML、MXML等几种界面描述语言统一为一种标准的格式（http:
//www.w3.org/2006/appformats/）。所以我们认为孟岩老师所看到的趋势是没有大问题的。从纯技术的角度来看，将来的Web界
面开发肯定会发展到这种技术。
5.
软件开发并不是流水线式生产。分工应该适当，分工太细，不同层次之间沟通的成本就会迅速上升。这又回到了
《人月神话》中的命题：主要的成本在于沟通的成本。依靠细致的分工降低对开发人员素质的要求，实现流水线式生产，创造大批软件蓝领，这本身就是一个幻想。
Ruby解决问题的思路与此是不同的，Ruby的思路是提高抽象的层次，使得一个开发人员有能力承担更多功能的开发。
总结了以上众人之言,我想说的是：
当以开发人员为本，得开发人员者得天下。
另：
http://www-128.ibm.com/developerworks/cn/linux/l-enhydra/index.html
2.1.2 一流的表示技术
XMLC的简洁和强悍，奠定了它在表示技术中的领先地位。
- 使用Enhdyra XMLC，界面设计人员和后台程序开发人员可以很好地分工协作。界面设计人员几乎可以任意修改用户界面而不会影响后台程序开发人员，反之亦然。
- 使用Enhydra XMLC，界面设计人员和后台程序开发人员只需要在项目开始时一起商定需要动态修改的元素及其ID值，其后就几乎不需要相互碰头了，分头去实现就可以。
- 使用Enhydra XMLC，界面设计人员不需要任何的Java知识，只需要专注于界面设计即可。
- 使用Enhydra XMLC，后台程序人员只需要极少的HTML等标记语言知识，只需要专注于动态内容的显示控制和业务流程的设计即可。
- 使用Enhydra XMLC，可以使用任何你熟悉的HTML编辑软件，因为XMLC没有引入任何额外的标记元素。Enhydra XMLC中所重用的ID元素，是HTML
4.0及其以上版本的标准元素。
- Enhydra XMLC把页面(HTML，XML，WML等)转换有对等的Java类(DOM树)，就意味着可以从面向对象的角度来操纵整个页面。
- 使用Enhydra XMLC，使得同时支持WML，XHTML，cHTML/i-mode，voiceXML，J2ME变的非常简单。
引自:
http://ajaxcn.org/forum/posts/list/304.page