AJAX Reality Check

by Zef Hemel

Recent announcements like that the iPhone will allow 3rd party developers develop “applications” for it using “modern web 2.0 technologies” and Adobe’s Apolle, err, AIR that brings these “modern web 2.0 technologies” to the desktop, made me wonder. Does anybody realize where we came from and that these “web 2.0 technologies” aren’t great at all, but just the best we could do — in the browser?

Let’s go back a few years. Developing web application was ok. You had HTML, CSS and if you were very fancy, a bit of Javascript. You had some form that the user could fill in and every link you clicked and button you pushed brought back a new page. It was slow and it was a bad user experience. But still, it was all running through a web browser. Everybody has a web browser and it worked no matter what operating system you were running on. It was the best we had.

Then some companies, most notably Google, came out with Gmail. They used this Javascript thing called XmlHttpRequest, which could do HTTP requests in the background. Using this approach Google with lots of rocket science managed to create something that was getting pretty close to a user experience similar to a regular desktop mailing application. This technique was later dubbed AJAX (Asynchronous Javascript And XML, or something). Creating such application was difficult at first, but hey, people chose to build their applications in the browser so you have to do as well as you can. Now a few years later there’s loads of javascript libraries to make building AJAX applications a bit easier. But still you need a lot of knowledge of HTML, CSS, Javascript and maybe Flash and SVG and other oddballs like Comet. And what does it give you? An experience more and more approaching a desktop app experience.

More and more approaching, but never exceeding or even matching.

Let’s just face it, the enormous amounts of time that it takes now to build an interface close to a desktop-like experience could have been done in a fraction of the time using an actual, proper client application framework like Java, .NET, GTK+, Cocoa or Visual Basic. And then you could also use cool features like 3D rendering and it would all be a whole lot faster too.

But people seem to have forgotten that things like client-side Java, .NET, Cocoa, GTK+ and Visual Basic even exist and how you could often drag and drop your interfaces. The horrible AJAX development experience has become the new cool, hip, modern web 2.0 technology. An experience that “we” apparently want everywhere now. Adobe is happy to bring it to the desktop. Thanks Adobe!

And now Steve Jobs wants to bring it to the phone. Thanks Steve! “Yeah, we have this new amazing modern way of developing applications for your phone, it’s called a website!” Awesome. “It integrates great with all the iPhone features. For example you can create a “call:0123223222″ link to call somebody!” Great. Except you always need an internet connection to use it, it’s slow, you can’t create an icon for it in the menu. And… oh yeah… it’s a frickin’ website! Apparently this was done for “security reasons”. What about Java, Steve? Every frickin’ phone supports Java. It all runs in a sandbox, it’s all secure. It even runs without an internet connection and it’s responsive (yes, that has become a feature in the web 2.0 day and age). Why no Java on the iPhone, explain it to me.

Listen, I’m all for web applications in general. And I really believed in this AJAX thing, but maybe we really have to think again about this. I really wonder why Java Applets never worked. They were perfect in concept. But I guess they came too early and were too slow back then. Maybe we really need an Adobe Flex or a Microsoft Silverlight to really bring richness to the browser. AJAX will only bring us so far and admit it: Javascript, CSS and HTML suck. You don’t want to create user interface in that. At least, I don’t.

Rss Commenti

7 Commenti

  1. I think it’s the best that Apple can do at the moment for a phone.

    I suspect that the GSM and other phone carriers stacks are relying highly on security by obscurity and it’s part of the deal that Apple just doesn’t allow third parties to take a snoop.

    #1 Bas Westerbaan

  2. Wow, finally someone being a bit critical as far as Ajax goes instead of the normal hallelujah stories all over the place. I think you’re absolutely right, Ajax is nice but desktop apps kick it’s but with two fingers in the nose. ;)
    Personally I think using Ajax is a good thing where portability is nice (e.g.: accessing your e-mail everywhere through GMail is nice) but if it doesn’t a standard desktop app is just the better way to go. :)

    #2 Wezz6400

  3. Bas, what do you mean by “are relying highly on security by obscurity”? For what, third-party application development? Java just uses a sandbox model so that’s just secure by itself.

    #3 Zef Hemel

  4. I suspect the GSM et al procotols are not very safe and implementations need to be kept hidden. (That’s why the opensource phone of Trolltech has got two full cpu stacks, one open and one closed)

    Java and other languages for that matter would indeed be effective in sandboxing, but it comes at a cost. It does take quite some space on the device to implement script and, I think even more important, it takes quite some effort to maintain an implementation.

    Maybe the iPhone applications will be local websites, as the widgets on mac os x are written with html/css/js too or as in the same way as the who UI of firefox is too (actually, that’s not completely true). They must have a browser with js support anyway (otherwise they wouldn’t be able to support google maps) so it’s all win for them.

    #4 Bas Westerbaan

  5. GSM is not all that safe, that’s true. About Java taking some space and effort. Sure. But this is the iPhone, it comes with either 4GB or 8GB of storage. It runs OS X, I would say that in theory it could even run the full J2SE if it wanted. So I don’t buy that that really is the reason.

    As it was demonstrated the iPhone applications, at least for now, will not be local websites, they are just pulled from the server every time. The browser in the iPhone is Safari, so that’s indeed a full-blown browser with Javascript support. And Google maps does not run within the browser on the iPhone, they built their own client to Google’s map data.

    On GigaOm I read that it may actually be AT&T who forced Apple not to open up the iPhone. AT&T and every other mobile provider in the world probably is scared to death of VoIP. My Nokia N95 can make Skype calls, which are a lot cheaper than making calls on the normal cellular network. I think that’s why they don’t open up the iPhone, to prevent people from making VoIP applications.

    #5 Zef Hemel

  6. I completely overlooked that! That makes a way more plausible explanation. It’s strange though that Apple didn’t try to find a provider that doesn’t try to lock in for the inevadable. Looking at the current trends it seems that internet via the mobile network is getting cheaper and cheaper.

    Lets see what happens after the initial 4 year (?) contract with AT&T.

    #6 Bas Westerbaan

  7. The desktop apps do have something to learn from the browser.

    1. Bookmarkable applications. I can send you the URL of a particular screen, or a particular record.

    2. This opens up applications to easily implement Most Recently Used Feature, or Most Recently Accessed Data

    3. It makes it easy to add annotation-like features to an app (through mashups).

    4. You can create mashups easily, e.g. treat an application as a component for free

    5. Back button (MSMoney-style UI), although the caching of application screens on browser make this somewhat broken, but desktop apps will be able to address this.

    #7 Chui

Sorry, the comment form is closed at this time.