像了解爱人一样了解ExtJs

投入项目前先做好功课 

EXT无疑是最近前端开发最受关注的话题。在近一年的YUI-Ext 0.30/ExtJS 1.X开发之后，上周五ExtJS又推出它的升级版本2.0，而更多的开发者也参与到前端开发这一领域来。 在Web2.0/Enterprise2.0声势、日益强调用户体验的情况下，选择EXT是否明智？这些都需要开发者慎重决策。

项目参与EXT切忌盲目 
    据资深IT分析人士表示，目前界业内的Ajax热浪，一方面是由于2005年以来的Google一线产品使人带来极大的用户体验，另一方面来自对旧事物新改造的关注。

    第一只“出海”的YUI-Ext只是作者Jack打算对基于BSD协议的Yahoo!UI库进行自定义的扩展，但后来一度风头盖过其父辈YUI，足以说明大家对它的热情，很多人把它投入项目人并不十分了解它。分析人士打了一比喻：就好比尚未谋面， 并不了解一个人的家庭、教育、品行等背景，只因为他有一副精致漂亮的外观，就对其陷入了疯狂的倾慕之中。因此分析人士建议，在投入项目前，要认真仔细地了解EXT的内在原理和与其他Ajax库不同地方。

               Ext的UI组件模型和开发理念脱胎、成型于Yahoo组件库YUI和Java平台上Swing两者，并为开发者屏蔽了大量跨浏览器方面的处理。相对来说，EXT要比开发者直接针对DOM、W3C对象模型开发UI组件轻松。

Ajax库各有不同 
    目前业界中Ajax库的主要是服务端系（服务端生产JS代码）和原生系（直接浏览器的JS代码控制），有消息说今后各JavaScript库团队也准备推出UI产品。不同的“家族”背景，决定了它们开发的Ajax库应用与风格的不同。

    从数目上来看，目前服务端系的Ajax库如（DWR、GWT、MS Ajax.Net）占据相当的市场份额，是较多用户的选择。

    原生系的Ajax库近期也迅猛发展，在ExtJS顺利试水之后，jQuery的UI库也已经发行，Mootools则在年底之前推出，其它元老如Dojo也在积极筹备新版1.0。

    原生系的Ajax开发在我国还是个新生事物，目前推出的Ajax库IDE支持方面普遍不足，需要大量的手工编码，各种浏览器之间的调试工具也不尽相同，属于较小开发者所掌握的技能，风险和人力成本都会相对比较高。

    今后如果各JavaScript库团队推出自己的UI组件库，－－由于大多数是开源的项目，因此其文档是否完善，案例、范例是否足够多，是否易于使用，都属于选型的相关指标。相对来说其社区越旺盛，其风险也就越小。

    研究不同类别的Ajax库，开发者可以知道它的投入项目价值和怎么迎合自身开发需求，而各测试报告、DEMO演示则比较可以帮助开发者分析风险收益，进而根据客户需求目的、预期和风险承受能力，来选择心仪的一个库。比如为快速将数据生成到前端，适合选择服务端系的产品； 而追求较佳的用户体验，对界面设计，用户交互操作有一定要求者，则可以EXT、Dojo专业UI库来实现。而希望学习成本低的开发者，可以使用微软的Ajax.Net库，允许方便地“可视化编程”。

决定实施之前多作比较 

    实际上，目前关于是否应该封装EXT“控件”存在着两种完全不同的意见。已有实践开发EXT经验的朋友甚至原作者Jack都表示，手工JS编码更适合EXT开发，这样各组件的耦合颗粒度更细，项目整体的灵活度机会高。而另一派的观点则认为，在Java/.Net的大背景下，多数开发者希望利用IDE或类似VB的GUI“画出”控件这样强大的支持来解决表示层的方案，以提供工作效率；另一方面，大量JavaScript投入项目产生，开发者会因JavaScript另外一本质－－－基于函数式编程（LISP但是C语法系）的困惑而对项目设计而大打折扣，我们没有道理离开熟悉的领域到陌生的地方去冒险。

    由于绝大多数EXT产品的都在实践和测试之中，因此，国内的开发者确实需要慎重思考，认真研读相关JS库的文档和资料，并将其与自己熟悉的JS库比较，确实了解其风险与客户需求再作决定。

    另外对于打算购买商业许可的用户，开发者还需要注意不同的商业的价格是不一样的。每种许可一般分为仅源码、源码＋技术支持和1.x的升级。而企业级的EXT许可证的门槛更高，大多在两万元人民币以上。

许可解读 
    EXT使用双重协议，其中之一是基于LGPL 3.0协议进行许可，另外是针对技术支持的商业许可。

    而很多用户对EXT协议的理解目前暂时还是“雾里看花”。

    按照官方网站的有关解析，如果商业使用不付费也是可以的，只要项目遵守LGPL 3.0的开源协议。
             
“Are using Ext in a commercial application that is not a software development library or toolkit, you will meet LGPL requirements and you do not wish to support the project”

    “如果您应用Ext在一个商业应用中（即商业应用不是作为软件开发库或工具箱，一般可以认为是第三方组件），您可以参见LGPL要求（如果你不想支持Ext项目）”。

就是说，如果只是把extjs包含在自己的项目中，而且这个项目是不是卖给用户做二次开发的工具箱，或组件库，就可以遵守LGPL协议免费使用。你可以不用为ext的发展而捐赠一分钱。

楼主的标题有点耸人，难道是翻译来的？我个人认为还没有哪一个ajax库需要像了解爱人一样去了解。。。我自己的项目那也是像了解儿子一样了解。。。

BTW，楼上这个抢沙发只能给一星了。

插一句话，ror对前端的封装粒度过细，也就适合封装prototype和scriptaculous这样的工具库，象extjs, jquery-ui（不是jquery）, dojo这样的完整组件库，应该用更大粒度的封装方式，可惜现在没有人做这件事。

hax老大言重了。在下是看到frank老大在群里发的留言，才过来看一下。估计只比hax老大早点提交了几秒吧？

爱人这个说法，其实我挺理解的，没女朋友只好把代码当爱人啦。比如在下。。。


虽然不知道ror在前端是如何操作的，但感觉extjs做的前端基本可以脱离后台依赖，只需要提供对应格式的json就可以跑得好好的。在下正在用extjs+java做个东西，数据调用都是使用的json，前台基本上只有html了。

这是一个新闻发布，还处在很初级的阶段，有兴趣的话，过来一起研究一下
http://code.google.com/p/anewssystem/

不是说你，那个抢沙发的已经被隐藏了。

顺便补充一下，如果ext像爱人，那prototype像什么？小情人？还有jquery、mootools、dojo、mochikit……

建议选择一个小项目来作为练习或评估，许多东西还是需要通过实际做才能体会到。

直接做OA集成项目，开发速度增快45%，原来需要三个合作，现在一个人就可以承担所有的工作，而且开发时间也缩短了

ajax库越来越多，而且每个js库的实现机制有各有不同，用起来确实不象java库那么轻松。这个是现在最郁闷的事情，给你一个java库你上手，拿到手上有API心里面有底，而JS库心还悬着...

这个标题怎么那么熟悉．．．
像了解爱人一样了解ie ->精华
像了解爱人一样了解ExtJs ->支持->精华