我在生产中运行了一个无代码应用程序，并意识到无代码需要做什么

在过去的一年里，我一直在两个领先的无代码工具上构建Web应用程序和本地应用程序。当我开始的时候，我被打动了。我可以在这么短的时间内做这么多事。

作为一名开发人员，这是一种解放。我一直觉得我们开发人员做的很多事情实际上并不那么复杂。不熟悉的语法和复杂的开发流程将人们拒之门外。99%的时间里，开发人员只是在布线。所以一开始，这是有意义的。当其他开发人员对这些工具嗤之以鼻的时候，我却在几周的时间里推出了一批又一批的应用程序。

几个月过去了，我与无代码工具的萌芽恋情逐渐消退。我努力证明我们为什么要用它们来建造东西。我对这个空间很感兴趣，所以我做了研究。我阅读了各种来源的无代码宣言，尝试了一系列其他工具，并开始整理我的想法。

本文就是这一研究的成果。请注意，当我在本文中说无代码时，我指的是无代码的应用程序构建器/网站构建器。我没有任何使用其他类型的无代码工具(如自动化、集成等)的经验，所以我不会评论它们。

让我们举一个物流的例子。在物流方面，公路、铁路和海洋都有标准化的解决方案。这种运输相对便宜，因为你可以一起搬运很多东西，规模经济也会发挥作用。

然而，把东西从高速公路运到每个家庭是困难和昂贵的，因为你需要为每个消费者提供一种运输媒介。这也被称为最后一英里的问题。

回到软件方面，我们现在对“高速公路”问题有了标准化的解决方案。我们有电子邮件、视频会议、搜索、娱乐等解决方案。这些问题是许多人面临的，因此企业去解决这些问题在经济上是有意义的。

然后，我们就有了小问题。例如，世界上有一家企业需要一款应用程序来解决运营挑战。这个用例是如此专门化，以至于企业没有动力去解决它。如果没有代码，这项业务将不得不让这个软件定制，这将花费大量的时间和金钱。这就是没有代码的地方。它提供了简单的构建块，用户可以使用这些构建块来组合自定义解决方案。不用说，无代码工具的好坏取决于它们的原语-这些基本的构建块，它们允许混合和匹配。

使用无代码，您可以为自己构建无法找到开箱即用解决方案的自定义内容。

昨天软件领域的许多最后一英里的问题现在都变成了铁路问题。事实上，我们也在为许多铁路问题找到更有效的解决方案。

以Shopify为例。今天有人白手起家建电商商店有意义吗？Shopify以如此低的起步价提供了如此多的功能，以至于任何人都不可能从头开始构建它。

直到几年前，如果你是一名SAAS成员，并且你需要一个像样的软件来组织你的指南、API参考和解决方案，你的选择是对讲机、Freshdesk和Zendesk。它们都是成熟的支持平台，您可能需要也可能不需要。今天，您可以创建一个包含所有支持文章的公共概念文档，然后就完成了。免费的。Concept提供开箱即用的搜索功能，支持各种媒体类型，外观非常棒。在概念上，您还可以做十几件以前会付钱给几个不同供应商的事情。

Airtable做了一些类似于对实体进行操作的事情。如果要在Airtable基座上创建表单，只需在Airtable中单击一个按钮即可完成。事实上，您可以在Airtable内组装整个应用程序。

在不久的将来，我们将看到解决方案将引入更好的抽象，并将最后一英里的解决方案升级为铁路解决方案，将铁路解决方案升级为更高效的变体。

我的基本问题是，大多数没有代码的工具都说他们的用户根本不需要代码。不，我指的不是“无代码”这个词。无代码社区中的许多人都认为这个名称用词不当。我指的是这些工具在Twitter上说的话，或者在它们的登录页面上写的东西。他们说你可以在没有任何代码的情况下构建任何东西。我认为这要么是无耻的谎言，要么是妄想。

使用无代码工具，您只需将块放在一起即可。如果您需要不同的块，或者如果您正在寻找比该工具提供的块更小的块，您就会陷入困境。

事实是-代码为王。当您需要自定义流时，代码将会提供帮助。当您需要一个不存在的组件时，代码会来拯救您。当您想要连接无代码工具的创建者没有想到的任何东西时，代码将是答案。

不要将我的论点与人们抛给无代码工具的另一个论点混淆-“您正在使用底层的代码。您需要该代码的开发人员。什么无代码？“。

我认为在代码之上创建一个层绝对是有价值的。我最大的问题是-今天的无代码工具似乎不承认它们的原语不够好。

有了今天没有代码的原语，就没有竞争优势了。任何人都可以构建一堆组件，编写一些集成，然后发布一个新的无代码工具。请不要说这些产品有社区。当用户陷入困境时，他们正在寻找答案，再多的社区支持也无法解除他们的阻碍。

