[專業術語]AJAX

AJAX即“Asynchronous JavaScript and XML”（非同步的JavaScript與XML技術），指的是一套綜合了多項技術的瀏覽器端網頁開發技術。Ajax的概念由Jesse James Garrett所提出。
傳統的Web應用允許使用者端填寫表單（form），當提交表單時就向Web伺服器傳送一個請求。伺服器接收並處理傳來的表單，然後送回一個新的網頁，但這個做法浪費了許多頻寬，因為在前後兩個頁面中的大部分HTML碼往往是相同的。由於每次應用的溝通都需要向伺服器傳送請求，應用的回應時間依賴於伺服器的回應時間。這導致了使用者介面的回應比本機應用慢得多。
與此不同，AJAX應用可以僅向伺服器傳送並取回必須的資料，並在客戶端採用JavaScript處理來自伺服器的回應。因為在伺服器和瀏覽器之間交換的資料大量減少（大約只有原來的5%），伺服器回應更快了。同時，很多的處理工作可以在發出請求的客戶端機器上完成，因此Web伺服器的負荷也減少了。
類似於DHTML或LAMP，AJAX不是指一種單一的技術，而是有機地利用了一系列相關的技術。雖然其名稱包含XML，但實際上資料格式可以由JSON代替，進一步減少資料量，形成所謂的AJAJ。而客戶端與伺服器也並不需要非同步。一些基於AJAX的“派生／合成”式（derivative/composite）的技術也正在出現，如AFLAX

優缺點：
使用Ajax的最大優點，就是能在不更新整個頁面的前提下維護資料。這使得Web應用程式更為迅捷地回應使用者動作，並避免了在網路上傳送那些沒有改變的資訊。
Ajax不需要任何瀏覽器外掛，但需要使用者允許JavaScript在瀏覽器上執行。就想DHTML應用程式那樣，Ajax應用程式必須在眾多不同的瀏覽器和平臺上經過嚴格的測試。隨著Ajax的成熟，一些簡化Ajax使用方法的程式庫也相繼問世。同樣，也出現了另一種輔助程式設計的技術，為那些不支援JavaScript的使用者提供替代功能。
對應用Ajax最主要的批評就是，它可能破壞瀏覽器的後退功能。在動態更新頁面的情況下，使用者無法回到前一個頁面狀態，這是因為瀏覽器僅能記下歷史記錄中是靜態頁面。一個被完整讀入的頁面與一個已經被動態修改過的頁面之間的差別非常微妙；使用者通常都希望單擊後退按鈕，就能夠取消他們的前一次操作，但是在Ajax應用程式中，卻無法這樣做。不過開發者已想出了種種辦法來解決這個問題，當中大多數都是在使用者單擊後退按鈕訪問歷史記錄時，通過建立或使用一個隱藏的IFRAME來重現頁面上的變更。（例如，當使用者在Google Maps中單擊後退時，它在一個隱藏的IFRAME中進行搜尋，然後將搜尋結果反映到Ajax元素上，以便將應用程式狀態恢復到當時的狀態。）
一個相關的觀點認為，使用動態頁面更新使得使用者難於將某個特定的狀態儲存到收藏夾中。該問題的解決方案也已出現，大部分都使用URL片斷識別符號（通常被成為錨點，即URL中#後面的部分）來保持追蹤，允許使用者回到指定的某個應用程式狀態。（許多瀏覽器允許JavaScript動態更新錨點，這使得Ajax應用程式能夠在更新顯示內容的同時更新錨點。）這些解決方案也同時解決了許多關於不支援後退按鈕的爭論。
進行Ajax開發時，網路延遲——即使用者發出請求到伺服器發出響應之間的間隔——需要慎重考慮。如果不給予使用者明確的回應，沒有恰當的預讀資料，或者對XMLHttpRequest的不恰當處理，都會使使用者感到厭煩。通常的解決方案是，使用一個視覺化的元件來告訴使用者系統正在進行後臺操作並且正在讀取資料和內容。

開發挑戰及解決方案：
對程式設計師而言，開發Ajax應用最頭痛的問題莫過於以下幾點：

