inferno

一.特性 fragment 模版支持fragment和string类型，对应ReactElement数组和字符串 v16.2.0还提供了JSX的fragment支持：<></> error boundary 组件级错误处理，支持捕获子组件树内部异常，UI层的兜底方案 portal 允许组件树与DOM树结构不一致，用于hovercards，tooltips等场景 例如tooltip在DOM结构上target与tip一般是兄弟关系（布局需要），而逻辑上tip是属于target的，是父子关系，portals特性用来处理这种场景 特殊的，事件冒泡经过处理，portals组件的父组件仍然能接到冒泡通知（React 16之前就内置了用来抹平DOM事件冒泡差异的事件系统，这里顺便支持拐弯冒泡 示例） support for custom DOM attributes 之前内置了HTML/SVG属性名白名单，自定义属性会被拦截并忽略掉，React 16去掉了这个限制 去掉该限制有2个原因，其一，这层内置的属性过滤对于非标准的（比如proposal阶段的）新属性和其它库/框架（比如Angular、Polymer）很不友好；其二，bundle里要内置一份体积不小的属性白名单，维护起来还挺麻烦 improved server-side rendering 号称比React 15快3倍

本文关键字：plan9,Inferno,limbo,Plan 9 from User Space:plan9port 在《除了UNIX，我们真的有可选的第二开源操作系统吗？》中，我们讲到那些传统的os之争是集中于游戏好不好支持，桌面好不好体验，发行够不够流行，总体好不好用这些方面。而从x86 cpu从0开始的抽象全栈，他们都是一样的 ------- 换言之，某种意义上他们都是一样的OS。 这种共同点在于哪里呢？对于最终的APP和APP开发来说，它们都是基于单PC+单PC下网络程序设计的。于是在这种架构下有了我们现在处处见到的web,云，—— 我们发现，当今的集群和分布式是放在云这个普化架构来做的：集群就是好多好多的PC通过网络计算起来，附带一些PC监控节点 —— 它们还是PC，在每一台PC内部运行的APP，都是从socket开始（更抽象一点，也许还有DCOM，消息件）的“云”程序:这种程序其实还是网络程序，这种总架构下的APPDEV，以OS来看，其实本质都是单机环境下网络交互的程序。 而这些都不是究极的分布式和分布式开发设计。 在《一种开发发布合一，语言问题合一的shell programming式应用开发设想》中，我们讲到了对于任何programming的设想，其实都是一个四栈从0开始叠加的设计。每一个appmodel，都是从hardware从0抽象来的，OS是大件。———