Fat is the new Thin

During a factor10 virtual coffee break, Niclas Nilsson and I had a chat about what’s going on in web app land, on the browser end of the landscape. So this is inspired by his observations and him ‘pushing’ me to write this.
Recently, I’ve seen a few people searching for the holy grail of the ubiquitous browser UI.  The usual suspects appear: Silverlight, Flex, JavaFX.  Then I always suggest “What’s wrong with HTML, CSS and JavaScript.  You are writing a browser app, aren’t you?”.  And I get this weird, one raised eyebrow look.  So, in response to the one-raised-eyebrow look, here’s what I have observed. (I use the word model and fat below, maybe it’s the wrong usage, but I think you’ll get the gist.)

In the early days of browser apps, everyone was trying to write fat desktop apps in HTML.  And that went horribly wrong because the programming model was different.  We eventually figured out page based, disconnected apps in the browser, then someone did the AJAX thing and we had out-of-bound HTTP requests and in-place DOM updates.  Another small twist in the programming model.  But we had already made the transition to a new programming model and AJAX was not a radical change.

Now we have Silverlight, Flex/Air and others.  They happen to run in a browser, but there’s nothing browser based about them.  Yes, they all let you interact with the DOM and run some JavaScript too.  But these apps might as well not be in a browser.  In fact, that’s now pitched as a super great feature: your code can run inside and outside the browser.  The programming model is different.  No matter what the marketing folk say, I think the in-browser feature is a clever adoption scheme.

The truth is that this new thin is actually fat, FAT, FAT!  It’s just fat and disconnected.  That is all.  My advice for those that want to go this pseudo-thin route, is to just write your app to run outside the browser.  Just forget about the browser.  If you want to use the browser, then go back to HTML and JavaScript. The common counter statement is that these clients get rid of browser incompatibility issues.  If you really want to get rid of browser incompatibility issues, then don’t use a browser.  Simple.  And these confused thin clients will let you do that.

But the part that really scares me is that the fat code I have seen so far reminds me of unmaintainable VB, Delphi or PowerBuilder code.  And there are other scary things too.  For example, the Cairngorm framework for Flex is based on a singleton pattern, but the underlying language does not make it easy to create singletons.  Imagine all the code to create a singleton just to get the framework to work.  And these frameworks are not very DRY either.  Somehow, it seems like a new group of developers are writing these frameworks and they have not bothered to learn from 10+ years of web UI framework lessons.  The good news is that code maintenance and framework quality issues are solvable.

But the game itself has changed.  It’s not a case of new rules in an old game.  That’s what caused the mess in 1999 with HTML.

By this time, most people either close their eyes or raise the other eyebrow at me.