• Ajax在本質上是一個瀏覽器端的技術，首先面臨無可避免的第一個問題即是瀏覽器的相容性問題。各家瀏覽器對於JavaScript/DOM/CSS的支援總有部分不太相同或是有Bug，甚至同一瀏覽器的各個版本間對於JavaScript/DOM/CSS的支援也有可能部分不一樣。這導致程式設計師在寫Ajax應用時花大部分的時間在除錯瀏覽器的相容性而非在應用程式本身。因此，目前大部分的Ajax連結庫或開發框架大多以js連結庫的形式存在，以定義更高階的JavaScript API、JavaScript物件（模板）、或者JavaScript Widgets來解決此問題。如prototype.js。

• Ajax技術之主要目的在於區域性交換客戶端及伺服器之間的資料。如同傳統之主從架構，無可避免的會有部分的業務邏輯會實現在客戶端，或部分在客戶端部分在伺服器。由於業務邏輯可能分散在客戶端及伺服器，且以不同之程式語言實現，這導致Ajax應用程式極難維護。如有使用者介面或業務邏輯之更動需求，再加上前一個JavaScript/DOM/CSS之相容性問題，Ajax應用往往變成程式設計師的夢魘。針對業務邏輯分散的問題，Ajax開發框架大致可分為兩類：

• 將業務邏輯及表現層放在瀏覽器，資料層放在伺服器：因為所有的程式以JavaScript執行在客戶端，只有需要資料時才向伺服器要求服務，此法又稱為胖客戶端（fat client）架構。伺服器在此架構下通常僅用於提供及儲存資料。此法的好處在於程式設計師可以充分利用JavaScript搭配業務邏輯來做出特殊的使用者介面，以符合終端使用者的要求。但是問題也不少，主因在第一，JavaScript語言本身之能力可能不足以處理複雜的業務邏輯。第二，JavaScript的執行效能一向不好。第三，JavaScript訪問伺服器資料，仍需適當的伺服器端程式之配合。第四，瀏覽器相容性的問題又出現。有些Ajax開發框架如DWR企圖以自動生成JavaScript之方式來避免相容的問題，並開立通道使得JavaScript可以直接呼叫伺服器端的Java程式來簡化資料的訪問。但是前述第一及第二兩個問題仍然存在，程式設計師必須費相當的力氣才能達到應用程式之規格要求，或可能根本無法達到要求。

• 將表現層、業務邏輯、及資料層放在伺服器，瀏覽器僅有使用者介面引擎（User Interface engine）；此法又稱為瘦客戶端（thin client）架構，或中心伺服器（server-centric）架構。瀏覽器的使用者介面引擎僅用於反映伺服器的表現層以及傳達使用者的輸入回到伺服器的表現層。由瀏覽器所觸發之事件亦送回伺服器處理，根據業務邏輯來更新表現層，然後反映回瀏覽器。因為所有應用程式完全在伺服器執行，資料及表現層皆可直接訪問，程式設計師只需使用伺服器端相對較成熟之程式語言（如Java語言）即可，不需再學習JavaScript/DOM/CSS，在開發應用程式時相對容易。缺點在於使用者介面引擎以及表現層通常以標準元件的形式存在，如需要特殊元件（使用者介面）時，往往須待原框架之開發者提供，緩不濟急。如開原始碼Ajax開發框架ZK目前支援XUL及XHTML元件，尚無XAML之支援。

Ajax是以非同步的方式向伺服器提交需求。對伺服器而言，其與傳統的提交窗體需求並無不同，而且由於是以非同步之方式提交，如果同時有多個Ajax需求及窗體提交需求，將無法保證哪一個需求先獲得伺服器的響應。這會造成應用程式典型的多程式（process）或多執行緒（thread）的競爭（racing）問題。程式設計師因此必須自行處理或在JavaScript裡面動手腳以避免這類競爭問題的發生（如Ajax需求未響應之前，先disable提交按鈕），這又不必要的增加了程式設計師的負擔。目前已知有自動處理此問題之開發框架似乎只有ZK。