一个 MVVM 框架的性能进化之路

性能一直是 框架选型 最重要的考虑因素之一。San 从设计之初就希望不要因为自身的短板（性能、体积、兼容性等）而成为开发者为难的理由，所以我们在性能上投入了很多的关注和精力，效果至少从 benchmark 看来，还不错。

San non-keyed performance

将近 2 年以前，我发了一篇 San - 一个传统的MVVM组件框架。对 San 设计初衷感兴趣的同学可以翻翻。我一直觉得框架选型的时候，了解它的调性是非常关键的一点。

不过其实，大多数应用场景的框架选型中，知名度 是最主要的考虑因素，因为 知名度 意味着你可以找到更多的人探讨、可以找到更多周边、可以更容易招聘熟手或者以后自己找工作更有优势。所以本文的目的并不是将你从三大阵营（React、Vue、Angular）拉出来，而是想把 San 的性能经验分享给你。这些经验无论在应用开发，还是写一些基础的东西，都会有所帮助。

在正式开始之前，惯性先厚脸皮求下 Star。

先不要脸的求关注

主要升级点如下：

• 【新特性】- 支持 template tag 声明自身不渲染元素只渲染内容
• 【新特性】- 事件声明参数为空时，默认 $event
• 【新特性】- 支持通过 native modifier，直接为组件的根元素绑定事件
• 【新特性】- 支持通过 capture modifier，在捕获阶段绑定事件
• 【新特性】- 支持 scoped slot
• 【新特性】- 支持 transition 机制
• 【新特性】- slot 支持 if 和 for 指令
• 【新特性】- 组件实例上添加 slot 方法，可以获取组件内部 slot 插入的内容
• 【新特性】- 组件实例上添加 nextTick 方法，避免组件实现需要 nextTick 必须显式依赖 san
• 【新特性】- main 上暴露 NodeType 枚举对象
• 【变更】- parseTemplate 的 ANode 去除 parent 的引用。消除循环引用后可以 JSON.stringify
• 【变更】- ANode 上子节点命名由 childs 变更为 children
• 【变更】- 组件 LifeCycle 对象静态化，main 上不再暴露 LifeCycle 类
• 【优化】- data 的 push 和 unshift 操作返回新数组长度，和 JS Array 保持一致
• 【优化】- 增加事件绑定到不存在方法时的错误提示
• 【优化】- 当数组上有非数字索引的成员并发生变更时，添加判断使视图更新时不报错，增加健壮性
• 【bug修复】- ssr 在多重循环下可能渲染不完整
• 【bug修复】- input[type=file] 的 multiple 属性由于低级的拼写问题导致不支持
• 【bug修复】- input value 使用双向绑定时，如果绑定值为 undefined，表单内容未自动转为空串

原定 3.3.0 的完成时间是11月底，我们赶在11月最后一天晚上发布，这充分说明我们有 精雕细琢的工匠精神 拖延症。

到此应该可以结束了。不过好像少了点什么，所以随便说点东西吧。

这一年多来，其实受到过不少质疑，比如“咦，你们又在发明轮子了？”。每当此时我只能嘿嘿嘿一笑，毕竟你做的东西看起来还只是个垃圾而已，而看起来我们有很多成熟的东西可以选了：Vue、React、Angular、Polymer等等。在今天，我们觉得 San 经过了一些项目的验证（踩坑）和进化（填坑），能够出来见人时，我们打算出来说说为啥要造轮子，造的是个啥样的轮子。

根据厚脸皮的惯例，先求Star。接下来是广告，可能你能从广告里得到一点启发。

为什么要做 San

MVVM 并不是什么新鲜事物，在 Web 上的应用我们也远不是先驱。从几年前，我们有些团队在 Angular1 开始一些实践，也有些团队接触了 React，但是让我印象最深刻的还是 Vue，并不是因为多高深的技术，而是因为真的“好用”。我们在一些要求不那么高（兼容性、性能等）的应用中实践一些流行技术，并享受一些便利。将近2年前，我们对实践过的东西进行了一些总结，有些东西已经比较常识了：

• 组件化
• 声明式视图
• view=f(data)
• 数据到视图的渲染引擎
• 异步渲染
• ......

背景：

MVC是一种架构设计模式，它通过关注点分离鼓励改进应用程序组织。在过去，MVC被大量用于构建桌面和服务器端应用程序，如今Web应用程序的开发已经越来越向传统应用软件开发靠拢，Web和应用之间的界限也进一步模糊。传统编程语言中的设计模式也在慢慢地融入Web前端开发。由于前端开发的环境特性，在经典MVC模式上也引申出了诸多MV*模式，被实现到各个Javascript框架中都有多少的衍变。在研究MV*模式和各框架的过程中，却是“剪不断、理还乱”：

1. 为什么每个地方讲的MVC都不太一样？
2. MVP、MVVM的出现是要解决什么问题？
3. 为什么有人义正言辞的说“MVC在Web前端开发中根本无法使用”？

带着十万个为什么去翻阅很多资料，但是看起来像view、model、controller、解耦、监听、通知、主动、被动、注册、绑定、渲染等各种术语的排列组合，像汪峰的歌词似的。本篇希望用通俗易懂的方式阐述清楚一些关系，由于接触时间有限，英文阅读能力有限，可能会存在误解，欢迎讨论和纠正。