主要是我感觉完全看不懂你的图，左右对照的分别是什么，若是实现跟协议，那么最后为什么来个 RPC 跟 IPC 放在一起的格子。
还有这个上到下的顺序是什么？ HTTP 上层？ Protobuf 底层？ HTTP 又不建立于 Protobuf 之上，何来 HTTP 更上层一说。

@xiamx RB 太经常考了，考 AVL tree 才好啊

@SharkIng 其实-a 是问题不大，根本的问题在于 push 到公共库的代码就不要做改动 commit log 的操作（ git commit --amend 或 git rebase 等等)
因为那样会引起其他协作的人代码冲突

@daimoon 前端都不好招，不过我据一个超级无脑的比喻，维护状态机就跟查表一样。不同的事件对应一个状态。大概难就难在 NFA 到 DFA 这个转换上吧（这个的话看看编译器相关的书就好了，我学艺未精，刚看不就，就不献丑了），不过我觉得这个 NFA 到 DFA 大可由高级程序员去做，我觉得只有学过编译原理对这块应该是挺快的啊。
然后剩下的就是编写无状态组件的事情了。这样的事情你大可招几个实现生来做。毕竟前端的精髓就在你那状态机而已了。
我觉得多个状态除了状态机就没有什么好的方法管理了。若是仅仅靠组件间通信来暴力维护状态，迟早药丸。

若是状态机的这样的概念都理解不了，我觉得这样的人就应该考虑一下是否合适程序员这工作。状态机不是这几年才出现的东西，那是学界千锤百炼，业界实现了千千万万次才得出状态机是维护状态的利器这一结论。
若是觉得状态机不好，偏要弄其他东西取代它，小规模（状态少）倒是可以，大规模的真的迟早药丸。早日叫各位前端去读读别人编译原理里面跟状态机的内容才是正道啊。

@daimoon UWP 现在倒是用 WPF 的啊。我觉得要说 WPF 失败倒不如说桌面端已经没有以前那么流行了。你可以看看写游戏，写桌面多，写 Android 跟 iOS 的是不是用组件的嘛。
至于你说的父子组件通讯我就真不明白了， react 的组件压根就没有什么父子组件通讯啊。现行流行的 flux 实现 redux 就是维护一个状态机一样的做法，不同的事件改变状态机的状态，组件仅根据传入的 prop 来渲染结果，只有最上层的包裹组件去读取状态机的状态才会有 state 其他的组件都没有。
这很复杂么？就是维护状态机的做法而已，不见得有什么复杂。

@janxin 对，刚查了一下， pypy 是有 GIL 的， pypy stm 才没有 GIL

GIL 出去不是什么大问题，性能下降有很多原因，不仅仅是 GIL 移除的问题。
移除 GIL 最大的问题是很有可能会引起现有的 c 扩展都挂了，因为那很有可能会改动 cpython 的 c api 。
其实按道理来说移除 GIL ，引入颗粒度更小的锁，用基于可达性分析的 GC 来替代朴素引用计数都基本上是现代高级语言的做法。
至于 Python 界不是没有移除 GIL 的实现，一个很好的例子就是 Pypy ，那个可是没有 GIL 的，性能杠杠，还能真多线程。

组件化这个方案必然还会存在，现在的 web 就是在走以前桌面的那一套。 WPF 就早有双向绑定了， XAML 之类的对应 html （ jsx ），但是你的类实现一样是组件化的(class ，继承）。
至少在我看来 3 年内这样的模式还是很有效的。

@franklinyu 可以当然是可以，但是写两个感叹号不是更简洁？

@bdbai 很正常的用法啊， angular 或者 lodash 里面就有，谁叫 js 的 undefined 没办法简单判断

终于看到中国版的 CI SaaS 服务了，就凭这股经，先赞一个。

肯定是自己结束了。 TCP 协议不存在自己默认自动断开时间。

编辑器我只相信 vim ， WebStorm 是 IDE ，谢谢。

二进制你不知道具体数据格式没办法读，毕竟这相当于一个解码的过程，你不知道具体的规则怎么读？

看是谁的锅