一、在前端框架中運用 MVVM 模式

當下我們正處于通過使用用戶電腦的計算能力完成 Web 應(yīng)用業(yè)務(wù)邏輯執(zhí)行和交互內(nèi)容渲染的時代。在早期 Web 應(yīng)用中，開發(fā)人員將所有的業(yè)務(wù)邏輯都放在服務(wù)端執(zhí)行，客戶端則只負責內(nèi)容渲染。但是現(xiàn)在更多的 Web 應(yīng)用通過將 90% 左右的業(yè)務(wù)邏輯放在客戶端執(zhí)行來滿足離線應(yīng)用等需求。

雖然現(xiàn)代的前端框架給開發(fā)人員提供了各式各樣的開發(fā)模式。但所有主流的框架都對使用 MVVM 模式進行編碼提供了支持。例如：Angular 將 View 和 ViewModel 分離在 2 個獨立文件中（一個 HTML 文件和一個 TS 文件），React 則將 View 和 ViewModel 以組件的形式嵌入在一個 JSX 文件中。

掌握常規(guī) MVVM 模式的知識有助于你快速上手任何前端框架、編寫出簡潔的 UI 控制程序和可測試的代碼。一些開發(fā)人員可能會認為 React 既不是 MVVM 也不算 MVC，它只是一個用來操作 View 的庫。然而，它卻讓開發(fā)人員以 MVVM 的模式編寫代碼。因此掌握 MVVM 開發(fā)模式，有助于開發(fā)人員判斷哪些代碼應(yīng)該寫在 View 中，哪些代碼應(yīng)該寫在 Controller 中。

二、遵循一般可用性原則

一些在意用戶可用性的公司，會聘請 UI/UX 工程師參與到前端開發(fā)工作中，甚至有些公司還會成立 UX 團隊，專門用于提高公司產(chǎn)品的可用性。通常，UI/UX 工程師的主要工作是原型設(shè)計、可用性測試、CSS 和 HTML 編寫。然而，大多數(shù)公司的前端開發(fā)人員也會在工作中使用 CSS 和 HTML。

因此，對于前端工程師而言，不管團隊中是否有 UI/UX 工程師，掌握一些一般可行性原則，對其工作都是很有幫助的。例如：你不再需要問 UI/UX 團隊，一個確定按鈕應(yīng)該放在左邊還是右邊。一般可行性原則可以使我們的 Web 應(yīng)用更加產(chǎn)品化，更加用戶友好，更加凸顯為用戶考慮。

想象一下，每當你開始一個前端開發(fā)任務(wù)的時候，就需要考慮設(shè)計一致性、組件分類、元素排序、顏色、文本尺寸、文本樣式、動畫、響應(yīng)設(shè)計等因素。然而，大多數(shù)應(yīng)用的原型都沒辦法全部涵蓋。因此，非常有必要花時間學習下一般可用性原則。

三、編寫簡潔的異步代碼

使用 JavaScript 機可以寫出同步代碼也可以寫出異步代碼。眾所周知，JS 是單線程的。因此下面這段代碼就會讓瀏覽器卡頓幾秒。

所以我們需要高效利用 JavaScript 的線程機制。出于這個原因，大部分瀏覽器 API 的設(shè)計要么是基于事件機制要么是基于 promise 的異步機制。例如，當你使用 JS 創(chuàng)建一個 WebSocket 鏈接的時候，JavaScript 不會等待鏈接真正建立完成，就像下面代碼展示的那樣：

因此我們需要訂閱不同瀏覽器在不同時間執(zhí)行的事件，這導致我們的 JS 代碼變得非常復雜，所以要編寫簡潔的異步代碼還是比較困難的。在處理瀏覽器事件的時候，部分初級工程師傾向于使用 setTimeout 函數(shù)的延遲執(zhí)行來處理，而不使用合理的事件處理函數(shù)。這樣就會導致在諸如瀏覽器、弱網(wǎng)、低端設(shè)備等不同客戶端上，相同的代碼會出現(xiàn)各種各樣非預期的行為。

