【微信名字加or】如何选择小程序框架-拍拖百科

小程序的诞生

微信开了一个头

微信不是第一个小程序的App，而是小程序最有优势的App(如高流量、用户长停留时间等)。从微信的角度来看，小程序在业务形式上更像是公众号开发的进化产物。此前，微信通过SDK格式加强了开发者开发公众号网站的能力。小程序的诞生是微信本身面向平台超级应用程序的商业行为，帮助用户更好地实现“轻量级web应用程序”。

微信小程序诞生之初，就自己定义了“标准”，与前端已经存在的生态不符，早期框架中存在着与组件、NPM、web生态的严重脱节。开发者因为特殊的多线程模型和与众不同的语法而非常痛苦。小程序的开放只是对三方业务的开放。

蜂拥而至的效仿

其他企业看到小程序业务的开放性，想制作基于平台的应用程序。支付宝小程序、百度小程序、淘宝小程序、360小程序、快速应用程序。他们中的大部分人都会选择像微信一样的体系结构、框架，这不是从技术角度做出的决定，而是想尽可能摩擦微信小程序的福利，让开发人员更快地投入到自己的平台上。当然，其中两个略有不同。一个是早期的淘宝小程序，不仅支持axml的写法，还支持Vue开发的SFC，使开发者有选择的权利，更好地连接现有前端生态系统。另一个是快速应用程序，也是用Vue等语法开发的，但有点畸形的是，它创造了对Vue的魔法改造等标准。开发者的开发成本没有有效提高。

小程序框架选择

小程序原生语法 and 增强型框架

小程序原生语法

这是不是基本语法，肯定是被抛弃了。站在2020年的这个时间节点上不是这样。单纯以微信小程序or支付宝小程序为例，目前的小程序生态系统足以让开发者利用前端已经有的部分生态开发出符合预期的应用程序。

与以前NPM功能的缺失相比，只能通过模板渲染来实施组件。现在小程序可以做前端工程，可以移植状态管理、CLI工程等前端生态系统中已经存在的概念。

也就是说，如果业务要求只适用于微信小程序或支付宝小程序，基本语法可能是前端程序员的选择。您可以组织项目、手写、使用社区中现有的状态管理库细分管理组件状态，还可以使用TypeScript编写自己的应用程序。总之，你可以把你习惯的一切带到小程序的这个领域。

渐进增强型框架

所谓的渐进式增强框架，在小程序引入NPM后，通过更开放的能力可以获得的收益更多。这些框架通常以小程序基本语法为主，但在逻辑层引入增强语法，以优化应用程序性能或提供更方便的使用方法。

以腾讯开源omix框架为例。

逻辑层

Crea(store，{

//从属声明

Use: ['logs']、

Computed: {

LogsLength() {

Return

}

}，

OnLoad: function () {

//响应，自动更新视图

=('logs') | | [])。贴图(log={

Return u(new Date(log))

})

settime out()={

//响应，自动更新视图

[0]='Changed！'

}，1000)

}

})视图层

View class='container log-list '

block wx : for=' { { logs } } ' wx : for-item=' log '

Textclass=' log-item' {{index1}}。{{log}}/text

/block

/view先不谈其语法是否符合直觉或容易使用。简而言之，它整体保存了小程序中已有的语法。但是在此基础上，通过[0]='Changed '可以直接修改状态，包括在Vue中引入比较有代表性的computed，进行了扩展和增强。可以说是以applet基本半Vue半React的语法(其中一半是量词)为背景完全Vue化的方案。

使用增强框架的最大优点是，可以只引入最少的依赖，保持对小程序的认识，同时用更舒适的语法编写代码。这些框架是只将目标放在特定平台小程序上的开发人员或非专业前端的理想选项之一。因为只要关注很少的新文档和小程序本身的文档就足够了。毕竟，在推进某种技术的过程中，也要考虑团队的学习成本。

转换

转换类框架

类框架的任务与逐步改进的框架相比完全不同。转换类框架的任务是让开发者很少感受到小程序基本语法，在前端有生态系统，实现* *“多端”

」的业务诉求，只是最后的构建产物**为小程序代码。随着这几年的发展，转换类框架大的方面分为两种 -- 编译时/运行时。下文会分别针对两种方案进行分析。

Rax 编译时/Taro 2.0

顾名思义，编译时方案的核心是通过编译分析的方式，将开发者写的代码转换成小程序原生语法。这里以 Rax 编译时和 Taro 2.0 为例，面向开发者的语法是类 React 语法，开发者通过写有一定语法限制的 React 代码，最后转换产物 1:1 转换成对应的小程序代码。

