But the more I read about their toolkit (Objective-J), the more unsettled I felt. It’s the same feeling I get when I see tools like Flex. These are some seriously complicated development environments, meant to abstract away to the fundamental building blocks of the web.

When 280 North released their Objective-J toolkit a few days ago, called Cappuccino, I poured through their documentation and demos to get my head around what they had built. And it’s very impressive. But as a jQuery addict, I didn’t like their dismissal of it as at tool for making small adjustments to a web page. I feel that you can build a full-fledged web application in jQuery just as simply — or simpler — by embracing HTML/CSS as a layout engine, and JavaScript as a scripting language.

So I tackled re-implementing their FlickDemo application (several hundred lines of Objective-J) using jQuery and jQuery UI. It took about 3 hours to build, and ended up being about 45 lines of code (plus the frameworks, of course), and just under 200 lines of CSS declarations.

What I didn’t do: I didn’t bother hacking the CSS to work in Internet Explorer. It’s not that it couldn’t be done — jQuery supports it just fine — I’m just lazy. So you’ll need a modern WebKit or Gecko browser to see the demo. I also didn’t implement the drop shadows that Cappuccino uses on their images.

Also, the jQuery version doesn’t take over all you keyboard shortcuts, so you can still navigate around in your browser.

Original Cappuccino version

My jQuery version

Download the source here: flickrDemo-jQuery.zip

Update: Due to popular demand, I’ve changed the behavior of the slider so the image size updates in realtime. Total change: one word.

Update 2: Alexander Simmerl was nice enough to provide an upgrade to the image loading, bulking up the code by a few lines but greatly improving the load animation. In the comments, dak contributed a 2-line CSS fix for the inline-block layout problems in FF2 and IE7, which I’ve also merged.

I think this is as far as I’ll take the demo. Ultimately, it’s not that compelling of an application (but it does make a good demo). To respond to some of the criticism I’ve read, my point was not to argue that jQuery was a drop-in replacement for Cappuccino. Clearly there’s a ton of nuances to the Cappuccino runtime that would need to be carefully reimplemented if we wanted a 100% identical demo. My point is that it’s quite simple to do web application development in jQuery, and something as heavy as Cappuccino is not the only option (and in many cases, probably not the best option). I see Cappuccino as a kind of AIR-in-reverse (native apps that run in a web browser!) and possibly an interesting technology path for coders that are already familiar with Cocoa but don’t have experience with the nuances of direct web development. One thing I’m sure of is HTML/CSS/JavaScript are not going anywhere… they may be complimented by frameworks like Cappuccino, but the core will remain.

In essence, what the IE team wants is web developers to “opt-in” to new renderer features using a custom meta tag or HTTP header. Pages will then be frozen at that renderer, ensuring they remain consistently rendered from now until the end of time (or at least, until Microsoft stops supporting that rendering model or breaks it accidentally). We went down this path once before, using the Doctype declaration to differentiate between “quirks” mode and “standards” mode. IE7 is, unfortunately, also quirky in standards mode, so apparently we need a new “super-standards” mode for the next version (and so forth).

From the perspective of the IE team, this solution makes sense. They can effectively freeze HTML rendering at today’s IE7 baseline and proceed with enhanced features in later releases. Maybe I’m looking at this the wrong way, but I never considered HTML content to perfect screenshots that should remain immutable. Well designed HTML is flexible — it can be rendered by a desktop browser, or stripped to it’s barest essentials by a mobile parser. (Note that I’m drawing a clear line between web content and web applications — web apps are by their very nature a snapshot of the present). The IE team should be encouraged to fix their mistakes at the expense of breaking badly developed content, just as users should be encouraged to update their rendering engines as frequently as possible. Notice that the IE team is the only browser developer that seems to have this problem.

As a web designer and developer, apparently I’m supposed to help Microsoft maintain their dominance in the web browser market by tagging my pages for their benefit. But what do I get out of the bargain?

Let’s assume for a moment that IE8 has been released with a spectacular new rendering engine, on par with Firefox or Safari or Opera in terms of “write once, render anywhere”. Let’s also assume I have a pretty good idea of what my target audience’s browser technology will be: 50% “IE8 compatible” (meaning IE8/FF/Safari etc), 30% IE7, and 20% IE6. None of these markets are small enough to ignore or deliver reduced functionality to. I would still need to optimize for three different version of Internet Explorer. IE7 doesn’t go away, and neither does IE6. I can’t just freeze the renderer at the IE7 level — I want to use all those fancy new features in IE8 that have been available in alternate browsers for years now.

