Blog Help

Some thoughts about the boundary between what we traditionally think of as thin and thick client apps.  With the increasing complexity of the browser environment I think the distinction is blurring between using a browser as an execution host vs. a “traditional” run-time as an execution host.

In the beginning there was the native client, and it was good.  For a while at least, until IT departments found out how expensive it was to maintain that software configuration.

So came the radical shift towards thin client, with a goal of zero client side application footprint.  There were two options:

·         Distribute a runtime and enable it to run network portable code.  Like Java and Applets.

·         Use a browser and send lightweight markup over the network.

Well, at the time there were problems with the runtime approach:

·         Distributing the Java runtime was problematic for many network connections.

·         Applets were painfully, agonizingly, slow in execution

·         The applets were also relatively big for the network (then) to carry.

So, momentum shifted to the browser model.

Well the browser was small and fast, and the markup was light, but it couldn’t really do that much.  Accordingly, the industry spend a decade or so enhancing the browser object models and environments until the browsers became runtimes in their own right, which are capable of hosting reasonably complex software that just happens to be JIT-Loaded from a web server, taking us to Atlas / Ajax today.

Atlas / Ajax does not represent any “Best Practices” in development from a purely technical standpoint; there are better ways to do it all.  It is the unfortunate reality that the industry has been unable to settle on a single well-conceived runtime environment and has instead taken a drunkard’s walk to arrive at a very unappealing, but relatively standard, programming environment.  Ajax is simply a way of trying to paper over the “poor” client characteristics of the browser / markup technology rootstock.

If we re-examine the runtime vs. browser decision today, would we make the same decision?

·         Browser downloads are now comparably sized to full-fledged runtimes and networks are much faster, so the browser no longer has any clear advantage in runtime distribution.

·         “Applets” or transportable .NET code is plenty fast for the client now, so that reason favoring the browser is also gone.

·         Downloaded byte-code or IL can still be pretty big.  This can be managed with proper techniques, but it is still nowhere near as light as interpreted script and markup.

So it seems that the size of the executable is the last strong fundamental reason to favour the browser model.  This must be balanced against the inferior programming model.

With new markup-enabled rich client technologies, such as WPF and Silverlight, the applications distributed to the client side run-times will be light enough, but with good user experience plus properly robust and productive development models.  This should knock the final pin out from under the browser approach.  From both a user and a developer standpoint I look forward fondly to a day where I don't have to submit to the tyranny of the back button.  ;-)