This post is a guest contribution from Shawn Xu (no relations). Shawn is a software engineer at TikTok, got his Masters in Human Computer Interaction at Carnegie Mellon, and writes an informative WeChat public account on SaaS called 硅谷成长攻略.


In Part I and Part II of our comprehensive Low Code No Code (LCNC) series, we explored the category’s landscape and various factors contributing to its growth. In this Part III, we will share our hands-on experience of using some best-in-class tools to build a real application for a real world use case, in order to build an evaluation framework for all these LCNC tools. We hope this lens will be valuable for potential buyers of these tools and investors alike.

If you want the TL;DR version: the maturity of LCNC tools to build applications is similar to the early days of self-driving. We are still at the L2 self-driving stage, as in you still need engineering knowledge to make things work and the experience is by no means “automated”. The industry still has ways to go before reaching the L3 stage, as in “citizen developers” with little engineering background can build useful applications.

Is reaching the “L2” equivalent for LCNC valuable? Absolutely! It offers experienced “drivers” (in our case, app developers) a much better operating experience and boosts productivity.

Website builder v.s. Application builder

Before we share our evaluation findings and takeaways, it’s important to distinguish between “website builders” and “application builders”, because people often conflate a website with an application. Websites are usually static, focusing more on layout and content, while applications are highly interactive, addressing complex business logics and processes. As the shortage of skilled developers continues to grow, especially in expensive western countries, LCNC tools that support application building will see growth opportunities.

HireLN: an app for evaluating LCNC application builders

In Part II of this series, I proposed the Rule of 5 – a simple set of rules of thumbs to evaluate whether a LCNC product is worth adopting. While those rules are useful as a quick proxy, they are not detailed enough to examine a LCNC application builder from a developer’s perspective.

In front-end engineering, a common way to evaluate a front-end framework's performance and usability is to build a TodoMVC – a minimal but functional todo list application with a view, data model, and controller layer.

Borrowing from this idea, I decided to build HireLN – a hiring application built using only Low Code No Code tools to see how useful these tools are. HireLN consists of a public-facing application form and a review portal for a hypothetical HR team. After a “candidate” successfully submits her application, this app should enable the HR team to schedule interviews, interviewers can enter feedback, and eventually, the HR team can send out offers or rejection letters via email.

Why build an app for hiring?

It’s a common use case that every tech company needs, but typically doesn’t want to assign engineering resources to build in-house (engineers should be building products!). Each company also has somewhat different hiring processes and preferences, so a level of customization is needed and off-the-shelf solutions can’t always satisfy all the requirements. It’s a great use case to test the value of LCNC tools, most of which tout their ability to boost productivity for non-core but essential business needs, like hiring.

I built a worksheet on this Notion page to evaluate a list of requirements that this HireLN app should have and their relative importance.

A screenshot for part of the HireLN Worksheet

Building HireLN with four best-in-class LCNC tools

I built several versions of our HireLN app, using four of the best-in-class LCNC application builders across the US and China tech market, to test out their strengths and weaknesses:

  • Retool, a Low Code tool for building internal tools
  • Bubble, a No Code tool for building any application
  • Notion, a No Code tool for solving common business needs
  • DingDing Yida (宜搭), a No Code tool for building any application, created by Alibaba

I’ve listed below all the different versions of HireLN I have tried to build. The ones with links have a functional prototype you can play with. The ones that do not have a link either did not work or took too long to build, thus defeating the whole purpose of using LCNC tools and failing our evaluation.

Long story short, I had the best overall experience building HireLN with Retool, though the initial learning curve was steep and dealing with UI responsiveness was frustrating. Bubble’s ambitious pure No Code approach is laudable, but the ambiguity of its natural language options makes some operations extra hard. While it was quite easy to build the public-facing application form with Notion (plus TypeForm) and Yida, they both struggled big time with the complexity of the review portal side of HireLN app, thus was not adequate enough to build a functional prototype.

A few example challenges of building HireLN with best-in-class LCNC tools

Cold Start Problem

