I was intrigued by this tweet from Abraham Williams.  I haven’t been paying too much attention to HTML 5, mostly because I think of HTML as pure presentation.  My expertise is the server-side of applications, not the UI.  My whole career I’ve been wondering when we’ll get to the nirvana that will let me concentrate on the business side of applications and let those who know UI build the UI that connects to the back end.

With the advent of REST, I really thought we were getting close to that.  I can write all the business logic of an application in whatever language I choose and expose everything as a bunch of linked REST URLs.  A UI designer can create that UI in HTML/Javascript, Objective-C, Java, C++, Ruby, whatever.  By divorcing all the business from the UI we can be much more flexible.

But in steps the aforementioned tweet talking about Chrome supporting IndexedDB.  I was curious, so I started poking around on the W3C website.  I found the Web Storage document, the Indexed Database API document, and the Web Sockets API document.  Interesting.  Web Storage and Indexed Database are both for storing data locally so that an application can work when not connected to a network.  Web Sockets allows two-way communication between browser and server.

This is strange and interesting to me.  What was once supposed to be a simple and standards-based way to display content across different operating systems has morphed into a new way of writing applications.  It all keeps getting more and more complex.  It’s getting to the point that you _have_ to be a programmer just to build a UI these days.  HTML + Javascript is the new QT, GTK, or Swing.  It’s just another way of building a rich UI.  Any of the standard native UI toolkits could ask a REST-based service for data just the same as the browser version.

I have to wonder, though, if there is a limited lifetime for local storage in the browser.  The day can’t be too far off when there won’t be the concept of being “disconnected” from the web.  Coverage will be such that we’ll be able to be connected to the internet all the time, no matter where we are.  Web Sockets is even more interesting to me.  The browser concept was never supposed to allow two-way persistent communication.  You make a request and receive a response, then you close the connection.  We’ve devised all kinds of workarounds using server-side sessions, so I suppose this is the next logical step.

I guess the end result is that we’ll never really see the ideal of separation of concerns with application development.  More and more APIs are being added to HTML and Javascript that are blurring the lines between presentation and business.  The frameworks to make the browser UI do cool things are complex enough that you have to understand programming to a certain degree to manipulate the DOM.

Sigh.  I’d better start learning the finer points of UI design now.