最近，前端多端框架经常出现。我相信许多需要多端代码操作的开发人员会有一些疑问：这些框架的优点和缺点是什么？我应该使用哪一个？

作为芋头开发团队的成员，作者希望尝试从本文的客观和公平的角度评估每个框架的选择，优势和缺点。但是，由于利益，本文中的观点可能会偏见。您可以从批判性的角度看待它们，只是通过介绍而行动。

因此，我们在谈论多端框架时在谈论什么：

多端

-

作者认为，流行的多端框架可以大致分为三类：

1。全包

这种类型的框架的最大特征是，它们都是从基础渲染引擎，布局引擎到中间DSL然后再到上部框架的。代表性框架是QT和。这种类型的框架具有明显的优势：高性能（上限）和每个平台的一致渲染结果。缺点也很明显：有必要完全重新学习DSL（QML/DART），并且很难适应中国风格的末端：迷你程序。

这种类型的框架是最原始，最纯净的多端开发框架。由于从底层到上层的每个链接都掌握在自己的手中，因此它可以在很大程度上确保开发和跨端体验的一致性。但是，他们的框架研发成本很高，渲染引擎，布局引擎，DSL和上部框架的每个部分都需要大量的人力来开发和维护。

2。网络技术

这种类型的框架将Web技术（，CSS）带入移动开发。自发开发的布局引擎流程CSS使用业务写作逻辑，将流行的前端框架用作DSL，每个端都使用自己的本机组件来渲染。代表性的框架和WEEX，这样做的优势是：

缺点是：

当交互复杂时，很难编写高性能代码。这种类型的框架的设计将不可避免地导致JS和JS之间的通信需要。经常触发通信可能会使UI无法在16ms之内绘制。有一些声明性的组成部分可以避免此问题，但是声明性写作很难满足复杂互动的需求。

由于在两端都没有使用本机组件的渲染引擎和渲染，因此相同代码渲染的一致性不如第一个。

3。编译

这种类型的框架是我们文章的主角：塔罗，wepy，uni-app，和原理相似：首先，基于它选择一个基于它的DSL框架，并使用此DSL框架作为标准，将其编译为不同的代码。每个端都有一个运行时框架或兼容组件库，以确保代码正确运行。

创建此类框架的最大优势和最大的原因是Mini程序，因为除了跨系统平台外，实际上还可以在浏览器中编译第一个和第二个框架。 （QT有QT，是的，是的-Web，WEEX本机支持）

另一个优点是它通常在移动设备上汇编为 /WEEX，因此它们也具有Web技术框架的优势。这看起来很漂亮，但实际上，无法避免 /WEEX的汇编框架缺点。此外，编译框架的抽象不是免费的：当发生错误时，问题的根本原因可能在于各个方面，例如运行时，编译时间，组件库和依赖它们的库。在塔罗开源过程中，我们遇到了错误，错误和引擎错误，当然，芋头本身也是必不可少的。我相信其他具有相同原则的框架无法避免此问题。

但这并不意味着为迷你程序设计的这种多端框架是没有用的。首先，各种巨型超级应用程序的迷你程序都在开花，框架将做很多工作来平滑迷你程序。在大多数情况下，这些任务不需要开发人员的关注。其次，许多业务类型不需要复杂的逻辑和交互，并且在框架的基本依赖关系中触发错误并不容易。

因此，当您的业务适合选择编译框架时，我需要考虑的第一件事是选择DSL的起点。由于多端需求企业通常希望快速发展，因此可以迅速适应团队发展速度的DSL至关重要。无论是Vue（或类似Vue），它们都有其优势和缺点，您可以根据团队的技术堆栈和偏好进行选择。

如果可以接受什么DSL，那么您可以转到下一步。

生态

-

以每个框架的稳定版本的发布标准（2019年3月11日）讨论以下内容。

开发工具

至于开发工具，Uni-App应该是最好的。它的文档是最详细和最丰富的文档，它还带有其自己的IDE图形开发工具。您只需一点点鼠标即可编译，测试和释放它。

其他框架使用CLI命令行工具，但是值得注意的是，有独立的语法检查工具，而塔罗则分别编写规则和规则集。

在语法支持方面，uni-app，taro和wepy都得到了支持，并且可以通过实现编辑器来自动完成所有四个。除了完成API之外，由于对JSX的良好支持，Taro还可以自动完成组件。

在CSS方面，所有框架都支持SASS，更少的和Taro支持另一个CSS。

因此，这一轮竞争的结果应该是：

uni-app>芋头>> wepy，

多端支持

从支持终端的数量来看，塔罗和Uni-App的数量在六个终端（移动终端，H5，微信Mini计划， Mini计划， Mini计划和 Mini ）方面略有领先地位，紧随其后的是缺乏 Mini Mini计划。

但是，值得一提的是，有一系列自我开发的多态性协议，这些协议将在编写多终端代码方面具有更好的经验。可以说是可以击中多末端发育疼痛点的功能。 Uni-App具有独立的条件汇编语法，可以同时对JS，样式和模板文件作用。可以使用基于业务逻辑中环境变量的条件来编译塔罗，也可以使用条件（类似方式）直接编译。

在移动方面，Uni-App自定义了一套基于WEEX的NVUE解决方案，以弥补WEEX API的缺点；塔罗暂时根据博览会实现相同的效果；在移动方面，有一组SDK与多终端协议合作，以与母语进行通信。