When developers jumpstart a new project with a full-code approach, a popular option is to adopt a bootstrapping toolkit. This toolkit would contain a minimum yet complete setup, with essential libraries installed, linters enabled, build and test processes pre-configured. Well-maintained toolkits such as Create React App also allow a great variety of customizations featuring different language flavors and community templates.

This same bootstrapping experience unfortunately is quite nascent in LCNC land. Sure, the LNCN builders provide functional templates: A PostgreSQL admin panel, an Amazon-like marketplace, an internationalized CMS, etc. However, starting a new project with these templates is like building a Lego Hogwarts with a Lego Death Star: good luck tearing down the Death Star and finding all the pieces you want to start building Hogwarts!

Building a Lego Hogwarts with a Lego Death Star

As I tried building HireLN’s candidate review portal, Retool’s PostgreSQL admin panel template felt like a good starting point - until I started demolishing pretty much the entire UI, picking only four out of the 27 built-in queries, and fixing all the broken connections, before building anything that specifically speaks to HireLN’s requirements.

More thoughtful approaches should be borrowed from full-code bootstrap toolkits, such as generating dynamic, user-specified starter projects (see conversational design below). This would, of course, require a much higher level of flexibility from LCNC products.

State Management Paradox

“States” dictate the current look and feel of an application. They can be as prominent as the current page’s URL, or as trivial as a dropdown menu opening or closing. They are hard to manage - questions like “where to store them” and “how to mutate them” can easily trip up a junior-level engineer.

LCNC builders get away with this complexity by largely hiding them completely. Users are presented with packaged “building blocks”, like a paginated table or a checkbox, without ever having to think about dealing with their internal states.

Simplifying “state management” may be well-intentioned, but unfortunately fails to meet the expectations of modern applications. The simplest example is “autocomplete input”, where users can type in something, and get suggestions from a remote source (think about the Google search bar). As common as this use case is, I wasn’t quite able to accomplish it with any LCNC builder (without crazy hacks), since the internal workings of text boxes and drop-downs are not exposed.

Modern applications are by nature rich in interaction. It calls for finer-grain control of states and allows modules to talk to each other. Providing such an ability to micro-manage, however, defeats the main appeal of building with LCNC. This paradox casts an impression that apps built with LCNC are subpar in user experience and for “internal use” only – a big limiting factor of LCNC’s adoption and expansion.

Painful to Scale

In software engineering, scaling has two major flavors: scaling the software itself (as it grows in features and complexity), and scaling the development process (as more developers collaborate to build this piece of software).

LCNC tools are still a bit young, compared to their full-code counterparts, to provide an answer to either of these two scaling challenges.

On the scaling of software, seasoned developers would make good use of abstraction and avoid frantic copy-pasting, in order to scale long-term maintainability. They are able to do so via declaring clear interfaces, and providing strict definitions of input and output -- something LCNC simply cannot provide with pure visual “building blocks”. When I worked on building HireLN, it was quite a pain to copy-paste ten text boxes, and then later have to go back to each one to modify the same attributes over and over again.

On the scaling of developer collaboration, no LCNC tool is able to provide an experience anywhere near Git -- the most widely-used version control scheme. After all, the difference between two code snippets is so much easier to examine than the difference between two built applications.

These two issues combined present unique challenges for LCNC users today, if they want to scale and maintain their applications. New development and version control patterns will eventually have to emerge to support LCNC startups’ future growth.

Absence of “Friends”

As a developer myself, “recreating the wheel” is something I rarely do unless for purely educational purposes (learning about a new tool, framework, algorithm, etc.). It’s essential these days for a developer to build in an open source community, full of “friends” who have already built something similar and whose knowledge (and code) you can leverage without worry.

Building in the LCNC ecosystem feels much more closed, where one can only build with a limited pool of building blocks. Let’s say we want a UI component to load data as user scrolls (an “infinite scroll” experience) – there is an abundance of full-code options available on GitHub, but none of them can be ported into a LCNC tool’s workspace.

Bubble ventured on this problem by allowing developers to create “plugins”, and make money from people’s adoption. However, most plugins are either too poorly maintained or too expensive (no free trial!). In the end, it’s the official, free plugins that are most reliable, so might as well make them built-in options.

