electron重应用开发风险

electron是chromium跨平台应用开发框架，它让具有web前端经验的开发者也能进行应用开发，不过对于C/S应用场景，web前端开发者使用electron开发还有诸多不便，不能以拧包入住的心态对待，实际上，直接基于electron+web前端技术开发，更像是入住毛坯房，对于数据密集的多窗口应用，还存在超出从前经验的问题，不加以重视，就会被这些业务无关的技术问题拖入泥潭，甚至面临项目失败的风险。
究竟有哪些技术问题会成为技术风险，根据我所见罗列如下：

1. 数据存储，对于简单的数据存储，采用localStorage、indexDB 大多数web开发者都能很好的应对，而一旦使用 sqlite（关系型） 或者 LokiJS（文档型） 这样的数据库，web前端开发者普遍不太了解，匆忙学习就做项目，往往只能做出能用，但难以维护、难以长期使用的设计。也许组内的后端开发者可以帮助解决一些问题，但后端程序员如果不懂前端技术，也只能提供有限的协助。
   a. 增删改查
   b. 建表,建索引
   c. 数据迁移
2. 多进程，如果说第1点给项目引入的难度是3，那么多进程引入的难度就是5，这并不是危言耸听，换个说法，要让web前端研发做分布式系统，同步多窗口状态，保障数据一致性，都是要在多进程上实现，没有分布式系统设计的基础知识，系统很容易产生“打地鼠问题”，刚解决这个，又出现另一个，没完没了。
3. 资源管理，对于重量应用，按单应用方式打包并不可取，如果你让每个窗口加载一次所有资源，窗口打开速度将会变得迟缓，因为每个窗口都加载所有的脚本和静态文件。也许我们会用预先加载，隐藏代替关闭消除这个延迟，单依然无法解决首次加载时的高耗时，以及由反复加载引入巨大js文件，造成CPU高消耗，并且这些消耗提高了对客户主机硬件的要求。
4. 跨平台，不同桌面操作系统，对桌面环境的设计差异，造成部分API接口无法做归一设计，这些特殊处理背后隐藏的是新知识学习成本。
5. electron 与 chromium 交集功能，些部分能力可能会误导开发者，选择错误，可能导致无法实现功能需求，比如剪贴板，通常我们要优先使用 electron 提供的能力。

解决以上这些问题，更需要前后端综合经验，专门的人力持续投入，亦或者使用已经解决这些问题的框架。