AppML 歷史
1999 年，Refsnes Data 開發了 AppML 的第一個版本。
那時，AppML 已經基於 Web 客戶端和 Web 伺服器之間的 HTTP 請求通訊。後來，這種方法以 AJAX 而聞名。
2000 年 9 月，為一位大型挪威客戶啟動了一個開發專案。該專案旨在僅使用 AppML，將一個龐大的資訊系統（約 300 個應用程式）從 Windows 桌面應用程式轉換為現代 Internet 應用程式。
基於 AppML 的系統於 2001 年上線，比計劃提前數月，成為世界上第一個商用 AJAX 應用程式。該專案取得了巨大成功，與普通的 Web 開發相比，開發時間縮短了 75%。自那時以來，又增加了新應用程式，該系統現在覆蓋了 1000 多個正在執行的應用程式。
2015 年 2 月，W3Schools 將 AppML 作為新產品重新發布，並向公眾開放。
AppML 設計目標
- AppML 應用程式必須透過 Internet 執行
- AppML 應用程式必須是平臺獨立的
- AppML 應用程式必須僅使用 Internet 標準（HTML、CSS、JavaScript）
- AppML 應用程式必須支援各種應用程式需求
- AppML 應用程式必須是自描述的
- AppML 應用程式必須易於開發、維護和更改
- AppML 應用程式必須是面向未來的
以下段落描述了 Refsnes Data 最初（1999 年）關於未來 Web 應用程式的設想。
可執行檔案將消亡，JavaScript 將永存
可編譯的可執行檔案（從 C 或 Java 等語言編譯而來）無法在不同硬體上執行。
可執行檔案（EXE 檔案、ActiveX 和 COM 物件、DLL 檔案）是阻止開發可在 Internet 上執行的應用程式的元件。
未來的應用程式將不使用或依賴於安裝在客戶端計算機上的可執行檔案或任何其他元件。
我們的建議
使用純 HTML、CSS 和 JavaScript 編寫您的未來應用程式。
確保您的未來應用程式可以在任何 Web 瀏覽器中執行。
Web 應用程式將成為 Internet 服務
歷史上充滿了大型、定製化的應用程式。其中許多很快就消亡了，因為它們無法適應需求的變化。
應用程式應靈活、通用，並能優雅地適應變化，而不會被破壞或摧毀。
應用程式應能從每天支援少量請求擴充套件到支援數百萬個請求。
應用程式應能從一個伺服器擴充套件到多個伺服器，或在伺服器之間移動，而不會中斷應用程式。
應用程式應能與其他應用程式協作。
應用程式不應包含大量程式碼。
應用程式應分解為更小的服務，易於建立和維護。
應用程式應為一組 Internet 服務，能夠響應提交的 Internet 請求並返回資料。
應用程式應透過標準 Internet 協議請求服務，而無需與伺服器保持永久連線。
我們的建議
使用基於 Internet 的 SOA（面向服務的架構）編寫您的未來應用程式。
使您的應用程式服務通用且靈活，並準備好響應不同型別的請求。
未來的應用程式將易於建立和編輯
客戶端和伺服器將以易於理解的方式交換資料。
如果可能，應用程式將不會被編碼。
應用程式將透過編輯模型建立和修改，而不是透過編輯程式碼。
應用程式描述將可供人類閱讀。
應用程式描述將是自描述的。
應用程式將由使用者編寫，而不是程式設計師。
我們的建議
使用人類可讀的文字檔案描述服務，並透過執行這些描述來提供服務。
使用文字檔案（如 JSON 檔案）來描述應用程式。
使用文字檔案（如 JSON 檔案）來交換資料。
使用 HTML、CSS 和 JavaScript 來執行應用程式。
三個小 Web 開發者...
很久以前，有三個小 Web 開發者在開發一個新的網站。
1. 第一個 Web 開發者使用的是 AppML。
2. 第二個 Web 開發者使用的是他最喜歡的伺服器程式語言。
3. 第三個使用的是專業的企業 Web 開發框架。
第一個 Web 開發者在兩天內就有了可執行的演示。與使用者協作後，在一週內就完成了令人興奮的原型。經過兩週的測試，一個智慧、快速、易於使用的網站就可以釋出了。
第二個 Web 開發者用了 6 個月才完成他的網站。但 WWW 改變了要求，他並不滿意。由於他的專案包含太多程式碼，他無法進行重大更改。於是他開始開發第 2 版。
第三個 Web 開發者從未完成他的工作。專業 Web 開發框架非常難以使用，非常難以理解，幾乎無法測試。
