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/