So where does this leave me, the web developer? Still coding for multiple releases of IE. In fact, the problem gets worse as Microsoft accelerates it’s release schedule — people simply don’t update quickly enough. IE6 is still estimated to have a 35% market share — over a year after IE7’s release. How do we solve the problem of supporting multiple renderers?

Simple. We deprecate IE6. We no longer support it. And we provide a clear, direct upgrade path that involves little to no effort on the part of the user. Maybe this involves just swapping out the rendering engine, leaving the browser’s UI intact (to minimize the impact on the user’s day-to-day experience interacting with their browser). I’m certain part of the resistance to upgrading to IE7 today is the horrendous overhaul to the UI that occurred between versions.

Apple doesn’t seem to have any problems keeping it’s Safari users (or iTunes users) on the latest release through an effective software update system. Firefox also has a fairly effective system, although it could be improved. But web developers don’t complain about supporting multiple, ancient versions of those browsers because the system, and the users, are proactive about updates.

We need to get over the idea of preserving out-of-date content as a snapshot of the day it was released. We need to stop worrying about breaking 5-year-old browsers and just get on with it.

Update: After further reflection, there is another (possibly better) approach Microsoft could take. They could include the IE6 and IE7 rendering engines in each new update, and provide a user-accessible toggle for enabling it on specific sites. Using the info bar, much in the same way they do when blocking popups or enabling ActiveX downloads, a message could be displayed along the lines of “This page may not be compatible with the Internet Explorer 8 display system. Would you like to switch to Internet Explorer 6 compatibility mode for this site?” IE would remember the setting and use it on subsequent visits. The compatibility message could be triggered by detecting known CSS hacks, or even based on the Last-Modified date of the document.

It turns out there is a free alternative to Spanning Sync called GCALDaemon, which is a bit more work to get running but a decent alternative if you don’t want to pay for Spanning Sync.

GCALDaemon is, unfortunately, a Java application, which makes me a bit uncomfortable running it all the time on my Mac. My experience with doing development using Eclipse and Tomcat is that my machine would need to be rebooted almost exactly every 7 days or it would start behaving erratically. I have no idea if this is related to the Java runtime or not, but it was still less than ideal having GCALDaemon run in the background 24/7.

Luckily, for my purposes — since I wasn’t really concerned with keeping Google Calendar and iCal perfectly in sync — I could launch GCALDaemon in “standalone” mode using Proximity and sync all my devices at the same time. To use this setup instead of Spanning Sync, do the following:

1. Install GCALDaemon according to the instructions on their site. Stop without setting it up as a service.
2. Setup GCALDaemon to sync your iCal calendars with Google Calendar by following the instructions. There is a simpler method for determining which corestorage.ics file is mapped to your local calendars: next to it you will find an “info.plist” file which contains the name of the calendar.
3. GCALDaemon has a feature which will run some AppleScript after each update. This is necessary if you keep iCal running all the time, as iCal does not check for changes to the ics file except on load. The default installation contains some code for switching the calendar view, but on my machine this failed to reload the calendars. The only solution I could make work was restarting iCal. Change the contents of GCALDaemon/bin/reload-calendar.scpt to:
   tell application "iCal" save quit delay 2 end tell tell application "iCal" to activate
   and ensure that you have turned on the Reload Calendar script option in the configuration editor.
4. Now you can execute the full synchronization from the Entering Proximity script by adding the following line:
   do shell script "/usr/local/sbin/GCALDaemon/bin/sync-now.sh"
   

The synchronization process will now take a few moments longer, but it’s worthwhile if you’re uncomfortable running a GCALDaemon as a service. It also solves the issue of refreshing iCal’s calendars after each update.

In any case, I’ve been facing an increased sense of panic every time I try to book an appointment. What if I have a conflict? Krista keeps her entire life in the pages of a daily calendar, so I’ve attempted to follow suit, digital style.

This isn’t the first time I’ve tried, but every previous attempt failed for one reason or another:

