A Rebirth, Revisited

Every so often, a shift occurs in the tools available to creators, lowering the barrier to entry and unlocking new audiences. The 14th-century Renaissance saw the introduction of oil paints and canvas, developments that made artistic creation more accessible and affordable than the tempera-on-wood methods that preceded them. As these barriers fell, a broader population could participate in the era's artistic output.

We may be at a similar inflection point for the web. The field of web design is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming, opening the door for a new wave of creators.

Block of stone
‘Every block of stone has a statue inside it, and it is the task of the sculptor to discover it.’ — Michelangelo. Some people see a block of stone, while other people see a source of creation. The tools available to us at any given time can bring out our maximum potential. (Large preview)

Two Worlds, Two Mental Models

Designers and developers often operate with fundamentally different mental models, a concept popularized by usability expert Jakob Nielsen. His eponymous law suggests that users prefer systems that behave consistently with their prior experiences. For professionals, this means the tools they use must align with their innate way of thinking to remain productive.

Designers generally thrive in WYSIWYG environments like Figma or Sketch, where placing elements on a canvas yields instant visual feedback. Developers, on the other hand, are comfortable with the abstract logic of code editors like VSCode. While a drag-and-drop builder might frustrate a developer trying to debug quickly, a text editor is often inappropriate for a designer testing a visual composition.

Chris Coyier, co-founder of CodePen, aptly notes, “CSS is closer to painting than Python.” Design and development require different modes of thought, and the gap between a designer's mental model and the conceptual model of many code editors is a primary reason why many designers struggle to cross over into coding.

No-code tools bridge this chasm through code abstraction. They visualize the underlying logic, making it significantly more accessible without requiring a deep dive into syntax. By adopting a familiar visual medium, the learning curve for designers is drastically reduced.

A realistic collage featuring a 3D sculpture smashing water
(Large preview)

This trend is gaining significant traction. Even Chris Wanstrath, co-founder and former CEO of GitHub, has predicted that “the future of coding is no coding at all.” As interest in no-code grows, it is becoming a legitimate means of development, offering flexibility without needing to write every line of code by hand.

A screenshot of Google Trends
Search for the term 'nocode' in the last 5 years on Google Trends. (Large preview)

Declarative vs. Imperative

Understanding the power of modern no-code tools requires a basic grasp of programming paradigms:

  1. Imperative Programming
    Focuses on how to achieve a result by providing explicit, step-by-step instructions to the browser. Examples include JavaScript and Python.
  2. Declarative Programming
    Focuses on what the result should be, leaving the browser to figure out the details. Examples include HTML and CSS.

Declarative languages are often domain-specific, such as CSS for styling or SQL for databases. This distinction is crucial because declarative languages like CSS were designed to let creators define constraints and let the system handle the rest—a philosophy that aligns much more closely with a designer's workflow.

The First Attempts: A Digital Middle Ages

The quest for a visual web design tool is not new. The 1990s saw pioneers like InContext Spider, Microsoft FrontPage, and Dreamweaver. This was also the era when the term “no-code” first gained popularity—though for a far different reason, thanks to a Pearl Jam album of the same name.

However, these early tools were limited and couldn't handle the complexity of the evolving web for three primary reasons:

1. The Layout Problem

Tim Berners-Lee's World Wide Web, launched in 1989, offered no inherent method for design. That began to change in 1994 with Håkon Wium Lie's proposal of an idea that became Cascading Style Sheets (CSS). CSS stood out for its simplicity and its declarative nature, which allowed browsers to handle the processing of style rules.

Yet for years, CSS could only style individual objects; it couldn't adequately address the relationships between them. Web developers were forced to resort to imperative programming hacks to build the complex layouts that modern sites required. Grid systems common in print design were a distant dream. These layout limitations pushed no-code platforms to rely on abstract layers that generated heavy, unscalable, and often inaccessible code.

2. The Browser Wars

