No-code development is about to hit a wall

Jane is a designer. she is great at capturing her clients vision and turning it into its visual manifestation. Jane, however, is not a developer. She cannot write code. 10 years ago, Jane would not be able to produce a working website for her clients without the participation of a (costly) developer. Today, she can. Thanks to the no-code movement, there are a myriad of tools and services that enable designers like Jane or even business owners to create their own websites. No coding is required.

No-code systems, as applied to web and app development, rely mostly on two principles:

1. WYSIWYG — What you see it what you get — using these tools, the creator edits the user interface using visual representations of the actual interface being created. This is opposed to editing HTML using a text editor where the editing process relates to text rather than the visuals of the UI elements.
2. D&D — Drag & Drop — editor has a sidebar with UI elements that can be dragged to the canvass, just like a painter has a palette choosing which color to apply to the canvass.

The underlying principal described here is that we are using visual tools to create visual user interface. However, visual editing does not cover the full extent of the required job.

Making the UI “Do” Stuff

In programming, there are two main paradigms:

1. Declarative: We describe what we want to have. HTML is an example of a declarative approach. We describe which web elements should appear on the page
2. Imperative: We describe what we want the program to do. Most programming languages, such as Javascript, are imperative. They list a series of actions (functions) that should be executed.

In web development, having all the widgets in place is a prerequisite. Once we have the layout established, we need to define how the user interacts with the web page. This has the structure of when the user …. then do … Something needs to happen — a web search, adding a new item to the shopping cart or send a 😃 to a friend. Interactions are typically defined using imperative programming languages (Javascript for web interactions). Actions are essentially not visual. They have no body. They are abstract. So how do we describe abstract concepts using visual tools?

Hitting the Wall

The go-to solution for representing activities visually is the activity diagram representing flows where each step is a box. This indeed is used by most no-code companies such as bubble, Webflow and many others. In some domains such as gaming, the activity diagram was extended into visual scripting, replacing programming language by visual programming.

This is a great solution for empowering non programmers to create software. However, once complexity grows, we hit the wall.

Take for example the following workflow on the right. It is taken from the excellent Bolt visual scripting tool for developing games on the Unity platform. On the left you can see the textual parallel in human language.

I would argue that the text of the left is a lot more concise and easier to understand than its visual representation on the right. It also occupies a lot less screen real-estate. But beyond that, visual programming just doesn’t scale. This visual scripts occupies a full screen. The text, when written with the same font size used in the image, takes just a fraction of that space. The 3 lines of text above takes 14 (complex) visual elements to describe. A relatively small 2000 lines of code project would require almost 10,000 visual elements spread across many screens. I know, the math is probably wrong but it is clear that for large scale projects, visual scripting is just not the way to go. An alternate path can be using textual scripting. However, there is a beast hiding in that statement.

Taming the Beast

There are two extremes to textual scripting:

1. Use programming languages or higher end scripting languages such as visual basic for applications (I’m dating myself but VBA used to be a big thing)
2. Use human language (like French) to define the programs behavior, using natural language understanding tools to interpret the text

The first option is really not ”no-code”. It requires training and technical inclination. It doesn’t solve the problem no-code want’s to solve.

The second option, using natural language understanding, is technically complex and, even with the progress done with machine learning models such as GPT3, seems out of reach for the immediate future.

But there is a middle ground.

Bridging the Gap

Let’s spend a few paragraphs analyzing the difference between programming language and human language. A program is a group of function calls arranged in a control structure. The simplest program is just a sequence of function calls, and human language is not very different. A paragraph is a sequence of sentences. A natural language program (snippet) might look like this:

when a user clicks on the button do the following:
1. change the color of the button to red
2. show the new task dialog

This can work for most no-code developers. So, what are the differences between human language and programming language that makes the programming language much more difficult to write and (even more important) to maintain:

• Programming language uses function notation like this: alert(“hello world”). This is great if you are a mathematician and everything seems like a type of function, but for the rest of us, the statement show an alert box saying “hello world” seems a lot more intuitive.
• In programming language, programmers need prior knowledge of available functions they can use in their program. In addition, using the functions is often not trivial. Using human language, any grammatically valid structure can be used.
• In natural language, when we interpret the text, we often use the context of the text for reference with phrases like: the active element, the user, it. In programming language, we try to avoid ambiguity at any cost so references are a lot more precise. Programmers use explicitly named variables and reference them later by their name. While this eliminate ambiguity, it provides for a cumbersome syntax.

Natura — No-Code Scripting

Now that we understands the shortfalls of programming languages, we can construct a no-code scripting solution using human language. Natura is our attempt at this. Have a look at our sample script . Natura has the following functionality:

sample screenshot from Natura script

1. Users select the actions or expressions from a list, solving the prior-knowledge problem.
2. Text is displayed like a text template with underlined slots for the arguments. This has a natural language look and feel, unlike the typical scripting notation. Slots can be filled with expressions — parallel to programming functions
3. User can select context phrases such as the element. Users can see exactly which element the phrase references eliminating ambiguity.
4. Hovering over an action or statement suggestion shows a detailed explanation of the meaning and usage of the phrases, solving the prior knowledge problem.

Overall, the script looks like a human language script, but the writing of the script is more like using code intellisense or Gmail’s Smart Compose.

Have a deeper look at the project at https://www.naturascript.org and let us know what you think of it!

Final Thoughts — What’s in it for Developers?

There is a lot of talk about the role of developers in a world dominated by no-code. Will we still need developers? My answer is definitely yes. This function, responsible for defining functionality of web pages and application will always be required. However, I do thing there will be a change in the focus of developers. There will be less emphasis on design (the platform will take care of that) and silly religious wars (React vs. Vue). The programmers work will be easier with a lower barrier to entry. But most important, programmers will focus on what to do rather than how to do it. Rather than dealing with the nuts and bolts of coding, they will focus on producing great experiences for their software users.