當我們第一次聽到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，提供了一個完全的面向對象的語言，因為它是相當標准的，浏覽器執行將還算是兼容。另外客戶端類庫也已經掩飾了浏覽器的大部分不兼容性。
客戶端支持者認為他們的方法能夠更好的使用本地計算機資源，這樣也導致在應用程序中能取代傳統的桌面應用程序。即使沒有一個持久的網絡連接。
有經驗的認為每一個方法都有其利弊，如果你開發一個全新的胖客戶端應用程序，就不得不選擇或者是瘦客戶端或者是客戶端-服務器模型。