以一段简单的代码为例：

Rax：

import { createElement, useEffect, useState } from 'rax';
import View from 'rax-view';

export default function Home() {
  const [name, setName] = useState('world');
  useEffect(() => {
    con('Here is effect.');
  }, [])
  return <View>Hello {name}</View>;
}

转换之后的小程序代码：

逻辑层

import { __create_component__, useEffect, useState } from 'jsx2mp-runtime/di;

function Home() {
  const [name, setName] = useState('world');
  useEffect(() => {
    con('Here is effect.');
  }, []);
  
  ({
    _d0: name
  });
}

Component(__create_component__(Home));
复制代码

视图层

<block a:if="{{$ready}}">
  <view class="__rax-view">{{_d0}}</view>
</block>

编译时方案最大的特点就是，开发者虽然写的是类 React 语法，但是转换后的代码和渐进增强型框架非常类似。开发者可以比较清晰的看出编译前后代码的对应关系。

简单来说，编译时方案会通过 AST 分析，将开发者写的 JSX 中 return 的模板部分构建到视图层，剩余部分代码保留，然后通过运行时垫片模拟 React 接口的表现。

以一个简单的 return <View>Hello world</View> 为例，如果想要提取到 <View>Hello world</View>，你可以写这段解析代码：

// 省略定义 babel parser 和包装 traverse 的部分
const code = (FILE_PATH);
const ast = parser(code);
traverse(ast, {
  ReturnStatement(path) {
    const targetNodePath = ('argument');
    if ()) {
      // 如果 return 的子元素是一个 JSX Element 就收集 or 处理一下
    }
  }
})

targetNodePath 就是 <View>Hello world</View> 的节点路径，关于 AST 相关的文章可以自行搜索一下，babel 的 handle book 已经比较详细了，再加上这个辅助网站基本是没有什么门槛的。

但是这个方案其实是存在明显的优势和劣势的。

优势

运行时性能损耗低
目标代码明确，开发者所写即所得
运行时、编译时优化

在这个方案中，你可以轻易的做到和渐进增强型框架一样的效果，即给予开发者更多的语法支持以及默认的性能优化处理，比如避免多次 setData，亦或是长列表优化等等。

劣势

语法限制高

由于需要完全命中开发者在模板部分所用到的所有语法，这就对编译时框架的实现者有相当高的要求。因为大部分前端开发者们其实已经对灵活的语法有一定的依赖性，比如会使用高阶组件，比如在条件判断的时候写很多 return 等等。进一步的，由于是 1:1 编译转换，开发者在开发的时候还是不得不去遵循小程序的开发规范，比如一个文件中定义只能定义一个组件之类的。

目前在阿里巴巴集团内部，Rax 的这套编译时方案已经落地了很多业务，包括「电影演出」小程序等，从开发者的实践来看，如果能够掌握编译时开发的技巧，即保证最终 return 的模板的简洁性，语法限制其实还是在可以接受的范围内的。

Rax 运行时/Remax/Taro Next

运行时方案相比于上面的编译时方案，最大的优势是可以几乎没有任何语法约束的去完成代码编写。这对于开发者而言，无疑是最大的吸引力，高阶组件用起来！createProtal 用起来！但是在小程序领域上暂时还不可能存在这么好的事情，这也是小程序原生语法最后的执拗。没有语法限制带来的更多的性能上的牺牲，这个与运行时方案的实现方式有很大的关系，接下来我详细介绍一下。

从渲染的角度来看，这套方案更贴近于富文本渲染。逻辑层将一个和节点渲染信息相关的组件树传递给视图层，视图层通过节点类型判断然后进行视图渲染。下面这个图简要的描述了一下整个过程：

虽然只用了维护两个字，但是逻辑层做的事情其实比较复杂。首先要做的是，去处理节点间的关系，去模拟 appendChild/ removeChild/updateNode 等各个行为来操作 VDOM 树。其次比较重要的是去模拟事件，在逻辑层每一个节点类会继承自 EventTarget 基类，这个和 W3C 是一样的，然后通过 nodeId 作为标识去收集需要监听的事件，当视图层通过 action 触发了某个节点的事件之后，再通过原生小程序事件中的 event.curren获取到目标节点的 id，最终触发目标回调。

由于本文篇幅问题，不会更加详细的介绍其中的各个部分更加具体的实现，感兴趣的同学可以通过 Rax 的源码或者 npm init rax demo 起一个项目通过最终的产物来研究整个原理。

在目前这个阶段，即使是运行时方案，也有不同的实现思路。以 Kbone (Rax 运行时方案是从 Kbone 改造而来) 和 Taro Next 都是通过模拟 Web 环境来彻底对接前端生态，而 Remax 只是简单的通过 react reconciler 连接 React 和小程序。

