funkatron.com

I’ve been developing with AIR for over a year now. It’s all been HTML/JavaScript apps, but the complexity of most of them has been pretty low. Spaz, the Twitter client I created, definitely isn’t simple, though – mostly because I’m kind of a crappy coder, but also because it just does a lot of stuff.

Lately I’ve been getting a little bummed about AIR, because I’m starting to bump into limitations of the platform more and more. What’s particularly frustrating is that some of these limitations are specific to HTML AIR app dev. So what follows is a couple of issues that have been particularly troublesome when developing Spaz and other HTML/JS AIR apps.

AIR gets greedy under OS X

Julien Viet, who has contributed significantly to Spaz, made a post recently about the base resources used by the AIR runtime. In it he finds that the basic “Hello World” sample app provided by Adobe used about 20MB of RAM, and hovered at about 2% CPU usage even when idling. I replicated these tests on my Macbook (2.2Ghz, 4GB) under OS X 10.5.4 and WinXP SP2, and had similar results:

I also created a Flex-based “Hello World” application to compare base usage if the Webkit renderer isn’t being used. Memory usage was slightly lower, but otherwise it was comparable to the HTML app.

The constant CPU usage seems to be specific to OS X: WinXP will jump back and forth between 0% and 2%. This is consistent with my observations of CPU usage in Spaz as well: in OS X, we get 10-15% CPU usage constantly, but under XP and Vista, CPU usage is 0% while idling. Initial memory usage is also about 30% higher with Spaz under OS X than it is under Windows. Something is goofy with AIR on OS X.

That aside, I don’t think the memory and CPU usage of AIR are surprising, considering the technology. AIR is a full Flash runtime, and HTML apps add a Webkit renderer on top of that. The memory and CPU usage is in line — or a bit lower — than most SSBs. Using traditional browser tech to build a desktop app is going to be a tradeoff in terms of memory and CPU usage, just like many other technologies that make development easier. But for one reason or another, the expectation seems to be that AIR is a lightweight technology, and it’s really not.

AIR HTML apps are leaky

What is particularly problematic is that there seem to be memory leaks within the Webkit engine as used in AIR – or at very least, it’s pretty easy to leak memory. Apps like Spaz run into this problem because it’s constantly pulling in large amounts of new data and images, and is often left running for hours or days on end.

Some of this is almost certainly because you can get away with that kind of thing on a web site, where users are unlikely to leave a single page open for days on end. Even if a web site does causes a big leakage, the browser almost always gets blamed. The libraries and tools available for HTML/JS devs, being browser-focused, typically don’t pay much attention to long-term performance issues.

Essential tools, like profilers and step debuggers, are non-existent

But memory leaks are a problem for most desktop app developers. That’s why memory profiling tools are common in desktop frameworks. And Adobe certainly understands this to be the case with Flex, as it’s FlexBuilder 3 IDE ships with memory and peformance profiling tools, as well as a full-featured debugger with breakpoints et al. That’s perfect if I was writing something in Flex, but it is completely useless for HTML/JavaScript AIR apps. I was able to get Spaz to run from within Flex Builder with a tiny bit of hackery, but the profiler gets no information about what’s going on within Webkit.

Other common choices for debugging web apps aren’t available either: Firebug is Mozilla-specifc, and the Drosera debugger and Web Inspector tools can’t hook into AIR’s Webkit instances. The information on Drosera does say:

In WebKit there is a WebScriptDebugServer which is started when WebKit starts and listens for a DCOM connection. Once a connection is made it will begin to interact with Drosera via Drosera’s ServerConnection class. WebScriptDebugServer informs Drosera about every line of JavaScript executed.

I would assume that WebScriptDebugServer exists inside AIR’s Webkit, but AFAIK this has not been utilized in any way. Adobe does have a nice AIR-specific tool called the AIR Introspector in the SDK, and it does offer some very useful functionality, but it too lacks step debugging and profiling capabilities.

That leaves us with good old console logging as our only option for debugging AIR HTML apps. That’s okay for simpler stuff, but tracking down execution bugs in more complex applications becomes extremely tedious. And console logging is basically useless for memory profiling, as there’s no insight into the underlying operations of Webkit.

I’m proud of the work I’ve done on Spaz, but as the application has grown in complexity, I’ve found the limitations of HTML app dev in AIR more and more problematic. Adobe has consistently stated that the HTML dev side of AIR is as important as the Flash/Flex side. To quote Mike Chambers:

Adobe AIR is as much about JavaScript, HTML, CSS, etc… as it is about Flash / Flex. #

If that truly is the case, Adobe needs to commit to providing a toolset for HTML/JS developers comparable to what Flex developers have. Until that’s changes, Mozilla’s XULRunner and Prism platforms are looking more and more appealing.

If there’s one thing I’ve learned in my years as a grown-up, it’s this: Don’t make assumptions. All too often, things I’ve thought were no-brainers turned out to be questionable at best, like:

• John Romero will make an awesome game on his own
• Sony and Microsoft have made Nintendo irrelevant
• Women will find my company tolerable

