Adobe Apollo: First Impressions
The first glimpse of Adobe Apollo has arrived: http://video.google.com/videoplay?docid=1551903488172905143 (via Mike Chambers http://weblogs.macromedia.com/mesh/archives/2006/11/video_leveragin.html)
The HTML + Flash integration is definitely sweet. I've long had the opinion that Flash just isn't as good as HTML at doing certain things, so being able use HTML for your grids and Flash for your videos, but then being able to apply animations, effects, etc. to everything is great.
Free tools are promised, which solves another of Macromedia's biggest mistakes with Flash... let's just hope they aren't stripped down versions like Flex offers (note to Adobe: if you are going to offer some server side stuff, name it something else instead of making it part of the "Enterprise" Apollo dev license).
However, right off the bat I do see some problems. Macromedia promises that you'll be able to reuse existing HTML/CSS/Javascript applications... but if I'm going to be able to reuse my apps, why the hell did they chose the WebKit/Safari engine instead of the Mozilla one? Really, that was a huge mistake. Things are already bad enough having to debug IE and Mozilla, now they want us to learn all the quirks about WebKit. I don't care if IE8, Mozilla 3, and the next WebKit release claim 100% CSS2 compliance, you'll still have to test in all of them because of rendering bugs and other off-spec differences.
They made the same mistake with Flash Video. First, they chose a slightly modified H.263 codec for video then they license this codec from a company no one has ever heard of before for the next version. If you build applications that generate SWF content and invested in adding Flash video support to your app for Version 6, you have to license video code from a completely different company for Version 7 (and pay many times more to On2 for their codec than you ever dreamed of paying for supporting the Sorenson codec). They could have just chosen a more standard codec like MPEG4, but they had to chose a cheap knock off because it fit their budget and their lazy developer's time constraints. They should have considered the constraints it would put on people trying to create tools that run on top of their platform instead.
Apollo is not a replacement for Flash. It is a runtime. This means it competes with .NET and Java. This means you won't browse to Apollo applications, you will install them. It also means that even if you like IE or Mozilla you'll have to kiss them goodbye when "browsing" an Apollo application. If Apollo requires an admin install or reboot like .NET and Java, then they just managed to eliminate one of the major benefits of writing web apps in the first place with this "Next Gen" engine. Also, if I am going to install a framework / runtime on all my clients, why the hell would I want to write all my apps for a Javascript based client with no existing libraries than in a mature runtime like JRE or .NET that has thousands of 3rd party libraries available, lets me take full advantage of the machine's capabilities, and supports a decent programming language? Somewhere along the line, Macromedia forgot that the reason Flash succeeded was not because it was such a kick-ass technology that does things no other technology can do, but because it delivered in a 30 second install with next to zero impact.
So, is Apollo a cool idea? Yes. Does it have some major issues that will put it in the same recycle bin as Central? Possibly. At least they don't have the restrictive Central licensing, but they are once again trying to provide us with a poor excuse for a desktop runtime that provides little benefit for all the hassle. I'm starting to agree with Marc here. They should just play with existing tools and stop wasting money trying to reinvent the wheel.