基于热替换技术推想将来的 Web 开发技术

微博上写了几段, 想一想太长, 仍是写成文章发出来, 这事对我还挺重要的
本来是在反思本身为何兴趣所在的前端项目竟然蔓延得那么广
甚至致使技术不专注, 不少细节作很差. 其中的缘由何在? 我认为前端太广
因而想到总体发展的趋势上, 因而认为背后还在更深层的事件
按这点进行推想, 也就是站在热替换这点往前眺望, 有种可能性
背后的想法已经挺长时间了, 临时想到整理成文章前端

文章章节拆分:面试

  • 热替换技术的现状编程

  • 后端热替换的能力后端

  • 热替换的要求和限制浏览器

  • 推想一种将来的开发方案服务器

  • 须要着手填补的短板网络

  • 总结框架

热替换技术的现状

这是 Elm 和 Webpack 烧起来的很旺的一把火, 随着 React 烧得更远了
很快你们看到对于前端 React 应用, 或者 React Native, 都有了
这种状况下能够一边写代码, 而且预期在模拟器当中直接查看改变
若是代码有错, 可能作到直接把静态检查的错误直接提示出来
那么开发人员直接修复错误, 直到代码正确, 代码进行热替换less

目前热替换, 前端方面有 Browserify, Amok 之类, 而 Webpack 支持前端后端
在 cljs 方面基于 boot-reload 能作前端, 基于 figwheel 作前端后端
Elm 能作前端, 只不过不像是前二者那么通用
而 Webpack 和 cljs 我在过去几个月作了几回尝试, 效果是能够的
我最多作到在阿里云跑开发环境, 远程编辑, 前端后端热替换, 直接加功能前后端分离

前端热替换主要基于 MVC 分离的思路, View 与 Model 分离, 能任意调用
全部的界面数据, 要么做为 global Store, 要么抽象为组件 states
只要保证 store 和 states 能在替换代码过程当中能保持, 就有整个界面
而 View 代码想要替换就替换掉好了, 替换完成从新运行就行了
方案主要基于 React 和相关有 virtual DOM 框架. 其余 Vue 也能够

另外 Time Travel Debugging 还有存储每一个数据操做方便重演的机制
相关的资料较多, 应该已经都注意到吧

后端代码

好比 Webpack 也能作后端代码的打包和热替换
也就能作到在 WebSocket 不关闭而状况下直接替换代码
所以结合两点以后, 实际上已经能作先后端同时热替换代码
好处就是不须要整个重载程序, 从新链接 WebSocket, 更快更方便

我后端经验很少, 前面试验的代码是用前端 MVC 的思路写的
也就是抽象出内存中的一份 Database 做为个人 Model,
同时把客户端对应的 Store 做为 View, 而 View 是容易替换的
那么代码更新过程当中, Model 不受影响, View 部分轻松替换
Webpack 替换的代码是局部的, 因此说 WebSocket 不受干扰

以前问过, 后端开发对热替换彷佛兴趣不大, 毕竟自己就作了解耦
数据都在 DB 当中, 不受程序的重启而影响, 因此整个重启就好
因此说不受影响, 即使生成环境全部服务器进程进行重启, 也正常
我以为这种方式毕竟, 各类 IO 都要从新建立, 有点开销, 并且有点慢
再者, 有 WebSocket 的话, 仍是须要方案来保证 WebSocket 稳定

热替换的要求和限制

对于 React 来讲, 热替换比较明显的问题在 states 处理上
因为 React states 是私有状态, 不像 Store 管理起来方便
不过这是个老问题, 我也明确了是有解决方案的, 好比设计全局组件状态
能解决就很少讲了

而后是热替换对程序状态的影响, React 中而错误代码会致使进程没法继续
缘由就是代码错误, 致使 React 内部记录的状态出错, 于是程序故障
这也是已经有办法的, 主要是静态检查, 在程序执行之间作一次筛选
作得好的好比 Elm, 能分析到具体的类型, 最终能编译经过就很难报错
我没写大的 Elm 程序, 而是用 cljs, cljs 的变量检查已经比较实用了
基本能明确类型设计得更舒服, 在这一点上会明显改善

对抽象的影响, 这就涉及到编写程序时整个程序如何设计的问题了
React 带出的 pure render, stateless, 跟这个直接相关
为了程序能更好地热替换, 其实要求了更严格的对反作用的限制
好比渲染代码会在代码替换时被执行, 那么就不能随便插入数据操做在其中
也就是限制反作用, 而让无状态因此可替换的代码能直接更新掉
因而不少从前的开发习惯就须要转变思路

