各位的 Nodejs 项目用 babel 或者 Webpack 的多吗？

发布于 1周前 作者 vueper 来自 nodejs/Nestjs

各位的 Nodejs 项目用 babel 或者 Webpack 的多吗？
Webpack 估计不常见毕竟那是前端资源的模块打包工具，但我还真见过有项目用的。那 babel 呢？我们现在的项目是基于 Node 6.10 的，虽然没有 es6 的模块，没有 async 和 await，但大部分需要的 es6 功能 6.10 都支持了，所以我是比较倾向不上 babel 的，请问各位呢？如果上的话是基于什么考虑呢？

Harmonyos Next教程
33 回复

用，为什么不呢？
把各种刚进的草案的、没进草案的、是标准的、不是标准的特性大量用在生产环境不正是 JavaScript 的魅力所在吗 :)
不过这样说的话，不如上 Node 8.0 吧，那样就不用 babel 转换 async/await 了


我就说一个 import export 就得用 babel ……
webpack 没法用，和浏览器运行 js 完全不一样，本来一个一个路径、目录好好的，打成一个单文件，各种问题。
所以只用了 babel。

想不明白，为什么要用 babel 而不升 node 版本呢？

node 版本 8.0，基本不会用到这两个，只想说 async/await 太好用了~

要么升版本 要么用 babel

8.0 还是不支持 import。现在用 babel 就用一个 babel-plugin-transform-es2015-modules-commonjs 插件就够了。

发布的时候就多了一个命令而已：
./node_modules/.bin/babel --no-babelrc --plugins transform-es2015-modules-commonjs ./src --out-dir ./web

支持 import 是不是要等 V8 升版本啊？

https://github.com/xiadd/zhuishushenqi 私人用到了 babel+koa 但是其实没太大必要

是啊 我也想不明白 7.10 不都已经支持 es7 了吗 async await 都能用啊

做外包会用 webpack，每次更新就丢过去几个文件让他覆盖重启就好了。自己公司的项目不会用。
我们项目都是基于想一个版本的 LTS 写的，等写好了就变成真的 LTS 了

我觉得主要是两点：

1. nodejs 版本之间在 es 语法支持能力上有差异，当然也可以选择更新 node 版本，但也有人会不想要在开发的时候考虑太多运行环境的问题（虽然还是要考虑 api 的问题）
2. 如果部分代码同时也会运行在浏览器上的话（ universal js ），肯定是要配置编译的，那干脆一起编译好了，两边运行的代码理论上也更加一致

肯定也会有人考虑性能的问题： http://incaseofstairs.com/six-speed/?utm_source=ESnextNews.com&utm_medium=Weekly%20Newsletter&utm_campaign=Week%2010

只在前端部分用 webpack，后端只用 TypeScript (仅需要把新版特性编译到 ES5, 不需要 bundle)

不用 babel 跟咸鱼有什么区别，不过 webpack 在 node 上用的经验不是太多

套上 TypeScript，我觉得比 babel 好很多

习惯了原生的 之前是用 koa@1 用 generator， 现在用 koa@2 用 async/await. Node 都到 8 了，对 async/await 原生支持，性能提升也大。为啥要用 Babel ？

webpack 很好用 嗯前后端都好用 初次配置麻烦 嗯 webpack 配置都麻烦

希望不是我看错，在 Node.js 环境下，es6 新特性对比 es5 性能落后不少啊？

为什么不用 typescript 呢

后端没必要用 webpack

我觉得没看错:) 我记得最近几次 v8 引擎的发版强调的最多的就是 es6 特性的性能： https://v8project.blogspot.jp/ 。拍着脑袋想，原因可能有两点：

1. babel 编译本身是不（那么）完整的实现，像是 es2015-loose 这样注重性能忽略边缘特性的编译方式（我并不清楚）
2. 现在的 v8 更擅长优化 es5 代码的性能

惨，目前项目全面 es6，没有考虑在 6.10.1 版本下的性能问题。看来要测试一下了

大多时候性能都不是重点，语法上的这点性能大多也不是真正的性能瓶颈

node 用的 7.7.0 版本，不用 8 是因为 node-sass 不支持 8。前端肯定是得用 webpack 了，业务是 react 全家桶。每次改代码最头疼的就是编译速度了，太慢了

-=- 不用 babel 怎么愉快的写，高版本会有兼容性问题啊。

似乎现在 node-sass 支持 Node.js 8 了哦？

确实啊，前一阵还没支持呢

node 项目为啥要用 import / export，想不通，node 项目从来不用 babel

见过后端库有用 webpack 的，虽然是一小部分，也记不清是哪些了

babel 我是用的，开发时在入口文件做 register，上线前写个脚本编译一下，美滋滋

最近用了 node V8.0.0 再也不用上 babel 了

我们服务端用新版 Node 而不用 Babel 等工具的原因：
1. 服务器环境是确定的，不会有兼容性问题。
2. 所写即所得，运行和调试的就是自己写的代码。
3. 用原生提供的特性，避免被引入的库坑。
4. Current 版本的 Node 的可靠性足够好。
5. 0 配置，拉代码装包即可运行。
6. 修复架构相关问题，而不是靠补丁掩盖。
7. 已有特性的性能被进一步优化。

当然不同项目的情况不同，要根据实际情况选型。

平时服务端用 require，前端用 import，对比各自都没有绝对优势，只是不同的写法罢了，或者说 import 只是 ES 标准收录而已。

写 Node 程序用 Node ES 最直接简单，虽然 Node ES 比其他 ES 实现经常要落后一些，但也用不了多久就能追回来，而且其他 ES 实现最终也都是要转化成 Node ES 才能被 Node 执行。

Babel ES 可能更贴近于 ES 标准，但其实也就只有几个不疼不痒的特性而已。

TypeScript 在 V8 没有原生支持 ES6 的时候有优势，但是 ES6 出来之后好像也就没啥特别强大的吸引力要转，除非依赖哪个重要的包是基于 TypeScript。

现在众多的 ES 实现，都差不多，选择哪个主要是习惯使然，很少有因为某个硬性的技术需求而刻意选型的情况。

其实造成这种现象也和 ES 标准的制定流程有关，新特性会由各自 ES 实现者出草案，然后加入到自己的 ES 实现当中，开发者用起来，当某一特性被使用到一定程度的时候才会有资格接受评审，接受了社区的广泛试用才能正式进入 ES 标准，而各自 ES 实现者在实现新特性草案的时候基本上也都是互相交流、互抄方案的，所以殊途同归也是必然的。

赞

在Node.js项目中，Babel和Webpack的使用是相当普遍的。

Babel主要用于将ES6+的代码转换为向后兼容的JavaScript代码，以便在旧版浏览器或Node.js环境中运行。例如，通过Babel，可以使用import和export语法以及一些ES6、ES7的新特性，而不用担心Node.js环境不支持。一个简单的Babel配置示例（.babelrc文件）如下：

{
  "presets": ["@babel/preset-env"]
}

而Webpack则是一个前端资源的打包工具，它可以将JavaScript、CSS、图片等资源当成一个模块进行打包，从而减少HTTP请求次数，提高页面加载速度。Webpack还可以处理高级JavaScript语法，如TypeScript、ES6等，将其转换为浏览器可识别的语法。以下是一个基本的Webpack配置文件（webpack.config.js）示例：

const path = require('path');
module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  }
};

总的来说，Babel和Webpack在Node.js项目中都有广泛的应用。Babel专注于语法转换，而Webpack则侧重于资源打包。根据项目需求，可以选择单独使用它们，也可以将它们结合使用，以充分利用各自的优势。

回到顶部