Using HTML to describe an application UI

As a front end developer, I've often been questioning whether HTML can really be treated as an application view descriptor, in particular in comparison with languages like, say, MXML. Of course, experience has shown that it could be done, but that necessary doesn't mean that it's the right tool for the job.

  

The first thing that strikes me, and what I'd like to share with you today, is the not so obvious relationship between html pages and application views, and the consequences in terms of strategies for source code organization.

 

HTML files, pages, and application views

 

 

Most websites generate web pages server side: the server assembles a whole new page each time the user requests a page, even if 95% of the content is the same as the previous page. Although we have AJAX, most of the time it's only used to update some small parts of the page as a result of some user interaction -such as an asynchronously populated data list-, not to power a client side rendered UI navigation system.

 

 

 

I think we can all agree on the fact that this model is definitely not well suited for web apps. Three reasons among others that come to my mind are:

  •  UX: dynamically driven navigation offer much more powerful options, especially in terms of responsiveness, not to the expense of deep linking (thanks to the history API).
  •  Optimization: each time you reload a page, you force the rendering engine do re-paint the whole interface, for no reason.
  •  Persistence: You loose your JS execution context with each page reload, hence no persistence at all, which is absolutely critical for any reasonably complex app.

 

Fortunately, we're not stuck with this somewhat archaic model, as we have some elegant, much more appropriate options at our disposal.

 

 

Single page models

 

Firstly, in a simple web app, you can use a single page model, aka single page application. Here, you simply describe your whole app as a unique HTML file, and hide or show divs representing your various application views. 

 

The core idea for the navigation logic is to hide and show divs using the display css property. That of course means that you need to keep track of the currently displayed div/page in order to hide it each time the user wants to navigate to another div/page.

 

 

Here's a simplistic code example using jQuery:

 

function changePage(pId) {

 $(currentpage).hide(); 
 $(pId).show(); 
 currentpage = pId; 

}

 

One particularly tricky question here is the integration of this navigation logic within the standard page navigation behavior. jQuery Mobile, for instance, catches the click to an anchor link, preventing the default behavior, and switches divs visibility accordingly (more details here).

 

Many JS architecture frameworks offer much more sophisticated implementations related to this, but I wanted to focus on the core idea here. Here's a nice article of how you can handle single page architecture in the context of jQuery.

 

Note: in this article, I focus on views representing "pages" or "screens", or at least a significant portion of the UI, as opposed to "components" and "item renderers" on which I will focus on a future post.

 

This is all great, but the problem, when compared to MXML, is that, as a developer, you lose view maintainability & reusability of the views. In other words, HTML being inherently anti DRY, you quickly end up having an ugly spaghetti code describing all your views. Certainly not a reasonable situation for a large scale application.

 

 

Consequences on source code organization

 

 

One approach to this issue would be to assemble various HTML files into one. You can do that either server side or at precompile time (or should I say authortime?) using a build utility. You'd then have a main HTML application page, and other HTML documents describing the various views inserted in the form of divs. In a way, this is pretty much what happens for RIAs such as flex apps, where of course views are compiled as classes, but end up in a single SWF.

 

You can also choose to load external HTML pages client side, at runtime, and injecting their DOM inside the main single-page document. This is a bit more expensive in terms of bandwidth and processing, as it occurs at runtime, but it also offers other obvious advantages. This is somewhat quite close to the behavior you have with Flex's Modules.

 

Again, this is something that some frameworks like jQuery Mobile lets you do. In fact, this is its default behavior when linking to external page on the same domain. Of course, this is also an inferior option as far as UX is concerned, since it is a much less responsive solution, but it has obvious advantages. 

 

However, we must keep in mind that we're talking about "pure" HTML content here. But in real life web apps, you want to integrate some kind of link between the description of the view and the data that's supposed to get there. One popular technique to do this is called templating, and it has important consequences on the organization of your code.

 

So in my next blog post, I'll dive deeper into templates in the context of Data binding & Item renderers, and see what strategies we can use to integrate them in our code.

 

AttachmentSize
singlepage.png19.74 KB