关于 Echo Live 操作体验优化方案的议题

[sheep-realms]

前端的能力是有极限的，我从短暂的前端开发生涯中学到一件事...... 越是整花活，就越会发现前端的能力是有极限的...... 除非超越前端。

咳咳，如题，Echo Live 在操作优化方面已经遇到了瓶颈，仅靠前端已经无法提供更友好的交互体验。为此，我设想了几种应对方案，但这些方案以我目前的能力是无法实现的。为此，我需要征集意见和寻求帮助。

这样做有什么好处？

Echo Live 有很多有意思的功能受限于纯前端网页无法实现，不过一旦有了后端或者直接开发成应用程序，这些功能都有可能实现：

• 消息与上一条消息之间的过渡效果。
• 联动 Live2D 动作。
• 模块化设计，让用户根据自己的需求只需动动鼠标就能选择所需的模块。
• 更丰富且更规范的扩展包功能。
• 如有需要，可自动获取更新。

方案列表

先让我们来看一下现有的方案吧。

方案 A：开发后端

通过架设本地服务器来实现跨浏览器的网页通信，用户只需在浏览器网页中点击发送按钮，数据就会通过服务器向 OBS 内置浏览器中的网页传递数据，以此更新对话框内容。基于我的知识储备，优先考虑 Node.js 或 ThinkPHP 编写后端程序。

优点：

• 不需要大幅度改动，甚至还能优化现有的前端架构。
• 对我而言已有积累一些的开发经验，开发效率不会受到太大的影响。

缺点：

• 可能会对不熟悉本地服务器的用户造成困扰。
• 如果使用了框架，可能会产生大量文件，甚至存在冗余文件，增加了客制化难度。

方案 A.2：开发网站并上线运营

直接将后端程序部署到云端服务器，供用户使用。

优点：

• 对于直播用户而言是最优秀的解决方案（总不能断网开直播吧？），并且有成熟案例可供参考。

缺点：

• 容易受到外部因素影响正常使用。
• 客制化变得特别困难，这将彻底改变客制化的发展方向。
• 费钱。

方案 B：开发浏览器套壳应用程序

基于 Electron 或 NW.js 开发应用程序。

优点：

• 用户学习成本更低。
• 能整更花的活。

缺点：

• 可能需要大幅度改动现有前端架构。
• 可能需要改变被 OBS 捕获的方式，这可能会造成一些特性的丢失。（这个问题可以解决）
• 如果没有为客制化铺好路，将会严重阻碍客制化。
• 对我而言是从零开始，开发效率会受到很大影响。

方案 C：使用别的渲染引擎

目前来讲，这个方案全是缺点，没有这个方案。

以上就是我目前能想出的所有方案，欢迎大家提出宝贵的意见，如果能直接提供技术支持那是对我最大的鼓励，谢谢大家！

其他问题

在确定某一方案后，旧版的 Echo Live 会怎么样？

如果整体架构没有产生过大的变化，旧架构将会与新架构共存，供用户自由选择。反之，新架构成为新的分支，创建新的独立项目。

[sheep-realms]

由于有了新的优化方案所以此议题暂时搁置。

[xiaoniaoawa]

补充一条，nw.js的兼容性堪忧，不然就是针对多平台发布多个release，这是所有带后端的程序的大问题 :(