【问题标题】:why use module loading in the backend?为什么在后端使用模块加载?
【发布时间】:2016-09-12 15:37:31
【问题描述】:

我一直在试图找到一个答案,为什么 webpack 关心后端的模块加载。是否有理由需要这样做? JSPM 是否也进行后端模块加载?

【问题讨论】:

  • 你能澄清一下“加载/加载到后端”是什么意思吗?您指的是模块捆绑吗?
  • 是“为什么要为客户端预先捆绑 JavaScript 代码?”对你的问题的一个公平的改写?
  • 实际上,这将是对问题的更好改写:为什么要关心为 nodejs 捆绑 javascript?
  • 直到现在您还没有提到 Node,但是 1、3、4 和更脆弱的 2(取决于代码的运行位置/方式)仍然适用。

标签: javascript node.js webpack amd jspm


【解决方案1】:

假设您的第一个问题类似于“为什么要为客户端预先捆绑 JavaScript 代码?”

模块捆绑的原因有很多。一些:

  1. 简单的文件聚合:捆绑相关代码使许多任务更容易/更直观。捆绑这些文件后,无需部署大型文件目录树,而是可以使用单个捆绑文件。
  2. 加载性能:在客户端单独加载位于单独文件中的依赖项历来非常缓慢。每个文件都必须单独解析和评估,根据使用的模块系统,在等待发现和加载依赖项时可能会产生相当大的延迟。
  3. 媒体类型抽象:捆绑器通常允许捆绑非 JavaScript 内容的方法。包含图像和样式表等资产很方便,并鼓励使用它们的应用程序部分明确/明确地依赖它们。
  4. 摇树:通过分析模块和代码之间的依赖关系,通常可以有选择地包含应用程序所需的内容并减少整个代码库的大小。这不是捆绑的固有特性,但通常会这样做,因为存在一些构建步骤的概念。

关于你的第二个问题

JSPM 确实提供了这个功能。这可以在命令行中使用jspm bundle 命令完成。

【讨论】:

    【解决方案2】:

    最简单的原因是性能。打开文件和关闭文件的过程比发送文件(流)所需的时间要慢,因此打开和关闭文件操作越少,服务器发送请求的文件的速度就越快。因此,通过减少构成 javascript/web 项目的文件数量,浏览器将更快地完成获取文件并开始为最终用户处理它们。

    一个好的构建过程可以为您的 Web 项目做的事情不仅仅是简单地将所有 Js 文件添加到一起,因为 JSPM 等工具还可以将 css 和 html 文件合并到一个 bundle.js 文件中,进一步添加到您的最终- 用户体验。

    【讨论】:

      猜你喜欢
      • 2014-01-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-04-27
      • 2011-09-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多