本文转载自微信公众号《Gogo的前端世界》，作者1234加班，转载请联系Gogo的前端世界公众号。刷知乎看到这个问题，下面只有2个答案。何士君老师其实也关注过这个问题，所以……以下为知乎原文。欢迎大家来知乎关注我的三个链接：点赞、评论、收藏。没有人邀请我勇敢地回答这个问题。我们先来看看提案是什么。JavaScript模块片段是命名的内联JS模块的语法，可用于将多个模块捆绑到单个JavaScript文件中。直译过来，JSmodulefragments是对JS模块语法的提议，我们也可以称之为“模块片段”，可以用来在一个JavaScript文件中编写多个模块代码。简单来说，现在的ESModule都是以文件为单位划分的，TC39的提出意味着它可以更进一步。在同一个JS文件中，代码被分成模块，这与许多其他编程语言有些相似。中的“区域”注释片段。比如上面的代码：//filename:app.js//定义一个模块#countmodule"#count"{leti=0;//模块导出一个函数exportfunctioncount(){i++;returni;}}//定义anotherAmodule#uppercasemodule"#uppercase"{//导出一个函数exportfunctionuppercase(string){returnstring.toUpperCase();}}//导入模块，这里和ES标准化模块的语法一致，import{count}from"#count";import{uppercase}from"#uppercase";console.log(count());//1console.log(uppercase("dan??iel"));//"DANIEL"是的，这是样本在提案代码中，我添加了注释。之所以会有这样的提案，可以从提案中的动机中找到。大致可以概括为小文件在各种环境下的加载成本非常高，需要其他打包工具。拿一段用我小学二年级的翻译水平展示一下：这个提案给JavaScript增加了一个语法，允许一个文件中有多个JavaScript模块。这种格式可以被打包器用作输出，执行开销很低，这样打包器就不必模拟那么多，JS引擎可以看到发生了什么。由JavaScript开发人员直接输入也很方便，而且它的开销应该很低以适应现有的工作流程。该提案添加了一种允许将多个JavaScript模块包含在单个文件中的语法。这种格式的模块可以打包输出，降低执行成本。因此，传统意义上的打包工具已经没有那么重要了。JS引擎本身就可以完成这一系列的工作，让开发者可以直接使用原始的JavaScript，并且很容易将其集成到现有的开发流程中。我个人支持这个提议。从根本上说，JavaScript的诞生太快了（“马虎”），没想到今天会有这么大的应用规模，所以很多高级功能都没有完备。从历史上看，JavaScript并没有模块系统，不可能将一个大程序按照各自的职责拆分成相互依赖的小模块，再通过简单的方式组装在一起。这对构建大型、复杂的应用程序构成了巨大的障碍。现在大家耳熟能详的Webpack，就是为了更好的解决这个问题而诞生的，只不过这一次，它不再是一个社区解决方案，也不再是一个工具，终于有人从语言标准入手，试图从语言层面站出来，彻底根除这个问题。问题。这个语法的出现，现阶段最大的核心能力就是“模块封装相关”。提案动机中提到了很重要的一点：“浏览器预测”，即浏览器提前预测模块是否需要预加载，从而区分模块是否需要加载，从而有效提高加载性能。当然，如果这个提案能够最终通过，那肯定是循序渐进的。至于能释放出多少能量，就看大佬们的脑洞了。xdm，支持这个提案的人给我点个赞吧。。。
