es module
估计很多人和我一样，纠结为啥 nodejs 要换 module 引入方式，难道 nodejs 真的作为前端小工具存在了？
import export 对于前端而言，最大的优势是异步引入依赖，这样，在加载文件的过程中，前端 js 其实是属于 wait 的状态，而不是同步堵塞，这对前端而言意义重大。
而 nodejs 作为后端，加载速度可以说毫无压力，之前在前东家，算是比较大的项目，加载速度也不过几十秒。况且，后端完全不在乎启动速度。
更更更何况，用异步和同步的方式去加载文件，速度都是一样的，区别是同步 cpu 是堵塞，异步 cpu 是活动。很多小白会以为异步加载会快一点，其实异步加载不是并发，就好比用 async/await fs.promise.readFile 和 fs.readFileSync 顺序加载一百个文件，速度其实是几乎一样的。
在我看来，nodejs 引入 import export ，最核心是为了解决三个问题：
第一个问题解决异步加载问题，commonjs 在页面上是无法直接支持 async await，以至于在加载模块的时候，无法去加载网络请求什么，这对服务器而言，动态加载配置会相对比较尴尬。
其实可以在启动页异步加载配置之后再启动系统，当然这样做的确会比较丑陋
但是其实 commonjs 理论上也可以支持 async/await 来实现这个效果，毕竟 nodejs 原生支持 async，不需要额外去封装逻辑。
我怀疑 nodejs 不让 commonjs 去实现第一层 async/await 有两个原因：
- commonjs 原生支持需要修改大量代码，这也是早期实现 async await 之后依然需要封装成函数才能调用的原因
- 如果 commonjs 实现了 async/await ，那对不支持 nodejs 版本而言可能是噩梦，因为不知道引入的包啥时候里面会加入异步的信息。所以干脆引入原本就是异步引入的 import module
第二个问题实现静态引入，可以让 IDE 和引擎更好的处理引用。对于后者的优化，其实不太了解。但对 IDE 而言，commonjs 的引用问题非常多，纵观 python 代码和 javascript 代码，js 代码比较多会实现一些黑科技函数，可能前端本身就属于多语言的编辑（js，html，css）。commonjs 也有类似的问题，比如遍历文件夹来实现动态载入文件。这对开发者是双刃剑，方便了引入，但是也不方便 ide 解析。import 在这方面要比 commonjs 要好得多。但是同样，以后也不会有投机取巧的加载了。同样，import 也可以支持互相引用，commonjs 就不行。
第三个问题是，可能未来可以实现解析引用，减少引用的数量。目前版本其实不支持的，还是整个文件都执行。未来可能会实现 webpack 打包的方式，减少无效代码的引用。这一点本意是好的，但是对后端而言其实就那样，毕竟服务器端，最不缺的可能就是内存。
总而言之，出来了，那就接受，虽然 nodejs 现在有点支离破碎的样子。地位也是一遍再变。nodejs 火，多少也是因为当年中国的前端开发者的数量基底，以至于不需要像其他语言一样，需要从 0 入门。nodejs 的后端没落，很大程度也是前端们真的把 nodejs 作为一个简单的小工具.