小程序 ide 是个好东西，除了包括调试器，模拟器，编辑器，还包括打包，部署，severless等机制，是个很好的工程化模型

我们可以使用 electron 来搞定，使用自带的 chromium 的 devtools 进行远程调试，然后使用自带的 node 进行 webpack 打包，然后再走 CI

如果只是这样，那就不需要我搞了，哈哈哈哈

no webpack

小程序 ide 最大的诟病就是打包编译速度太慢，还不支持热更新，只要还有 webpack，那么这个问题就是无解的

那有没有新思路呢？

答案是有的，那就使用 type=module

类似的项目还有 vite、snowpack……说实话由于太简单，我认为这种开发模式没办法火起来

但确实很适合小程序 ide，因为可以摆脱 webpack，收回主动权，甚至热更新都可以做了，而这一切，只需要启一个 server

deku for worker

理想很丰满，现实很残酷，deku 的思路只能用于支持 type=module 的浏览器，可以我们小程序的逻辑都是跑在 worker 里的，根本不支持 type=module 肿么办……

万幸的是，最新的 chrome 83 已经对 sharedWorker 进行 module 支持，而且 service worker 的标准也已经更新了，只是还没有被实现

也许等我搞定小程序引擎的时候，它也差不多得到支持啦

我们最终肯定是使用 sw 没错了，下一篇讲自动化部署会讲到，我们要利用 pwa 跑 lighthouse，然后部署上线后还支持【将小程序添加到桌面】功能

好吧，和 web-component 一样，pwa 也是个鸡肋，必要性没有，但是小玩意还是一堆，不搞白不搞嘛

总结

通过本篇，我们知道了新的 ide 思路，抛弃 webpack 和慢到死的构建速度，借助 sw（在 module 得到之前只能用 shared worker 替代） 实现 module 的加载，最终获得完美的开发体验

优点除了快，还可控，而且心智负担也很小，就是个 server 而已

我们下一篇讲 pwa 怎么和小程序结合，已经剩下的步骤（部署，serverless等等）

可以看到，这一整套流程走下来，就是一套有意思的产品了，哈哈

和 web ide 的区别

最后不得不说一句，小程序 ide 虽然也是一个 webide，但我认为小程序 ide 的模型要好得多

因为我是不打算掺合编辑器的，小程序 ide 就只包括调试器和模拟器和一个 dev server

至于编辑器，用户自己用 vscode 即可

但确实，这个思路和大厂的 webide 如出一辙，其实都是为了自动构建那些东西，真没必要整一个编辑器了，有调试器和模拟器就很干净纯粹