在H5方面，多态协议实现也支持了它，而Uni-App和Taro都在H5中实现了兼容的组件库和API。

两者都提供了在双方转换小程序的功能，但是H5或移动设备的支持都不是。

因此，最后一轮比较的结果是：

>芋头，uni-app>> wepy

组件库/工具库/演示

作为最长开源时间的框架，Wepy在演示，组件库号和工具库方面具有一定的优势。

Uni-App拥有自己的插入式市场和UI库。如果您包含付费框架和插件，则它不如Wepy。

塔罗（Taro）还具有正式维护的跨端UI图书馆塔罗 - UI。此外，国家管理工具中还有很多选择（MOBX，DVA），但是演示的数量不如前两个选择。但是塔罗（Taro）有一个将微信小程序代码转换为塔罗代码的工具，这可以弥补此问题。

没有官方维护UI库，基本上没有第三方演示和工具库。

因此，这一轮的顺序是：

wepy> uni-app，芋头>>>

访问成本

有两个方面可以访问成本：

首先是将框架连接到原始的微型微型程序生态系统。由于微信小程序是当前唯一的开源组件和库（例如Zan-UI等），主要是基于本机微信 的语法编写的。目前，似乎Uni-App，Taro和所有人都有文档或演示可以直接在框架中使用本机组件/库。由于操作机理问题，Wepy需要在许多情况下稍微修改目标库的源代码，这提供了一种迁移方法，可以根据步骤大大修改目标库的源代码。

第二个是重建原始微信Mini计划项目的访问框架的一部分。在这方面，芋头对JD购物迷你计划进行了大胆的做法。有关详细信息，您可以查看文章“ JD购物迷你计划的芋头实践”。其他框架没有提及相关内容。

两种访问方法芋头都提供芋头功能，可以将原始的微信系项目转换为芋头多末端代码，或将微信小程序生态系统的组件转换为塔罗组件。

因此，这一轮的顺序是：

芋头>，uni-app> wepy>

受欢迎程度

从恒星的角度来看，塔罗和哭泣之间的差距很小。从NPM和CNPM的CLI工具的下载次数来看，它是Taro（3k/）>（2K/W）> Wepy（1K/W）。但是发布时间恰恰相反。作者估计，这三家公司的受欢迎程度和案例没有太大不同。

Uni-App声称有成千上万个案件，但与其他框架不同，大型制造商有一些申请案例。此外，Uni-App在开发人员的数量方面也是领先的，有20多个通信组（最大人数为2,000）。

因此，从受欢迎的角度来看，应该是：

uni-app>芋头，哭泣，>

开源构造

开源工作可以走多远，由框架维护团队和第三方开发人员确定。尽管开源构造无法详细量化，但它仍然是测量框架/库的活力的非常重要的标准。

就第三方贡献者的数量而言，塔罗在这方面处于领先地位，塔罗的一些核心包/功能（MOBX，CSS）也由第三方开发人员贡献。此外，的开源OMI 也基于芋头完成。

Wepy在的开源计划的支持下在这方面表现出色；由于很长一段时间的停滞发展，它相对落后。这可能是由于产品策略所致，Uni-App在开源构造中并不热心，并且某些代码不是开源的。它只是开源的，但其代码和测试用例非常标准化，并且将来可能会表现良好。

那么本轮的比较结果是：

芋头> wepy >>>> uni-app

最后，添加一个总生态比较图：

未来

-

从每个框架发布的计划来看：

Wepy发布了V2.0。版本。尽管没有公共文档可以检查2.0版本的新功能，但据其作者称，Wepy 2.0将采取重大举措，并且是“值得开发人员”的版本。作者也非常期待在正式发行2.0后Wepy的表现。

2.0版已发布，主要是为了更新其他小程序的支持。但是，从代码提交的答复/解决率来看，如果您想在将来取得成功，则必须首先消除社区对您是否忽略还是更新的怀疑。

Uni-App在生态基础上建立了很好的建立，应该在此基础上继续稳定发展。如果Uni-App可以加强开源并进一步加强与主要制造商的合作，我相信它将能够在将来达到更高的水平。

计划相对宏伟。尽管这是最后一个框架，但已经计划或实施的功能包括：

如果制定了所有这些功能，并且生态系统继续改善并为更多的第三方开发人员而努力，那么将来将有很大的潜力。

塔罗的未来也值得期待。塔罗（Taro）即将推出的1.3版将支持以下功能：

同时，芋头还对移动终端进行了大规模的重建；开发图形开发工具；开发组件/材料平台和图形页面构建工具。

结论

-

说了这么多之后，我应该使用哪一个？

如果您不介意尝试和学习DSL，可以尝试Wepy 2.0，一个是2.0的新升级，它已经酿造了很长时间，而另一种则具有专门用于多终端开发的多态性协议。

与芋头相比，Uni-App更像是“桶形型”框架。在工具，UI库，开发经验，多终端支持等方面，由于一段时间的开发停滞不前，没有明显的缺点，看来所有方面似乎都不如基于其在微型编程方面的Uni-App的方面那样好。

当然，谈话是。如果您对此主题更感兴趣，则可以单独学习。您可以在有时间阅读代码，并且没有时间阅读提交：

长按华丽的分隔线以识别QR码，遵循“前端生存之路”，或加入我们的QQ组：获取更多免费的前端访谈材料，以获取免费的前端源代码分析，以及许多好处o（≧v≦）o让我们在前端的路〜（≧≦）/〜上变得更强大，