一、低代码的理解

在讨论各个低代码方案前，首先要明确「低代码」究竟是什么？

这个问题不好直接回答，因为低代码是非常宽泛的概念，有很多产品都声称自己的低代码，但我们很容易反过来回答另一个问题：「什么是低代码产品唯一不可缺少的功能？」

我认为这个功能是可视化编辑，因为非可视化编辑就是代码编辑，而只有代码编辑的产品不会被认为是低代码，因此可视化编辑是低代码的必要条件，低代码其实还有另一个更清晰的叫法是可视化编程。

既然可视化编辑是低代码的必要条件，那从实现角度看，实现可视化编辑有什么必要条件？

我认为可视化编辑的必要条件是「声明式」代码，因为可视化编辑器只支持「声明式」代码。

1.1 声明式与命令式区别

除了声明式之外还有另一种代码模式是「命令式」，我们分别举两个例子，如果想绘制一个红色区块，用「声明式」来实现，可以使用 HTML+CSS，类似下面的方法：

<div style="background:red; height:50px"></div>

而换成用「命令式」来实现，可以使用 Canvas API，类似下面的方法：

const ctx = canvas.getContext('2d');
ctx.fillStyle = 'red';
const rectangle = new Path2D();
rectangle.rect(0, 0, 100, 100);
ctx.fill(rectangle);

虽然最终展现效果是一样的，但这两种代码在实现思路上有本质区别：

「声明式」直接描述最终效果，不关心如何实现。
「命令式」关注如何实现，明确怎么一步步达到这个效果。

从可视化编辑器的角度看，它们的最大区别是：

「声明式」可以直接从展现结果反向推导回源码
「命令式」无法做到反向推导

反向推导是编辑器必备功能，比如编辑器里的常见操作是点选这个红色区块，然后修改它的颜色，在这两种代码中如何实现？

如果是「声明式」的 HTML+CSS，可以直接改 style 的 background 值，而基于 Canvas 的命令式代码则无法实现这个功能，因为无法从展现找到实现它的代码，命令式代码实现同样效果的可能路径是无数的，除了前面的示例，下面这段代码也可以实现一样的效果：

const ctx = canvas.getContext('2d');
ctx.beginPath();
ctx.moveTo(0, 0);
ctx.lineTo(50, 0);
ctx.strokeStyle = '#ff0000';
ctx.lineWidth = 100;
ctx.stroke();

甚至有可能这个颜色是多个字符串加随机数拼接而成，即便通过静态分析也找不到来源，从而无法实现可视化修改。

「命令式」代码无法实现可视化编辑，而可视化编辑是低代码唯一不可少的功能，所以我们可以得到结论：所有低代码平台必然只能采用「声明式」代码，这也是为什么所有低代码平台都会有内置的「DSL」。

既然低代码都是声明式，那我们可以通过分析其它「声明式」语言来了解低代码的优缺点，其实在专业研发里，声明式语言在部分领域已经是主流了：

HTML+CSS 是一种页面展现的 DSL
SQL 是一种数据查询及处理的 DSL
K8S 的 yaml 是一种服务部署的 DSL
NGINX conf 是一种反向代理的 DSL

1.2 声明式特点

「声明式」语言有以下优点：

容易上手：因为描述的是结果，语法可以做得简单，非研发也能快速上手 HTML 及 SQL。
支持可视化编辑：微软的 HTML 可视化编辑 FrontPage 在 1995 年就有了，现在各种 BI 软件可以认为是 SQL 的可视化编辑。
容易优化性能：无论是浏览器还是数据库都在不断优化，比如可以自动改成并行执行，这是命令式语言无法自动实现的。
容易移植：容易向下兼容，现在的浏览器能轻松渲染 30 年前的 HTML，而现在的编译器没法编译 30 年前的浏览器引擎代码。

「声明式」语言有以下缺点：

只适合特定领域：命令式的语言比如 JavaScript 可以用在各种领域，但 HTML+CSS 只适合渲染文档及界面，SQL 只适合做查询，所有这些语言都。
灵活性差：比如 SQL 虽然内置了很多函数，但想只靠它实现业务是远远不够的，有些数据库还提供了用户自定义函数功能（UDF），通过代码来扩展。
调试困难：遇到问题时如缺乏工具会难以排查，如果你在Firefox出现前开发过页面就会知道，由于IE6没有开发工具，编写复杂页面体验很差，遇到问题要看很久代码才发现是某个标签没闭合或者 CSS 类名写错了。
强依赖运行环境：因为声明式只描述结果而不关注实现，因此强依赖运行环境，但这也带来了以下问题：

功能取决于运行环境，比如浏览器对 CSS 的支持程度决定某个属性是否有人用，虽然出现了CSS Houdini 提案，但 Firefox 和 Safari 都不支持，而且上手成本太高，预计以后也不会流行。
性能取决于运行环境，比如同一个 SQL 在不同数据库下性能有很大区别。
对使用者是黑盒，使用者难以知道最终实现，就像很少人知道数据库及浏览器的实现细节，完全当成黑盒来使用，一旦遇到性能问题就不知所措。
技术锁定，因为即便是最开放的 HTML 也无法解决，很多年前许多网站只支持 IE，现在又变成了只支持 Chrome，微软和 Opera 在挣扎了很多年后也干脆直接转向用 Chromium。同样的即便有 SQL 标准，现在用的 Oracle/SQL Server 应用也没法轻松迁移到 Postgres/MySQL 上。低代码行业未来也一样，即便出了标准也解决不了锁定问题，更有可能是像小程序标准那样发展缓慢，功能远落后于微信。

因为低代码就是一种声明式编程，所以这些「声明式」优缺点，其实就是低代码的优缺点，了解声明式的历史及现状就能更好理解低代码，因为：