低代码：新风口还是行业毒瘤？

究竟是新风口还是行业毒瘤？对于低代码，你怎么看？

作为软件工程师的你，一定听说过低代码（LCNC） 工具吧？来自谷歌的低代码趋势图显示，人们对“低代码”一词的兴趣越来越浓厚。

::: hljs-center

图 1：谷歌趋势图
 
:::

此外，低代码方面的相关投入也不断加大，来自 Spreadsheetweb 的调查数据显示如下：

::: hljs-center

图 2：Spreadsheetweb 调查统计
 
:::

尽管受全球经济形势持续低迷的影响，低代码相关投资热度骤减，但是 Spreadsheetweb 预测：到 2027 年，“低代码开发平台市场”将达到 848 亿美元（预测平均值）规模，前景非常乐观。

::: hljs-center

图 3：Spreadsheetweb 调查统计
 
:::

不过数据归数据，回到低代码本身，它真的对软件开发有帮助吗？
 
本文从低代码工具与开发应用程序的经典方式，低代码工具创建真正自定义应用程序的功能，以及低代码工具替代方案（网站模板和经典 IDE）等方面，给低代码市场的火热泼一泼冷水。

01 什么是低代码？

低代码工具有望解决构建 Web/移动应用程序所涉及的大量成本和时间问题，尽量减少或干脆免去花费在昂贵工程资源上的资金，至少厂商是这样承诺的。
 
典型的低代码工具试图通过为用户提供拖放式界面来开发 Web 应用程序，即用户将 UI 元素放在画布上，将它们彼此连接后，再连接到数据源，并为某些元素添加某些操作，从而构建应用程序。
 
换句话说，低代码工具为可视化软件开发提供了一个环境，而不是用工程师在 IDE 中编写代码这种传统方式。低代码方法被认为更高效，而且只需较少的专业技能即可。
 
以下是在谷歌上搜索“无代码工具”时，第一页上提及的几款低代码工具：

::: hljs-center

图 4：包括 Bubble、Retool、Microsoft Power Apps、Adalo、Webflow 和 Google Appsheet
 
:::

02 低代码继承了可视化编程语言的弊端？

虽然被宣传为一种全新的软件开发方法，实则低代码工具并不新颖，在经验丰富的工程师眼里它就是一种熟悉的“可视化编程语言”。
 
可视化创建程序的想法从编程早期就存在了，但由于一些原因，它从未被广泛采用。
 
据维基百科解释，“可视化编程语言（VPL）允许任何用户通过图形方式操作程序元素，而不是用文本方式。”
 
现在不妨将这句话与维基百科对低代码开发平台的定义进行比较：“低代码开发平台允许程序员和非程序员采用图形化用户界面并进行配置，并不非要用传统的计算机编程方式来创建应用软件。”
 
这两个解释听起来是不是有些相似？还是完全相似？想要知道为什么低代码并非我们想象般前景广阔，有必要先分析一下可视化编程语言为何并未广受欢迎。
 
Ivan Danyliuk 在其文章中表示：可视化编程最适合定义空间关系（图形元素和 UI），而文本编程最适合定义时间关系（时间轴上的事件顺序）。

换句话说，人脑很容易可视化映射空间的物理对象，而不是使用文本来描述它们；很容易以文本方式描述事件的顺序（算法或指令），而不是绘制流程图。这是人脑的一种自然属性，因此不要逆着来，最好适应这样的规律。
 
使用可视化编程的另一个问题是，相对于更容易、更快将想法付诸实践的用键盘打字，它实际上增加了另一层抽象（鼠标和屏幕）。换句话说，打字比移动鼠标更快。
 
Ivan还认为（我认同）：“可视化编程语言”从未广泛流行起来的原因，在于人们希望以文本方式而不是以可视化方式给出指令。从我的角度来看，这与低代码工具从长远来看会失败的原因一样——算法更擅长以文本形式读写。低代码/无代码工具试图像“可视化编程语言”那样以可视化方式对待软件开发，这同样继承了可视化编程语言的弱点，在我看来，注定落得同样的命运。

