JavaScript Web 應用最佳實踐分析

【編者按】本文作者為 Mathias Schäfer，旨在回顧在客戶端大量使用JavaScript 的最佳 Web應用實踐。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

對筆者來說，JavaScript 社群似乎已經陷入了一個時間扭曲隧道。我們現在進行的關於 JavaScript驅動(JavaScript-driven) Web 應用的討論與2006年“Ajax”出現以及2012年JavaScript“單頁應用”流行起來時的討論如出一轍。只要我們站在巨人的肩膀上努力改進已有的最佳應用，那麼，繼續這樣的討論就是有意義的。

最近，Stefan Tilkov大放厥詞，寫了一遍名為“為什麼我憎恨單頁應用”的文章。文中提出了針對 JavaScript 網路應用的大膽斷言和概括性表述。作為一個對漸進式增強興趣強烈的人，看到這篇關於漸進式增強的粗劣分析，筆者感到很失望。

多一些JavaScript Web應用，少一些單頁應用。

首先，筆者認為“單頁應用”是一個由來已久的錯誤概念，最終招來了對該概念的批評。筆者個人使用術語“JavaScript網路應用”來描述在客戶端延伸使用JavaScript的網路應用，就像典型地使用Ember，React和Angular打造的應用一樣。在上一篇貼文中，筆者寫了一個簡短的“單頁應用”定義，但是其實應該使用“JavaScript網路應用”這一術語：

一個“JavaScript網路應用”指的是一個擁有複雜介面來提供高水平互動性的網站。互動性的很大部分都通過客戶端的JavaScript實現，而且一些互動只能通過JavaScript實現。

有時候，HTML 需要在客戶端進行渲染 ，但是並非必須。實際上，所有HTML程式碼或者至少其初始結構都需在伺服器端渲染。

此類應用能避免使用者每次輸入後都進行伺服器往返，而是讓HTTP伺服器在後臺發出請求來發布動作或是載入新資料。

繼續閱讀…

傳承最佳應用實踐

2003年，Pamela Fox的一次綜合性講話描述了一個網路應用從使用者和開發者角度來說必須滿足的要求。該講話基本確立了大量使用JavaScript的網路應用的最佳實踐。

今天，大型的JavaScript框架擁抱的便是這些最佳實踐。我們在2006年和2012年遇到的大多數問題已經在今天得到了解決。我們能夠開發出在瀏覽器端動態呈現且快速可及的網站。使用漸進式增強（progressive enhancement），我們能夠開發出健壯的JavaScript網路應用，保證其可用性 。

JavaScript網路應用並無特別之處，它們也僅僅是全球資訊網中的一些超文字節點。因此和傳統的網站一樣需要建造在URLs上，故而連線和書籤功能都一樣。實際上，該問題早在2010到2012年間就得到了解決，那時瀏覽器和庫已經支援HTML5 history API。

更好的JavaScript網路應用

毫無意外，一些JavaScript網路應用並沒有遵循這些最佳應用實踐。網路協議棧中的任意一項技術可以說都是如此，如HTML或伺服器端程式語言。我們要搞明白為什麼一些網站不遵循最佳應用實踐。

是因為這個概念使其難以應用魯棒性原則嗎？那麼，讓我們改進最佳應用實踐，改善指南、庫和工具。面對表現不佳的JavaScript網路應用，解決措施並不是完全擯棄，而是建立更好的應用。

為什麼我們要再次開發JavaScript Web應用？

十年前，網路創造者嘗試弄明白本地應用的使用者互動如何工作及其能提供哪些益處。為了效仿桌面應用的“豐富性和響應性”，它們將一些特定的已有模式應用於網路。

今天，我們需要回顧克服伺服器往返和整頁重新整理的使用者互動所具備的優勢。我們只能通過已有的前端技術來提升使用者體驗。因此，我們需要確定能夠且應該在客戶端JavaScript改善的互動。

