The WebKit Open Source Project provides a JavaScript test Suite dubbed SunSpider. According to the description on the SunSpider home page, “this benchmark tests the core JavaScript language only, not the DOM or other browser APIs. It is designed to compare different versions of the same browser, and different browsers to each other.” We at Medialets have found it to be one of the best attempts to measure real world JavaScript performance in a balanced and statistically sound way.
Medialets ran the SunSpider test suite in the following environments:
Safari 4.0.1 on a 2.0 GHz Intel Core 2 Duo White MacBook.
The MacBook results were used as a baseline for relative comparisons.
Mobile Safari on the iPhone 3G with iPhone OS v2.2.1
Mobile Safari on the iPhone 3G with iPhone OS v3.0
Mobile Safari on the iPhone 3GS with iPhone OS v3.0
The “Browser” app on the T-Mobile G1 with Android OS v1.5 (Cupcake)
The “Web” app on the Palm Pre with Web OS v1.0.2
Each device was fully restored and rebooted immediately before running the test suite. Every attempt was made to assure that no atypical background tasks were executing while the tests were running. The SunSpider tests automatically run five times sequentially and the mean average from all five tests are reported. Network speed and latency have no effect on the results of the test.
We all know to beware of benchmarks, but it does show off how powerful these devices are getting!
Appcelerator has announced a Titanium beta that adds to their desktop vision with new APIs and developer tool but also allows you to create mobile applications using HTML/CSS/JavaScript (and in fact Ruby, Python, …) that run on iPhone and Android.
You can take a look at what it takes to develop for desktop and mobile in this screencast from Kevin Whinnery:
I instantly thought of PhoneGap and asked Jeff Haynie about the differences. It appears that Titanium Mobile handles the device mapping in a different way. Instead of focusing just on device APIs and giving developers access to those APIs via JavaScript, it goes a little further. The Titanium tool will compile down your code and you will see that native widgets will be used in places. As the mobile version moves forward, they expect to do more of that kind of work, so instead of a WebView + APIs, you have native where you can, and WebView where you can’t.
From watching the Titanium Developer tool at work, you can quickly see that it is nicely taking care of you, the Web developer, as you go through the process of dealing with phones. Dealing with the SDKs from Apple and Android can be messy business and the tool really tries to make it much more seamless. The same can be said for the packaging and deployment process.
It is great to see yet another product that comes along to help Web developers take their existing skills and have them work on mobile platforms. Personally, the thought of going to Objective-C land isn’t a pleasant one for me, so this and PhoneGap make total sense. If other platforms such as Android and hopefully webOS catch on, then it will make even more sense to go cross platform. Who better to write code on difference devices that Web devs since we have to deal with it every day ;)
Need a visual builder? You could take the upcoming 280 Atlas, use Interface Builder or Atlas itself, and deploy your app to the phone. Great times for the Web platform.
Of course we didn’t get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we’ve skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we’ve learned so that others can take advantage of HTML5 as well.
Great to see the mobile Web continue to merge as just One Web, and I look forward to hearing from the trenches on issues the team ran into, so we can learn from them.
Close to 5pm, and you started to see a huge snaky line making its way to the keynote area where Palm was about to have a reception and short announcement. People were jazzed to hear more about the Pre, and Michael Abbott was there to open up access to developers:
Today, Palm expanded the Mojo SDK program for webOS, announcing that a broad group of developers will be provided with the software development kit to create applications for the Palm Pre phone (as well as other future devices running webOS).
Speaking at the Web 2.0 Expo, Palm’s senior vice president of Applications Software and Services Michael Abbott also highlighted some of the most exciting aspects of webOS — including a new branded service that lets developers create apps that push live content across the Internet — and invited the audience to apply for the early access program at the Palm Developer Network website.
The power of webOS lets developers rethink how they develop for mobile devices — and creates opportunities for new kinds of apps. Abbott highlighted several key features of webOS that open up new avenues for the creative ingenuity of the developer community:
a cards metaphor that simplifies multi-tasking
Palm Synergy to unify information from sources like Google, Facebook, and Exchange
a user-friendly approach to notifications that ensures the user is up to date without distracting them from the task at hand.
An often-overlooked aspect of webOS is that Web applications run natively on the phone. They don’t depend on access to a server, and can run even when there is no access to the Internet. But the full power of webOS is unleashed when the device works together with “the cloud” – the combination of all of the Web sites and services that a user interacts with.
David Kaneda has created jQTouch a "jQuery plugin with native animations, auto list navigation, and default application styles for Mobile WebKit browsers like iPhone, G1, and Pre."
New HTML structure to ease toolbar button variations and improve animations.
Various performance improvements
Added minified code
Started a custom theme, which will be offered alongside the standard Apple theme
Created a new Home Screen icon
Removed some iPhone-dependent code
David also answered some questions for us:
How does it compare to iUI?
It is similar in the way it can load views via built-in HTML or dynamic GET/POST requests, but it uses hardware-accelerated animations, and also includes transitions like slide up and 3D page flip. It also includes code for image preloading, a custom theme, and a much easier setup function which eliminates the need to write META tags for the app icon, viewport settings, etc.
What kind of extended functionality are you looking into
Ultimately, I plan on testing extensively on the G1 and, eventually, the Palm Pre. Other plans include a more robust theming system, and various callback methods to make extending jQTouch even easier.
With PhoneGap, would it just be a script that you can get built in?
I am currently in talks with the PhoneGap crew, and we are planning on including it stock with the kit. We're currently unsure if the script should be ported to XUI or remain based on jQuery.
Peter-Paul Koch (AKA ppk) has truly provided a tremendous service to the development community over the years building one of the most important resources in determining compatibility of web standards among the major browsers, the Compatibility Master Table. This resource is referenced often by developers and publications and is exhaustively granular in its data.
With his focus shifting to the mobile space, PPK continues to serve the community by providing similar data for mobile browsers.
Right now I’m doing basic tests while also figuring out what “basic tests” means in the mobile space. It turns out that I even have to test basic CSS stuff like font-style. Many of my already-existing tests use such typographic CSS to denote whether a browser supports a certain selector or effect; but if a mobile phone doesn’t support the CSS in the first place, my tests will misfire horribly.
His Mobile Compatibility Tables, while still very new and a work in progress, will surely be of tremendous help to the many developers who are now looking to mobile web development as the next big wave.
He's already collected a large amount of information on the following mobile browsers:
Opera Mobile
Opera Mini
WebKit
NetFront
Blackberry
and for the following browser capabilities:
Events including key & click
Basic DOM & Ajax support
Basic font CSS
CSS Media
Focus, blur, scroll
Screen orientation support
Font sizes
If you're a mobile web application developer, I urge you to go visit this great resource and even offer PPK feedback to expand his data.
Ben and I have been promoting PhoneGap as a great solution for Web developers to create applications with the technology they know and love, without having to jump off of the cliff to other proprietary worlds. PhoneGap is still new, but gets more impressive every day.
The team is getting more interested, and put together a video on What is PhoneGap?.
You can see a budding list of existing applications that use PhoneGap already and note that PhoneGap isn't just about the iPhone anymore.... Android and RIM are in the house.
Fancy writting a Web application on the architecture above? Since announcing the Palm Pre we have seen a lot of people wondering about the goods under the hood. We now have an online reference to check out.
Once you get past the high level stuff, you get to the meat:
Palm's user experience architecture provides for a greater degree of application scope than is normally considered in a web application. To support this and specific functions of the framework, Palm has introduced a structure for webOS applications built around stages and scenes.
A stage is a declarative HTML structure similar to a conventional HTML window or browser tab. Palm webOS applications can have one or more stages, but typically the primary stage will correspond to the application's card. Other stages might include a dashboard, or other cards associated with different activities within the application. You should refer back to the earlier example of the Email application where the main card held the Email inbox and another card held a draft Email. Each email card is a separate stage, but part of the same application.
Scenes are mutually exclusive views of the application within a Stage. Most applications will provide a number of different kinds of scenes within the same stage, but some very simple applications (such as Calculator) will have just a single scene. An application must have at least one scene, supported by a controller, a JavaScript object referred to as a scene assistant, and a scene view, a segment of HTML representing the layout of the scene.
Palm webOS applications are required to use directory and file structure conventions to enable the framework to run the applications without complex configuration files. At the top level the application must have an appinfo.json object, providing the framework with the essential information needed to install and load the app. In addition, all applications will have an index.html file, an icon.png for application's Launcher icon, and an app folder, which provides a directory structure for assistants and views.
By convention, if the app has images, other javascript or application-specific CSS, then these should be contained in folders named images, javascripts, and stylesheets respectively. This is not required but makes it simpler to understand the application's structure.
Launching a webOS application starts with loading the index.html file and any referenced stylesheets and javascript files, as would be done with any web application or web page. However, the framework intervenes after the loading operations and invokes the stage and scene assistants to perform the application's setup functions and to activate the first scene. From this point, the application would be driven either by user actions or dynamic data.
The HTML 5 specification provides a new mechanism for client-side data storage: JavaScript database support. HTML 5 is currently in development by the Web Hypertext Application Technology Working Group (WHATWG).
JavaScript database support is available in Safari 3.1 and later, and in iPhone OS 2.0 and later.
You should read this documentation if you are a web developer who wants to store data locally on a user’s computer in amounts beyond what can reasonably be stored in an HTTP cookie.
Michael Nordman of Google asked "Is this stuff built into shipping Safari or iPhone browsers yet?"
David Kilzer replied "This feature shipped with iPhone OS 2.1. When you use "Add to Home Screen" from the "+" button on Safari for iPhone, a web application with a manifest defined (per the HTML5 spec) will be saved with any cached resources. Note that the manifest file *must* be served with the correct MIME type for this to work.
There is no shipping version of Safari for Mac OS X or Windows that supports this feature yet."
He ended up with webkitMobile.dojo.js which is 26-29% smaller (depending on compression).
The big size wins (in decreasing order) were:
Moving to a QSA-only version of dojo.query()
Being able to use intrinsics for dojo.forEach, etc.
Dropping IE and FF-specific rendering, XHR, and style hacks
Using a common closure wrapper for the entire core
And there’s even more fruit on the vine. I think without too much more work I’ll be able to drop the current animation system in favor of pure CSS animations and can significantly simplify the XHR code which doesn’t do the straightforward thing to avoid terrible memory leaks on IE and very old versions of FF.
It is great to see the mobile Web kick up so strong recently. I am a little torn on WebKit becoming all powerful king ("which WebKit?") even though it is open source (and has many vendors in there to keep Apple honest), so it will be good to see if there is any real competition in the future (Disclosure: I work for Mozilla which is working on a mobile browser, Fennec).
Brian Leroux and some of the PhoneGap team have created XUI, a JavaScript library aimed at mobile development. Why?
We hear your words. Why another JavaScript framework?! When development of PhoneGap was under way we noticed slow load times for modern JavaScript frameworks (such as Prototype, MooTools, YUI, Ext and (yes) even jQuery. A big reason why these libraries are so big is because is mostly they contain a great deal of cross browser compatability code. The mobile space has less browser implementations (so far) and different needs. Thus XUI.
XUI strives to be a framework for first class mobile device browsers such as WebKit, Fennec and Opera with future support under consideration for IE Mobile and BlackBerry.
XUI contains code for easy DOM manipulation, CSS, eventing, and JSON.
There is also word of xui-app: a nifty mvc microframework for mobile apps the PhoneGap crew is working on.
The mobile Web is getting increasingly interesting. Nokia has put another hat in the ring with their new Nokia Web Runtime that embeds WebKit into S60 phones:
Widgets — you're familiar with them from the desktop. Small, focused web applications that are easy to install and use. Perfect for the small screen. Nokia has extended the S60 browser engine to behave as a runtime platform in its own right.
Web Runtime (WRT) is available in devices based on S60 3rd Edition, Feature Pack 2 and later. It's also available as a software update for selected S60 3rd Edition, Feature Pack 1 devices. WRT is a simple mobile web technology that can really work for you.
Aptana is expanding its support for mobile web applications with today’s beta release of the Nokia WRT (Web Runtime) plug-in for Aptana Studio. The Aptana iPhone Web development plug-in has been one of the most popular for Aptana Studio – and now there’s support for Nokia phones too. What’s cool (other than all the great development tools in Aptana Studio now available) is that Nokia has embedded WebKit for NATIVE phone apps. That’s right -- You use your Ajax, JavaScript, HTML and CSS skills to create NATIVE apps – and in so doing get better and more optimized performance along with more capabilities that come from running natively.
The Nokia WRT is based on WebKit. So there's lots of sound, open web technology there as a foundation upon which to build. Despite the "duh factor" of this, it's kind of revolutionary since mobile devices historically have required specialized runtimes, libraries and tools resulting in a highly fractious eco-system for mobile app development. WebKit's adoption by many leading mobile device manufacturers, including Apple for its iPhone, lays a great foundation at last for a mobile standard: JavaScript, HTML, and CSS -- Duh!
Jeffrey Sharkey has created OilCan a thin wrapper on top of the WebKit shipping on Android that allows you to install userscripts that allow you to access to Android "Intents".
Intents are very nice abstractions that allow you to access large components and reuse them in different ways. Romain Guy has a nice post on them.
OilCan lets you customize any website by inserting JavaScript to change the website and help it reach into the Android world using intents.
OilCan inserts some powerful buttons into normal websites, and that power comes from Android intents. We didn't write a barcode scanner or the radar app into OilCan, but using intents we can launch those apps with parameters. We can request the Barcode Scanner app to scan something and return the code to us, or launch the Radar app with a specific lat/lon.
Userscripts can do other cool stuff, like hide the navigation columns in Wikipedia to make it easier to view on small screens. This is a proof-of-concept for now, and will probably turn into a binary plugin for the default Browser in the future.
A nice piece from an example shows the intent call out:
, Performance