所以，盡可能將事件的處理函數(shù)放在一個獨立函數(shù)體內(nèi)，避免使用隨機延遲函數(shù)處理事件回調(diào)，在應(yīng)用上下文退出的時及時清除事件處理函數(shù)，不要使用老的回調(diào)模式，使用 async/await 模式（如果非要使用，請使用 promise 轉(zhuǎn)換下），避免在行內(nèi)事件處理中添加業(yè)務(wù)邏輯。

除此之外，經(jīng)常練習編寫簡潔的代碼是編寫簡潔的同步代碼的秘訣，下面的文章闡述了每個程序員都可以寫出簡潔的代碼。

四、熟悉瀏覽器 API 是 Web 應(yīng)用開發(fā)的必要條件

老版本的瀏覽器提供了基本的 DOM 操作 API。后來，由于 JavaScript 的流行，W3C 引入了許多現(xiàn)代 Web API。因此現(xiàn)在我們可以通過使用客戶端存儲、原生 HTTP 客戶端、語音合成、消息通知等 API 來構(gòu)建更加用戶友好的 Web 應(yīng)用。與此同時，現(xiàn)代瀏覽器在 DOM 操作和渲染上的支持上也比以前更加的智能和全面。

例如，以前我們并沒有很好的方法來處理 DOM 元素尺寸變化的事件，而現(xiàn)在我們只需要使用 ResizeObserver API 就能完成。在處理 RESTful 數(shù)據(jù)請求上，現(xiàn)在我們可以使用更輕量的 Fetch API 完成，而不再需要使用老的基于 XHR 的第三方庫（沒錯，Axios 也是基于 XHR 的）。

因此，在說“這個在用戶瀏覽器中是無法實現(xiàn)的”這句話之前，我們最好先查看下最新的瀏覽器 API?，F(xiàn)在我們可以利用 WebAssembly API 在客戶端瀏覽器中運行一些高 CPU 消耗的任務(wù)。同時我們還可以利用 web workers 編寫多線程的 JavaScript 操作?，F(xiàn)在幾乎沒有人使用 IE11 訪問現(xiàn)代的 web 應(yīng)用了，所以在使用正式階段（非試驗階段）的 web api 時，不必考慮再三。

五、理解前端的局限性

不知道你是否關(guān)注過慢而臃腫的 Web 應(yīng)用程序？由于諸如冗余 UI 元素、靜態(tài)資源未做 CDN 加速、沉重的第三方庫或框架等原因，Web 應(yīng)用通常會變的慢而臃腫。與此同時，如果你將大量的業(yè)務(wù)邏輯放在客戶端執(zhí)行，也會導致 Web 應(yīng)用渲染的比較慢。在不阻塞 JS 線程的情況下，將一些數(shù)據(jù)的排序和篩選放在客戶端是沒問題的，否則就需要將這些數(shù)據(jù)處理的操作放在服務(wù)端或者數(shù)據(jù)庫。

雖然 JavaScript 通過非阻塞操作提供了一種類似并行的機制，但一個瀏覽器實例在同一時間點是不能同時完成 2 個 JavaScript 操作的，因此大量的數(shù)據(jù)操作會必然會讓你的 Web 應(yīng)用變的很慢。除此之外，過多的事件處理也會影響使 Web 應(yīng)用變慢。所以需要確保事件處理的高效性，而且在應(yīng)用上下文退出的時候，也要及時清理事件處理函數(shù)。

相對于基于云計算的后端服務(wù)，客戶端的資源是非常有限的?，F(xiàn)在，人們依然在使用低端或中端的終端設(shè)備訪問互聯(lián)網(wǎng)。因此，一旦你在客戶端實現(xiàn)了比較重的功能時，就需要關(guān)注 Web 應(yīng)用程序的內(nèi)存占用描述文件。例如：下面的內(nèi)存占用描述文件給出了 YouTube 在視頻播放期間，其內(nèi)存使用的信息。只需將下面的內(nèi)存使用統(tǒng)計數(shù)據(jù)與您正在構(gòu)建的 Web 應(yīng)用程序的內(nèi)存使用情況進行比較即可。

以上即是本次分享的全部內(nèi)容了，希望對你有所幫助，對編程感興趣的小伙伴們可以前往六星云課堂獲得更多相關(guān)資訊哦~