I’ve had intermittent access to an iPad for about two weeks now through work, and finally feel like I have a grasp on what it is, what it’s good at, and what it lacks.

First off, the iPad doesn’t do everything. It’s not a full-on replacement for a computer. In fact, you can’t even get it running without a computer to which you can connect it. It lacks a camera, so you can’t use it for videoconferencing or photography. While it’s better for content creation than the iPhone, thanks largely to its bigger screen and support for Bluetooth keyboards, it includes no facilities for printing out the content you do create. For that, again, you’ll have to rely on a computer.

That said, it does 90% of what people use a laptop for, and does that 90% beautifully. Web surfing is a smooth, fast delight. Dealing with email goes smoothly and quickly. The Calendar and Map applications are lovely to look at, and a pleasure to use. Listening to audio and watching video, while hampered a bit by the monophonic built-in speaker, is likewise a pleasure. The vibrant high-resolution screen makes it great for showing off photography. (In fact, I’ve already heard of a graphic designer friend-of-a-friend who got a job because he’d loaded up his portfolio onto the iPad to show it off.) Writing works great, especially with a hardware keyboard. And of course, there are a wealth of applications designed for the platform that make it even more versatile and capable.

Is it for the person who likes to tinker with computers? Probably not so much. Apple takes great pains to keep the iPad and its related platforms, like the iPhone and iPod Touch, locked down and controlled. On the other hand, this is a device I could give my Mom and expect her to actually use it. If one wants to do the things the iPad does, there’s not much way to do those things better, faster, or more intuitively.

A couple months back, my team at work started working with Appcelerator’s Titanium, an open-source system for developing iPhone applications that, instead of requiring one to learn Objective C, wrapped up the iPhone APIs so that they could be accessed from familiar web languages.

The version that was current at that time made it very easy for people with web development backgrounds to create native iPhone applications. It did so by opening a web view for every screen of the application and then letting one author HTML, CSS, and Javascript that ran within that context. By layering native controls on top of those web views, one could make decent-looking applications quickly in a way that was intuitive for those of us who live and breathe these technologies already.

Unfortunately, this was not an efficient approach. Having so many web views in an app caused it to run slowly and take up a good deal of memory. Additionally, apps written with HTML/CSS instead of more traditional methods tend not to look quite right, since they make less use of native controls and use more web-like design.

Appcelerator’s solution? With their latest releases, they’ve changed the architecture pretty dramatically. Instead of basing everything on web views, applications now use native controls exclusively, only falling back to web views when you’re actually doing something on the web. The application UI is created entirely in Javascript, and HTML and CSS now have very little, if any, place in an application.

The upside to this is that performance has been improved by an impressive amount. Apps written in Titanium are generally as responsive as apps written directly with Objective C and Apple’s tools. Additionally, all of the UI elements are now dynamic, so that one can make adjustments to on-screen objects at any time — not just when a window is initially rendered. Managing the scope of variables makes a lot more sense in the new version than it used to, and requires far fewer chintzy hacks to pass data from place to place.

The downside, sadly, is that Titanium loses a portion of the ease-of-use that made it attractive for us to begin with. All of the UI we had done with HTML/CSS now has to be rewritten using native controls, which are a good deal more cumbersome. Essentially, one is writing much more directly to the iPhone API, but just using Javascript instead of Objective C to do so. (Which is still a win, in my book, as I have a pathological hatred of having to manage memory for myself.)

We’re currently pushing forward with the transition to the new way of doing things, and probably have about 40% of our prototype app rewritten for the new system. The new version feels generally tighter and more professional, but is definitely taking longer to write than was the case with the old methods. And while I’m still very impressed and happy with Titanium as a product and feel that the tradeoffs were the right ones to make, it does now feel much less like iPhone programming “for the rest of us.”