Owning the Container

The big limitation of Web apps is that you’re at the mercy of the user’s browser. It may behave like you want it to, or it may not, but there’s no doubt that it limits how complicated and functional a Web app can get.

In a browser, remember, your page is only in the viewable area because the user has put it there. Your page can leave just as quickly – the user could reload it, they could click on a bookmark, etc.

A browser is a container. Your app is poured into one page at a time, and can just as easily get poured out, sometimes at inopportune times.

This leads to times when you need your app to do just a little bit more than a Web app can do. These are the times when you think, “Should I do this as a compiled, installed app instead?” But that’s a big leap – there really needs to be a middle ground.

Related to this, I’m seeing a fair amount of software these days that’s nothing but a Windows app with a big HTML area in the middle. Just the other day, my company was trying out some financial analysis software that had a familiar Windows feel for all the drop-down menus, and there was a tree-control in the sidebar, but the app itself was all done in an HTML-based workarea in the middle.

It was like a hot-rodded browser that only accessed one set of HTML pages. So, here we have something that’s part installed app, part HTML-based app (in this case, all the HTML content was local, but it could have been remote just as easily).

Could this be the next generation of apps? Sort of half-installed and half-Web? As a friend of mine put it the other day, “You can do a lot more when you own the container.”

For instance, if you own the container you can do things like getting rid of the back button. If you surround the “page area” with enough navigation controls (it is your app, after all, so you know where the user needs to go), do they need a back button? Additionally, you can control things like page load and unload – this means you can make sure they don’t accidentally refresh a form after typing a bunch of data into it.

At the same time, however, the core functionality of the app (the part in the “page area”) can come from a hosted environment, so you get all the benefits of distributing code to your clients, just like any other Web app.

In effect, you have a Web app, but the user accesses it via a customized browser. Obviously, this is only appropriate for apps into which the user has a lot invested. Basecamp comes to mind. We use it a lot around here, and I’d love to have a customized browser for it that would take advantage of all the native Windows functionality to make doing stuff easier.

There are a couple of ways to approach this:

• You could do the standard Windows app way – write an app in C# or whatever that’s centered around a big HTML rendering control in the middle of the page. Any page loaded into that would have full rights to affect the container into which its loaded (you should, of course, lock down the servers to which it can access).

• Wouldn’t XUL do this? I’ve played with XUL a little bit, and it strikes me you could really blur the line between what’s a Web app and what’s a compiled app.

• Microsoft has a technology that they talk about very little called “HTML Applications.” These are HTML files with an hta extension that you can fire up in a stripped-down browser window and which have full rights to the Windows environment.

I used this to write a little app that batch-transformed XML documents against an XSLT – everything was written in client-side VBScript. It worked beautifully and I wrote it in an evening.

The only big problem with this is that HTML Applications are really flighty about loading new pages into the same process. They tend to (1) not do it, or (2) treat the attempt as a download and ask the user what they want to do with the file.

(However, if you just loaded and reloaded the active “page” by massaging the innerHTML of the BODY tag, then you might have something. Combine with with XMLHttp and there you go.)

So, am I smoking crack here, or is owning the container a practical, usable way to bridging the gap between a Web app and an installed app?