That indignation seemed to find an ally in Google.  At Google I/O 2010, there was much ballyhoo about open standards and open platforms.  There was direct mention of Flash being an important part of the internet at large, and Adobe fans seemed to have found a Mao for their Ho Chi Minh.  Outside of sharp words, Adobe had very little ammunition in this battle.  Adding Google as a key ally seemed at least to justify their position – even solidify a dynamic place in the marketplace for media delivery.

The politics of this war are less about openness of platform, however.  Apple’s exclusivity practices in the past few decades have been largely about limiting competition and thus maximizing margins from a niche product.  When the product suffered and competition increased in the early 90′s from Microsoft and others, Apple was only able to recover not by changing their strategy but by executing on the fundamentals that allowed this strategy to succeed in the first place – high quality.  Today, Apple has maximized the potential for the platform itself – whether it be a mobile device, laptop, or media center, to sustain it’s own profitability.  But with the computer and handheld market on lengthy cycles between purchases, maximizing revenue opportunity becomes a challenge of ensuring that customers are purchasing Apple product more frequently.  This is where the iTunes Music Store is so critically important to Apple’s strategy.

Flash as a platform is flawed, says Steve Jobs.  His arguments have some merit, particularly on handheld devices.  But once again, this is a proxy argument.  The problem with Flash isn’t that Jobs can’t control the content developed in the platform.  The problem is that by allowing Flash into the Apple ecosystem, Jobs would be opening a wormhole into an alternative media delivery platform.  Flash is a development tool – but by leaps and bounds it’s greatest claim in the frontier of the internet is multimedia content delivery.  YouTube, Brightcove, and Vimeo are all powered by Flash and all deliver the same content for free that Apple wants to be able to charge for.  This is where Apple dogma and Google dogma meet, and Adobe is simply a place for this war to be fought.

Adobe cannot win and remain sovereign in this battle.  Apple’s desktop platform is the chosen home for many creative’s who use Adobe’s landmark products like Photoshop and Fireworks.  Google owns YouTube, has built it’s own rich internet application framework, and fully backs the HTML5 standard that allows the modern web browser to do all of the things one could only do with the support of Flash in the past.  Google has Adobe smiling with a knife at their back.  For Google, the relationship is convenient to buy time until Android devices overtake Apple devices (likely in 2011).  Apple’s aggression gives Adobe little choice but to ally with the greater but less immediate threat.

Apple’s fatal flaw in this fight is not the control over development for their devices, but how users will get media delivery to those devices.  It’s not that Google is on the opposite side of the debate – they simply don’t care.  Google is a data company that is using mobile platforms as another tool for understanding their users as to maximize the ad revenue that has made them so successful.  Whether or not the user buys their content from Amazon or Apple or Walmart is inconsequential.  If the user clicked an ad for one of those companies to buy an MP3 and Google made $.05 from that click – it’s been a successful day for Google.  The Google approach is open solely because it maximizes revenue potential by maximizing the channels that can generate that revenue – not because of some religious developer fervor.

So Adobe can scream and yell at Apple all they want about openness and freedom.  They have the backing now of a much stronger, much better positioned ally that could turn on them at any minute.  One move for Adobe could be to find a way to exclusively integrate their products with iTMS.  Such a move would at least leverage them against any passive Google aggression.  But ultimately they are but a proxy in the coming Apple/Google apocalypse.  To me, it’s more curious that Apple has decided to bring this battle to such an intermediary first, rather than to try to stunt the emergent competition in Google head on.  It could well be that the cost of such a direct war would be so great to Apple that they’d rather not play offense but instead focus on defense – ensuring exclusivity of content delivery on Apple platforms.  It could also well be that we’ll be watching TV on our Android devices in 2015 and forwarding through the “I’m an Android.  I’m an iPhone.” commercials.  Only John Hodgman will be wearing the Steve Jobs mock turtleneck.

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.