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.
f3yourmind 
And how would you suppose to write a rich client application that runs _outside_ the browser, but is still easily downloadable on all platforms?
How else can I make sure PC, Mac and Linux users are all served at the same time?
@Jurgen. These days it is very easy to write a proper rich client application using Java Swing or Eclipse RCP, and have then started from your website using the Java Webstart technology. I’ve been doing that for years, and it always impress the clients way more than any web ui. Auto-update is build into Webstart. A proper language is used to build the applications.
Yes, all in response to those scary clients who want the world out of a Browser. The big problem is clients expect that web pages in a browser to behave as desktop app.Then we as developers, instead of educating, bend over backwards to please the client.
But having said that, I must admit that web apps have come a long way in the past few years.
I don’t think that it is all that bad to have these extra plug-ins in the browser world to make the experience all that better.
After all, the browser is not a picture viewer yet we are pleased that we can view pictures in the browsers.
Evolution is inevitable.
I have to disagree with you mostly. Having primarily done web development for 10 years, there are a lot of problems with the browser as an application platform. Browser compatibility, statelessness, javascript weirdness, limited UI features. Yes it has gotten a lot better. Yes you could always write a java app. But then they have to install it. Same with .NET MSI’s or exe’s. Assuming they become ubiquitous, JavaFX and Silverlight let me write in the same language on both client and server, are completely cross platform, require no install and tighter sandboxed security, get a bunch of out of the box controls and UI features web browsers only dream of and I dont have to deal with cookies, javascript or session state.
I do agree that every time a new platform comes out, its like the vendors have amnesia on what we’ve learned over the years. But theres nothing wrong with wanting the best of both worlds – thick client processing, pretty ui and ease of development and thin client compatibility and zero install or update.
So build a Flex, silverlight or JavaFX app today!
Die Html! Die Css!
Craig,
I am not saying that people should not develop with Silverlight, Flex, JavaFX etc. My point is that if people are going to develop with those technologies, then be very aware that the programming model is different from page based HTML+CSS+JS applications.