• Google Calendar: I love having my schedule available from pretty much any machine with an internet connection, but launching it seems horribly slow and the whole experience is oddly divorced from everything else on my Mac. I could write a whole other post (and maybe I will) about my migration from Windows native apps to Web Applications, and back to native Mac apps. I think it says a lot about how good OS X’s integrated tools are, though, that I’ve taken that path.
• iCal: really, a beautiful calendar, but I missed the “everywhere-ness” of Google Calendar. I can do a one-way sync from Google to iCal using iCal’s Subscriptions, but anything I add to my local calendar won’t get reflected back. This is critical, as I’d like to be able to check the calendar from any other machine, including my cell.
• Sony Ericsson k790’s built-in Calendar application: a surprisingly full-featured little calendar tool. For my process to work, I need to be able to quickly add events on the go. iSync takes care of synchronizing iCal and the k790, but I’m too forgetful (and lazy) to sync it myself whenever changes are made.

1. Spanning Sync – the only part of the system that will cost extra money, Spanning Sync works perfectly for two-way synchronization between iCal and Google Calendar.
2. Proximity – a nice little free application that monitors the presence of a bluetooth enabled device (in most cases, a phone) and runs AppleScripts based on it’s appearance and disappearance.

For my purposes, I was mostly interested in having iSync silently keep my phone updated, as well as keeping Address Book attached to the device so I could respond to SMS messages directly on the Mac.

After installing Proximity, I created an Entering Proximity script to manage iSync. I was primarily concerned with keeping the iSync process invisible, which was achieved by adding some application exit status detection to Jesse’s script. Here’s what I came up with:

tell application "Address Book"
if not unsaved then
try
quit
delay 1
end try
end if
end tell
-- Reconnect to the Address Book
do shell script "defaults write com.apple.AddressBook
 ABCheckForPhoneNextTime -boolean true"
try
tell application "Address Book"
launch
end tell


tell application "System Events"
set the visible of process "Address Book" to no
end tell

end try

-- Synchronize the Device
tell application "iSync"
launch
tell application "System Events" to set visible of process
 "iSync" to false
if last sync is less than ((current date) - 900) then
synchronize

repeat while (syncing is true)
delay 5
end repeat
set syncStatus to sync status

if syncStatus = 2 then
-- Success
quit
else
if syncStatus = 3 then
set syncStatus to "completed with warnings"
else if syncStatus = 4 then
set syncStatus to "completed with errors"
else if syncStatus = 5 then
set syncStatus to "last sync cancelled"
else if syncStatus = 6 then
set syncStatus to "last sync failed to complete"
else if syncStatus = 7 then
set syncStatus to "never synced"
end if
display dialog "syncStatus: " & syncStatus
syncStatus
end if
end if
end tell

I didn’t bother with an Exiting Proximity script, although there are plenty of entertaining tasks that you could automate in this fashion. I also lowered to update frequency on Proximity to 60 seconds.

The beauty of this system is I can now

• add an event using iCal, Google Calendar, or directly on my phone and have it automagically appear across all devices.
• receive reminders, no matter my location.
• share my calendars with friends through Google Calendar.

It was during a lazy Friday afternoon of Revolving DJ and beer than an idea was sparked in my head, regarding the iPhone and the lack of 3rd party native applications. It doesn’t take too many songs before you long for a method to effortlessly transfer tracks directly from one iPod to the next. A few moments later, someone will inevitably realize “hmmm, the Zune could actually do that“. Unfortunately, it’s implementation was so hopelessly crippled by the marketdroids and RIAA-fearing managers at Microsoft that the device was essentially stillborn.

Apple has also built an iPod with WiFi — it’s called the iPhone, and while most people are rightfully focusing on the new features of the device (phone, web browser, email client), it’s also considered one of the best iPods ever built (ignoring the anemic storage for now). The device runs a version of OS X, meaning the only preventing a mobile p2p application that can share music with friends or strangers is a smart programmer and a way to load the application onto the iPhone — conveniently left out. The Zune crippled it’s WiFi in firmware, but an open SDK on the iPhone would mean anyone could easily install such an app on their phone. Even better, if you didn’t already have the p2p app, you could easily jump on the web and download it the moment you needed it. It’s the viral-social, the dream application for music-heads everywhere, and Apple can’t stop it without throwing the baby out with the bathwater, which is pretty much what they did by not shipping an SDK for the phone.