JavaScript是在瀏覽器中開發良好互動性的最佳技術。然而，對於客戶端JavaScript開發者來說，最為重要的技能是決定什麼時候不使用客戶端JavaScript來解決問題。在協議棧中解決問題總是更加魯棒。

從漸進式增強的角度來看，化解傳統伺服器端應用和JavaScript網路應用之間膚淺的二分法很有必要。從傳統伺服器端應用到依賴JavaScript應用的轉變需要做到無縫。我們需要找到開發高架構同時又不失去低構架優勢的方法。“通用JavaScript” 框架就是這樣一個充滿希望的方法。

Web 應用架構

筆者想評價一下Stefan Tilkov關於網路應用構架的設定：

“在這個架構方法中（一個傳統的非JavaScript網路應用），很明顯，實際的業務邏輯責任完全依賴於伺服器。……業務邏輯不屬於客戶，除非你願意不厭其煩地處理每種你所支援（你不僅需要在伺服器端維護處理，還請記住，你永遠不能信任客戶）客戶的繁瑣邏輯。”

這話並沒有錯，但是JavaScript網路應用自身並沒有複製業務邏輯。

業務邏輯是建立在資料之上的一系列高水平操作。例如建立、閱讀、更新和刪除記錄（CRUD），更新記錄之間的關係，查詢、轉換或是合併記錄以滿足某個特殊的請求。

通常，業務邏輯存在於伺服器程式碼中。資料最終在伺服器中進行處理，因而資料應該是一致的，你也無法輕易篡改這裡的程式碼和資料儲存。所有的身份驗證、認證以及安全檢查都在此處進行。

一般來說，這個伺服器程式碼提供一個能由多個客戶（如網路或本地客戶）使用的HTTP REST介面（API），這些客戶一般都含有介面邏輯。

在伺服器和客戶之間共享邏輯

舉個例子，輸入驗證是片灰色區域。為了一致性，API伺服器擁有對認證的最終話語權。然而，就算只是簡單的輸入驗證都能提高使用者的體驗。這能及時地給出反饋，而不用讓使用者等待伺服器請求和使用者介面的更新。

這就將我們引向了著名的邏輯共享問題。該問題存在於每個無需客戶為每次使用者操作進行伺服器往返的客戶端伺服器端軟體構架中。這個問題既不是JavaScript網路應用獨有，也不會因為不使用客戶端JavaScript就能避免。

與簡單地禁止在客戶端實現有用的邏輯相反，讓我們從方便使用者的角度來談一談分享特定邏輯。再次說明，該問題不僅涉及JavaScript網路應用，還與所有從架構上與API伺服器分開的客戶端有關。

其實，有很多實用的方法可用於實現客戶與伺服器之間的邏輯共享。在表格驗證的例子中，我們可以用中立的、陳述性的格式如JSON或XML來描述規則。每個客戶都有粘結程式碼（glue code）以便讀取和應用針對特殊使用者介面的規則。

用客戶端-伺服器架構取代單一結構

Tilkov寫道：

“SPA（單頁應用）方案導致問題的一個絕佳例子就是並行工作。如果你有一個多人團隊甚至是天理不容地擁有多個團隊處理同一個SPA，你需要想出一個好辦法來做支援這個專案。或者，你也可以讓每個團隊都開發他們自己的應用。每個應用都能由相同的組織（如果你願意的話，這也可以適用於其他任何網路應用）在同一時間連線起來 —— 實際上，這依賴於網路的核心力量”

筆者沒有在此看出問題。實際上，有更大的團隊以及多個團隊在為構建真實世界的JavaScript應用而努力。Tilkov似乎將JavaScript構架與一般的獨石構架相混淆了。以筆者的經驗來看，JavaScript網路應用是鬆散聯絡的REST服務的最佳搭檔。

如果你有一個面向服務的構架，使用相同的API，不同的團隊可以開發出各異的並行客戶端。這些客戶端是JavaScript網路應用、傳統網路應用或是本地應用都沒有關係。這些客戶端可以使用URL或安卓上的Intents等機制相互連線。

