一个 MVVM 框架的性能进化之路
性能一直是 框架选型 最重要的考虑因素之一。San 从设计之初就希望不要因为自身的短板（性能、体积、兼容性等）而成为开发者为难的理由，所以我们在性能上投入了很多的关注和精力，效果至少从 benchmark 看来，还不错。
San non-keyed performance
将近 2 年以前，我发了一篇 San - 一个传统的MVVM组件框架。对 San 设计初衷感兴趣的同学可以翻翻。我一直觉得框架选型的时候，了解它的调性是非常关键的一点。
不过其实，大多数应用场景的框架选型中，知名度 是最主要的考虑因素，因为 知名度 意味着你可以找到更多的人探讨、可以找到更多周边、可以更容易招聘熟手或者以后自己找工作更有优势。所以本文的目的并不是将你从三大阵营（React、Vue、Angular）拉出来，而是想把 San 的性能经验分享给你。这些经验无论在应用开发，还是写一些基础的东西，都会有所帮助。
在正式开始之前，惯性先厚脸皮求下 Star。
阅读全部往返缓存（Back/Forward cache，下文中简称bfcache）是浏览器为了在用户页面间执行前进后退操作时拥有更加流畅体验的一种策略。该策略具体表现为，当用户前往新页面时，将当前页面的浏览器DOM状态保存到bfcache中；当用户点击后退按钮的时候，将页面直接从bfcache中加载，节省了网络请求的时间。
但是bfcache的引入，导致了很多问题。下面，举一个我们遇到的场景：
sample
页面A是一个任务列表，用户从A页面选择了“任务1：看新闻”，点击“去完成”跳转到B页面。当用户进入B页面后，任务完成。此时用户点击回退按钮，会回退到A页面。此时的A页面“任务1：看新闻”的按钮，应该需要标记为“已完成”，由于bfcache的存在，当存入bfcache时，“任务1”的按钮是“去完成”，所以此时回来，按钮也是“去完成”，而不会标记为“已完成”。
既然bug产生了，我们该如何去解决它？很多文章都会提到unload事件，但是我们实际进行了测试发现并不好用。于是，为了解决问题，我们的bfcache探秘之旅开始了。
Node.js 的出现，让 JavaScript 脱离了浏览器的束缚，进入了广阔的服务端开发领域。而 Node.js 对 CommonJS 模块化规范的引入，则更是让 JavaScript成为了一门真正能够适应大型工程的语言。
在 Node.js 中使用模块非常简单，我们日常开发中几乎都有过这样的经历：写一段 JavaScript 代码，require 一些想要的包，然后将代码产物 exports 导出。但是，对于 Node.js 模块化背后的加载与运行原理，我们是否清楚呢。首先抛出以下几个问题：
本篇文章，就会结合 Node.js 源码，探究一下以上这些问题背后的答案。
阅读全部
先不要脸的求关注
主要升级点如下：
原定 3.3.0 的完成时间是11月底，我们赶在11月最后一天晚上发布，这充分说明我们有 精雕细琢的工匠精神 拖延症。
到此应该可以结束了。不过好像少了点什么，所以随便说点东西吧。
阅读全部在 ECharts 新发布的 3.8 版本 中，新加入了 树图，支持 横向布局、纵向布局、径向布局；新加入了 SVG 渲染支持（beta 版） 的支持，从而可以根据自己的需要，选择 SVG 或者 Canvas 作为渲染引擎；代码的模块系统改用 ES Module，从而能够受益于 tree shaking 减小 bundle 的体积；同时开放了构建脚本协助用户进行 自定义模块、语言地构建。
阅读全部在这个教程中，我们将使用 Ionic 创建原生应用，并用 ECharts 创建饼图和水球图。Ionic 项目开发语言是 TypeScript，而 ECharts 的官方版本是基于 JavaScript 的，本教程将带你轻松实现在 TypeScript 中创建 ECharts 图表。
最终，我们将实现这样的效果：
