在過去的2016年，很多前端的框架都越來越穩定，也被廣泛應用于各大移動端產品中。關于移動 Web ，去年發生了兩件大事，一個是微信小程序引起的熱議，另一個就是讓眾多開發者位置迷醉的谷歌推PWA。種種跡象都表現出移動 Web 的更多可能性。

現狀及問題

盡管網絡速度正在變得越來越快，但是移動 Web 頁面的體積也越來越大。單頁面應用的體積在加載時，仍然值得我們好好研究——如何更快展示用戶需要的內容，而不是讓用戶在頁面加載的過程中等待著讓他們離開。除了使用服務端渲染來優化初次體驗，我們還需要設置緩存，使用一些技術策略來加快用戶打開的速度。

然而，我們仍然還面臨著一堆亟需解決的問題。比如在服務端采用微服務架構來加速開發，當我們需要在一個頁面里請求大量 API 時，微服務架構就會成為一個新的問題。當用戶在請求過程中切換頁面時，就需要中斷大量 Promise 請求。因此就需要使用 GraphQL 或 Falcor 這樣的 API 框架來減少客戶端 API 請求。

安全問題

除去上面這些內部因素，移動 Web 應用還飽受外部因素困擾。在2016年，我們發現越來越多的移動站點正深受運營商劫持的影響，由于 HTTP 協議是明文的，而流量都要經過運營商，因此運營商可以輕而易舉地在頁面中植入廣告。這時，解決問題的有效辦法就是全站 HTTPS。與此同時，對于安全的考慮也仍然值得注意。我們意外地發現一些移動 Web 網站只在前臺做了數據校驗，而缺少后臺的數據檢驗，這會帶來相當大的安全隱患。

冗余代碼

前端項目正在變得越來越臃腫，體積讓人難以接受。在缺乏單元測試的項目里，維護這樣的一個前端項目正在變得舉步維艱。當后臺走向微服務的同時，前端走向微前端也變得可以接受。一個應用程序可將基本需求分解為不同的幾個前端頁面，如面向用戶、面向管理員。

盡管已經有了如 React 這樣的 CSS in JS 的框架，維護 UI 組件仍然是一個相當大的考驗。移動 Web 對于屏幕大小有更高的要求，響應式設計會帶來更多代碼。樣式代碼數量的增加，對于前端的樣式架構有了更大挑戰。如我們所見 SCSS 或 SASS 這樣的 CSS 預編譯器可以帶來更少的代碼，而對于項目中的新人來說，仍然是個問題——在項目進行過程中，我們往往關注于如何更快地交付功能。

相似地，我們也可以在社區開發的開源庫上看到一些“微前端”趨勢。借助于 ES6 的模塊化功能，我們可以在項目中只 import 所需的函數，在使用 webpack 打包的過程中也會刪去那些不需要的模塊。過去我們使用一個庫的某個方法時，可能就會考慮直接創建一個類似的庫，而不是引入——原因是這個庫對于應用來說太大了。

框架和工具

從傳統 Web 網站到單頁面應用遷移的個難題是：是否真的需要單頁面應用？單頁面應用更多的是帶來用戶體驗的提升，然而很多網站并不需要這種變化，大部分網站只需要支持更好的響應式設計。

在上一個項目里，我們使用了 React 來替換之前的桌面及移動站點。除了代碼老舊之外，還有部分原因：業務變更時需要修改三份代碼。舊有的舊面網站代碼可以追溯到2010以前，難以維護；移動站點是在2013年底創建的，使用當時流行的 Backbone + Mustache + Require.js 技術棧；與此同時還有手機 App。

當我們決定做一個移動單頁面應用時，就需要開發考慮對于技術方案的選擇。

框架選型

而在過去的一年里，開發人員在做技術選型時，發生了一些有趣的變化。首先是 React 對于大部分的開發人員來說，存在學習曲線比較陡峭的問題，JSX、虛擬 DOM、組件化、同構等，使其無法成為短期項目的；其次是 Angular 2.0 的跳崖性升級，使得相當多的開發人員無法選擇 Angular.js 1.x 的版本，而2.0在接近年底才完成，且周邊的組件還有待完善；因此，我們發現 Vue.js 由于其簡單并且容易上手，在今年顯得特別受歡迎。

2016年里，在移動和桌面 Web 使用 Angular.js，移動端使用基于 Angular.js 的 Ionic 框架是非常不錯的技術選型。Ionic 擁有相當多設計優美的 UI 組件，這些組件可以讓我們輕輕松松地做出移動應用。并且，我們也可以和 Web 端共用 filter、directives、services 等的內容。相信在2017年，Angular 2.0 搭配基于 Angular 2.0 的 Ionic 仍然是好選擇。

