The future of no-code is parametric design

No-code tools are limited

Throughout the history of no-code tools, one aspect has always been very evident: no-code tools are very limited.

When you think about direct manipulation of an object on a canvas, it's difficult to imagine that this can allow you to build anything you want, and rightfully so. Direct manipulation can only manipulate what can be represented on the canvas.

This changes the moment you have additional controls that allow you to change parameters of the object that you can’t really touch in 2D or 3D rendered graphics. For example, let's imagine an animation where an object is moving through space. You can’t easily change its velocity from the canvas, but what you can do is have another dimension of controls that allow you to change that.

This is the most primitive form of a parametric design.

Here is the definition from Wikipedia:

Parametric design is a design method in which features, such as building elements and engineering components, are shaped based on algorithmic processes rather than direct manipulation. In this approach, parameters and rules establish the relationship between design intent and design response.

It suggests that parametric design requires algorithms rather than direct manipulation, but this definition is rather narrow.

Before I can explain why I think the future of no-code is parametric design, we need to widen our understanding of the term.

Parametric Design System in design tools

If you look at mature design tools like Figma, they have long moved past simple direct manipulation into the realm of parametric design, though their capabilities remain much more primitive compared to the web.

To name a few examples: Figma has variables and auto layout. Both are great examples of parametric design.

Auto layout is a simplified version of CSS flexbox, which allows the user to specify parameters like “Vertical layout” or “Horizontal layout” with a click of a button. The very same thing is called “direction” in CSS and allows the flexbox algorithm to place items inside the layout in a vertical or horizontal stack (column and row).

When it comes to CSS, it always comes with more options, because most tools make significant compromises to the power they expose when trying to create a visual way to control CSS. Even in this case, flexbox also offers “row-reverse” and “column-reverse” to parameterize your direction depending on your needs. For example, in a right-to-left language, you may need to reverse the order of the items.

HTML and CSS differ from design tools in a lot of powerful features that are required to build accessible and fast experiences.

Parametric Design System with CSS

A less primitive form of parametric design is a design system. In the most basic form, a design system is a set of constraints that define how design elements should look or behave. A set of colors defined by the design system used for a specific product or brand is essentially a set of parameters. Let's take this simplified example with CSS:

A brand has four colors:

:root {
  --color-accent-light: purple;
  --color-hint-light: darkgray;
  --color-text-light: black;
  --color-background-light: white;
}

So far this is a static design system; it is not parametric yet. Let's introduce a dark theme:

:root {
    --color-accent-dark: darkpurple;
    --color-hint-dark: lightgray;
    --color-text-dark: white;
    --color-background-dark: black;
}

With these two themes, we would have eight color names to maintain individually, twice as much work to maintain even in this unrealistically simplified design system.

Let's use a CSS light-dark function to implement a parametric design and reduce the amount of variables by a factor of two:

:root {
    --color-accent: light-dark(darkpurple, lightpurple);
    --color-hint: light-dark(darkgray, lightgray);
    --color-text: light-dark(black, white);
    --color-background: light-dark(white, black);
}

Now, with this function, we only have to maintain four color names, and the switch happens automatically depending on the chosen theme.

Imagine the amount of complexity we've just reduced in a real-world design system.

Could we reduce it even further? Yes. You probably already noticed that, in total, this system has six colors—in particular, dark/light purple and dark/light gray. What if we could calculate those colors based on a single color? Meet oklch. Using this tool, I am going to play with my light theme purple color to find the color I want to use on a dark theme.

:root {
    --color-purple: rebeccapurple;
    --color-gray: gray;

    --color-accent: light-dark(
        var(--color-purple),
        oklch(from var(--color-purple) 60% c h)
    );
    --color-hint-dark: light-dark(
        var(--color-gray),
        oklch(from var(--color-gray) 70% c h)
    );

    --color-text-dark: light-dark(black, white);
    --color-background-dark: light-dark(white, black);
}

Now we still have six colors, but we don’t maintain six colors; we maintain only four, because the rest is derived from them, using Relative Color Syntax, based on the parameters we specified. The CSS function oklch() takes four arguments in our case.

oklch(
    from rebeccapurple /* original color */
    60% /* perceived lightness */
    c /* the original chroma */
    h /* the original hue */
)

We took the original color and created a new color using three parameters, using just standard CSS.

