「可视化搭建系统」——从设计到架构，探索前端领域技术和业务价值

阿里巴巴集团前端委员会主席 圆心：未来前端的机会在哪里 对前端未来期许有四点：搭建服务， Serverless，智能化，IDE。仔细想想，一个「可视化搭建系统」的想象空间，正能完美命中这些方面。前端的边界在哪里，对于业务的价值又在哪里，我们不妨静下来，一起从知乎会员事业部前端实现「可视化搭建系统」的过去和现在，以及未来规划去思考。

—— 有人说前端「可视化搭建系统」说到底只是重复造轮子产生的玩具；有人说前端「可视化搭建系统」本质是组件枚举，毫无意义。片面的认知必有其产生道理，但我们不妨从更高的角度出发，并真切落地实践，也许你会发现：作为 FEer，我们能做的事情也许更多。

页面搭建技术流派概览和彩蛋放送

据我观察“几乎每一个前端团队，都会有一个页面搭建系统”。页面搭建技术是一个老生常谈的话题，可这个话题伴随着前端技术的发展，历久弥新。究其原因，包括但不限于：

• 运营活动页面对于产品业务至关重要，是吸引流量、提高留存的关键手段

• 高频且重复度较高的活动页面开发，对于前端意味着大量的时间和人力成本消耗 在此背景下，快速页面搭建技术就显得尤为重要。

由于每个产品业务的特点、运营需求和设计规范不尽相同，因此页面搭建平台就出现了“百花齐放，百家争鸣”的局面。我们在“闭门造车”的同时，博览众家之长，对比归纳，持续优化。为此，我们分析了社区上几乎所有开源产品和方案，包括但不限于：

• 百度 H5

• iH5

• 转转魔方平台

• 百度外卖页面配置平台：Blocks

• 携程乐高系统

• 人人贷活动运营平台

• 新版微信编辑器

• 鲁班H5

• 阿里云凤蝶

• MAKA

• 码良平台

• grapes

• 可视化布局 bootcss

• 民间方案：pipeline-editor

• 一个国外的民间方案：vvvebjs 相关技术分析文章：

• 页面可视化搭建工具前生今世

• 页面可视化搭建工具技术要点

• QQ会员活动运营平台演变和技术实践——高效活动运营

• 积木系统，将运营系统做到极致

• 活动运营自动化平台实践

• 可视化搭建前端工程 - 阿里飞冰了解一下

• 飞冰对于活动引擎的可借鉴之处

• 前端工程实践之可视化搭建系统

• 如何设计高扩展的在线网页制作平台

• 鲁班H5作者：@小小鲁班

• 厌倦了写活动页？快来撸一个页面生成器吧！其特点和技术方向可以各有特点，但总体可以归纳为以下图示：

按照目标受众，可区分：

我们也从海量优秀方案中总结出解决这一类运营需求的通用手段：将复杂页面的搭建抽象成结构化数据，由结构数据驱动组件/模版的拼装。简单的这样一句话很好理解，按照这样的想法也能构建出一个可用的平台，但能否更进一步，想在技术和业务上突破瓶颈，还需要打通更多环节：

• 结构化数据如何设计才能兼顾优雅和高性能，且天然支持活动编辑时的“时光旅行 Redo/Undo”功能

• 如何平衡页面的自由发挥度和规范统一度

• 如何突破原始模版引擎，借力框架（React、Vue 等）组件化思想，并做到 framework free

• 如何优雅实现专题模版功能，一键导入功能以及插拔式编辑

• 如何贴合自身业务特点，平衡实用性、适用性和可扩展性

• 如何不断持续迭代，以适应新的需求发展

• 如何借助社区的力量，做大做强

• 如何最大化发挥可配置，如何最大化方便接入方扩展

• 如何避免组件枚举堆积的混乱 业界已有方案中，有的较好地解决了这些关键点中一个或多个问题，有的更像是一个练手的玩具。请读者继续阅读，接下来我将介绍「结合编辑器技术的页面搭建平台」思路，整体如下图：

当编辑器技术遇见页面搭建需求