我們也可以使用 React 框架來做類似的事。盡管有相當多的開發者選擇使用了 React Native，但是這不意味著我們需要在移動端使用它。在移動端使用 Cordova + React 也是一個不錯的選擇——既然可以使用 React 做響應式設計來匹配不同的屏幕大小，那么也可以很輕松地使用 Cordova + React 來達到同樣的目的。

同理于 Vue.js，盡管 Weex 還不是很成熟，但是使用 Cordova + Vue.js 也仍然不錯。

開發工具越來越完善

在過去的一年里，我們發現能選擇的開發工具越來越多。不同的開發商都在不斷創造開發工具，這些工具可以幫助我們編寫出更好的代碼，開發出符合用戶需求的軟件。 

現在市面上的主流前端開發工具都已經可以支持 ES6、TypeScript，并且不同的瀏覽器對于 ES6 的支持力度也在提高，Edge、Firefox、Chrome 對于 ES6 特性的支持度均在90%以上，而 Safari 瀏覽器則達到了。這也意味著對于面向 iOS 的移動 Web 應用，可以很隨意地在這些設備上使用 ES6 語言了。

并且各瀏覽器對于移動設備的調試能力都在不斷提高。在開發移動 Web 頁面時，我們使用 Chrome 瀏覽器來匹配移動設備。而在新版本的 Safari 里也提供了“進入響應式設計模式”的功能，它可以模擬常見 iPad、iPhone 顯示網頁，甚至可以模擬 iPhone 橫屏。

Adobe 在今年推出了 UX 工具 Experience Design（官方縮寫XD），可以為 UX 設計師快速創建出用于移動設備的網站或者應用程序。這個工具除了具備響應式設計能力，還可以實現簡單的 App Demo，如在桌面上點擊某個頁面跳轉，并具備有頁面間跳轉的效果。這可以讓開發者更容易理解產品的設計原型，創建出更符合需求的產品。

更好的用戶體驗

對于在早期已經采用單頁面應用的團隊來說，他們面臨的一項新挑戰是：如何提供更好的用戶體驗。

更好的交互體驗

相當有意思的一點是，我們發現業務人員對于移動 Web 的要求更高了，他們希望有著類似于移動應用的用戶體驗。過去，在移動 Web 領域使用 Tap 事件來代替 Click 事件只是一個開始——使用 FastClick 這樣的庫來規避 Click 事件的延遲。

手勢交互： 下拉時刷新在移動 Web 上已經不是新鮮的事，我們還要類似于微信的左右滑動切換不同的頁面，除此還會有旋轉、縮放等功能。

適配屏幕大小： 對于移動設備來說，屏幕是個大問題，應用既要支持 iPhone 這樣的小屏幕，還要匹配上 iPad 這樣的設備。可以使用媒體查詢來解決，但設置合適的字體還是問題。px、em 已經很難滿足要求了，我們還需要 rem 這樣可以根據網頁的根元素來設置字體大小的單位。

更流暢的體驗

過去，我們關注的移動 Web 流暢度主要集中于緩存。當緩存已經成為了業界的通用模式時，人們便開始尋求更多的解決方案。如對于流量來自 Google 的網站來說，他們可以使用 Accelerated Mobile Pages（AMP）技術來加快網頁的加載，這可以為新聞和博客網站帶來更快的訪問速度。

與桌面相比，移動 Web 頁面對流暢度有著更高的要求，這主要是受限于移動設備。盡管新 iPhone 提供了相當快的處理能力，各大 Android 設備生產商在競爭中也在不斷提高設備的處理能力，但是仍然有相當多的用戶使用舊版移動設備。

在移動網頁上，除了采用支持 Virtual DOM 的框架來提高性能，還可以采用 Virtual Scroll 機制——只渲染足夠填充 Viewport 大小的數據集，頁面滾動時再渲染新數據，以此改善移動端列表頁面數據過多的問題。

除了對于頁面本身的優化，還有相當多的內容是對于資源和 API 優化。Facebook 創建了 GraphQL 來減少 API 的請求，一次請求多個需要的 API；Netflix 創建了 Falcor 來合并多個數據源。這些都可以加快移動應用的響應速度，除此我們還注意到 Service worker 開始受到開發者追棒。

Service worker 是在 Web 應用和瀏覽器與網絡之間的代理服務器，旨在創建更好的離線體驗。并且可以依據當前網絡是否可用、服務器是否有內容更新來采取合適的策略。同時它還支持通知推送及后臺 API。