I've never been a fan of the web (from a programming point of view). It's really quite a hideous collection of historical artefacts, and belies the plain fact that it was never intended to be an application platform, but an information publishing platform. Who'd have thought that we would have demanded that our 'document' content should take on more and more complex behaviour and become dyed-in-the-wool applications? It's quite strange that the browser has come to be a cross-platform application runtime environment, when its only real strengths are that it acquires content on-demand (which can therefore be updated freely by authors), and it offers security by sandboxing the content from the rest of the user's machine. Neither of these advantages require a browser per se, and therefore a document rendering client would seem a poor place to start to arrive at a good general purpose application runtime environment. Indeed, IMHO, it's an awful choice, but probably the only way such a thing was really going to happen (and be so ubiquitous), because it had one other thing mostly in its favour - it wasn't formally controlled by any one commercial entity. I'm not even going to get started on the issues of standards and testing necessary to ensure that a myriad different browser clients are offering a consistent platform for applications!
Whatever the reason that a document rendered has been press-ganged into service as an application runtime, the "web" is here to stay. It offers just too many advantages to the consumer (and IT shops) in terms of the deployment flexibility and independence of other infrastructure decision making - such as what computers to buy and what software to install. Meanwhile, developers have been saddled with a pretty hostile platform for creating applications of any real sophistication, and until very recently most web applications patently 'sucked' when compared with ergonomics available in thick-client applications. The developer community knew it had to innovate new ways of coding applications in browsers, but how do you tame all the legion bits and pieces: HTTP, HTML(at various versions), DOM, Scripts, CSS, user sessions, server-side objects/databases, etc.? If you consider all this paraphernalia, most of the mess is on the client-side and/or historical artefacts of document rendering. If the world had grown comfortable with something like web-delivered pure Java as a standard cross-platform app platform, then there would still be a need to host the downloadable classes, and to provide any centralised services (such as databases), and maybe we would have kept a single port (e.g. 80) between the server and client 'sandboxes' for security - despite the drawbacks this represents. So, the server-side would look very similar to today's configurations for supporting web apps, save for the actual web service itself. The client however, would be much more homogeneous and based on fundamentally more appropriate principles for running applications. Alas, that was not to be.
So, the poor old web browser has been cast as the saviour of secure, on-demand, client-server general computing. How on earth are we going to turn this thing into a reasonable system to program? Well, unsurprisingly, the saviour seems to be JavaScript, or scripting more generally if you prefer. Each 'page' can contain script fragments that manipulate states on the page, and even the page's own structural description, in order to produce richer 'application-like' behaviour in the browser. This works fine, but has some weird properties:
- The page structure is still at the heart of the 'application', even though any allusion to document-like behaviour may be extremely artificial for much 'application content'.
- Scripts are delivered in little pieces, and an application must be partitioned into pieces (pages or bits of page) that are loaded. This is almost like the old "overlays" in applications when computer memory was stuck at 640k!
- The 'drawing primitives' of the application are all derived from odd document description terms and primitives - essentially HTML tags, enriched perhaps with other technologies such as SVG that can draw on canvases that are a part of the loaded document.
Suffice it to say that *if* you truly want to deliver an application to some browser, then you probably don't care about having all that page description junk lying around. Rather, you just want to build your application, as usual including all the necessary logic, UI, communications, storage and other resources to allow it to perform its designed functions. Having to cross-cut all these things you actually care about, with arbitrary document/page principles is just annoying, and no fun at all. This is the background to my long-held somewhat dim attitudes to web-programming. I realised that it was necessary, but had literally no motivation to really get into it until I had some respect for the medium in which applications could be made.
Well, it looks like some interesting things are finally happening. After many years and many many frameworks, and the realisation that the only way to really achieve applications on the web was with a lot of scripting, the world finally gave a name to the way you pretty much had to develop (in just a regular browser, not a plugin like Flash). AJAX (asynchronous JavaScript and XML) was the way that the real pleasant-to-use applications were made. AJAX is all about sending (nominally) JavaScript down to the client, and then having this script request data from the server as XML. The scripts can alter page structure or draw UI elements in keeping with the data that is received on request. AJAX techniques gave us cool things like Google Maps, but AJAX was more of an idea than an actual technology until a few people started to codify the technique in higher-level frameworks that would generate appropriate AJAX web content automatically from some much more developer-friendly form of scripting. Google offered an early form of this called GWT (Google Web Toolkit), but the capabilities were still quite limited.
Wind the clock forward a few years and we now have some truly interesting new frameworks available. Two of these are SproutCore and Cappuccino. In particular Cappuccino does something quite remarkable. It actually lets you write an application as if you were writing a thick-client, modulo calls to a server to get data. Moreover, Cappuccino has chosen the rather excellent (IMHO!) Cocoa framework on which to model itself, including aping the language that underpins Cocoa - Objective-C. Thus, Objective-J is a language to JavaScript that Objective-C is to C. The Cappuccino framework is a rich library of objects that aims to deliver corresponding behaviour in a web application to that offered by Cocoa in a thick-client application. This approach completely hides all the document-centric behaviours of the browser, and instead treats the browser windows as 'screens' in which regular application windows reside. All the display entities (views/controls) can be manipulated just like their thick-client counterparts, and application logic is coherent and encapsulated in an natural way.
To my mind this is the natural evolution of the web as an application platform. If the browser has to be platform for general applications, then its document processing features should be deemphasised as much as possible - i.e. completely from a programmer perspective. It would be nice if browsers eventually turned into windows that ran JavaScript well and offered certain drawing primitives and functions. Those features could certainly include HTML rendering, but the scripting/programming layer should sit beneath the document layer, rather than the inverted case we have now.
In any case, and whatever the future holds, Cappuccino is a very interesting idea as it finally hides the mess. It also ostensibly provides a way to allow the underlying mess underneath to change while preserving the programming interface - but we'll see.
I shall certainly be spending a little time getting to know Cappuccino and perhaps I'll practice on a prototype of the D-WARP idea I've blogged about (though I've gone right off the name!)
No comments:
Post a Comment