让我们先回到一个宽泛而有趣的问题上：“前端开发的难点到底在什么地方?”。

在这个问题下，我的好友，前淘宝工程师 @于江水提到两个点：

• 业务逻辑很复杂而且多变

• 垂直领域解决方案并不简单 这里对其答案进行简单扩展，原答案可参考：于江水的回答。顺着这个思路我们来分析，前面提到的运营活动页面——单纯开发这些页面难度其实不高。但是对于前端团队来说，如果高频多变的运营需求在短时间内集中爆发，那么就成了一个系统性的问题了。比如极端情况：对于淘宝双十一、京东大促，简单地堆人堆时间也只是杯水车薪。于是诞生了页面搭建平台。

这样一个平台涉及到的技术点是网状的：比如涉及到开发工具链、数据结构设计、渲染器和交互设计、数据源导入、页面编译构建、页面生成、代码发布、活动发布、版本管理、在线运营管理、权限管理、可视化“所见即所得”实现、后端存储、CDN 同步、数据打点和统计、数据分析等。后续结合平台化能力，也会涉及到组件市场的设计，甚至 serverless，no/low code 技术。

而作为垂直领域一个不可忽视的方向——编辑器开发，技术难度只会更高：除了编辑器本身的各种功能实现外，还需要兼顾兼容性，更要适应业务需求。同时，编辑器就是生产工具，任何一个中后台系统似乎都必不可少，需求市场上，不管是石墨文档、钉钉文档、头条飞书等都有着广泛而强烈的需求。该领域值得深耕而优秀开发专家却凤毛麟角。

为了解决「可视化搭建系统」，我们尝试把一个上述「复杂的业务平台」和「垂直领域的富文本开发」这两大难题结合起来，打造一个功能强大的编辑器，同时完成页面搭建平台的工作——这听上去虽然是“难上加难”，但似乎两大方向的融合是一种美妙的思路和创新。

具体来说，编辑器除了支持传统富文本功能以外，需要加入对业务功能区块的支持，这时候在数据结构上，选用 JSON base 的存储方式：传统富文本区块以 JSON 字段存储富文本内容，其它复合型自定义业务区块存储为 JSON 对象结构。在此基础上，我们实现对该 JSON 对象结构的解析，实现编辑器内“所见即所得”。

这里单独说一下富文本之外的“复合型自定义业务区块”。我们知道最终搭建出来的页面将会充满各种 Sku 商品、自定义组件、用户卡片等区块，最终这些内容的输出需要被 C 端渲染器所理解、所解析。

我们来结合下图，进一步说明：

区块 1 是传统富文本内容，区块 2 是一个复合型自定义业务区块——Sku 卡片，区块 3 是另一个复合型自定义业务区块——用户卡片。这样一来编辑器不再是一个单一的富文本编辑器，而是最终输出内容为复杂 JSON 类型的多功能编辑器。

不同业务场景、特点，需要完全不同的前端解决方案，在开发这些垂直解决方案的时候，业务分析、技术选型、架构设计、开发落地是非常难的。接下来，就让我们一步步探索，一步步实现一个基于并兼顾编辑器技术的多功能的页面搭建平台。

灵活强大的 Markdown 编辑器和页面搭建创新尝试

我相信现如今没有程序员不知道 Markdown，它对程序员或者所有互联网从业人员来说都非常友好。简单说，Markdown 是一种轻量级标记语言，它允许我们使用易读易写的纯文本格式编写文档。现如今许多网站都广泛使用 Markdown 来撰写帮助文档或是用它来在社区上发表消息。比如：GitHub、Wikipedia、简书、reddit 等。

除了易于编写，Markdown 的可扩展性和可转换性也是它收到追捧的重要原因。也正因为如此，我们初期的运营活动页面搭建就是基于 Markdown 编辑器实施的。具体流程如图：

当然这只是一个非常粗略简易版的流程示意图，接下来我将分：

• Markdown 扩展和自定义解析器

• 完善使用体验，打造页面生成能力 两个方面进行详细解释。