Interesting factoid about jQuery being adopted by .NET and Web Runtime. I agree re: JVM being used for system components. MS CLR: not sure how long can Microsoft continue supporting .NET CF on mobile.. it would be interesting to see stats on .NET vs native apps that have been written for Windows Mobile, but my guess would be that most developers go for native.

Andreas

In fact, about a year ago in an internal report I predicted the bundling of something like JScript or Prototype on the phone – then in September this came along: http://jquery.com/blog/2008/09/28/jquery-microsoft-nokia/

I agree that JavaScript will be mainly deployed as a component of WebKit and FL; but that other runtimes will be used for system components (not apps). This may end up as a couple of common runtimes (e.g. JVM or MS CLR) with various different language bindings.

JavaScript engine fragmentation is a new problem and I wonder how Apple will react. The Google fork is unsettling the equilibrium of power around WebKit code development.

As for Javascript winning, I don’t see Javascript deployed as a standalone engine far beyond WebKit and Flash Lite. So I would consider FL and WebKit as the main two contenders which encompass a Javascript interpreter. So I agree that Javascript will be most widely deployed, but not as a standalone runtime, rather as a component of WebKit and FL.

- Andreas

- Andreas

However I believe that actually AJAX is the winner for fast delivery of services/apps (and thus fast-changing apps), however for middleware/servers/daemons that are not written in C/C++, it’s more subtle. I was impressed by Sean Moss-Pultz OpenMoko replacing C/C++ with Python.

http://www.iconocast.com/EB000000000000027/S5/News3.htm

Technically I would define a runtime as an application environment that manages the application lifecycle, communication and memory use (in the traditional sense of a Java VM or Microsoft COM). In this sense Qt, Flash Lite, Java, Python and Silverlight fit well within the runtime category. Lua is on the borderline of this definition because it is a blueprint for a runtime implementation. GTK+ is a set of graphical libraries and primitives, so it doesn’t manage application lifecycle as far as I know. Moblin is a complete stack including OpenedHand graphics libraries and its own application framework – so in this sense Moblin is a superset of an application runtime.

Andreas

Thanks for the detailed post with tables and graphics. I always enjoy reading them.

I was confused by your definition of “runtime”. I wouldn’t have put Qt, Webkit and Python in the same category. Would you also include GTK+ and Moblin your runtime category? Or are they separate?

Thanks,

Stormy

Following Nokia’s announcement of Qt on S60 (and across the Nokia device portfolio) I have up’ed our previous estimate of Qt in-ROM embeds for 2009 to 50M handsets.

You make a fair point on the Java ME and Flash Lite handicaps – and WebKit is perhaps the revelation of 2008, evolving from a new kid on the block to stardom, thanks to Nokia’s commitment for deploying WebKit on S40 and Symbian Foundation code.

Andreas

I think your estimate for devices addressable by Qt is way too low. It should be possible to target all devices from S60 3rd Edition onwards with Qt (currently it’s officially 3rd FP1 but there’s no technical reason for this). Also, Qt is already available on Windows Mobile and embedded Linux platforms.

Since Qt is native code it isn’t really a “runtime” and the necessary DLLs can simply be packaged with your application.

Generally I’d agree with David, a runtime has “won” when it gets included in ROM, which Qt (and I think probably PyS60) will eventually. Other than that there will be no outright winner since they’ll all be used for different purposes. So in essence the “who will win” question is pretty pointless.

In terms of winning over developer mind share, the ones with the handicap are Java ME (previous bad fragmentation experiences) and Flash Lite (high cost of tools). The web runtime (although I’m no fan) has a massive head start since almost anyone can code JavaScript.

Mark