如今，ES7模块几乎已在浏览器中得到普遍支持。解决此问题的旧解决方案似乎涉及将babel与Browserify或Webpack一起使用。这仍然是在本地和npm模块上都使用ES6导入/导出语法的最简单的，受充分支持的方法吗？
编辑：是。蒸馏出来。
答案 0 :(得分：1)
TLDR：使用捆绑程序仍然是交付/打包应用程序的最佳方法。
这不仅仅是模块的问题。它与服务器拓扑和整体捆绑更多有关。
例如，您有一些第三方npm模块，它作为ES模块（也称为import/export语法）提供。通常将其安装在node_modules文件夹中，其依赖项也将安装。现在，您将在代码中使用此模块，您将希望使用它
import xyz from 'my-npm-module';
使用上面的简单语句，存在多个问题。上面的导入类型是非相对导入。对于Node.js或Webpack或Rollup等捆绑程序，这很简单，只需从当前目录开始查找node_modules文件夹，然后一直查找到根分区。
现在，浏览器不了解非相对导入分辨率（浏览器不使用Node样式模块分辨率）。因此，第一个问题是浏览器如何知道在服务器上的此类模块的位置。第二个问题，假设您以某种方式教会浏览器使用非相对模块并遵循Node样式解析算法，则仍然需要打包整个node_modules文件夹，包括子目录。这是一个非常麻烦的过程，不必要地增加了应用程序的最终构建大小。
这就是为什么您仍然需要使用Webpack和Browserify等捆绑程序的原因。为了保持精简，如果您不想支持旧的JS引擎，可以跳过Babel。但是，如果您确实要使用ES模块并将其发送到浏览器，请考虑使用Rollup.js，它支持输出格式为ES module，而不是Webpack的UMD或Common.js。
您可以考虑使用System.js + JSPM捆绑应用程序的另一种方法，其中ES modules是默认设置，但它不像Webpack或Rollup那样提供灵活性。另外，还有一个新的捆绑器-Parcel.js，旨在成为零配置解决方案，并且非常易于使用。您不会注意到所有复杂的皮带和口哨声。
最后，现实世界中的前端绑定不仅仅与JavaScript有关。还有其他资产，例如TS文件，ReasonML文件，Images，SVG文件，您可能希望使用高级优化（如Tree Shaking，HMR（开发模式））进行打包并最终捆绑到最终捆绑包中。