Summary

In Part I and Part II of our LCNC deep dives, we presented a pretty rosy picture of this vast and growing category (see 2021 LCNC landscape below). This Part III post balances our analysis by describing more challenges, discovered from our own hands-on experience using some best-in-class tools.

As daunting as these challenges may be, the LCNC ecosystem is still in a great position to meet the demand caused by the ever-growing developer shortage crisis. More and more startup founders are turning to these LCNC tools to accelerate their own companies, which drives the entire ecosystem’s growth trajectory and market validation.

Adjacent to LCNC’s growth is the massive wave of API-centric products that are eating large industries, one API request at a time. Machine learning, crypto, finance, payment, healthcare, and many other once-complex domains are being broken down to just a few API calls.

The holy grail for LCNC application builders is no different from any full-code tools or frameworks – make application development of all sorts and flavors easy for as many developers (experienced and novice) as possible. This category is young and will need more time to mature. But just like automating self-driving, as adoption increases, more resources will pour in, competition will intensify, and the pace of improvement will accelerate towards maturity.

本篇文章是徐晟洋(和我没有亲戚关系,纯属凑巧哈)在《互联》上的第三篇“嘉宾专栏”。他是TikTok的一名软件工程师,在卡内基梅隆大学获得了人机交互的硕士学位,并写一个与SaaS行业有关的干货很足的微信公众号《硅谷成长攻略》。


低代码、无代码(三): 用Notion, Retool, Bubble, Yida搭招聘应用程序

在前两篇低代码、无代码(下称LCNC)文章中(第一篇第二篇),我们分析了这个领域的版图和增长点。在这第三部分里,我想切换一下视角:从一个用户的角度来体验市面上最好的LCNC工具,搭建真实可用的应用,以此来建立一套LCNC产品的评价体系。相信这个过程和体系无论对潜在的LCNC买家,还是投资人,都有裨益。

如果你不想通读全文,一个简短的结论是:时至今日,LCNC的成熟度和自动驾驶很像——我们依旧在第二级自动化(也就是还需要有经验的程序员),远未到第三级的程度(也就是所谓的“业余工程师”都可以上手搭建出有用的应用程序)。

那么这区区“第二级”,有其价值吗?答案是非常有价值。它可以让熟练的驾驶员们更轻松、愉快地行驶在路上(在LCNC领域,也就是让工程师们更快更好地推出软件)。

网站开发与应用开发

我们首先要澄清一个概念:网站开发和应用开发并不是一回事。许多人把“网站”和“应用程序”混在一起。“网站”大多偏静态,主要呈现一些布局和内容(比如下图左的首页);而“应用”则各式各样,通常有更为复杂的交互,实现某些商业流程(比如下图右的仪表盘页面)。

由于应用开发难度较大,并且在欧美国家,技术精湛的工程师缺口逐年增大,能够帮助应用开发的LCNC工具有更大的想象空间。

HireLN:一款评估LCNC工具的应用程序

在本系列的第二篇中,我提出了评测LCNC产品的“Rule of 5”。这个评价体系足够快捷,却不够细致,难以在重要的购买决策时提供有力支持。

在前端工程领域,我们最常用来评估一个代码框架的方式,是用这个框架搭一个TodoMVC——一个迷你、但功能齐全的待办事项应用(Todo list)。

顺着这个思路,我设计了HireLN——一款公司招聘相关、以LCNC搭建的软件。与TodoMVC类似,在亲手搭建或使用HireLN的过程中,潜在用户可以直观、量化地评价一个LCNC建站平台。

HireLN本身并不复杂:一个面向求职者的表单页面,和一个HR用于管理面试进度的控制面板。当一个求职者成功提交申请后,HR可以在控制面板安排面试、输入对面试反馈、发offer或拒信。

为什么以招聘软件作为切入点?

