AJAX

AJAX 即 “Asynchronous JavaScript and XML”（非同步的 JavaScript 與 XML 技術），指的是一套綜合了多項技術的瀏覽器端網頁開發技術。Ajax 的概念由傑西・詹姆士・賈瑞特所提出。

傳統的 Web 應用允許使用者端填寫表單（form），當送出表單時就向網頁伺服器傳送一個請求。伺服器接收並處理傳來的表單，然後送回一個新的網頁，但這個做法浪費了許多頻寬，因為在前後兩個頁面中的大部分 HTML 碼往往是相同的。由於每次應用的溝通都需要向伺服器傳送請求，應用的回應時間依賴於伺服器的回應時間。這導致了使用者介面的回應比本機應用慢得多。

與此不同，AJAX 應用可以僅向伺服器傳送並取回必須的資料，並在客戶端採用 JavaScript 處理來自伺服器的回應。因為在伺服器和瀏覽器之間交換的資料大量減少，伺服器回應更快了。同時，很多的處理工作可以在發出請求的客戶端機器上完成，因此 Web 伺服器的負荷也減少了。

類似於 DHTML 或 LAMP，AJAX 不是指一種單一的技術，而是有機地利用了一系列相關的技術。雖然其名稱包含 XML，但實際上資料格式可以由 JSON 代替以進一步減少資料量。而客戶端與伺服器也並不需要非同步。一些基於 AJAX 的 “派生／合成” 式（derivative/composite）的技術也正在出現，如 AFLAX。

應用

運用 XHTML+CSS 來表達資訊；
運用 JavaScript 操作 DOM（Document Object Model）來執行動態效果；
運用 XML 和 XSLT 操作資料
運用 XMLHttpRequest 或新的 Fetch API 與網頁伺服器進行非同步資料交換；
注意：AJAX 與 Flash、Silverlight 和 Java Applet 等 RIA 技術是有區分的。

發展史

20 世紀 90 年代，幾乎所有的網站都由 HTML 頁面實現，伺服器處理每一個使用者請求都需要重新載入網頁。這樣的處理方式效率不高。使用者的體驗是所有頁面都會消失，再重新載入，即使只是一部分頁面元素改變也要重新載入整個頁面，不僅要重新整理改變的部分，連沒有變化的部分也要重新整理。這會加重伺服器的負擔。

這可以用非同步載入來解決。1995 年，JAVA 語言的第一版釋出，隨之釋出的的 Java applets（JAVA 小程式）首次實現了非同步載入。瀏覽器透過執行嵌入網頁中的 Java applets 與伺服器交換資料，不必重新整理網頁。1996 年，Internet Explorer 將 iframe 元素加入到 HTML，支援區域性重新整理網頁。

1998 年前後，Outlook Web Access 小組寫成了允許客戶端指令碼傳送 HTTP 請求（XMLHTTP）的第一個元件。該元件原屬於微軟 Exchange Server，並且迅速地成為了 Internet Explorer 4.0 的一部分。部分觀察家認為，Outlook Web Access 是第一個應用了 Ajax 技術的成功的商業應用程式，併成為包括 Oddpost 的網路郵件產品在內的許多產品的領頭羊。但是，2005 年初，許多事件使得 Ajax 被大眾所接受。Google 在它著名的互動應用程式中使用了非同步通訊，如 Google 討論組、Google 地圖、Google 搜尋建議、Gmail 等。Ajax 這個詞由《 Ajax: A New Approach to Web Applications》一文所創，該文的迅速流傳提高了人們使用該項技術的意識。另外，對 Mozilla/Gecko 的支援使得該技術走向成熟，變得更為簡單易用。2006 年 4 月 5 日，全球資訊網聯盟 (W3C) 釋出了 XMLHttpRequest 物件的第一個規範草案，試圖建立正式的 Web standard 標準。XMLHttpRequest 物件的最新草案於 2016 年 10 月 6 日釋出，XMLHttpRequest 規範現已成為現行標準。

