On June 11th, 2007, Apple held the WWDC Keynote where they talked about three things. Leopard, Safari for Windows, and iPhone apps. I don’t need to replay this for you all, but I will anyway – the Leopard announcements were for the most part rehashes, and Safari for Windows was simply fantastic news, both for users of Safari and for web developers. But the iPhone announcement definitely left a sour taste in many mouths, mine included. Not so much the lack of a true iPhone SDK, as I wasn’t really anticipating seeing that at WWDC (as hopeful as I was), but rather the buildup of the announcement.

One of those sour sour mouths is that of Wil Shipley, one of the founders of Delicious Monster. In his latest blog post, he decrys the idea of using JavaScript and Safari as a platform for developing iPhone applications. Many of his reasons, such as a lack of Keychain and difficulty in monetization, are valid. However, there are a couple things that I, as both a Cocoa and web developer, disagree with. Furthermore, it’s completely plausible that the iPhone SDK that we all want soooo bad will be something that runs in the iPhone’s JavaScript interpreter, which I’ll talk more about in a bit.

First, he spends a good time railing against JavaScript. Specifically:

JavaScript was thrown together by some dudes a couple years ago to make web pages kind of, like, do shit and stuff. It’s famous for being slow, hard to read, hard to program, and incompatible across different platforms.

This statement is pretty wrong on all counts, both with respect to JavaScript as a language and a platform for writing the client-side logic of iPhone applications.

1. Hard to read/write. JavaScript isn’t any harder to read or write once you get used to it. In fact, it’s arguably easier to read, as JavaScript’s method calling syntax is significantly closer to C than Objective-C’s is. Someone with experience can read a function like:

Foo.prototype.bar = function(baz) {
	var foobar = document.getElementById("ohsnap");
	foobar.style.backgroundColor = "black";
};

…pretty easily. Compared to the same ObjC method:

-(void)bar:(id)baz{
   id foobar = [document getElementById:@"ohsnap"];
   [[foobar style] setBackgroundColor:@"black"];
}

There isn’t really a readability difference. Once you get used to the prototype syntax in JavaScript, it’s completely a non-issue – and I went from knowing zero JavaScript to doing full OO stuff in less than a weekend.

2. Slow execution. This is mostly a per-browser thing (IE, I’m looking at you). And while I agree that, in generic web development, this is an issue, you don’t have to worry about any of that. Because the iPhone doesn’t run Firefox, Opera, or IE. It runs Safari, and specifically JavaScriptCore (which is part of the WebKit framework on OS X that runs as a JavaScript interpreter), which is the fastest out of any of them for most tasks.

Furthermore, the speed of JavaScript interpreters across the board (with the exception of Internet Explorer, as it’s pretty obvious that Microsoft, with Windows and Office, feels very threatened by web applications) is bound to increase significantly in the next couple years. With the rise of more JavaScript-heavy web apps, the optimizations should definitely continue as they have for the past couple of years. Stuff like JIT compilation of code will help a lot.

And all that being said, JavaScriptCore is already pretty damn fast. You can pull off some decent framerates with even full-screen animations on the iPhone’s version of Safari. It’s no Core Animation, but it’s usable.

3. Incompatible across platforms. JavaScript as a language is pretty standardized. The DOM bindings in the browsers are where the incompatibilities lie. It’s fairly easy to spot where to workaround browser incompatibilities.

And besides, if you’re not concerned with generic web development and are only focused on writing iPhone apps, who cares?! You’ve got one target, Safari. Period. You don’t have to do the cryptic tests, like checking for the existence of document.all, to determine what browser you’re running on.

Apple’s got a decision to make: it can try to fix all the myriad problems with developers actually trying to deploy non-free applications using AJAX, OR it can say, “Look, this isn’t going to be easy, but we’re smarter than hell, and we’re going to make a secure, tight, mini-Cocoa for the iPhone — this is our chance to start fresh and do everything right. No NSCells, everything animated, resolution-independent from the start, no CF stacks under and NS stacks, always garbage-collected, all database-driven…”

And now we come to the crux of my argument. Who’s to say that this new mini-Cocoa couldn’t be written as a set of JavaScript calls embedded in the interpreter? JavaScript is already all garbage collected. Apple could embed technologies such as Core Animation right into JavaScriptCore, so creating an animation with CA could be as simple as a couple JavaScript functions, exposed to John Q. Developer in a similar fashion as the window and document objects.

Here’s the kicker – since these functions and properties would be compiled into the interpreter, they would be running as native, (I’m assuming) Cocoa code, so any possibility of slowdown would come from the JavaScript lexer and not from the actual JavaScript code. Therefore, your only speed limitation is that of JavaScriptCore’s ability to quickly process code.

If Apple’s claim of security threats presented by Cocoa/Obj-C apps is real, then it completely makes sense for them to want to sandbox it. That’s not stopping them, however, from implementing an entire application framework into iPhone’s JavaScriptCore. Throw in SQLite storage and the ability to save the app to the iPhone’s app launcher, and you’ve got yourself a pretty rock solid, secure application platform. And it wouldn’t surprise me if this is the compromise that Apple comes up with.

Granted, there are definitely speed issues to contend with; Apple’s only got a 620 MHz ARM processor in the iPhone, so it may just not be fast enough. But languages like Python have much faster interpreters, and may be investigated rather than JavaScript. But if Apple really needs the sandboxing that something like Safari requires in order to open up to native application code, well, I’ll take what I can get.

