包含 26 篇内容
Vite 的定义 Vite 是面向现代浏览器的一个更轻、更快的 Web 应用开发工具，核心基于 ECMAScript 标准原生模块系统（ES Modules）实现。 表象功能上看，Vite 可以取代基于 Webpack 的 vue-cli 或者 cra 的集成式开发工具，提供全新的一种开发体验。 具体细节往下看。 Vite 的由来 在此之前，如果我们所开发的应用比较复杂（代码量偏大），使用 Webpack 的开发过程相对没有那么「丝滑」，具体表现为以下两点： Webpack Dev Server 冷启动时间会比较
你好，我是汪磊，今天我要带你了解一个近两年非常火的打包工具：Parcel。 Parcel 是一款完全零配置的前端打包器，它提供了“傻瓜式”的使用体验，我们只需了解它提供的几个简单的命令，就可以直接使用它去构建我们的前端应用程序了。 下面我们直接来看具体如何去使用 Parcel。 快速上手 这里我们先创建一个空目录，然后通过 npm init 初始化一个项目中的 package.json 文件。 完成以后我们就可以安装 Parcel 模块了，具体命令如下： $ npm install parcel-bundler -
你好，我是汪磊，今天我要跟你介绍另外一款同样十分优秀的打包工具：Rollup。 Rollup 是一款 ES Modules 打包器。它也可以将项目中散落的细小模块打包为整块代码，从而使得这些划分的模块可以更好地运行在浏览器环境或者 Node.js 环境。 从作用上来看，Rollup 与 Webpack 非常类似。不过相比于 Webpack，Rollup 要小巧的多。因为 Webpack 在配合一些插件的使用下，几乎可以完成开发过程中绝大多数前端工程化的工作。而 Rollup 可以说仅仅是一个 ES Modules
你好，我是汪磊，今天我们要一起探索的是 Webpack 在生产模式打包过程中的一些常用配置和一些的优化插件。 在前面的文章中，我们了解到的一些用法和特性都是为了在开发阶段能够拥有更好的开发体验。而随着这些体验的提升，一个新的问题出现在我们面前：我们的打包结果会变得越来越臃肿。 这是因为在这个过程中 Webpack 为了实现这些特性，会自动往打包结果中添加一些内容。例如我们之前用到的 Source Map 和 HMR，它们都会在输出结果中添加额外代码来实现各自的功能。 但是这些额外的代码对生产环境来说是冗余的。因为生
你好，我是汪磊，今天我将继续和你分享 Webpack 另外的一个高级特性，Code Splitting（代码分包）。 All in One 的弊端 通过 Webpack 实现前端项目整体模块化的优势固然明显，但是它也会存在一些弊端：它最终会将我们所有的代码打包到一起。试想一下，如果我们的应用非常复杂，模块非常多，那么这种 All in One 的方式就会导致打包的结果过大，甚至超过 4 ～ 5M。 在绝大多数的情况下，应用刚开始工作时，并不是所有的模块都是必需的。如果这些模块全部被打包到一起，即便应用只需要一两个模
你好，我是汪磊，今天我想和你分享 Webpack 的两个高级特性，分别是 Tree Shaking 和 sideEffects。 它们都属于 Webpack 打包结果优化的必备特性，而且现在应用的也十分广泛。 Tree Shaking Tree Shaking 翻译过来的意思就是“摇树”。伴随着摇树的动作，树上的枯树枝和树叶就会掉落下来。 我们这里要介绍的 Tree-shaking 也是同样的道理，不过通过 Tree-shaking “摇掉”的是代码中那些没有用到的部分，这部分没有用的代码更专业的说法应该叫作未引用
你好，我是汪磊，在之前的文章中我们已经简单了解了 Webpack Dev Server 的一些基本用法和特性，它为我们使用 Webpack 构建的项目提供了一个比较友好的开发环境和一个用于调试的开发服务器。 使用 Webpack Dev Server 就可以让我们在开发过程中专注编码，因为它可以自动监视我们代码的变化，然后自动进行打包，最后通过自动刷新的方式同步到浏览器，以便于我们即时预览，效果如下： 自动刷新的问题 但是当你实际去使用 Webpack Dev Server 自动刷新的特性去完成具体的开发任务时，
你好，我是汪磊，上一期我们介绍了如何使用 Webpack Dev Server 提高开发效率，今天我们来介绍需要编译的前端项目该如何调试。 通过构建或者编译之类的操作，我们将开发阶段编写的源代码转换为能够在生产环境中运行的代码，这种进步同时也意味着我们实际运行的代码和我们真正编写的代码之间存在很大的差异。 在这种情况下，如果需要调试我们的应用，或是应用运行的过程中出现意料之外的错误，那我们将无从下手。因为无论是调试还是报错，都是基于构建后的代码进行的，我们只能看到错误信息在构建后代码中具体的位置，却很难直接定位到源
你好，我是汪磊，通过前面几片文章的介绍，相信你已经了解了 Webpack 的相关概念、基本用法，以及核心工作原理，看似好像已经掌握了 Webpack，但是如果以目前的认知状态去应对日常的开发工作，其实还远远不够。 因为“编写源代码 → Webpack 打包 → 运行应用 → 浏览器查看”这种周而复始的开发方式过于原始，在实际开发过程中，如果你还是按照这种方式来工作，开发效率必然会十分低下。 那究竟该如何提高我们的开发效率呢？ 这里我先对一个较为理想的开发环境做出设想： 首先，它必须能够使用 HTTP 服务运行而不
你好，我是汪磊，在前面的文章中我们已经对 Webpack 两个最重要的特性：Loader 和插件机制有了深入的了解，今天我们再来解读一下 Webpack 的运行机制和核心工作原理。 工作过程简介 其实 Webpack 官网首屏的英雄区就已经很清楚地描述了它的工作原理，如下图所示： 那这里我们先来快速理解一下 Webpack 打包的核心工作过程。我们以一个普通的前端项目为例，项目中一般都会散落着各种各样的代码及资源文件，如下图所示： 比如 JS、CSS、图片、字体等，这些文件在 Webpack 的思想中都属于当前
你好，我是汪磊，上回说到 Webpack 的 Loader 机制，今天我要跟你分享 Webpack 的另外一个重要的核心特性：插件机制。 Webpack 插件机制的目的是为了增强 Webpack 在项目自动化构建方面的能力。通过上一篇文章的介绍你应该知道，Loader 就是负责完成项目中各种各样资源模块的加载，从而实现整体项目的模块化，而 Plugin 则是用来解决项目中除了资源模块打包以外的其他自动化工作，所以说 Plugin 的能力范围更广，用途自然也就更多。 我在这里先介绍几个插件最常见的应用场景： 实现自
你好，我是汪磊，今天我要跟你分享的内容是如何通过 Loader 机制实现特殊资源加载，通过开发一个 Loader 深入理解 Webpack Loader 机制的原理。 正如开篇中所讲到的，Webpack 想要实现的是整个前端项目的模块化，项目中的各种资源（包括 CSS 文件、图片等）都应该属于需要被管理的模块。换句话说， Webpack 不仅是 JavaScript 模块打包工具，还是整个前端项目（前端工程）的模块打包工具。这也就是说，我们可以通过 Webpack 去管理前端项目中任意类型的资源文件。 因为 Web
你好，我是汪磊，今天我要跟你分享的内容是如何使用 Webpack 实现模块化打包？ 相信通过上篇文章内容的学习，你应该对前端模块化有了更完整的认识。在上篇文章的最后我们提出了对模块化打包方案或工具的设想或者说是诉求： 能够将散落的模块打包到一起； 能够编译代码中的新特性； 能够支持不同种类的前端资源模块。 目前，前端领域有一些工具能够很好的满足以上这 3 个需求，其中最为主流的就是 Webpack、Parcel 和 Rollup，我们以 Webpack 为例： Webpack 作为一个模块打包工具，本身就可
你好，我是汪磊，今天我要跟你分享的内容是 Webpack 背后的模块化以及它的发展过程。 正如开篇中所描述的，Webpack 最初的目标就是实现前端项目的模块化，也就是说它所解决的问题是如何在前端项目中更高效地管理和维护项目中的每一个资源。 所以如果你想要搞明白 Webpack ，就必须先对它想要解决的问题或者目标有一个充分的认识，带着问题再去理解它的很多特性，学习思路会更清晰，理解也会更深刻。 在这一章中，我将带你简单了解前端模块化的发展史，以及这个过程中所出现的一些标准规范。有句话叫作：读史使人明智，希望通过学
经过最近几年的爆炸式发展，前端已经绝不再是简简单单的页面开发了，从早期只是配合后端“切图”，到现在已经能够独立驱动整个业务，这背后就需要引入更多的思想、框架和工具。比如： 现阶段的大型应用就要求前端必须要有独立的项目，独立的项目想要有足够的效率就必须进行工程化。 具有复杂数据状态的应用开发过程就必须要有合适的框架，采用数据驱动开发的方式增强可维护性。 复杂项目结构必须进行模块化管理，一来提高部分公共内容的可复用性，二来增强团队并行协作能力。 重复规律性的工作必须采用自动化工具实现，一来提高效率，二来避免人为出错。
在对前端工程化的整体有了初步的认识之后，我们顺着一个项目的开发过程，先从脚手架开始，探讨前端工程化在项目创建环节中的具体表现。 脚手架可以简单理解为用来自动帮我们创建项目基础文件的工具。看似很普通的需求，背后却饱含哲学，因为除了创建文件，它更重要的是提供给开发者一些约定或规范。 脚手架的本质作用 通常我们在开发相同类型的项目时都会使用一些相同的约定，其中包括： 相同的文件组织结构 相同的代码开发范式 相同的模块依赖 相同的工具模块配置 相同的基础代码 这样一来就会出现在搭建新项目时有大量重复工作要做。脚手架工具
前端工程化是指遵循一定的标准和规范，通过工具提高开发效率、降低维护成本的一种手段。近些年被广泛的关注和探讨，究其原因，主要是因为前端应用的功能要求不断提高，业务逻辑日益复杂。 作为当下互联网时代唯一不可或缺的技术，前端占据了整个开发行业的「半壁江山」。从传统的网站到现在的 H5、移动 App、桌面应用以及小程序，前端技术几乎无所不能的全面覆盖。 在这些表象的背后实际上是前端行业对开发人员的技能要求发生了天翻地覆的变化，以往“写 Demo，套模板，调页面”这种刀耕火种的方式已经完全不符合当下对开发效率的要求。前端工程
Electron 是一个运行平台，它能够让我们通过 HTML + CSS + JavaScript 开发桌面应用程序。 核心原理就是 Electron 中将 Chromium（Chrome 的内核）和 Node.js 打包到了一起，通过 Chromium 提供 WebView 从而实现 UI 编程能力，通过 Node.js 提供 APIs 从而实现系统接口调用。 简单来说就是，在 Electron 中我们可以像在 Web 开发中一样，通过 HTML + CSS 完成 UI 开发，通过 JavaScript（ECM
背景介绍 在了解 AJAX 之前我们可以简单的认为「JavaScript 能力有限」，因为在此之前 Web 平台提供所有的 API 都只停留在「单机」的阶段。 这样就会造成一些无法实现的功能，例如： 无法在实现用户登录功能时，当用户输入邮箱地址显示用户对应的头像 无法在实现用户注册功能时，当用户输入邮箱或者用户名就提示是否存在 无法在实现留言板功能时，实时看到最新的用户留言 思考：为什么做不到这些呢？ 这些功能的开发最终都卡在一个相同的问题上：所需要的数据存放在服务端，我们无法通过已知的 API 获取到服