Ajax 前景非常樂觀，可以提高系統性能，最佳化使用者介面。Ajax 現有直接框架 AjaxPro，可以引入 AjaxPro.2.dll 檔案，可以直接在前臺頁面 JavaScript 呼叫後臺頁面的方法。但此框架與表單驗證有衝突。另外微軟也引入了 Ajax 元件，需要新增 AjaxControlToolkit.dll 檔案，可以在控制元件列表中出現相關控制元件。

優缺點

使用 Ajax 的最大優點，就是能在不更新整個頁面的前提下維護資料。這使得 Web 應用程式更為迅捷地回應使用者動作，並避免了在網路上傳送那些沒有改變的資訊。

Ajax 不需要任何瀏覽器外掛，但需要使用者允許 JavaScript 在瀏覽器上執行。就像 DHTML 應用程式那樣，Ajax 應用程式必須在眾多不同的瀏覽器和平臺上經過嚴格的測試。隨著 Ajax 的成熟，一些簡化 Ajax 使用方法的程式庫也相繼問世。同樣，也出現了另一種輔助程式設計的技術，為那些不支援 JavaScript 的使用者提供替代功能。

對應用 Ajax 最主要的批評就是，它可能破壞瀏覽器的後退與加入收藏書籤功能。在動態更新頁面的情況下，使用者無法回到前一個頁面狀態，這是因為瀏覽器僅能記下歷史記錄中的靜態頁面。一個被完整讀入的頁面與一個已經被動態修改過的頁面之間的可能差別非常微妙；使用者通常都希望單擊後退按鈕，就能夠取消他們的前一次操作，但是在 Ajax 應用程式中，卻無法這樣做。不過開發者已想出了種種辦法來解決這個問題，HTML5 之前的方法大多是在使用者單擊後退按鈕訪問歷史記錄時，透過建立或使用一個隱藏的 IFRAME 來重現頁面上的變更。（例如，當用戶在 Google Maps 中單擊後退時，它在一個隱藏的 IFRAME 中進行搜尋，然後將搜尋結果反映到 Ajax 元素上，以便將應用程式狀態恢復到當時的狀態）。

關於無法將狀態加入收藏或書籤的問題，HTML5 之前的一種方式是使用 URL 片斷識別符號（通常被稱為錨點，即 URL 中 #後面的部分）來保持追蹤，允許使用者回到指定的某個應用程式狀態。（許多瀏覽器允許 JavaScript 動態更新錨點，這使得 Ajax 應用程式能夠在更新顯示內容的同時更新錨點。）HTML5 以後可以直接操作瀏覽歷史，並以字串形式儲存網頁狀態，將網頁加入網頁收藏夾或書籤時狀態會被隱形地保留。上述兩個方法也可以同時解決無法後退的問題。

進行 Ajax 開發時，網路延遲 —— 即使用者發出請求到伺服器發出響應之間的間隔 —— 需要慎重考慮。如果不給予使用者明確的回應，沒有恰當的預讀資料，或者對 XMLHttpRequest 的不恰當處理，都會使使用者感到厭煩。通常的解決方案是，使用一個視覺化的元件來告訴使用者系統正在進行後臺操作並且正在讀取資料和內容。

相容性

JavaScript 程式設計的最大問題來自不同的瀏覽器對各種技術和標準的支援。

XmlHttpRequest 物件在不同瀏覽器中不同的建立方法，以下是跨瀏覽器的通用方法：

// Provide the XMLHttpRequest class for IE 5.x-6.x:

// Other browsers (including IE 7.x-8.x) ignore this

// when XMLHttpRequest is predefined

var xmlHttp;

if (typeof XMLHttpRequest != "undefined") {xmlHttp = new XMLHttpRequest ;

} else if (window.ActiveXObject) {

var aVersions = "Msxml2.XMLHttp.5.0", "Msxml2.XMLHttp.4.0", "Msxml2.XMLHttp.3.0", "Msxml2.XMLHttp", "Microsoft.XMLHttp";

for (var i = 0; i

AJAX 支援的瀏覽器有：Internet Explorer、Chrome、Firefox、Opera、Konqueror 及 Mac OS 的 Safari。但是 Opera 不支援 XSL 格式物件，也不支援 XSLT。

開發挑戰及解決方案

對程式設計師而言，開發 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 送出按鈕），這又不必要的增加了程式設計師的負擔。