JavaScript應用的可及性

在JavaScript社群中，可及性這一議題一直以來都處於被忽視的狀態，而且在更大的網路開發社群中繼續遭到忽視。為了提供當今網路應用的可及性，我們需要有意義的批評和建議。這也是為什麼筆者對下面這種直言感到失望：

“就可及性而言，在伺服器端使用語義HTML提供了一個絕佳的便利支援。”

這話太具有誤導性。在伺服器端使用HTML並不會提高可及性或語義更加明顯。不管是你在伺服器端或是在瀏覽器中使用HTML，你都需要寫出可及的語義標記。

其實，可及性在伺服器端呈現與客戶端呈現之間存在差異：在客戶端呈現的魯棒性相對較差，因為你對客戶的控制非常有限。但是一旦HTML被解析至DOM，可及性就變得一樣了。

在使用JavaScript來顯示、隱藏、插入或改變內容時，對可及性有特殊的要求。幾乎所有的JavaScript都會執行這些任務。如果每次內容發生變化時你沒有重新整理頁面，就需要使用WAI-ARIA技術來引導使用者。而一些特定的如標籤（tab）和動態對話（modal dialog）控制需要特殊的ARIA標記和人工調節管理。

有價值的JavaScript網路應用

關於Tilkov的文章，筆者最無法苟同的是他認為JavaScript網路應用沒有用處：

“[我所知的單頁應用]都十分腫脹且載入緩慢，即使它們需要展示的資訊和提供的互動十分簡單。[…]”

“在我所知道的幾乎所有案例中，你們的[單頁應用]對使用者來說毫無益處，而實際上，還有很多瀏覽器特性值得擁抱。”

雖然，可能的確存在簡單互動的JavaScript網路應用，但是僅通過寥寥幾屏，你無法看出其中的複雜程度。

筆者每天接觸的大多數具有成熟瀏覽器互動的網路應用是用JavaScript開發的，而且只能用JavaScript開發：Flickr、Youtube、Facebook、Twitter、GMail等等。很有可能，你每天去逛的網站也都是由JavaScript支援的。你可能還沒有注意到這點，因為它們依照最佳實踐“就行得通”。

這些網站給使用者帶來了極大的益處。最終，每個軟體、每個資訊系統都應該允許使用者簡單快速可及地執行任務。這應該引導你的構架決策。

通過否認JavaScript對使用者體驗做出的巨大貢獻，Tilkov推崇了一個筆者認為相當落後的漸進式增強。漸進式增強應該擁抱技術進步並承認使用者的利益，但同時保證使用的技術具備魯棒性與相容性。

JavaScript網路應用“在網上”

正如Greg Babiars所說：“看到這些談論細微技術差別、討論使用者體驗，還聲稱某種方法能解決所有需求的貼文，我的心很累。”

JavaScript網路應用已經被證明用處頗大，不會消失不見。因此我們不要再羞辱JavaScript了。在前端工具棧中，JavaScript必不可少。為了使用者的利益，我們需要討論的是何時如何正確地使用它。

我們需要停止以“網路本來的樣子”為由而排擠JavaScript。和其他的網站一樣，JavaScript應用也“屬於網路”。網路潛力巨大，而我們的工作才剛剛開始。

網路最初是作為“檔案檢索系統”而被發明的，我們需要感謝通用訪問一類的理念。但同時，網路還是一個“應用交付系統”。讓我們儘量地調和使用這兩種方法，而不是忽略或排擠其中一個。

本文系 OneAPM 工程師編譯呈現。OneAPM Browser Insight 是一個基於真實使用者的 Web 前端效能監控平臺，能夠幫大家定位網站效能瓶頸，網站加速效果視覺化；支援瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁面。想閱讀更多技術文章，請訪問 OneAPM 官方技術部落格。

本文轉自 OneAPM 官方部落格

原文地址：http://molily.de/javascript-web-apps/