Mobile application development middleware?

I am the author of an ExtJS based cluster management web-application (Scyld IMF at Penguin Computing) that allows controlling a high performance compute cluster from any web-browser, be it from your desktop or from a mobile device. This works fairly well already even without writing a special view for the mobile devices as current smartphones (iphone, android) come essentially with a full blown javascript capable web-browsers and lots of processing power. However performance still could be better by having a native app that uses the same data sources / api as the full blown web-application (javascript app running on the browser being the client to the webservice-api on the server side), but implementing the view natively.

After hacking up a proof of concept for the iphone (thanks John for your awesome iphone JSON flickr tutorial and xcode example for download) and thinking of how to do the same for android without duplicating effort, I realized that it would be nice to be able to have some kind of middleware that allows me to create and populate native gui components without code duplication.

One such middleware is phonegap which requires you to write your application in javascript and html, and allows accessing phone specific features through javascript calling the middleware. It then is bundled as a native application that can be submitted to the app store for purchase and can run completely offline once downloaded, unless the programmer chooses to access remote resources. Their initial focus seems to have been allowing access to smartphone specific features like the address book, vibrate and sound, gps location and such, but there also is code in there to use native gui components as well.

I have two problems with the approach:

1. development of javascript – while palm pre developers might tout this as an advantage, I find javascript development and debugging rather tedious and would prefer writing my code in java or objective-c and be able to run it through a full control debugger on my desktop before deploying it to the simulator. I know about and am actively using firebug, the javascript debugger for firefox, but a lot of the bugs I had to deal with were incredibly hard to hunt down and rather than the debugger it was the forums and interacting with developers on #extjs chat, as well as using jslint and manually analyzing code, that helped me figure out a root-cause, workaround or fix.

2. performance – developers report that the phonegap version of their app appears to consume more resources rather than less compared to a remotely hosted javascript app, accessed through the mobile devices web-browser. Apart from the overhead of having to parse javascript at runtime, developers sometimes need platform specific knowledge and implement different than for a web-application, i.e. iphone onclick events being much slower from the touchscreen than ontouch events.

The advantage on the other hand appears to be that it is relatively easy to add new mobile platforms to phonegap. So far they appear to have iphone, android, blackberry and some nokia platforms covered, with palm pre being on the horizon to be added beginning of next year.

And according to phonegaps website, there are already several real-world phonegap powered apps in the marketplaces of both the iphone and android.



Python based webapplications – WSGI – state of the web 2009

I read a really interesting article by Mike Orr on regarding WSGI / python web frameworks, dated June 2005 and wondered what had happened since then. Mike was so friendly to update me and would like to share what I learned:

I asked him: “I saw an older article of yours at linux that had an overview of web frameworks and WSGI.  If you where trying to find an update to that, where would you look first?”
The answer:

“There is no state-of-the-web overview that I know of, but a lot has
happened since I wrote that article.  Pretty much all new frameworks
are written for WSGI, and the older ones have been retrofitted.
(CherryPy can run as a WSGI server, Plone can run as an application,
parts of Zope have been extracted to independent Repoze components,
and Quixote has a WSGI gateway floating around somewhere.)  Django
works with WSGI sort of, and has been ported to Google App Engine via

I’m involved with Pylons, a framework that’s fully WSGI and modular to
the core, built on top of Paste, which is a low-level WSGI library.
TurboGears 2 is being built on top of Pylons.  This means that
different frameworks with different goals and target users can share
the same technology, and essentially makes every TG developer a Pylons
developer, doubling our developer base.

There’s a group of WSGI framework developers including
Pylons/TG/Repoze.BFG that is designing a new framework to potentially
supercede all of them, with plug-in personalities to reflect their
different application styles.  This is still at the idea stage but may
have some alpha code by the end of the year.  If so it could point the
way to the next generation of frameworks.

Another big issue is Python 3.  Over the next year frameworks will
either be ported to Python 3 or replaced by frameworks written for
Python 3.  (Though the Python 2 frameworks may continue in use for
several years.)  This has to be done on a dependency basis; e.g.,
Pylons can’t upgrade until all the components it depends on have

Reproduced with Mike Orr’s friendly permission.