Parametric Design System with components

HTML, CSS, and JavaScript as a combination allow you to create components—reusable blocks that can be defined once and then parameterized to produce different results.

To give you a simple built-in example from HTML, let's have a look at an <input> element. Here, an input with the parameter “type” and value “text” will render a text box where you can type.

<input type="text">

An input with type “checkbox” will render a checkbox that you can click on to check or uncheck:

<input type="checkbox">

In both cases, type is a parameter that changes the behavior of a component and is a basic example of parametric design.

Combine HTML, CSS, and JavaScript, and you can build the most sophisticated components for a complex parametric design system.

At the most basic level, JavaScript frameworks like React let us build components that form a parametric system. A React component, in a nutshell, is a function that receives parameters (props) and returns a renderable spec (HTML), and allows you to combine and orchestrate the rendering of HTML, CSS, and JavaScript logic.

function MyButton({param1}) {
    return <button />
}

Browser as a parametric design platform

From a design perspective, the web platform can be seen as a very powerful parameterizable design platform. Because of the number of features, it also became very complex and has resulted in the death of visual-first tools from the early days of the web, such as Dreamweaver and FrontPage builders, which we now jokingly call the first no-code tools.

They disappeared from the landscape not because the idea was fundamentally bad, but because progress runs in cycles. Humanity started discovering the limits of code. We started hand-coding websites from scratch, and it was a decent experience until capability requirements started to grow, leading to an explosion of complexity and the creation of a giant web engineering industry.

As history usually works, we are now rediscovering the benefits of the visual approach, its speed of iteration and experimentation. A design-centric approach that involves fewer people in the process has now proven to be a much more economical choice, and now it’s time to build systems that are not only easier to use, but are also powerful enough to build anything you want.

And here is the resistance that you often hear when you talk to engineers:

“What if I need to do this custom logic or behavior and your design tool can not do it?”

or

”How can a parametric design system be easy to build if you need to write code for it to work?”

The answer is that “Code” <> “Visual Development” isn’t necessarily a 1:1 translation. For some use cases, you should be able to build 100% of it visually, while for other use-cases you might only be able to get 80% of the way, while needing some code for the rest. What is important is how easy the tool makes it for you to do the remaining 20% without making the whole build hard to maintain.

Our goal should be not to try to build everything visually, but build mostly visually and use code where it serves as a better tool. Code vs no-code is a spectrum.

When pure no-code tools fall short

When it comes to achieving a seamless transition between code and no-code, tools that try to be 100% no-code fall short. You will inevitably reach their limit. This is a dead end. Pure no-code tools are what give no-code a bad reputation, a reputation where you can only build some basic prototypes, but not the real product.

Pure no-code tools lack code-based representation of the thing you are trying to build. They generate data in some internal format only, and that format is not human readable, and hence it's likely you will hit a roadblock.

The truth is that not everything can or should be built visually; certain complex things are easier with code.

AI is changing how we think about no-code

With the latest iterations in AI, we can now see how it can be a helpful tool in the build process.

Large language models can directionally interpret what we want to build from natural language and help us overcome the blank-canvas problem.

An important factor here is to be able to convert AI-based generation to the format a no-code platform would understand. The closer the platform is to the languages used by the platform, the easier the translation, since LLMs will have a large amount of knowledge based on previously written code in standard languages.

Once you have leveraged the AI to generate something directionally correct, you will inevitably want to adjust things to meet your goals. This is where a visual designer becomes useful again, allowing you to build precisely what you wanted and make it actually usable in production.

The interplay between AI generation, visual manipulation, and parametric design is the future of no-code and, hopefully, of the development industry as a whole.

Code will stay extremely important because it's the glue that lets AI understand and learn while simultaneously being readable by humans.

The more LLMs can learn from human-made code, the more they can understand our intentions. Code generated from visual tools can keep refining that information if it is generated, not only kept hidden as internal data in a database. It is much cheaper to use LLMs trained on standard languages based on lots of different resources than to train them on proprietary data structures and keep continuously investing in that training over time.

New opportunities for visual development

Visual development is becoming so much better than it used to be, just like the web itself - more powerful and yet easier to use at the same time. The interplay and integration with AI are going to change how we think of it in the long run. The future is parametric design, code and AI combined on a visual canvas.