iPhone 2.0: Safari hosts local apps; SQL on a smartphone!; go get Safari 3.1 now

I have a secret: I love JavaScript. It has an extremely simple C-like grammar--it has far more in common with C than Java--and is readable and compact. I can teach it to a child in an hour. With just a few days of messing around, a beginner can write powerful client and server applications in JavaScript, and the minimum required toolset is a browser and a text editor. To test changes to your code, you refresh its browser page.

I developed my appreciation for JavaScript by using it to create applications of surprising scale. In 1999, I wrote a book about creating Web applications, laying out in detail how one can do anything with JavaScript, CSS, DHTML, XML and SQL. The pinnacle of client-side JavaScript at the time was Microsoft's JScript, implemented in Internet Explorer. I took great care in my book to balance IE against Netscape, and to document the ways in which each browser adhered to and diverged from W3C standards. IE did better than most people would assume. It went on to become the basis of the ECMAScript standard. Then Microsoft all but pulled the plug on the language's internal development. The JScript editor and debugger vanished from Visual Studio. My book flopped, but worse than that, a simple language that had justifiable momentum, and even a job market built around it, dropped from sight except as a means to render dynamic HTML content and discern one browser from another.

JavaScript has reemerged as the J in AJAX, where it's assigned such common duties of manipulating in-memory data structures, loading plug-ins and performing explicit animation on user interface elements. It's good to see JavaScript back in action, but for years I've imagined what JavaScript might have become if it had been actively developed after Microsoft let it go. My crushing disappointment was that AJAX, not so advanced in light of history, didn't aim at the one target I felt JavaScript was destined for: Standalone browser-based applications.

Now we're back on track. Incremental developments in WebKit, the open source project on which Apple's Safari is based, have coalesced into the Safari browser for iPhone 2.0, due out in June, and Safari 3.1, which was just delivered for OS X. Apple and WebKit developers have invested an impressive amount of effort to implement vital portions of HTML 5, CSS 3 and SVG (scalable vector graphics) standards. HTML 5 provides a standard for embedded SQL statements into script code. SVG (scalable vector graphics) does what its name suggests, but also brings motion into places where only static bitmap graphics worked before. SQL (through SQLite) and SVG are linked into Safari, not plug-ins. CSS 3 sets up implicit and explicit animation, with both managed by the renderer.

In the transition from Safari 3.0 to Safari 3.1, WebKit coders and Apple somehow blew the doors off prior JavaScript performance. Apple created a JS benchmark, SunSpider (a click here will run it immediately; be aware that it takes some time), to prove its point. It measures the average time taken to complete a few cycles of complex JavaScript tasks. An 8-core, 3 GHz Xserve ran the SunSpider suite on Safari 3.0.4 in 6624.6 millisconds (6.62 seconds). A dual-core, 2.4 GHz Santa Rosa MacBook Pro running Safari 3.1 completed the SunSpider suite in 3211.8 milliseconds, or 3.21 seconds. The fact that SunSpider expresses its results in thousandths of a second portends sub-second results.

As for persistence, well, Apple decided that cookies and XML just wouldn't do. Since SQLite is already pervasive in iPhone OS, Apple wired it into Safari to give JavaScript coders the ability to manage data using real, grown-up SQL with transaction support. SQLite is strictly client-sized, but very powerful for a database that links entirely into your code (and it's open source). I wasn't that hot on SQLite in OS X's Core Data until I saw it in action in the iPhone SDK. Now that I see it it running on an embedded device, I see SQLite for the tight coolness it is.

There is another motivation to using SQLite as the persistence mechanism for iPhone Safari applications: It forces developers to give much more thought to their use of storage, which is a finite commodity on a phone or music player. It also slashes a lot of tree walking and in-memory XML out of your script code. But if you've just got to do the DOM, Apple did fold in two new native-ized DOM query methods to displace still more iterative scans.

Safari on iPhone 2.0 (and iPod touch 2.0) pushes the envelope in so many ways that Mac users will want it in desktop Safari and Dashboard. Okay, I'll speak for myself. I've been hollering for standalone browser-based applications, not those pseudo-apps that require a teeny HTTP server, for years. I'm on record saying that if Apple just did persistence in iPhone's Safari, I'd quit harping at them about a native SDK. I got what I wanted and then some, so now I can harp at you about what Apple poured into iPhone/iPod touch 2.0, Safari and the SDK.