AJAX不应该只是EXT

我觉得楼上二位对ext的理解有点偏差 或者说不够全面

我的看法倒是EXT在某种程度上阻碍了大部分较传统的美工的发挥，因为对EXT组建的美术风格的修改，需要较好的CSS基础和很强的耐心。
不然一个padding或者margin的数字错误，就及其容易把组件弄乱。很多细节上的图片拼接也比较讲究。

如果不去修改，就很容易做出同质化的东西：“一看就是EXT做的，没意思”
但是修改有一定难度。

制作ext的风格 需要修改(或者说只能修改)的 只是 和颜色 图片相关的东西
至于 padding margin border width height ... 这些东西
如果不是对ext超级了解 还是不要动的好

组件化就为避免重新造轮子。

现在看来,对EXT越来越没信心了,其实只想用其中的GRID,哎,国产的,美工的确不如人家的,没办法呀
Ext3,到时又象Ext2一样,根本不能向下兼容,那就晕头了

关于EXT这种组件库啊。。嗯。。美工问题

其实我一直设想可以做这样的事情。。不是很简单的，涉及的东西比较多。。
但是通过团队努力应该可行。。

做成这样的东西。。整个产品软件包里包含的不是一堆堆的js文件库
而是一个能够运行的GUI应用程序，作为脚本库的定制工具。

通过此处，能够设定一些基本的组件默认参数。（解决实际使用时经常要更改参数的问题）
用类似换肤的方式（灵活地设定图片，拖拽改变组件元素的大小等）定制所有界面上的美工效果。（解决美工很不容易参与，不容易做出个性化界面的问题）
选择需要的组件，根据组件逻辑相关性载入所有关联组件。（解决库引入，体积等的问题）
最后进行工程“编译”，编译出的结果就是需要的定制打包好的js组件库

真是越说越像flex。。不过flex编译出来的东西是flash。。
理论上，是可以做出类似的东西，编译出来的结果是javascript的。

事实上以上说的很多东西都有不同的组件库作了一些。只是没有全部做到。
如果想做一个比EXT更厉害，更killer的组件库。真的可以这么来做。
（如果能编译成flash，javascript，silverlight等多种东西的话。。啧啧）

不过这水太深了。一个人是不敢去淌的。。况且淌完了，有多大的商业回报。。未知数。。
EXT的作者已是个英雄了，还有没有新的英雄呢？

对于通常的应用来说，用Ext做快速开发是相当不错的啦（特别是做Demo），而且做出来效果也比较好（看）。

我认为楼主的担忧也不是没有道理，AJAX开发应该可以更加多样化，目前还是有不少处女地等待着开垦的，还有许多领域等待着深入的，如果讨论总是来源于项目需求，而且总是点到即止的话，对于水平的提高是比较有难度的。

对于像Ext这样的组件库，我是又爱又恨啊，喜欢那样方便地构造应用的使用方式，不喜欢它跟样式设计绑定得太死，出于对设计的执着，我始终希望有着自己的设计。

一直都极度渴望有一个可以让这两者解耦开来的方案，目前正着手研究，希望能让程序专心干它该干的事情，让设计更加自由而丰富多彩。

做个广告 如果你只想使用grid 你可以试一试 GT-GRID 呵呵

虽然我承认ext是一件很牛的作品，但我还是一直觉得ext这种东东的存在是历史的倒退。

M$十多年前就在尝试把web界面带入桌面，如Active Channel，DHTML form等，看重的就是web界面灵活和多样化的布局，特别对于信息阅读这样的场合。

象outlook express，norton antivirus等诸多软件都采用了这个思路，大量程序虽然没有直接在窗口内嵌入浏览器来实现界面，却也通过其它方式实现了一定的BS界面的体验。

许多年前就看过bindows这种东东，把treeview/listview/toolbar/menu/dialog等东西从桌面搬到浏览器里面，当时除了赞叹一声真牛之外，却没觉得有什么前途，另外一个体验是：慢。

如今ext似乎把bindows的遗志发扬光大了，追捧者日增，但除了在线邮箱这样的类CS应用外，我看不到它存在的价值（即使是在线邮箱我也更喜欢OLD STYLE的HTML界面，而不是看起来象桌面程序的ajax界面）。

有人可能会说用ext也可以做得不象CS风格的界面，但那样用它相当于拿电钜去切豆腐，既发挥不了电钜的功能，也不称手，还可能把手指切掉。。

楼上的观点是基于 互联网应用的角度吧?

其实在企业应用中 有太多的东西都比你所说的在线邮箱更加"类CS应用"