Early on, disalignment among browser makers meant developers often had to build multiple versions of the same site to ensure compatibility across the competition. Standards like those from the World Wide Web Consortium (WC3), founded in 1994, eventually aimed to fix this, but progress was slow.

For a long time, browsers refused to align. CSS development stalled as a result; if a declarative language doesn't support a feature, you must resort to imperative hacks, and this frequently broke and created an even greater barrier to creating robust, maintainable designs.

3. Data Binding

The transition from static brochure-ware to dynamic applications with data-driven content proved the undoing of many first-generation no-code tools. Easy, visual data binding was rare, and performing the semantic marking necessary for dynamic content mixed imperative and declarative programming in ways that these tools couldn't handle. At best, the user experience of linking a site to data was clunky; at worst, it was impossible.

A realistic collage featuring a 3D holding Old TV with glitch screen
(Large preview)

From Struggle to a New Form

Everything changed on June 29, 2007. It was then that the iPhone began reshaping the nature of the Internet, introducing responsive web design as an inescapable reality. Designers no longer controlled the canvas; they had to adapt their fixed layouts for tiny mobile screens in an era where the hack solutions of the past were falling apart.

This moment forced a necessary reevaluation of the entire web creation process, serving as a catalyst. As the web—and its users—became more sophisticated, there is renewed opportunity to create engineering and design tools that reconcile the goals of the designer with the capabilities of the underlying web platform.

Why No-Code Finally Worked

A pair of statues floating in the air as they hug each other
(Large preview)
The turning point wasn’t any single tool but the maturation of the web platform itself. Modern browsers now overwhelmingly support the W3C standards, which means developers can build sites on a shared foundation that will keep working as browsers evolve. Layout methods like media queries, flexbox, and grid are native to the browser, making flexible designs with dynamic element sizes practical. When CSS Grid arrived in March 2017, it marked a tipping point for layout capability. As Rachel Andrew put it in The New CSS Layout, that was the moment when technology became powerful enough for truly creative layouts, letting each project and each type of content express its own structure. With these standards aligned, HTML could return to its intended role: clean, semantic description of content. The growing divide between declarative markup and imperative logic opened the door for no-code tools that sit on top of a consistent, powerful foundation.

What Designers Gain

A screenshot of Editor X in edit mode
Editor X | David’s photo by Igor Ferreira on Unsplash. (Large preview)
As the abstraction between design and code improves, the way designers plan and build sites changes fundamentally. Planning with real materials. Traditional design tools only mock up static content, which is why Stephen Hay’s joke—that Photoshop shows clients what their website will never look like—still lands. No-code tools change that. Designers work with dynamic content, micro-interactions, animations, and responsive breakpoints directly in the workspace. Since style and content are separate, real content can be pulled in and laid out visually, and interaction behavior appears immediately for testing. Implementation without translation. In a conventional workflow, designers hand off static prototypes, and developers interpret them—frequently with drift between intent and result. No-code tools remove that handoff. Designers place objects, control visibility, and define behavior themselves, reaching a final result without depending on a second pair of hands. A practical example: during the early pandemic, a small team needed to connect young volunteers with isolated seniors. Working in a no-code environment, two designers stood up the full website and wired up user registration to a database in three days, while the developer focused on integrating that data into a separate mobile app.

What Designers Don’t Replace

No-code does not replace developers. The change is in how the two roles collaborate. JavaScript’s evolution has been just as significant as CSS’s, and it no longer makes sense for frontend developers to control every interaction on a page. No-code lets designers build their own visual and interactive work while developers concentrate on logic and data flow. It is a division of labor that gives each side more control over what they do best.

What’s Still Missing

Designers do not yet have complete freedom. Some styling capabilities in CSS still require imperative code, and until those gaps close, no-code tools cannot cover every edge case. That said, the trajectory is clear. No-code removes bottlenecks and gives designers more ownership over the experiences they create. As the web continues to evolve and the abstraction between intent and implementation narrows, the question of who builds a site is changing too. The no-code movement changes not only how things are made, but who gets to make them.