03 编写代码在软件行业永远不会过时

此外在我看来，低代码工具不是图灵完备的——用低代码工具只能达到有限的配置集。
 
如果一个系统能解决任何计算问题，不管有多困难，只要它有足够的时间和内存以及相关的指令，就可以说它是图灵完备的。
 
由于指定指令（时间关系和事件顺序）的最佳方式是文本形式，指定这些指令的能力将因低代码工具的性质而被削弱，因此使整个方法受到限制。
 
编程语言实际上是自然语言的计算机可读版本，足以描述任何数量的对象之间的任何关系。
 
这意味着为了在低代码工具中保持灵活性，要想构建一个真正符合特定需求的应用程序，用户就要在低代码工具中编写代码（SQL 查询、JavaScript 注入或模板等），这在前面提到的一些工具中已成为可能，最终使低代码工具成为了 IDE。
 
看看下边的逻辑：

• 我想构建一个尽量减少代码编写量的应用程序；

• 我使用低代码工具创建一个应用程序；

• 我需要扩展应用程序以满足我的特定要求，因此我在低代码工具中编写代码；

• 由于我已经在编写代码了，何不先安装一个 IDE，然后用正常的方式编写代码？

因此，为了能够构建功能完备的软件，低代码工具需要与 IDE 融合，因此将与当前产品（Visual Studio 和 JetBrains）竞争。
 
从我的角度来看，向 IDE（即 UI 构建器）添加低代码功能比从头开始构建新的复杂 IDE 来得容易。
 
此外，低代码工具基于浏览器，因此 IDE 也必须基于浏览器，这限制了其功能。这就是为什么我认为编写代码在软件行业永远不会过时。

04 为何没人谈论模板市场？

模板、入门工具包、主题、样板，这些词的含义非常相似，即一组文件和文件夹充当应用程序的起点。
 
有各种示例，比如 Github 上的免费模板（比如 create-react-app 或 react-material-admin）、有大量 WordPress 主题的 ThemeForest、Template Monster、Creative-Tim 和 Flatlogic 以及专门面向 Web 模板的资源等。
 
自 2013 年发布以来，仅 Flatlogic 就销售了至少 20000 份许可证。Metronic 销售的许可证超过 100000 份。免费模板的使用则更广泛。每天有多少用户在使用 create-react-app？
 
在我看来，模板创造了真正的价值。也许这是我的偏见，但我不知道任何单单使用低代码构建的实际应用程序。
 
最终，人们需要自定义应用程序作为代码，而不是作为服务，因为拥有代码为定制、扩展和集成提供了无限的机会。
 
所以关键是模板市场是需要颠覆和创新的市场，而低代码市场不是这样的市场，因为最终每个人都需要编写代码。首先，模板市场很活跃。
 
可能最重要的玩家是 Envato，单单它一家的年收入就超过 2 亿美元，盈利达 3600 万美元。
 
我估计，就今天的整个市场规模而言，如今几大市场玩家获得的实际收入至少达 10 亿美元。但是你从来没有在新闻中听说过这个市场。
 
我认为低代码工具方面的投入多得多，模板/主题方面却没有投入，这是由于向投资者推销不用编程就能创建 Web 应用程序的“灵丹妙药”要容易得多，因为大多数投资者并不通晓技术，因此不明白本文中解释的这些内容。
 
各种“研究”预测几年后低代码市场规模可达到多少亿美元也起到了造势的效果，相反根本没人谈论模板市场。
 
这就是为什么我们创建了一个工具，可以根据一些输入（比如技术堆栈、UI 设计和数据库模式）生成全栈 Web 应用程序的代码库。
 
我们并不在产品上贴上无代码标签来紧跟潮流，而是解决实际市场的实际问题。
 
作者：Philip Daineka

标题：Hard limits of low-code/no-code and what is an alternative solution

链接：https://flatlogic.com/blog/hard-limits-of-low-code-no-code/