There are different levels and types of applications, and different needs. So of course you end up with developers who are more accustomed to application development at various levels. By recognizing some of these differences, we can potentially identify areas for new types of internet applications.
Obviously developers don’t fall into nice, tidy categories all of the time. However it is safe identify some general categories that developers may fall into. Sort of a general developer target audience. After all, developers are users too!
I’ll mention two, and note the “traditional” qualifier here:
- Traditional desktop application development
- Traditional web application development
Traditional Desktop Development
What typically is involved with this kind of application development? Much of the time, especially for any cross-platform development, there is a lot of low-level platform programming and configuration. It’s not uncommon to need to deal with compiler configurations, and platform optimizations and/or tweaks. And a lot of this work is done with some variant of the C programming language. Even when just targeting one operating system, there can be a good number of issues to deal with. Then you need to worry about installation and packaging schemes to get your app on your users’ machines.
The desktop developer has a lot of freedom to do a million different things, and customize and integrate his app to his heart’s (or budget’s) content.
Traditional Web Application Development
So what goes into this kind of application? There can be a good deal of RDBM design and server-side business logic development. But focusing on the client, the developer really just needs to worry about putting an interface together that works in a browser. Whether that’s traditional HTML, AJAX, or Flash/Flex. There are strong limitations of what can be done client-side in a browser. But then at the same time, things are more simple. The client-side web developer doesn’t have to worry about the myriad of different things that a desktop application developer does.
So what is the effect of this simple client-side target for web application development? A shared runtime, that for many purposes has sufficed project/product needs and development requirements. But as demands for better interaction with web apps increases, so does the need for more capabilites and freedom for client-side development.
Technologies like Flash/Flex and AJAX have been trying to make the most living inside the browser chrome. But what does it mean to break out of the browser? Does it mean catapulting ourselves to the other extreme of low-level desktop application development? I think there is a lot space before you go all the way to that side that can be utilized to great advantage.
Merging the two worlds
What would a merge of desktop/web application development look like? Something like Adobe Apollo falls right into this category. There is this thought that shared runtimes are the boogey-man. But think about it, there are successful internet-savvy shared runtimes that exist right now and are in great use. Flash Player, Firefox XUL (Add-Ons, etc.) are a couple of great examples. Do these not count? Just because they are developed and deployed a little differently? What if we could have the best of both worlds, could Add-On/web developers make use of a Firefox based shared “private” XULRunner? Would developers rebel at the fact that they couldn’t tweak and customize the runtime to their finicky heart’s content, or would they embrace the new capabilities? Do developers thrash under the limitations of Firefox’s Add-On development model? Are Flash Developers protesting not being able to tweak a custom version of the Flash Player for their own needs? No.
The determining factor for how successful a new hybrid runtime is, I believe, the deployment/install/updating experience. Part of this is getting the runtime on a user’s machine without it being an “event”. And if they get this runtime delivered to them utilizing existing software they know and trust, then that would be a huge win factor. Adobe is in a good position for this with the Flash Player. We have yet to see how or if they will take advantage the Flash Player in getting the 1.0 release of Apollo distributed. Firefox could be used to the same effect.
What about Firefox though? How does the whole upgrading/updating/versioning story work with add-ons? Pretty good I think. No doubt there could be improvements, but something exists and works.
So why not apply the same model to an application deployed via Firefox’s Extension Manager that makes use of a “private” shared XULRunner runtime. Allowing the developer to break free of the Firefox chrome and menu system? Something that doesn’t have to be directly related to browsing. Heck, focusing on this as a feature of Firefox 3, it could even be called something like a “Super Add-On” or something.
This wouldn’t be targeted at the Joosts and Songbirds of the world, but at folks with smaller resources, or ones wanting to take smaller steps at first, or who don’t need excessive customization. Someplace where developer’s can get their feet wet with XULRunner, build stuff, without a whole bunch of deployment or set-up headaches. They could graduate later if needed to their own embedded XULRunner possibly, after they have fleshed out an idea, or evaluated the viability of an approach.
There are interesting questions to answer with something like a Super Add-On of course. Like, could a user launch a Super Add-On outside of Firefox? How would that work? Some sort of alias/symlink/shortcut scheme?
So this was an idea that popped in my head, thinking and reading about all of the current discussions surrounding new types of internet applications, and in particular, discussion surrounding XULRunner in the Mozilla community. Would it be successful with developers and end-users? I don’t want to duplicate a runtime wholesale for every application I write. All I can say, is that it is something that would definitely increase my desire to create applications with XULRunner, and not just focusing on Apollo exclusively for IDA development.