談談前端工程化 js加載

paulli3 發布于2019-08-23 17:15 / 1692人閱讀

摘要：當年的加載在沒有前端工程化之前，基本上是我們是代碼一把梭，把所需要的庫和自己的代碼堆砌在一起，然后自上往下的引用就可以了。而且對于前后端的技術要求較高，所以對于項目未必是最有效的方案。

當年的 js 加載

在沒有前端工程化之前，基本上是我們是代碼一把梭，把所需要的庫和自己的代碼堆砌在一起，然后自上往下的引用就可以了。
那個時代我們沒有公用的cdn，也沒有什么特別好的方法來優化加載js的速度。最多用以下幾個方案。

可用的性能方案

可以在代碼某些需要js的時候去使用 loadjs 來動態加載 js 庫。這樣就不會出現開始時候加載大量js文件。

再大點的項目可能用一下 Nginx ngx_http_concat_module 模塊來合并多個文件在一個響應報文中。也就是再加載多個小型 js 文件時候合并為一個 js 文件。

BigPipe 技術也是可以對頁面分塊來進行優化的，但是因為與本文關系不大，方案也沒有通用化和規范化，加上本人其實沒有深入了解所不進行深入介紹，如果先了解可以參考新版賣家中心 Bigpipe 實踐（一）以及新版賣家中心 Bigpipe 實踐（二）。

當然那個時期的代碼也沒有像現在的前端的代碼量和復雜度那么高。

Webpack 之后的js加載

與其說 Webpack 是一個模塊打包器，倒不如說 Webpack 是一份前端規范。

需要庫沒有被大量使用情況

對于我們代碼中所需要的代碼庫沒有大量使用，比如說某種組件庫我們僅僅只使用了 2、3個組件的情況下。我們更多需要按需加載功能。
比方說在 MATERIAL-UI 我們可以用

import TextField from "@material-ui/core/TextField";
import Popper from "@material-ui/core/Popper";
import Paper from "@material-ui/core/Paper";
import MenuItem from "@material-ui/core/MenuItem";
import Chip from "@material-ui/core/Chip";

代替

import {
  TextField,
  Popper,
  Paper,
  MenuItem,
  Chip
} from "@material-ui"

這樣就實現了按需加載，而不是動輒需要整個組件庫。但是這樣的代碼中這樣代碼并不好書寫。我們就需要一個幫助我們轉換代碼的庫。這可以參考 Babel 插件手冊以及簡單實現項目代碼按需加載來實現我們的需求。

需要庫大量被使用情況

如果我們的庫被當前的項目大量使用了，按需加載其實就未必是最好的方法了，如果我們的服務器不是特別好的情況下我們可以使用 Webpack 的 externals 配置來優化項目的js。就簡單的對 externals 配置簡單說明一下。externals其實是在全局中的得到庫文件。

  // 頁面中使用 cdn，這樣的話，我們就會在 window 中得到 jQuery
  // 也就是 global.JQuery 瀏覽器中 global === window
  

  // 在項目中導入 jquery 使用
  import $ from "jquery";

  // 配置中 左邊是 配置的 jquery 告訴 Webpack 不需要導入
  // 配置中 右邊是 配置的 JQuery 告訴 Webpack 記載 jquery 時候使用 global.JQuery
  externals: {
    jquery: "jQuery"
  }

但是使用 externals 曾遇到這樣的情況。我在使用 material-ui 組件庫時候發現該庫在全局導出的代碼是 material-ui。
也就是:

  externals: {
    "@material-ui/core": "material-ui"
  }

此時會發生導入錯誤，錯誤原因為: window.material-ui。
本來我是想要引入material-ui，卻 - 符號變為了減號。
本來想要利用用 ["material-ui"] 來替換，卻發現行不通: windows.["material-ui"]
解決方法:

  externals: {
    "@material-ui/core": "window["material-ui"]"
  }

因為 window 對象有自己引用自己，所以 window === window.window.window。所以代碼為 window.window["material-ui"]。可以參考 MDN Window.window

上文中的性能優化方案依然可用 loadjs 動態加載

在當前所需要 js 文件不需要大量使用同時需要的 js 文件是不需要開始時加載(如 React, React-Router 一類)的時候我們依然可以使用loadjs來加載(比如說圖標庫一類，只在某一些頁面使用)。

合并多個小型 js

對于在 HTTP2 中合并多個小js文件未必好。因為在 HTTP2 中，HTTP 請求是廉價的，合并便不再顯得有優勢。

BigPipe 方案

當然了,BigPipe 方案不是針對單頁面應用程序。而且對于前后端的技術要求較高，所以對于項目未必是最有效的方案。

其他

現如今也可以使用一些其他的方法。例如 Service Worker,Wasm 等一系列方案。不知道還有什么其他方法，也可以介紹給我。

參考文檔

新版賣家中心 Bigpipe 實踐（一）
新版賣家中心 Bigpipe 實踐（二）
Babel 插件手冊
簡單實現項目代碼按需加載
MDN Window.window

GPU云服務器云服務器 js前端加載數據前端工程化前端前端工程師前端工程師前端

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/104059.html

2017年五月前端面試題目的總結

摘要：持續心累的找工作階段算是結束了，不同公司對面試的知識側重點不同，整體的感受就是大公司可能更偏向一些基礎或者原理布局一些經典算法方面。現將我在面試過程遇到的問題總結下。目前先傳題目答案整理好之后再發布出來。持續心累的找工作階段算是結束了，不同公司對面試的知識側重點不同，整體的感受就是：大公司可能更偏向一些JS基礎或者原理、html布局、一些經典算法方面。小公司的面試更加側重對經驗和細節...

warkiz 2019-08-20 17:30 評論0 收藏0
2017年五月前端面試題目的總結

摘要：持續心累的找工作階段算是結束了，不同公司對面試的知識側重點不同，整體的感受就是大公司可能更偏向一些基礎或者原理布局一些經典算法方面。現將我在面試過程遇到的問題總結下。目前先傳題目答案整理好之后再發布出來。持續心累的找工作階段算是結束了，不同公司對面試的知識側重點不同，整體的感受就是：大公司可能更偏向一些JS基礎或者原理、html布局、一些經典算法方面。小公司的面試更加側重對經驗和細節...

dreamGong 2019-08-29 12:48 評論0 收藏0
2017年五月前端面試題目的總結

摘要：持續心累的找工作階段算是結束了，不同公司對面試的知識側重點不同，整體的感受就是大公司可能更偏向一些基礎或者原理布局一些經典算法方面。現將我在面試過程遇到的問題總結下。目前先傳題目答案整理好之后再發布出來。持續心累的找工作階段算是結束了，不同公司對面試的知識側重點不同，整體的感受就是：大公司可能更偏向一些JS基礎或者原理、html布局、一些經典算法方面。小公司的面試更加側重對經驗和細節...

liangzai_cool 2019-08-01 17:03 評論0 收藏0
談談前后端的分工協作

摘要：針對上面看到的問題，現在也有一些團隊在嘗試前后端之間加一個中間層比如淘寶的。淘寶有很多類似的文章，這里不贅述。淘寶團隊做了兩套接口文檔的維護工具，以及，不知道有沒有對外開放，兩個東西都是基于的一個嘗試，各有優劣。原文出處：小胡子哥的博客（@Barret李靖）前后端分工協作是一個老生常談的大話題，很多公司都在嘗試用工程化的方式去提升前后端之間交流的效率，降低溝通成本，并且也開發了...

Scholer 2019-07-25 11:26 評論0 收藏0