谈谈前端工程化 js加载

更新日期: 2019-05-03阅读: 1.8k标签: 工程化

当年的 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
  <script
    src="https://code.jquery.com/jquery-3.1.0.js"
    integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
    crossorigin="anonymous">
  </script>

  // 在项目中导入 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 等一系列方案。不知道还有什么其他方法,也可以介绍给我。


原文来自:https://segmentfault.com/a/1190000019061704


链接: https://www.fly63.com/article/detial/3183

前端工程化的的理解,浅谈web工程化的开发流程

一个完整的前端工程体系应该包括:统一的开发规范;组件化开发;构建流程。开发规范和组件化开发面向的开发阶段,宗旨是提高团队协作能力,提高开发效率并降低维护成本。

web前端工程化/构建自动化

前端工程化的概念在近些年来逐渐成为主流构建大型web应用不可或缺的一部分,在此我通过以下这三方面总结一下自己的理解。为什么需要前端工程化。前端工程化的演化。怎么实现前端工程化。

前端工程化的浅析

前端工程化的本质是将可以用工具来完成的事情用工具来完成。前端工程化在目前的开发中是不可逆的趋势,每一个身处工作岗位的前端,都应该确立前端工程化的开发思维和开发方法

Node.js项目拆包工程化

在我们开发的过程中,经常会遇到这样的问题,开发完了一些代码或者一个接口,别的小伙伴过来问你,代码可不可以给他复用,接口可以给他调用。这说明代码的复用和抽象对团队协作是很重要的

聊聊前端工程化_我对工程化的理解

工程师是个古老的职称了。耳熟能详的有建筑工程师,电器工程师等,往往他们在人们脑海中的印象是刻板,严谨,可靠。随着互联网的发展,软件工程师出现了!他们不用一砖一瓦,也不用尺子电钻,计算机是他们的施工现场,代码是他们的工程部件

谈谈前端工程化是个啥?

Web业务日益复杂化和多元化,前端开发已经由以WebPage模式为主转变为以WebApp模式为主了。现在随便找个前端项目,都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了。工程复杂了就会产生许多问题,比如:如何进行高效的多人协作?如何保证项目的可维护性?如何提高项目的开发质量?

前端工程化:构建、部署、灰度

优秀的技术方案很多,大部分时候我们感觉只是在现有技术方案里面做排列组合、求笛卡尔积、选择最优解,做出一个最适合当前项目的方案。未来,人类应该编写最核心的业务代码、设置规则

前端工程化的一些设想

最近几年前端工程化这个事情随着模块化标准(曾经的事实标准 commonjs,今天的 ES Module )的落地和工具链的成熟,大家普遍都在采用一体化的策略来完成工程从构建到发布的过程。

你了解 Browserslist 吗

细说起来,它是现代前端工程化不可获取的工具,无论是处理 JS 的 babel,还是处理 CSS 的 postcss,他们的背后都有 browserslist 的身影。

前端工程化配置指南

本文讲解如何构建一个工程化的前端库,并结合 Github Actions,自动发布到 Github 和 NPM 的整个详细流程。我们经常看到像 Vue、React 这些流行的开源项目有很多配置文件,他们是干什么用的?

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!