There’s a new Flash Blog, which is concentrating on FlashMX developments. I’ve been doing some thinking, and while everyone (perhaps excepting some at Macromedia) seems to agree on the unsuitability of Flash as a primary content delivery mechanism on the web, most arguments being made against FlashMX have been made exactly against that strawman (see: Macromedia Reinvents the Web, Concerns on FlashMX Positioning).
Now Macromedia isn’t doing anything revolutionary. It’s been tried before (remember when Java was going to be on your desktop?), but they are in a unique position to make a play. 1) While I doubt it’s quite 98.3% penetration, it’s pretty damn close. 2) The display and logic engine are integrated. If it’s installed it’s going to work. 3) Flash has an IDE (such as it is, but compare it to say your DHTML options). 4) Flash would be the “Cold Fusion” of web application front-ends. Maybe not necessarily truly easier than your other options, but marketed that way to non-technical customers.
Now here are my concerns on issues directly related to FlashMX’s suitability for web application/services interfaces:
- FlashMX platform stability
- The current API is still weak (say compared to Java) – how forward/backward-compatible is the API? Will new revisions break existing versions?
- Lack of DOM – this is a major weakness, also related to the lack of tools (client or server side) for manipulating published SWFs
- Commitment from Macromedia as well as survivability issues – this may be the biggest concern
- 3rd party integration, including:
- Ability to inclue media beyond FlashMX capabilities (MP3, proprietary voice codec, proprietary video)
- Interaction with standard web page elements
- Dynamic generation of elements using 3rd party/OS tools
- Security Issues – this obviously is not a concern specific to FlashMX, however I’ve seen very little out there dealing with this. If FlashMX is to become a major platform, this and other fundamental issues like this needs to be addressed
I think it might be worth noting that I’m not necessarily against creating web applications/web services interfaces on Flash. It may be the most effective solution in some cases (certainly easier than creating cross-platform DHTML guis). I am however concerned about committing to unstable or dead-end technology, and whatever support/legacy issues that might introduce.
The other concern I have is with the development costs of FlashMX. The component library, while welcome, is rather bare at the moment. So one of the key questions of adoption is whether it’ll actually help in delivering a better product in a shorter or comparable development cycle.
Now, as far as alternatives, what’s out there? Well, one can use a DHTML API (DomAPI or DynAPI probably being the most viable. Or if you can commit to a single platform, XUL on Mozilla is an option. Java might work, but again, requires some installation, especially with XP coming without a VM… It’s a tough field out there.
I’ve mentioned it before, but I’ll bring it up again now that XWT has gone 1.0. It runs as an ActiveX control or Java Applet and is fairly simple to get up and running (XML layout, JavaScript behaviors, zipped archive, network connections via HTTP, SOAP/XML-RPC). This could be an interesting alternative for creating web applications. Of course, it’s pretty rudimentary at this point and I’m not sure if it’ll be able to handle the multiple media types, etc., or can get the developer mindshare necessary to make it a viable alternative.
Perhaps much of this will become somewhat moot if non-DOM compliant browsers (ahem, NS4) suddenly drop off the map and some of the better DHTML libraries start gaining momentum. I wouldn’t expect that soon (even w/ the Mozilla movements wrt AOL and MachV), but who knows? Stranger things have happened.