大部分Web应用的富文本内容都是以HTML字符串的形式存储的，通过HTML文档去展示HTML内容自然没有问题。但是，在微信小程序（下文简称为「小程序」）中，应当如何渲染这部分内容呢？
小程序刚上线那会儿，是无法直接渲染HTML内容的，于是就诞生了一个叫做「wxParse」的库。它的原理就是把HTML代码解析成树结构的数据，再通过小程序的模板把该数据渲染出来。
后来，小程序增加了「rich-text」组件用于展示富文本内容。然而，这个组件存在一个极大的限制：组件内屏蔽了所有节点的事件。也就是说，在该组件内，连「预览图片」这样一个简单的功能都无法实现。
再后来，小程序允许通过「web-view」组件嵌套网页，通过网页展示HTML内容是兼容性最好的解决方案了。然而，因为要多加载一个页面，性能是较差的。
对于移动端的Web单页应用来说，为了达到媲美原生应用的效果，页面过渡动画是必不可少的。常用的页面过渡动画包括：
（注意：以下讨论和实验均在 Chrome 68 浏览器环境下进行）
目前大多数设备的屏幕刷新率为60次/秒，算下来每个帧的预算时间约为16.66毫秒（1/60秒）。考虑到浏览器还有其他工作要执行，实际上预算时间只有10毫秒。跟此预算时间的差值越大，用户就会觉得动画过程越卡。那么，在这10毫秒内要完成什么事情呢？当使用JavaScript实现视觉交互效果时，一般要经过以下流程：
HTML 5 曾被认为是移动应用的明天，却被原生App在性能和功能上轻易战胜，Web逐渐成为App的附属。然而，马云“爸爸”告诉我们：“梦想还是要有的，万一实现了呢？”如今，我们离梦想又近了一步。
PWA，全称「Progressive Web App」，是Google提出的为Web提供App般使用体验的一系列技术方案。它优势主要体现在：
本文将逐一讲述PWA涉及的主要技术方案。
由于网页传播的便捷性，从网页向APP导流几乎是所有APP厂商都会采用的推广手段，具体来说就是在网页上提供一些触发点（例如按钮、链接），用于跳转到APP。
上一篇文章主要介绍了我们团队的「Vue.js项目模板」的搭建过程，这只是第一步。作为新手，在实际开发过程中，难免还会遇到各种各样奇怪的问题。本文主要介绍问题的起因以及解决方式。
在单页应用中，由于页面切换不会导致浏览器重新加载页面，所以页面的标题是不会改变的，这时候就要通过Javascript去修改标题。这个操作本来是非常简单的，只需要修改「document.title」即可：
document.title = 'New title';然而，在iOS的微信和QQ中，这种方法可能无效，具体的现象就是：导航栏上的标题没有改变。这是iOS微信和QQ的bug，解决方法就是在修改「document.title」之后，用「iframe」发送一个请求（任意一个请求）。把相关的代码封装成函数：
function setTitle(title) {
document.title = title;
if (isIOS && (isInWeixin || isInQQ)) {
let iframe = document.createElement('iframe');
iframe.style.display = 'none';
iframe.src = '/favicon.ico';
iframe.onload = () => {
setTimeout(() => {
document.body.removeChild(iframe);
}, 9);
};
document.body.appendChild(iframe);
}
}据说新版的微信和QQ已经修复了这个bug，但为了兼容旧版本，这段代码还是必须的。
从今年（2017年）年初起，我们团队开始引入「Vue.js」开发移动端的产品。作为团队的领头人，我的首要任务就是设计整体的架构。一个良好的架构必定是具备丰富的开发经验后才能搭建出来的。虽然我有多年的前端开发经验，但就「Vue.js」来说，仍然是个新手。所幸「Vue.js」有一个配套工具「Vue-CLI」，它提供了一些比较成熟的项目模板，很大程度上降低了上手的难度。然而，很多具体的问题还是要自己思考和解决的。
我们公司的H5产品大部分是嵌套在手机客户端里面的页面。每个项目的功能都比较独立，而且规模不大。这样一来，既可以让这些小项目各自为政，也可以把它们集中放到一个大项目中管理。各自的优缺点如下：
| 一个大项目 | 多个小项目 | |
|---|---|---|
| 代码仓库 | 一个 | 多个 |
| 代码冲突 | 可能性大 | 可能性小 |
| 独立发布 | 不可行 | 可行 |
| 公共代码 | 共用一份 | 重复维护、加载 |
考虑到我们团队刚开始使用「Vue.js」，需要逐步摸索出合适的架构。如果做成一个大项目，一旦架构要调整，很可能会伤筋动骨。所以最终的选择是划分成多个小项目。
JavaScript是单线程运行、支持异步机制的语言。进入正题之前，我们有必要先理解这种运行方式。
以「起床上班」的过程为例，假设有以下几个步骤：
最简单粗暴的执行方式就是按顺序逐步执行，这样从起床到上班共需50分钟，效率较低。如果能在「洗刷」之前先「叫车」，就可以节省10分钟的等车时间。
这样一来「叫车」就成了异步操作。但为何只有「叫车」可以异步呢？因为车不需要自己开过来，所以自己处于空闲状态，可以先干点别的。
先看一段代码，这是一个实现倒数功能的类「Countdown」及其实例化的过程：
function Countdown(seconds) {
this._seconds = seconds;
}
Countdown.prototype._step = function() {
console.log(this._seconds);
if (this._seconds > 0) {
this._seconds -= 1;
} else {
clearInterval(this._timer);
}
};
Countdown.prototype.start = function() {
this._step();
this._timer = setInterval(function() {
this._step();
}, 1000);
};
new Countdown(10).start();运行这段代码时，将会出现异常「this._step is not a function」。这是JavaScript中颇受诟病的「this错乱」问题：setInterval重复执行的函数中的this已经跟外部的this不一致了。要解决这个问题，有三个方法。
我还在56网工作的那段时间里，创业公司遍地开花，偶尔也会有以前的同事邀请我加入，其中就有美黛拉的产品技术团队。虽然跟公司的老板并不熟，但是团队中有不少以前网易的老同事，所以考虑再三之后还是选择了加入。
入职之初，除了我以外，公司只有一名前端工程师。前端的项目也不多，只有后台管理系统和几个零散的手机端页面。所有前端项目都采用前端渲染的模式，目的是为了避开前端写页面后端套模板这个坑。但这样做的问题在于： SEO不友好；加载数据的延时。而就在此时，公司打算要做PC站，客户端的一些功能也要通过内嵌网页来实现。所以建立起一个良好的前端架构显得非常必要。
毫无疑问，这个架构必须是前后端分离的，而且要做到前端渲染和后端渲染兼备，同时两端的代码要尽可能复用。要同时满足上述条件，最好的选择就是用Node.js在后端和浏览器之间做一个中间层。浏览器的请求会先到达这个中间层，中间层请求数据渲染出HTML后返回到浏览器。
我在加入公司之前，已经把自己的博客用Node.js重写了一遍，所以再去写这个中间层并不吃力，最终做出来的成品被我命名为「Back2Front」。此外，还基于Gulp开发了配套的构建工具。
先来看这样一段代码：
function update() {
loadData().then(function(data) {
$('#content').html(data.content);
var delay = data.nextUpdateTime - new Date();
if (delay > 0) {
setTimeout(update, delay);
}
});
}其流程非常简单：通过AJAX加载数据后更新HTML的内容；如果有指定下次更新时间，则通过计时器在该时间点再执行一次整个流程。
要说这段代码有什么隐患的话，那就是data.nextUpdateTime与当前时间的时间差（即delay变量的值）比较小的时候，会导致内容频繁更新。但这是属于正常的业务逻辑，要优化就只能牺牲内容更新的即时性。然而这里我要说的是，当时间差非常大的时候，也会出现同样的问题。