【IT168 专稿】“Ajax技术在哪里？”，人们谈到Zend框架的时候，经常会问及这一个问题。我认为这是人的一种天性：大多数人对项目的一些基本东西并不会过多关注，例如MVC设计模式的实现，以Lucene为核心的搜索引擎，缓存组件等。他们想要的是更吸引人的闪亮的东西，他们想要Ajax。而且他们不想花大力气来了解它。

    在过去的十个月里，各种应用程序框架纷纷创建了自己的Ajax组件，都开始宣称自己兼容Web 2.0了。它们之所以这样做，是因为它们没有考虑自己是否应该这样做，而只是关心了它们有没有能力这样做。毫无疑问，这种做法将导致一些问题的发生。

    在我自己的应用程序中，为了决定是否应用一个改变，我通常如此考虑。首先，这种改变是必要的么？假若是，选择是很明显的；假若不是，我继续问自己以下问题。这种改变会带来某种好处么？它将对现有的应用程序造成什么伤害么？诸如此类，等等，以此来确定应用这一改变是否是一个正确的选择。

    自然，这些通用的问题也适合于来检验我们今天讨论的话题，下面让我们依次来确认一下这些问题。

    首先，采用Ajax是必要的么？应用程序框架通常被设计成服务器端编程。除了通过GET、POST或其他方法来请求一个指定网址，或者对结果进行解释外，Ajax与服务器还有另外的交互内容么？没有；这个过程与一个标准的Web请求完全相同。因此从服务器的角度出发，Ajax并没有做什么新鲜的事。因此采用Ajax不是一种必须的选择。

    其次，采用Ajax是有益的么？大多数Ajax组件包装了JavaScript库，像Script.aculo.us或Dojo等，甚至它使用了和JavaScript同样的方法名称。对于那些基本了解Javascipt的人来说，使用Ajax内的JavaScript库节省了大量时间，不过事实真如此么？对于那些不了解JavaScript的人来说，不明白一项技术的工作原理就把它嵌入到应用程序中，这种做法明智么？笔者看来，最好还是花上几天的时间来了解一下JavaScript和XMLHttpRequest背后的原理，然后选择一个最能满足你的需要和编程风格的JavaScript库。

    当你只能直接写JavaScript代码的时候，为什么不选择使用Wicket框架用Java语言编写更多的程序代码呢？

    据我所知，这些组件中的大多数之所以存在，是因为开发者可以藏在使用它们喜爱的语言编织成的“茧”中，从而感到非常舒服，而不用冒风险去尝试另一种语言。这在Java开发者中是一个普遍存在的态度，正如Google Web工具集所展示的那样。尽管它有一些好处，但是坦白来讲，使用它的真正理由就是不用写一行JavaScript代码。JavaScript如此差劲么？以致于要使用另一种语言来编译它才是更好的选择？尤其是现在还存在像Firebug这样优秀的编译器。