Also, someone please tell Shipley that you can’t do “programming in AJAX”. 🙂

I wrote some crafty Javascript to dump out the contents of arbitrary objects in the DOM in iPhone’s Safari. After the jump is a list of what the iPhone’s got for window, document, and document.body. If you need more, let me know.

Safari on iPhone has a number of things that are NOT implemented. Here’s a list of things that don’t seem to work (and I’ll be adding more as time goes on):

• window.onmousedown
• window.onclick
• window.onscroll

• overflow:hidden
• position:fixed
• position:static
• -webkit-column-*

If you find any more, please leave them in the comments and I’ll add them to the list.

When I started this site in 2003, I didn’t really know what to do with it. It started off as a faux-blog, during the blogging revolution, but all I was trying to do was carve out a little hole in the Web where I could put stuff. Since then, it’s expanded to be a full blog, along with many other nice things, like my project showcase, my photos, etc. Up until now, everything’s been great.

But it’s time to give this blog some focus. So, starting immediately, this blog will be focused on the one thing I know best – software. Developing software for OS X, developing web applications, using software, designing UI, critiquing other software, etc. Apple software, Microsoft software, open source software, all of it. It’s the one thing that I’ve spent the last ten years of my life figuring out.

So what does that mean in terms of content? Well, I’ll be working to post more about those topics and more. I’ll also be working to clean up the archives to support this focus (nothing will be disappearing, but I will be moving a lot of it around). Also, I’ll be adding some stuff to the design of the site to facilitate it (such as last 5 reviews, iusethis apps, etc.).

I’ve been kicking this decision around for awhile, as is evident by my last two posts (on iTunes and Coda). I’m confident, though, that this is the best decision. This blog has never really been anything more than just a general soapbox for me to get on when the time comes, as seen by some of my more political posts, so I’m glad to actually be able to turn this into something that becomes more of a resource rather than just a melting pot.

Today, Panic released their first new major app in a long time. Named Coda, it’s a tool for serious web developers who want an Xcode-like tool for web development. It integrates a lot of tools into one app, which is a very nice thing. Unfortunately for me, Coda’s still missing a lot of what I need to make extensive use out of it, or enough to justify the $80 price tag. I’d like to point out the big 5 that are missing from Coda’s arsenal that would really make the app significantly more useful.

If you don’t understand the title of this post, don’t bother reading any further. If you do, here’s a nice regular expression that will, given an Obj-C source file (.h or .m), give you all of the method signatures. It should work in every case that I can think of, but if you’re doing anything involving weird types or preprocessor macros it should work.

iTunes was released on January 9, 2001, at Macworld San Francisco. It was a huge deal at the time. Like, really huge. The big deal Mac MP3 players at the time, well, sucked as music jukeboxes. They were just that – MP3 players. that left the organization up to the end user. So when iTunes came out and replaced SoundJam MP, it was not only revolutionary, but extremely welcome to those of us with large music collections.

However, iTunes 1.0 was more than just a rebranded SoundJam. It had a completely reworked UI. Gone were the completely horrific looking skins that accompanied it. It was a music jukebox, just like it had been advertised. And Apple made it dead easy to rip, mix, and burn. Suffice it to say, iTunes 1.0 was a pretty amazing app. But Apple didn’t stop there.

Microsoft’s Zune. I swore to give the Zune an honest look when it actually began materializing on the Internet. I wouldn’t be a Mac zealot for the sake of being a Mac zealot – I’d actually give it a fair and honest run through. Well, as it came out a couple days ago, a couple of my friends decided to each get a Zune at launch. Naturally, I got my grubby hands on it, and gave it a ten minute run-through.

I’m not impressed, but I am a bit worried. More after the jump.

Introducing Tubular, the brand new YouTube client for OS X. Why would you want a YouTube client? Simple.

• It’s pretty. Tubular was designed to have a simple, elegant, and out-of-the-way user interface that still manages to look gorgeous. With icons designed by Cyril Seillet and Tom Stoelwinder, and a user interface designed with the collective wisdom of dozens of people, Tubular is simply beautiful.
• It’s familiar. Anyone who has used iTunes will feel right at home with Tubular’s look and feel. We’ve taken the UI ideas given to us by iTunes and ran with them, producing a user interface that is intuitive and usable.
• It’s useful. Features like one-click iPod conversion and drag-and-drop playback really give Tubular incredible utility to anyone who uses it.

We’ll be unveiling more about Tubular in the next couple weeks. You can go check out the blog at TubularApp.com, where I’ll be posting updates periodically.

I was looking for something that would display the currently playing iTunes song on my desktop. Nothing, however, seemed to really fit. No solution really looked like it belonged on a Mac’s desktop. So, I wrote one. And here it is.

Introducing DeskTunes.

DeskTunes is a very simple, very elegant way to see what’s playing in iTunes right now. It stays stuck to the bottom left corner of the Desktop, no matter what you do. It even stays put if you try and hide all of your windows with Exposé. You can also rate the currently playing song by clicking the star bar.

Simple. Elegant. Tiny. Out of the way. Beautiful.

The best part? It’s totally, completely, eternally free. Click here to download it.

Update (4/18/2008): DeskTunes keeps getting talked about all over the place, and now on TUAW and Lifehacker. I’m planning on releasing DeskTunes as open-source soon. It’ll be available on Google Code as soon as I get around to cleaning up the source code and making sure it works on Leopard. Thanks for checking it out!