What Perl, PHP, Python, and Ruby have done for application development, particularly classic web application development, has been nothing short of revolutionary.  Take C out of the picture.  Facade it with modern concepts that young developers can take to quickly and get results with.  Lose all accountability for memory management.  Push the heavy lifting to the open source teams maintaining these languages, let them deal with security concerns.

But in the last few years, web applications have changed.  The focus has shifted to moving state management and logic to the browser.  Rich internet applications aim to deliver experiences and tools that simply can’t be solved by these scripting languages or even their more heavy-handed older siblings, J2EE and ASP.Net.  Javascript is the new soup du jour.  A slew of abstractions have grown up around the limited facilities of Javascript, all trying to simplify this new mode of development through quirky but innovative approaches to DOM management, component reuse, and RPC.  But all of them are still Javascript.  All of them still take the code written by the engineer and with limited optimization execute it with the browser runtime.  As the complexity of these applications has scaled, the task of making them scalable and performant has become sisyphean.  Web developers have always needed to deal with issues of cross-browser compatibility, interactions with different operating systems, etc.  But now more and more we are talking about the limited capabilities of the browser itself and how it doesn’t manage memory in our Javascript applications the way that we are magically accustomed to.  For all the RIA frameworks we have today – Flash, Silverlight, JavaFX, etc., there’s still only one platform we can count on to deliver client-centric browser applications, and that’s Javascript.

So when the cost of delivering these solutions begins to increase incongruently with the complexity of the functionality we are looking to deliver, what are we to do?

An interesting thing happened the other day in the mobile application space.  iPhone development – typically the domain of pompous Mac owners like myself and a few willing Webkit jockeys, suddenly opened it’s doors to Adobe’s Flash platform.  After months – no, years of wrangling – Adobe has finally found a way to play on Apple’s lucrative mobile platform.  But this isn’t Keith Peters’ Flash.  This is Actionscript being compiled magically into native iPhone runtime applications.  It’s a stunning development, one drawing ire and concern about performance.  But it’s not the first time that a development platform hailed for it’s scalability and ease of entry now has been used to usurp a underlying native platform which has proven to be a barrier in and of itself into development for the target platform.

Google Web Toolkit started the latest generation of application development, with it’s seeds in Microsoft .Net’s CLR.

As I noted, Javascript development today is hard.  It requires a significant amount of skill and experience to do right, and there’s simply not enough talent around to deliver the types of applications that every web site should be delivering.  There are fantastic software platforms written in C – but as we saw in the initial explosion of web applications, C is not a language that lends itself well to a pool of experienced and cheap labor.  PHP was that language.  Perl was that language.  It distilled down the concepts an engineer needed to know about to deliver a reliable application and simplified those concepts – memory management, semaphores, I/O, etc.  It allowed engineers to focus on solving the business problems of the dot-com boom and subsequent flurries of enterprise IT demands.  Now that the nature of those problems have changed – PHP as a tool is simply a square peg for a round hole.  And given the dreadful performance of our target operating environment, an interpreted language on top of Javascript is not an option.  What is an option is another language platform that could be compiled into JavaScript, complete with optimizations for memory management and portability.  GWT made Java the potential language of choice when it came to RIA development in Javascript.  It once again gave power back to engineers to be able to focus less on the non-functional needs of the application and put the focus back on fulfilling the functional requirements.

While the performance of GWT is stunning and it’s architecture a stark deja vu of past optimizations approaches to software compilation – our other example may not quite have the grit.  Compiling ActionScript to Objective-C is a nice trick, but may only solve the problem of heterogeneous development environments for Flash developers who haven’t had the guts yet to get into Cocoa development.  Natively, Objective-C is rather optimized, with device performance on the iPhone of platform applications running remarkably well.  So the compiler optimizations that web applications gain from GWT development aren’t really there.

But guns are certainly drawn on the problems of complex platform development, whether it be the arcane and aging Javascript platform in the modern web browser or the stifled promise of mobile application development.  For years, the complexity of executing a piece of software on a mainframe (or older system) acted as a significant barrier to delivery of commercial software.  The innovation of the compiler changed all of that.  Fast-forward 50 years later and we see the same problem, and the same solution is staring right at us.  The odd natural selection of software languages will repeat itself it seems.  Once again, the compiler saves the day.