个人不建议企业级应用使用Extjs。
原因如下：
1、体积过于庞大。经过极限压缩（连GZIP静态压缩都用上）后，仍然有109KB的体积，这还未包括其依赖的基础库。企业级应用有一个最为重要的性能指标就是系统能够支持的并发数量，并且是初次加载的。拿最为典型的大集中方式的部署为例，某企业总部对地方的专线带宽2MB（国情如此），每季度需要各地市分支机构进行一次报表填报工作，很可能填报时间为2天（防止各分支机构有充裕的时间修改数据），这种情况，就会出现大并发的初次加载。几万人同时用仅有2MB的带宽用来下载109KB的Extjs，必然完蛋。
2、企业级WebAPP对于可用性的需求通常并不高，良好的业务功能组织和设计实现要比控件的可用性重要的多。JIVE，JIRA和Confluence都是非常优秀的纯粹的Thin Client Webapp，它们的成功是建立在优秀的业务功能组织和设计实现上，而不是靠Grid和Split Button抑或是DD。相对于Desktop Style APP来说，Web UI的固有特点和最大的优势正是它的开放和灵活，如果使用Ext，很可能会使UI设计师和可用性设计人员束手束脚迷失了Web UI设计的方向。
3、毫不客气的说，Extjs（甚至Javascript）能做的事儿，JSP Tag一样能做，而且更加安全有效——JSP Tag的逻辑是你无法洞察的，而JS代码无论隐藏的多好也是无法遁形的（大不了看IE cache）。Web前端架构设计的根本目标就是在Server和Client这两者之间寻找一个最适合自己的完美平衡。Ext毫不掩饰的把Clients端能实现的工作全部交由自己去实现，虽然大幅度减轻了Server端的压力（某些时候甚至让人觉得Server只是个DataSource而已），同样的，也让Server变得无所事事而Client痛苦不堪。实际的硬件情况呢？国内很多企业，客户机硬件环境并不是很好，而Server的能力却仍有富余。4C8G的小型机随处可见，你却很难找到一台512MB内存的客户机，大多数企业都是这样。目前来看，完全把工作交由Client来做是一种十分冒险的行为，浏览器的各种兼容性问题和隐含的危机（鬼才知道为什么同样的JS代码在他的浏览器上不好用）是一个深渊，我们敬而远之都来不及呢，哪还敢铤而走险。正是Ext的这种大包大揽的方式搞得Web前端架构设计师无所适从，Tag封什么？几段简短Ext的控件定义么？那还封Tag做什么？做成AK那样？晕。。。
4、Ext的Skins是最吸引我的部分，也是最让人头疼的部分，这就好像给你一幢竣工的大楼，让你来装修，虽然Ext提供了Template方法。但毕竟任何人都没有太多的精力去做那些Template，大多数时候我们仍然是在修改Skin涉及的CSS和Image，因此，我们仍然是在做装修。面对用户千差万别的需求，Flexiable在Ext面前嘎然而止，问题很严重，UI设计师很无奈。
5、你甚至可以把Ext理解为一门全新的表现层用户界面描述语言，从语法上来讲，它背离XML的Mark描述界面的方式（例如XUL、HTML），也背离了Javascript（Javascript最传统的定义就是，HTML定义了文档结构和数据，CSS控制文档的外观表现，而Javascript可以修改前两者）。很难想象，一个企业级WebAPP如果用Ext来开发的话，设计开发表现层的员工离职会给企业带来多大的风险和困难。
如果让我来作出选择的话，我更倾向于充分利用客户端浏览器可以实现的功能，少做复杂的扩展（比如Grid，企业级应用仅仅需要在某些情况下支持Lock Header的功能，如果你能提供Lock column和Inline Editing用户很可能会高兴的跳起来）。选用JS基础库（我更喜欢Mootools）的唯一目的就是使用其OO的基础支持，Cross Browser的基础支持，XHR、DD、Selector。可以大幅度的减少代码冗余，优化代码结构，减低Bug出现的几率，仅此而已。
而且，即使要用，也需要自己实现一个Adaptor，尽可能不让引入的Framework对应用有较强的侵入，这样，一旦选用的Framework出现问题，也便于及时更换。
同时，在Tag中只做纯粹的Thin Client实现（我指的是纯粹的HTML Contrl），以便适应某些大并发的窄带用户的需求（甚至需要考虑PDA用户）。然后，通过construct的方式将HTMl的控件构建成包含丰富交互方式的自定义控件。
总而言之，企业级WebAPP的前端架购设计绝非控件和组件库的问题，控件好并不一定是真的好。我认为，Ext更适合做Web Mail等对可用性要求非常高的OPOA应用，而并不适合用在大型企业级WebAPP上。
BTW：小弟初来乍到，很喜欢Javaeye的氛围，非常希望能跟各位同行交流经验，共同提高。
原因如下：
1、体积过于庞大。经过极限压缩（连GZIP静态压缩都用上）后，仍然有109KB的体积，这还未包括其依赖的基础库。企业级应用有一个最为重要的性能指标就是系统能够支持的并发数量，并且是初次加载的。拿最为典型的大集中方式的部署为例，某企业总部对地方的专线带宽2MB（国情如此），每季度需要各地市分支机构进行一次报表填报工作，很可能填报时间为2天（防止各分支机构有充裕的时间修改数据），这种情况，就会出现大并发的初次加载。几万人同时用仅有2MB的带宽用来下载109KB的Extjs，必然完蛋。
2、企业级WebAPP对于可用性的需求通常并不高，良好的业务功能组织和设计实现要比控件的可用性重要的多。JIVE，JIRA和Confluence都是非常优秀的纯粹的Thin Client Webapp，它们的成功是建立在优秀的业务功能组织和设计实现上，而不是靠Grid和Split Button抑或是DD。相对于Desktop Style APP来说，Web UI的固有特点和最大的优势正是它的开放和灵活，如果使用Ext，很可能会使UI设计师和可用性设计人员束手束脚迷失了Web UI设计的方向。
3、毫不客气的说，Extjs（甚至Javascript）能做的事儿，JSP Tag一样能做，而且更加安全有效——JSP Tag的逻辑是你无法洞察的，而JS代码无论隐藏的多好也是无法遁形的（大不了看IE cache）。Web前端架构设计的根本目标就是在Server和Client这两者之间寻找一个最适合自己的完美平衡。Ext毫不掩饰的把Clients端能实现的工作全部交由自己去实现，虽然大幅度减轻了Server端的压力（某些时候甚至让人觉得Server只是个DataSource而已），同样的，也让Server变得无所事事而Client痛苦不堪。实际的硬件情况呢？国内很多企业，客户机硬件环境并不是很好，而Server的能力却仍有富余。4C8G的小型机随处可见，你却很难找到一台512MB内存的客户机，大多数企业都是这样。目前来看，完全把工作交由Client来做是一种十分冒险的行为，浏览器的各种兼容性问题和隐含的危机（鬼才知道为什么同样的JS代码在他的浏览器上不好用）是一个深渊，我们敬而远之都来不及呢，哪还敢铤而走险。正是Ext的这种大包大揽的方式搞得Web前端架构设计师无所适从，Tag封什么？几段简短Ext的控件定义么？那还封Tag做什么？做成AK那样？晕。。。
4、Ext的Skins是最吸引我的部分，也是最让人头疼的部分，这就好像给你一幢竣工的大楼，让你来装修，虽然Ext提供了Template方法。但毕竟任何人都没有太多的精力去做那些Template，大多数时候我们仍然是在修改Skin涉及的CSS和Image，因此，我们仍然是在做装修。面对用户千差万别的需求，Flexiable在Ext面前嘎然而止，问题很严重，UI设计师很无奈。
5、你甚至可以把Ext理解为一门全新的表现层用户界面描述语言，从语法上来讲，它背离XML的Mark描述界面的方式（例如XUL、HTML），也背离了Javascript（Javascript最传统的定义就是，HTML定义了文档结构和数据，CSS控制文档的外观表现，而Javascript可以修改前两者）。很难想象，一个企业级WebAPP如果用Ext来开发的话，设计开发表现层的员工离职会给企业带来多大的风险和困难。
如果让我来作出选择的话，我更倾向于充分利用客户端浏览器可以实现的功能，少做复杂的扩展（比如Grid，企业级应用仅仅需要在某些情况下支持Lock Header的功能，如果你能提供Lock column和Inline Editing用户很可能会高兴的跳起来）。选用JS基础库（我更喜欢Mootools）的唯一目的就是使用其OO的基础支持，Cross Browser的基础支持，XHR、DD、Selector。可以大幅度的减少代码冗余，优化代码结构，减低Bug出现的几率，仅此而已。
而且，即使要用，也需要自己实现一个Adaptor，尽可能不让引入的Framework对应用有较强的侵入，这样，一旦选用的Framework出现问题，也便于及时更换。
同时，在Tag中只做纯粹的Thin Client实现（我指的是纯粹的HTML Contrl），以便适应某些大并发的窄带用户的需求（甚至需要考虑PDA用户）。然后，通过construct的方式将HTMl的控件构建成包含丰富交互方式的自定义控件。
总而言之，企业级WebAPP的前端架购设计绝非控件和组件库的问题，控件好并不一定是真的好。我认为，Ext更适合做Web Mail等对可用性要求非常高的OPOA应用，而并不适合用在大型企业级WebAPP上。
BTW：小弟初来乍到，很喜欢Javaeye的氛围，非常希望能跟各位同行交流经验，共同提高。
8067
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