性能方面, 热替换自己彷佛问题不大, 毕竟 Erlang 用了也仍是快的
可是在 React 这样的方案观察下来, 因为用了函数式写法, 就可能有问题
函数式编程首先经过不可变数据和高阶函数造成了对内存的压力
而这在 virtual DOM 方案当中, 又是很难消除的因素
性能问题和明了, 也是你们共同的问题, 很少讲

一会儿能想到的限制就这些, 估计还有很多琐碎的问题

推想一种将来的开发方案

在热替换基础上, 我尝试的开发方式已经和以前有不小的区别了
除了前端的热替换, 我还把后端联系到了一块儿, 让后端控制 store
因此我能够在改一段后端代码, 直接发送 diff 到前端, 界面直接更新
也就是说能作到动态修改 View 代码, 而网络链接, 浏览器页面状态都不受影响
Controller 代码也能更新, 但须要经过其余方式从新运行查看结果
Model 因为存储了程序的状态, 处理起来会更复杂, 须要记录每一个操做
大致上是这样.. 至关于 React 的效果, 对多个客户端也生效

我想说, 还能走得更远. 我但愿是, 能作到不少人同时一块儿开发
对, 多人同时开发同一个项目, 而不是每一个人拷贝一份本身开发再 merge
好处应该想得差很少, 新人来了开发环境不用单独配, 省不少时间
一块儿作, 相互能熟悉工做内容, 相互也能监督, 下降交流成本
当一个功能有多人同时作, 开发速度也能提升, 相比一我的作不一样的细节

想法很简单的, 但如今都没作起来, 显然难点有不少
首先, 即使在服务器上用 Vim 或者在线工具编辑, 多人操做也不方便
其次, 不一样的人写的代码相互冲突了怎么办, 怎么开发下去?
一我的写完了一部分, 重启服务测试, 影响到另外一我的正在测试怎么办?
虽然有其余问题, 但我认为影响最大是这些问题

首先多人编辑, 印象里有看到新闻有在尝试, 估计不成熟, 待会再回头说
可是代码冲突, 功能调试, 我想热替换已经给了不错的解决方案了
代码冲突首先能够依靠类型静态分析干掉不少, 作到代码有问题不去运行
热替换技术当中单个文件的类型分析很廉价, cljs 中也算成熟了
而功能测试, 因为不须要重启服务器, 相互直接也就少了不少的影响

另外有一点, 热替换要求程序严格控制反作用, 有另外的好处
在 React 而言, 这要求应用的结构, 组件的模块化, 作得更加严格
结果是你们写的 React 组件抽象出 state, 抽象出渲染方法, 其实相似
而这有利于编程思路编程规范相互之间少一点分歧, 读代码更容易

须要着手填补的短板

如今热替换直接上, 作多人协同编程, 有些难度, 我只是以为能够一试
就 React 而言, 我认为对错误的容忍性过低, Flow 或者 TypeScript 应该更好
个人话是 cljs, 虽然不能避免全部错误, 但变量检查已经能干掉好大一部分数量
我以为这些主要是加固吧, 为了让调试过程更加增量, 影响范围也更小
多说一句, 我认为须要引入 Haskell 系的强大类型系统来帮忙, 山寨一个也好
ADT 完整的实现确实门槛高, 可是其中实用的地方拿过来总能够吧...

编辑器的问题是大头, 首先就是先后端分离, 跑在服务器上, 浏览器端操做
而后, 每一个修改须要是增量的, 这样方便同步到大量的客户端
而且, 操做合并应该只有极少甚至没有冲突, 不然实际操做会很繁琐
在就是 UI 上要作不少的改进, 讲多我的的状态显示出来
的以我目前在单页面的探索来看, 这个事情可能性是达成了的, 虽然难度很多
我能够基于 Cirru 先搞出这样的方案来, 先试验一下效果如何

另外类型检查, 也是个能改进的地方, 注意到吗, 类型检查都打 log
为何类型检查不能直接在编辑器上提示, 而后给个选项一键纠正?
编辑器是基于文本的, 并非基于图形界面的, 我估计这个事情麻烦了
若是 IDE 都是像 CSS 这样用树形编辑器操做, 我想也许就好多了
而这同时也是前面说的增强类型检查功能所遇到的问题...
想法还不成熟, 之后再想一想

总结

基于上边这些讨论, 我认为热替换带来了不小的突破的机会多人协同编程的某些障碍, 已经由热替换技术扫平了, 成了相对次要的问题若是能让编辑器支持多人开发, 距离多人协同编程就很近了我以为能够在 Cirru 上继续探索一下...如今都已经能直播写代码加在线热替换了, 再开发出编辑功能如何?

相关文章
相关标签/搜索