js 世界里有几种工具，一种是 transpiler，比如 babel.js，可以把翻译许多新语法翻译成老语法。另外一种是 polifill，现在最流行的应该是 corejs，就是给不支持新语法的浏览器尽量打补丁，但是有些是补不出来的，比如 Proxy。还有一个工具是 browserslist，它的作用是给定一定的规则，它负责算出来哪些语法不需要翻译。

虽然也可以完全自己从头搭，但是这年头随便找个 boilerplate、create-xxx-app 之类的前端库，要么带个 .browserslistrc 文件，要么直接放在 package.json 里面，你只要填想支持什么浏览器就可以了，根本不是需要额外操心的

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你们现在是不是已经彻底不支持 chrome 以外的浏览器了？
--
FROM 115.188.159.*

那就看人了，css 这东西谁都保不齐的。我们这开封菜外卖，windows 里 chrome 没啥问题，mac 里 chrome 就有个别地方不正常。ios 里不正常也就算了，毕竟是 safari 的核，能做成 win/mac 都不一样我也是挺佩服的

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 大哥，我不是新手。。不用向我解释那么多。我问的是 babel 编译的 target，大家还会不会选择对 es6 支持不好的 ie11/edge 以及早期版本的 chrome (有些 winxp 机器还在用旧版的 chrome, 因为新版的不再支持 32 位，也不再支持 winxp 了)，毕竟选择支持越多的浏览器，生
: 不单是 js, 还有 css. 我想问的是，大家是不是不再支持 ie/old edge/firefox 了。我最近看到好些网站不支持我用的 firefox 了，显示会错乱。。
--
FROM 115.188.159.*

虽然 promise 跟 await promise 没差别，但 () => promise 跟 async () => promise 却有差别

(() => {
  const foo = async () => new Promise((resolve) => resolve('foo'));
  const bar = () => new Promise((resolve) => resolve('bar'));

  foo().then(console.log);
  bar().then(console.log);
})();

执行结果是
bar
foo

因为写了一个多余的 async，你的代码变慢了。没必要 await 的时候 eslint 可以提示不要写，印象中这条规则不会 autofix；没有了 await，就更不要乱写 async，在实际中会创建多余的 micro-task。

还是老话，js 是设计跑在浏览器里的语言，本身就基于 event loop。为了保证在不同执行环境里的一致性，es6+ 的每个设计都不是拍脑袋的决定。从 Promise 到 async/await，各家引擎都花了大量的精力和时间，才正确实现了标准。你只考虑自己的使用习惯，从有限的使用和经验中就得出种种结论，根本就不会去考虑作为语言本身有哪些问题。你一直都到处说 async/await 传递性，就是你不求甚解想象出了一条不存在的规则。如果不需要使用结果的话，反正我是从来不做多余的 await，直接把 promise 放在结果里返回，一直到需要处理函数才 async/await。

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 好吧。。好像还真是。
: 如果打算返回一个 promise，岂不是又踩坑？
: let promise = await async () => { return new Promise(...); }
: ...................
--
FROM 115.188.159.*