最近几年Ajax应用程序开发出现了两种截然不同的方法，每一种方法都对以前的结构模型进行扩展。由于两种方法性质看起来是不同的，所以在实际应用程序的开发中应选择其中一种。

    当我们第一次听到Ajax这个术语的时候，我们的第一反应可能就是其较高的Web页面交互性。至少在JavaScript中的Web应用程序部分必要的代码提供交互性，虽然在Ajax应用程序意义方面都有一致的意见，但对于开发者如何与JavaScript进行交互或者如何在客户端与服务器之间分配显示逻辑有一些分歧。

    最近几个月，在Artima中报道了几个Java中心胖客户端框架，目的在于完全的隐藏开发者与JavaScript进行交互。这些框架将JavaScript集成到了JSF组件中，从而作为一个工具来处理JavaScript，其中的细节对开发者来说是隐藏的。利用JSF服务器端表现模型的优势，基于Ajax的JSF在客户端呈现出组件的状态。

    相反，Ajax在个别的客户端组件工具包中有优势，像Dojo或者 Prototype不仅将JavaScript呈现给用户，而且对开发者来说开发页面类型的应用程序更加容易。例如Dojo工具包提供许多API，这些API模拟J2SE API的重要部分，像收集和验证器。另外UI工具，这样的应用程序将不仅起显示逻辑的作用，甚至一些在客户端上业务逻辑，这些业务逻辑将会使用JavaScript来进行编码。与服务端进行交互将会被限制在这样的情况，即客户端应用程序必须与外部的资源进行交互，例如，提取数据到客户端或者保存用户的变化到数据中去。

    因为基于Ajax的JSF方法执行在服务器端的展现层并且将Ajax的特性融进到组件中去，这看起来像瘦客户端的一个扩展，并且是传统的Web应用程序的直接派生，这种方法的细微的共同点是Sun Ray瘦客户端设备，这种瘦客户端设备在服务器端显示桌面图片，客户端处理至多一个专门的显示。第二种方法是一个客户端-服务器的扩展，以至于在客户端和服务器之间显示应用程序的逻辑。在Ajax中，客户端是一个可编程的Web浏览器。

    这两种犯法都是建立在良好的实践基础上的，在应用程序开发中是不同的体系，瘦客户端涉及到在浏览器中JavaScript执行的不兼容性，他们很少涉及到是否瘦客户端模型是首选的即使所有的浏览器能够很好的显示JavaScript.

    然而，JavaScript在开发逻辑方面仍然是比较困难的，在一个新的版本， EcmaScript 4，提供了一个完全的面向对象的语言，因为它是相当标准的，浏览器执行将还算是兼容。另外客户端类库也已经掩饰了浏览器的大部分不兼容性。

    客户端支持者认为他们的方法能够更好的使用本地计算机资源，这样也导致在应用程序中能取代传统的桌面应用程序。即使没有一个持久的网络连接。

    有经验的认为每一个方法都有其利弊，如果你开发一个全新的胖客户端应用程序，就不得不选择或者是瘦客户端或者是客户端-服务器模型。