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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2735 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

32 条回复 • 2017-07-17 10:55:54 +08:00

gucheen

2017-06-16 16:13:21 +08:00

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

lgh06

2017-06-16 16:24:32 +08:00

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

chairuosen

2017-06-16 16:29:26 +08:00

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

zhihy123

2017-06-16 16:34:05 +08:00

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

2017-06-16 16:36:25 +08:00

要么升版本要么用 babel

wobuhuicode

2017-06-16 16:40:24 +08:00

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

wobuhuicode

2017-06-16 16:41:21 +08:00

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

mosliu

2017-06-16 16:41:33 +08:00

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

xiadd

2017-06-16 16:57:22 +08:00

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

septem123

2017-06-16 17:04:05 +08:00

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

jiangzhuo

2017-06-16 17:14:10 +08:00

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

oyyd

2017-06-16 17:16:22 +08:00

我觉得主要是两点：

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

momocraft

2017-06-16 17:18:04 +08:00

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

otakustay

2017-06-16 17:22:27 +08:00

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

notreami

2017-06-16 17:37:05 +08:00

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

solee

2017-06-16 17:40:02 +08:00

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

lianyue

2017-06-16 17:44:32 +08:00 via iPhone

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

MadbookPro

2017-06-16 18:41:17 +08:00 via Android

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

maomaomao001

2017-06-16 18:53:59 +08:00

为什么不用 typescript 呢

TangMonk

2017-06-16 18:55:20 +08:00 via Android

后端没必要用 webpack

oyyd

2017-06-16 18:56:26 +08:00

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

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

MadbookPro

2017-06-16 19:01:59 +08:00 via Android

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

oyyd

2017-06-16 19:19:51 +08:00 via iPhone

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

duan602728596

2017-06-16 19:29:26 +08:00 via iPhone

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

guokeke

2017-06-16 19:37:34 +08:00

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

Exin

2017-06-17 00:12:03 +08:00

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

duan602728596

2017-06-17 00:22:20 +08:00 via iPhone

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

nino

2017-06-17 00:27:37 +08:00

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

seki

2017-06-17 03:40:46 +08:00

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

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

tutulyy

2017-06-17 22:37:55 +08:00

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

libook

2017-06-20 00:58:24 +08:00

我们服务端用新版 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 实现者在实现新特性草案的时候基本上也都是互相交流、互抄方案的，所以殊途同归也是必然的。

rekey

2017-07-17 10:55:54 +08:00

@libook 赞