原因很简单:所有公司都有招聘的流程,但通常不愿意倾斜宝贵的工程师资源,打造一个全新的内部招聘系统。在此基础上,每个公司的招聘流程和偏好,都有些许不同,很难通过定制市面上的第三方工具,来满足所有需求。用招聘这个各个科技公司都需要,但又与核心业务无关的use case来评估LCNC工具很合适,因为绝大部分LCNC厂商都会以这种use case来宣传和体现自己工具的价值。

我把HireLN所应有的一系列产品要求,都列在了这个Notion页面

HireLN产品评价体系的截图

上手体验:用市面上最好的LCNC工具打造HireLN

秉着实践出真知的想法,我使用了以下四款在美国和中国小有名气的LCNC应用开发工具,分别搭建了HireLN,并且用上述评价体系做了评估。他们分别是:

  • Retool,一款主攻企业内部应用的低代码(LC)工具
  • Bubble,一款主打无代码(NC)建站的工具
  • Notion,一款无代码的通用协作类工具
  • 钉钉宜搭,一款来自阿里的无代码建站工具

以下是我截至目前所有的尝试。凡是有链接的样品,读者们都可以上手试试;而没有链接的则大多由于工程难度和耗时,未能完成,不符合HireLN在生产力提升上的标准。

在这些尝试中,我觉得Retool的使用体验最佳,尽管其学习曲线十分陡峭,且在屏幕适配方面做的不尽人意。Bubble的“无代码”建站很有野心,但由于自然语言的模糊和局限性,很多地方相比于全代码搭建,反而事倍功半。Notion(加TypeForm)和钉钉宜搭,在搭建面向公众的求职者申请表这一块十分流畅,体验极佳,但很快折戟于后台招聘管理中心的高交互性和复杂度,因此用来做出一个完整可用的HireLN应用还不足。

在用以上产品打造HireLN时遇到的一些问题示例

冷启动的难题

在我们用代码写一个新项目时,通常会采用一个流行的“工程脚手架”。这个脚手架包含了常用库、初始代码、构建流程、静态分析,等等。像Create React App这样维护良好的工具,还可以让工程师自定义想要的功能和模板。

一旦到了低代码、无代码的世界,“项目启动”的体验着实差了不少。不少LCNC产品都提供了功能完全的示例应用:一个基于PostgreSQL的后台控制面板,或是一个类亚马逊的电商网站,或是一个支持多语言的内容管理系统。然而,如若不选择“白手起家”,而是从这些示例应用开始新项目,这体验无异于用一个乐高“死星”搭出一个乐高“霍格沃兹城堡”——先得把整个“死星”给拆了,找到需要的积木,才能开始搭“霍格沃兹”。

用乐高“死星”搭出一个乐高“霍格沃兹城堡”

比如在用Retool搭HireLN的招聘管理中心时,我觉得它们的PostgreSQL中控样例是个不错的开始点。然而,我几乎得把样例里绝大多数的UI组件删掉,在27个内置query里找所需的4个,修复所有报错的组件,才得以开始搭HireLN。

其实,工程脚手架已经提供了更优秀的方案可以借鉴:可定制、个性化的初始项目生成器(参考下图)。当然,这对LCNC的产品灵活度来说,是不小的挑战。

状态管理的困境

一个应用当前展示的界面,几乎都是由“状态”决定的:大到当前页面的URL,小到一个下拉框弹出与否。这可以说是前端工程里最棘手的话题,诸如“状态储存在哪里”和“如何更新状态”,很容易让新手工程师头疼。

LCNC建站产品想方设法地帮用户们绕开这个工程难题。最常见的策略是提供许多包装好的“标准组件”,例如可翻页表单、多选框、文件上传控件,这样就无须用户们事无巨细地管理这些组件的内部状态了。

然而很多情况下,这并不能满足现代化UI界面的需求。最简单的例子是类似Google搜索的“自动完成输入框”——用户输入一些文字,发送一个请求到后端,再渲染最符合的几个选项。即使这组件如此的标准、普及大众,我到目前为止还没法用任何一款LCNC工具实现出来,因为无法手动管理“标准组件”的内部状态。