从业务诉求来看，笔者认为，Rax 和 Taro Next 可能会比 Remax 更加开放。首先，需要考虑是三部分的诉求，（1）毫无语法限制，既然已经没有了语法限制，为什么不能用前端更加熟悉的方式来开发，即拥有操作 DOM 的权利；（2）不和 DSL 耦合，尽管在阿里巴巴集团内，对 React 的认可度更高，但是从实现原理上来看，和某个框架进行强绑定一定不是最优解；（3）旧有的 Web 业务迁移，今天我们所面对的开发者，很多都是因为业务压力或者其他情况需要将原有的 Web 页面迁移到小程序上，那么用模拟 Web 环境这套方案是最好不过了，根据我们的测试，大部分业务几乎可以无缝迁移过来。

说了这么多漂亮话，运行时方案真的很香，但这并不是救世主，我来说说它的劣势。

**劣势 1：**数据传输量大，我们需要将完整的组件树在逻辑层传输到视图层；

**劣势 2：**页面上存在大量的监听器，每一个组件都需要无时无刻监听所有的事件，在事件不断触发的过程中，通过 nodeId 筛选出真正需要触发的事件；

**劣势 3：**模板递归渲染，如果使用原生语法，原生框架可以在渲染前就知道页面大概的结构，来对渲染进行优化，但是如果仅仅只是通过类似 <view a:if="{{node.tagName === 'view'}}"></view> 这样的信息，是很难判断页面的真实结构的。

组合

鱼和熊掌虽然不能兼得，但是可以各要一半~再次强调，本文不是广告文。如果编译时和运行时方案共存呢？基于淘系前端高度现代的工程化积累，开发者已经习惯通过区块来组建项目。更得益于，Rax 在编译时和运行时方案都有所积累，我们希望能够将运行时方案和编译时方案组合使用。对于基础复杂或者对于性能有要求的模块通过编译时实现。然后再通过 npm 包的形式，引入到运行时的项目中去，从而有效降低了运行时方案的性能损耗，并且能保证绝大部分的业务场景可以用无限制的语法完成，而开发者所面对的都是 Rax DSL。

用一个 Demo 来看下：

// 这是一个倒计时组件，通过编译时实现，然后发布为 rax-taobao-countdown
import { createElement } from 'rax';
import View from 'rax-view';

function CountDown(props) {
  // 省略各种逻辑...
  return <View>{day}:{hours}:{minutes}:{seconds}</View>
}

export default CountDown;

// 运行时项目
import { createElement } from 'rax';
import CountDown from 'rax-taobao-countdown';

function Home() {
  return <CountDown now={Da()} />
}

假设，我们这个倒计时组件结构非常复杂，并且要求极高的交互性。那么，开发者可以通过编译时方案开发一个高性能 CountDown 组件，然后在运行时项目中引入使用。此时，视图层所得到的节点树信息大致如下：

{
  "tagName": "custom-component",
  "type": "element",
  "behavior": "CountDown",
  "children": []
}

而不会有更多更深层结构的节点信息，有效避免刚刚说的运行时方案中存在的劣势。

Web 才是未来

小程序原生语法绝对不是小程序 or 下一代的渲染方案。通过微信小程序现有的语法规范来对开发者进行绑架，只会让更多的人想突破围城。微信小程序似乎已经意识到了这一点，从目前的迭代来看，微信小程序引入了越来越多 Web 已有的东西，包括通过 wxs在视图层就可以一定程度上操作 DOM，甚至获取到逻辑层组件实例等等，这个可以给现有的转换类框架提供更多的可能性。但是，如果小程序如果一开始设计的不这么糟糕呢，我们可能会失业（开个玩笑）？

对于业务的开发者而言，「一码多端」才是效率最大化的。今天的业务需求可能只是投放到小程序容器，明天的需求可能就是投放到 Web，未来甚至是 Flutter。Web 是最贴近前端开发者的，有组织保障（W3C）的规范。所以，站在 2020 年这个时间点，无论是框架提供者，还是业务开发者都应该更多的从标准的角度思考问题，这样才能让业务代码有更多的可能性。

总结

距离小程序诞生已经过去很多年，2020 年应该如何选择业务合适的小程序框架，这个需要开发者衡量利弊之后再做出选择。因为每个业务的形式不同，应用的存活时间也不相同，根据自己的需要选择可能才是最好的，本文只是从一个全局的视角对所有类型的框架进行分析，希望能够让正在看文章的你，不那么纠结~

链接：
来源：掘金