Realtime User Interface Design

By Brad Carleton

This is the third installment in a series on Building Realtime HTML5 Apps. Most of the thoughts and ideas from these articles stem from my experience building, a realtime javascript framework. The previous articles focused on Websockets vs AJAX and Single Page Apps & Realtime. This article will focus primarily on understanding Realtime User Interface Design as opposed to MVC for browser-based applications.

The Evolution of the Browser

As web applications have moved from the server to the browser, there have been a few important milestones in how we think about browser-based applications. Now obviously this evolution has been complex with many actors, organizations, and open source projects, but I’m going to try and condense it down a bit for clarity’s sake.

The first major advancement was the introduction of jQuery and other cross-browser DOM manipulation libraries. This allowed developers to program functionality into the browser with relative confidence that their code would work across the Web. A proliferation of plugins and other goodies soon popped up which made the Web a fertile playground for interactivity.

The next major advancement in front-end development was the MVC-based frameworks that were able to abstract DOM manipulation and data retrieval into a broader structure. This gave developers the opportunity to build larger more complex browser-based applications, and was brought about mainly by libraries such as Backbone and Angular.

As the HTML5 specification grows in features and complexity, what are the paradigms and philosophies that will help deliver the next generation of applications?

The Case against MVC in the Browser

I don’t believe that MVC is the best paradigm for understanding and structuring browser-based applications. The usefulness of the “Model” as a first class concept in the browser doesn’t make sense in many circumstances, especially when the data involved is transient in nature. If your main goal is to get “hot” data to the DOM, then the added abstraction layer of a “Model” often gets in the way of what you want to do.

For instance, let’s take a real life example, “Google” search.

Does the MVC architecture really describe this model of user interaction well?


If I had to break this “Google” search box into its separate concerns, here is how I would describe it:

  1. [DOM Event]: A user interacts with the Search Box by Pressing Keys on the Keyboard
  2. [Data Out]: When a Keyboard Interaction Occurs, contents of the Text Box are sent to the Server
  3. [Data In]: Receive Search Results from the Server
  4. [DOM Manipulation]: Render Search Results to the Search Results Box for the user to see

In this example, you don’t really “care” about the data for the Search Box, because the data itself is transient and volatile. You just care about rendering meaningful search results as fast as the user can type.

For this reason, I feel like the following diagram, the pattern, provides a better framework for understanding the “Google” search box.

The “Google” search example can be generalized to be largely “data-agnostic”, maybe it’s a search for books, condos, web pages, whatever. “Modeling” the search results or the text box that generates them is largely irrelevant.

How we access Data, Drives how we build Applications

In a lot of ways, how we access data drives how we build our applications. For example:

  • A search box is most likely powered by a Search Backend (maybe Lucene or ElasticSearch)
  • A data table is likely powered by a SQL database (maybe MySql or Postgres)
  • An activity stream is likely powered by a NoSQL database (maybe Cassandra or Redis)

In all of these instances, a generic user interface component largely drives the selection of the underlying “database” technology. As long as the server can send data in a format that fits the “search box” model or the “data table” model, then it can easily be rendered onto the DOM.

Therefore, when working on realtime HTML5 applications, I believe it is a better approach to construct applications in terms of “data-agnostic” user interface components. Components that can be easily reused, regardless of the different types of data flowing through them.

I hope you enjoyed this article, and please read the next in the series on Building Realtime HTML5 Apps.

Brad is a badass JavaScript coder who enjoys building cool stuff and long walks on the beach. As the Founder/CTO at TechPines, he has worked with large companies and startups to build cutting-edge applications based on HTML5 and Node.js. He is the creator of, a realtime HTML5 framework, and is the author of Embracing Disruption: A Cloud Revolution Manifesto.

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in HTML5, JavaScript, jQuery, Open Source. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • sdotone

    Looking at your diagram I see “abstraction leakage” and “bad separation of concerns”. Don’t confuse rendering and communication with higher level concepts such as Model, View or Controller.

    • techpines

      sdotone I’d be interested to hear more about why there is abstraction leakage or bad separation of concerns.

      Higher level abstractions are only useful if they allow you to reason more intelligently about lower level constructs.

      From my perspective, one of the main points of the browser is to communicate data effectively and efficiently with the rest of the cloud (servers, and other devices). Let the server figure out how to “Model” data, the browser should just be concerned with effective data communication, and the efficient manipulation and interaction with the DOM.

      I believe focusing on the inputs and outputs of what affects a browser-based application, is a reasonable approach to discovering an effective high level separation of concerns. And in my experience it leads to less code, easier to reason about programs, and simpler to test functionality.

      • The MVC controller still exists in all this, it’s just distributed so that your Model and part of the Controller is on the server side, and part of the Controller and the View is on the browser side. The input/output in the diagram above is only another label for a small part of what the controller is supposed to do. MVC architecture should IMO be applied to the system as a whole with the browser acting mostly as the View with some Controller responsibility.