Intelligent UI should not be confined to an AI chat, framework, programming language or hosting platform. Discover how Web Definition Language makes interfaces portable across hosts.
Intelligent UI is changing how people interact with the Web. Instead of navigating only predefined pages, users can increasingly receive interfaces composed around their questions, tasks and context. For decades, product teams have decided which pages, forms, tables and controls users will need in advance. Developers implement those decisions, browsers render the result, and users learn the navigation. Generative AI introduces another possibility. Someone could ask to compare products, configure a service or explore a dataset and receive a relevant, interactive view. This emerging experience is often called Generative UI, a way of producing Intelligent UI. But the most important question is no longer who generates the view—it is whether that view can work beyond the system that created it.
Intelligent UI needs a common description that different applications and runtimes can interpret. We already have mature Web technologies: HTML describes structure, CSS styles it, JavaScript supplies behavior, and frameworks organize applications. Those foundations remain essential. The missing piece is a portable declaration of the interface before a particular host turns it into a Web view. AI assistants can compose UI inside conversations. Websites can offer contextual tools. A CMS can build pages from reusable components. Yet when each representation belongs to one host, reuse becomes difficult. A universal language for Intelligent UI offers a shared contract: describe the interface once, and let compatible hosts implement it according to their capabilities.
The AI model—or any other decision-making system—can interpret intent, select relevant information and decide which kind of interaction might help. The interface definition describes the view that should appear. A renderer translates that definition into Web output. The host remains responsible for business rules, permissions, data access and executing consequential actions. This separation is essential. An interface should not need to contain a model, own a database or assume a specific cloud provider in order to display a comparison table. Likewise, the intelligence selecting that table should not have to rewrite an entire frontend application for every new request. Intelligence can propose a view. A shared language can describe it. Hosts can decide how to execute it safely. This distinction is central to Intelligent UI: a model or application may decide what should be shown, but a shared UI definition expresses how the view is structured. Different hosts can then render it and enforce their own rules.
RuledWDL is an effort to give Intelligent UI and other Web views a declarative definition. Web Definition Language (WDL) expresses an interface in structured data so humans, authoring tools and AI systems can work with the same representation. WDL is not a replacement for HTML, CSS or JavaScript. It is not a new model, and it is not limited to AI chat. It is a language for defining Web structure, styling relationships and data bindings before an implementation produces the final interface. The ambition is straightforward: author a WDL definition once, then interpret it through a compatible runtime in the environment where the experience is needed. The language should be the common contract, not the application that happened to generate it.
WDL organizes Web views around distinct responsibilities. COMPONENTS describe structure and composition. REGISTRY provides the design rules and styling vocabulary. DATA provides the values that populate the view. DATA_SCHEMA can express the shape and constraints of the data expected by reusable components. These sit on top of Web primitives, a language schema and specifications. A component can express a repeated collection without embedding the product database; the data can change without rebuilding the structural definition; design rules can evolve without asking every author to rewrite the content. The result is a structured document that can be inspected, validated, stored, edited and rendered. This separation is valuable even when no AI is involved. AI simply makes the value of a common definition more visible.
A universal language should not demand one programming language or one vendor's hosting platform. That is why the WDL specification and the code implementing it are distinct. The JavaScript implementation, @ruledwdl/core, provides the primary working runtime, with companion packages covering state, DOM updates, events and nested composition. Bootstrapped RuledWDL repositories also exist for PHP, Python and Go. These are starting points for expanding WDL beyond JavaScript—not a claim that each implementation already supports every feature with identical behavior. The longer-term direction is to make the open specification and shared conformance examples the reference point. A developer should be able to implement WDL for their own runtime host, compare expected rendering behavior and contribute improvements without having to depend on the JavaScript implementation.
Imagine an online store where someone asks, 'Show me lightweight laptops in my budget and let me compare battery life.' A host application could ask an AI system to compose a WDL definition for filters, product cards and a comparison view. Its own services would provide verified inventory, pricing, permissions and transactions. The compatible WDL renderer would turn the definition into the interface the visitor can use. The same pattern could apply to a support portal that generates a relevant troubleshooting flow, an analytics dashboard shaped around a question, or a CMS where the editor moves between human and AI authoring. These examples describe possibilities rather than finished integrations. Their common principle is the same: generative UI should become a Web capability, not an experience available only inside the interface of an AI assistant.
A useful interface rarely ends at static markup. Filters must respond, quantities must change, rows must update and controls must communicate intent back to the host. The RuledWDL JavaScript ecosystem includes packages for component state, declarative events and native DOM updates. In an interactive menu proof of concept, WDL definitions rendered a styled menu, quantity controls triggered state changes and the host calculated a cart total without replacing the entire menu. That experiment also exposed an incomplete binding: the quantity label between the controls did not refresh as expected. This is precisely the kind of behavioral detail a language ecosystem must test and improve. Interactivity is part of the journey, and reliable component-to-DOM binding is essential to making the experience dependable.
Developers should not have to start by creating a complete hosting environment to understand a language. RuledWeb provides a first hosted environment where WDL-based page authoring, rendering and publishing can be experienced in practice. That does not make RuledWeb a requirement for adopting WDL. The language is intended to be host-agnostic: a website, edge runtime, application server or independent renderer can use the specification on its own terms. The relationship is intentional. RuledWDL defines the language and its open ecosystem. RuledWeb demonstrates how a real publishing host can use the language to create and serve Web experiences. Other hosts and other implementations are not just possible; they are part of the goal.
For WDL to serve as common Web vocabulary, its definition must be open to inspection and implementation. The project has chosen Apache License 2.0 as the direction for the language specifications, including grammar and schemas; the repository's licensing notices are being aligned with that decision. The official RuledWDL runtime is currently distributed under AGPL-3.0-or-later, and alternative commercial runtime licensing is planned. Those implementation terms are distinct from the intention to let developers build their own compatible renderers using the specification. Open specifications create an invitation. PHP developers can make WDL native to PHP applications. Python and Go developers can build server renderers. Framework authors can explore adapters. Toolmakers can create validators, editors and test suites. A shared language grows stronger when independent implementations can challenge and improve it.
RuledWDL is early enough that important questions remain open: how should implementations demonstrate conformance? Which data-binding and event behaviors must be consistent? How should accessibility be validated? What are the minimum expectations for a compatible renderer? Those questions deserve public examples, tests and discussion. We are inviting developers to use WDL, experiment with the JavaScript runtime, help advance the PHP, Python and Go implementations, or begin a renderer for another host. Contributors can work on specifications, fixtures, documentation, accessibility, performance and developer experience. The goal is not to make every application use the same UI framework. It is to give Web interfaces a common definition that different tools and environments can understand. A new beginning. Same web. The next wave of Intelligent UI should be defined by what people can accomplish—not which AI application happens to display the interface. A common Web language gives that future room to grow.