现代软件应用的交互十分复杂,这意味着对应用状态更细粒度的控制,并允许“组件们”实现一定程度的“状态互通”。LCNC却难以做到这一点,因为一旦提供了这些复杂的接口,所谓的低代码、无代码也就名不副实,一心击败全代码的“勇士”,自己也变成了高学习门槛的“恶龙”了。这个困境,使得大多由LCNC工具生成的应用在产品体验上较为逊色,难以进一步“出圈”。

“可扩展性”的缺失

软件开发领域里,有两种常见的“可扩展性”:一是软件本身的可扩展性(是否能容纳更多功能和复杂度),二是开发者协作的可拓展性(是否能让更多的开发者在同一个代码库上共同开发)。

LCNC工具在这两方面,比起全代码开发这个“老前辈”,都仍显稚嫩。

在软件的扩展性上,有经验的开发者通过适当的抽象化,避免复制粘贴代码,使得代码更容易维护。最常见的方法例如定义标准化接口,确保可预期的输入和输出变量。很明显,可视化组件很难做到同样的事,LCNC在这方面也还差得远。在搭建HireLN的过程中,我经常得Ctrl C + Ctrl V十几个文本框组件,回头来一个一个地修改他们的某个属性。

在开发者的扩展性上,很难想象LCNC工具可以提供类似“Git”的体验(最广为使用的版本管理系统)。毕竟,两段代码的区别,比两个可视化应用的区别来的直白得多。

这两个扩展性的挑战,让当下用LCNC来长期开发、维护一个软件,难上加难。即使这样,随着LCNC的快速发展,我们还是可以相信,不差于全代码开发的新工程、协作模式,会逐渐出现。

闭门造车的瓶颈

作为一个工程师,我会尽量避免“重复造轮子”(除非是出于学习目的,比如新的工具,框架,算法等)。有开源社区这个“宝库”作靠山,一键挪用“轮子哥”们的产出,夫复何求。

LCNC的生态,相较之下“闭环”得多,用户们能够选择用来建站的“标准组件”很受限。比如,如果我们想要一个“无限下拉”组件来展示数据,GitHub上针对各个平台和框架,都有大量的解决方案——可惜无一能被加入到LCNC工具的组件库里。

Bubble在这方面做了勇敢的尝试。第三方开发者们可以自行创建“插件”,一旦有其他用户购买并使用,就可以获得分成。想法虽好,很可惜大部分插件都质量堪忧,缺少维护,还很贵(更别提不让试用)。到头来还是几个Bubble官方出的插件最好用——还不如将其内置到组件库里。

结语

在我们对LCNC深入研究的第一篇第二篇中,对这个庞大且不断增长的产品类别描绘了一幅相当美好的前景(见下的LCNC版图)。在这第三篇里,我们平衡了一下分析角度,从亲身使用一些同类最佳LCNC工具的实践体验来形容其中发现的各种挑战。

尽管挑战重重,低代码、无代码产品可谓搭上了时代的顺风车。在开发者短缺的大环境下,越来越多的创业者们转向这些LCNC平台,来加速自己的创业进程,从而也给整个LCNC生态创造成长机遇和宝贵的用户反馈。

顺应这个潮流的另一个趋势是API产品的崛起,逐渐在吞噬各大领域,从机器学习、区块链、到金融、支付、健康医疗等等,这些曾经难以上手的领域,如今只需要注册个开发账号、发一些API请求就可以轻易玩转。

一些基于LCNC开发的产品原型案例

无代码、低代码产品,和全代码语言和框架一样,都在不断地追求更高的普及度,让更多新手加入到应用开发的大军中。这自然不可能一蹴而就,然而正如同自动驾驶一样,当越来越多的人开始使用时,更多的资金就会大量入局,竞争就会愈演愈烈,而整个无代码、低代码的趋势就会加速迭代达到成熟,最终惠及所有人。

如果您喜欢所读的内容,请用email订阅加入“互联”。要想读以前的文章,请查阅《互联档案》。每周一篇新文章送达您的邮箱。请在TwitterLinkedIn、Clubhouse(@kevinsxu)上给个follow,和我交流互动!