I often see techie types making assumptions based on their experience, like “program A is unusable” (because on his rather oddly set-up system, it crashed on install) or “no real programmers write in Ruby” (because he doesn’t know anyone personally who do) or “only a tiny fraction of Mac users browse with Firefox” (because it’s the default browser out of the box, and average users always use the default, right?).

It was this last assertion, and the accompanying statement “I don’t have to prove something so obvious” that inspired this article. I wouldn’t have been particularly surprised if Safari had a majority of the Mac browser market, but my personal experience had been that a fair number of non-techie Mac folks use Firefox. Beyond that, I wanted to get some real data, and not make assumptions. If you can’t provide some basis for your assertions, they’re not worth much. It’s a clear sign of a bad argument, and little gets me more worked up than weak logic.

The audience for a web site has a pretty significant impact on what browsers we see visitors using. Tech-oriented sites tend to have a higher percentage of users running alternate browsers like Firefox. You’ll get more Camino users on a Mac-oriented site, and Konqueror will show up more often on sites with content for Linux users. That means we have to at least take into account the content of the site when drawing conclusions from the numbers.

Here’s what I’ve found myself, and what others have shared with me, so far. Understandably, some folks shared their stats with me asked to remain anonymous, or that the site they come from not be revealed. I’ve described them as best I can. Also note that in some cases I received just info on Mac browsers, and others I had data for all browsers. I’ve calculated a ratio and “winner” at the end of each entry.

Is this data conclusive? Of course not. It’s a small sample of a handful of sites, and not particularly popular ones at that. But, it does seem to at least indicate that Firefox may be quite a bit more popular among Mac users than I – and certainly other people – thought.

If you’d like to contribute data, just drop me a line or leave a comment.

Funkatron.com

This site, obviously strongly tech-oriented, but also gets a decent amount of sport-oriented search engine traffic

Approx ratio: 1.5/1 Firefox

• Screenshot

Sorority web site

Non-tech focused, active site for members of sorority

Approx ratio: 1.1/1 Safari

EricaBaker.com

Personal blog, significant tech/mac content

Approx ratio: 1.3/1 Firefox

Abandoned non-tech subculture site

Very low, mostly search engine traffic

Approx ratio: 1/1

• Screenshot

Abandoned personal blog

Some tech/mac content

Approx ratio: 1.7/1 Firefox

New sports blog

Approx ratio: 1.1/1 Safari

Abandoned sports web site

Very low, mostly search engine traffic

Approx ratio: 2/1 Safari

• Screenshot

Low-traffic, non-tech site

Approx ratio: 3/1 Firefox

I’m not dead — I’m just busy. Spaz has had a few long-standing issues since the upgrade to AIR Beta 2, and this new version (0.3.0) fixes many of them. If you already have Spaz, just go to the Prefs tab > Upgrades > Check Now. If you don’t have Spaz installed, you can install it from the Spaz homepage.

Here’s a breakdown of what’s new in 0.3.0:

3.0 (2007-10-30)

• All timelines now retrieve all data, not just from last 24 hours (including DMs, @s, sent messages, followers/following lists)
• New theme: “Dumb Terminal.” Works best on Windows with Bistream Vera Sans Mono or Iconsolata font; OS X has readable mono fonts by default
• New window behaviors: Minimize to systray (on by default), minimize when in background, restore when in foreground
• Added Native Shell Menus under OS X
• Added System Tray Icon in Windows w/ context menu
• Added Dock item menu
• User-defined CSS tweaks file now works again
• Tweets can now be “selected.” Hit ‘@’ (SHIFT+2) to send reply to selected tweet’s user
• Prefs that require restart to be applied are now indicated
• Better descriptions of data retrieval errors; should properly determine if response timed out or if request limit is exceeded
• Fixed charcount to reset properly after successful send
• Added simple DOM context menus - currently allow user to copy URLs to clipboard
• Use ‘-khtml-user-select’ to limit selectability of elements; should eliminate many problems with onlick operations
• Popup panels should work a bit better; center properly and drag more easily. Popup panels will be moved to modal windows soon
• Upgraded to jQuery 1.2.1
• Dumped Interface lib, added jQuery.UI lib
• Fixed size of protected post icon
• Lots of code cleanup and refactoring

I’ve also created a simple screencast in Jing to show off what I think is one of the coolest, most underused Spaz features: User CSS tweaks. It lets you load up your own CSS file to modify the current theme. If you don’t like the font size or a color, you can change it yourself, without having to author a whole theme.

• Screencast: UserCSS in Spaz - a simple example (Flash required)

I didn’t record any audio with this screencast, as I didn’t have a decent mic handy. Hope it’s still helpful!

As always, direct bug reports, questions or suggestions to Spaz at Twitter.

Update: This is fixed in Speed Download 4.1.12

Suckers Early adopters like me have already downloaded the Safari 3.0 beta, because it pays to be super cool like us. However, it’s hard to be awesome when your browser crashes on startup, like mine was. It looks like the Speed Download plugin I had installed was at fault.

To remove it, I went to <My Home Directory>/Library/InputManagers/ and trashed the SpeedDownload Enhancer folder. Now Safari 3.0 starts nicely.

I wrote up a short review of the 2.0 release of the Siira web browser for OS X. Check it out over at Ars Technica.