更糟糕的是，像Concept和Airtable这样的SAAS软件最终可以提供无代码工具提供的开箱即用的大部分功能。它们可以访问相同的原语。这已经在发生了。今天，有一些SAAS为餐馆、便利店、电商商店等提供白标应用程序。

假设现在有一款应用程序是人们使用无代码工具来构建的。如果有足够数量的用户需要这款应用程序，最终会有一个通用的SAAS来概括用户的需求，并提供一个标准的解决方案。由于他们将深入研究这一特定问题，他们将能够将没有代码的应用程序构建者需要很长时间才能构建的功能组合在一起。有些甚至可能是不可能的。

我知道有些人会说-“他在说什么？我用x无代码工具构建了某某复杂的软件“。让我举一个非常具体的例子，告诉你我的意思。我个人也曾和这件事做过斗争，所以我知道我在说什么。

假设您有一个包含便利店列表的应用程序。每当用户打开您的应用程序时，您都希望按照距用户当前位置的距离递增的顺序对商店列表进行排序。就这样，没什么大不了的。

每个商店的纬度和经度都在Google地图链接中。从逻辑上讲，你需要做的是-。

找出每个商店和用户位置之间的距离。你可以在这里使用哈弗正弦公式，它应该会给出足够好的结果。

您如何使用无代码工具来实现这一点呢？让我们看看我们的选择。

使用API吗？好的，我们怎么写API呢？密码。假设有一个无需代码即可构建API的工具。您将如何编写核心排序逻辑？好吧，代号。

是否使用应用程序脚本根据距离对位置进行排序？什么是Apps脚本？密码。

一些无代码工具漏掉了自己的编码范例，称自己为无代码工具。这仍然是具有与其他编程语言相同的问题和挑战的代码。那么，代码。

您唯一的希望是该工具能够提供开箱即用的功能。即使到那时，您也需要做一些工作才能为它提供它所需的正确格式的数据。

请考虑对此问题进行哪怕是很小的修改。假设您必须根据应用程序运行时可用的给定固定位置(而不是用户的位置)对上面的列表进行排序。这一小小的调整也可能对无代码解决方案造成严重破坏。如果无代码工具希望您指定要排序的列表和排序位置，那么您将会想知道如何告诉该工具获取用户的当前位置。如果该工具默认获取用户的当前位置，那么您将不知道如何将其传递给您的自定义位置。

这是一个很小的例子。在任何类型的业务中，最终，流程变得复杂，验证变得棘手，集成变得具体。您会一遍又一遍地看到上述问题的变体，呈现出不同的风格。有时，您需要推动人们沿着该工具不支持的路径前进，您需要收集一些有关该工具无法让您了解的用户体验的数据，您还需要引入该工具无法提供给您任何实现方式的业务逻辑。这些问题只会增加应用程序的其他部分的复杂性。

我已经在其中的一些工具上构建了成熟的生产应用程序，一想到我们必须做出多少改变才能很好地使用这些工具，我就哭了。工具的僵硬把所有的责任都推给了我们，让我们找到一种方法来使一个功能在它上面发挥作用。

我将在未来的博客文章中更多地谈论我面临的挑战的非常具体的问题。那么，如果你对这个空间感兴趣，为什么不订阅我的时事通讯呢？

我担心今天所有使用无代码工具创建业务的人，这些业务总有一天会变得庞大，并因此变得复杂。他们的开发人员会怎么做呢？

再说一次，不要把我的批评误认为是对无代码运动的不尊重。我认为这些运动的原则很有意义。这是正确的做法。在我们这个世界的历史上，我们一再看到，让创造变得更容易推动人类前进。

底线是，没有代码的工具需要发明自己的原语，这些原语比我们目前拥有的原语更具表现力。这些原语应该支持用户无法从SAAS获得的功能。只有到那时，无代码才能将自己确立为代码的“真正”替代品。还记得我们在“为什么没有代码”一节中说过的话吗？只有当您的用例是自定义的时，才使用无代码。

我花了一些时间思考用正确的方式来表达这个问题。如下所示：

人类天生就是解决问题的人。我们都知道怎么做。不知何故，在计算机内部解决问题已经成为一种专业技能，尽管它使用相同的原理和需要相同的技能。人们很害怕它。问题是，我们如何才能让它像解决现实世界中的问题一样容易呢？人们已经知道他们想要实现什么。我们怎样才能让他们表达他们的意思呢？

这就是我要留给你们的问题。我很想听听你的想法。如果您觉得这很有趣，请考虑订阅。我也会在未来的帖子中写到这个领域(以及一些无关但有趣的领域)。