Inventing DNA Part 1

A skilled developer consistently tracks latency and employs all available strategies to mitigate it, including intelligent design, CDNs, and caching. But could we go a step further and completely eliminate the issue of lag by embracing some new, radical ideas? In a previous post, I touched on the concept of delivering only the “DNA” of an application to the client side, and how that might bring a feel of extreme responsiveness to experiences. Today, let’s dive deeper into an architecture that might support such a model, and start to define what this “DNA” might be made of.

Framework

First, we will need a framework to host our DNA.  Let’s narrow our focus to browser-driven web applications for this analysis. From experience, we know that certain web presentation elements will be repeatedly used—user interface objects like widgets, calendar date pickers, menus, and the various HTML containers that frame content within the hierarchical layout of the Document Object Model (DOM). These elements constitute what we can call the “framework.” If we could deliver these components once, at startup—similar to how CSS stylesheets are managed today—and if we could cache them indefinitely (since they don’t change as frequently as our DNA data will), we’d eliminate the need to reload them constantly. This frees us up to make managing the efficient flow of DNA data to and from the application our primary focus.

Rendering Engine

It’s also becoming increasingly feasible that most HTML and CSS shouldn’t be “delivered” at all. Instead, we might leverage a new invention, a browser-side “rendering engine” that dynamically generates content from a single execution of JavaScript code. This JavaScript will act as the powerhouse, interpreting the DNA and constructing all but the most static of components. Our central rendering approach must be limited by design, a feature-rich closed box of sorts, with extensions and plugins handled in modular way, to provide extensibility to our framework. Given the immense optimization of browser engines over the past two decades, JavaScript execution is now incredibly efficient, making this approach both viable and performant.

DNA

The DNA of a web application, in contrast to its framework, would contain a lean outline of the page. It will be metadata that can be used to create a hierarchical layout of the page, alongside information about how each section should look and behave— for example, whether it’s clickable, and what should happen when it is clicked. Even some light content required for application functionality might be included directly in the DNA, since the data can be compressed and transmitted quickly. More extensive content could be fetched through AJAX calls from the framework side, requiring only a content ID to be passed in the DNA. But ultimately, the mechanisms and management of content will reside in the decisions made in the rendering engine, in compliance with the architectural contract in place.

“Entire Agreement”

A core principle here is that the DNA should represent the “entire” application in the sense that any framework/renderer combination that meets our interface specifications could fully render and app with complete usability and functionality. For instance, depending on the complexity of the rendering engine, at rendering time, a date field might expressed as a simple text input relying on backend validation or a full-blown sophisticated date-picker with integrated UI components.

Bringing it All Together

A web application, in our model, therefore comprises three parts:

• the Framework,
• the Renderer, and
• the DNA.

The loading process in our browser application scenario would typically follow this sequence:

• First, the framework content is delivered, which is mostly static,
• This includes a reference to the rendering engine, which then loads.
• Extensions or plugins might load afterward, possibly on-demand.
• The framework will make a single call to retrieve the DNA, and once received, the rendering engine starts crafting the user experience in the browser.
• User interactions with the page are managed client-side, in JavaScript, and subsequent user actions can trigger further renderings from the rendering engine.

Ideally, unless data needs to be saved or some interaction requires server-side involvement, navigation and updates within the web application will occur solely in the browser, without any network trip at all, maximizing responsiveness and minimizing perceptible lag.

In Part 2, we’ll take a deeper dive into the DNA component of this architecture—exploring its functions, potential design, and the potentially radical shifts in application development we will be required to consider, in order to leverage this transformative approach.