Offline-Enabled Web Apps: The Future

I was reluctant to join the world of web development. I started in high school with a few sites and realized several things: Javascript sucks, Internet Explorer sucks; therefore web development sucks.

Fast-forward through a couple academic degrees. Job hunting with one requirement: Python. Python jobs all require Django.

So I learned Django, assuming, incorrectly, that if I was developing python backends, I wouldn’t need to work with the horrors of Javascript or Internet Explorer. I earned money. I relearned Javascript and became a first rate web developer.

In the back of my mind I still felt that web development sucks. So a few weeks back when deciding on a platform for a personal project, I thought I’d try something new. The Android platform was in my hands and I gave it a whirl.

I didn’t enjoy it much and I am now rewriting the app as an offline enabled webapp using Google Gears.

Then Chrome OS was announced and I realized that I’ll probably be doing a lot of offline enabled webapps using Google gears and/or HTML 5. Like it or not, it’s the future. Me, I like it. There are a lot of advantages to this kind of setup: I can access the apps from my phone, my laptop, my parent’s desktop, or Phrakture’s hacked computer whenever and wherever I want. I don’t have to write a different client for each one. Its true ‘write once, run anywhere’. I can upgrade each of those clients automatically as long as there’s a network connection.

On that note, you don’t need a network connection to run HTML 5 or Google Gears based apps. They both provide a ‘localserver’ that caches pages and javascripts, and give you an SQLite database for data caching. Typically offline versions of apps are not as powerful as their networked counterparts, but they do not require network access to run. Further, because they are locally cached, they can be made to run as fast as a “standard” (old fashioned) desktop app. The apps run in the browser, but the browser is just a container, a window manager, to hold the application.

In traditional webapps, you code most of the logic on the server side. In this new model, you end up coding most of the logic in the client, because the app needs to run without a guaranteed server connection. For me, this has a massive, nearly show-stopping drawback: A large portion of the app must be written in Javascript. JQuery makes Javascript suck lest, but it still sucks. I’m a Python programmer.

For years, I’ve dreamed of browsers supporting tags that allow me to write my DOM manipulation scripts in Python rather than the ubiquitous and annoying Javascript. This wasn’t possible because python can’t be adequately sandboxed such that arbitrary scripts running on the web don’t have access to, say, your entire hard drive.

This is no longer true. The PyPy project finally has a complete Python 2.5 interpreter that can be safely sandboxed. Since discovering this at Pycon 2009, I’ve been thinking about interfacing it with a web browser.

I figured “somebody must have started this already”. Google didn’t help much, but when I logged into #pypy on freenode I was told “fijal started doing that with webkit yesterday”. I’ve been following up trying to get the project to build (I was warned that the build process is a mess and was invited to wait until it is cleaned up a bit). So far, no luck, but I am optimistic that python support is finally coming to the browser. Granted, it won’t be much use for public webapps (at first) since browsers won’t want to be distributing pypy, but a lot of my projects are personal, and satisfying the general public will be far lower on my priorities list than ‘developing in my preferred language’.

I’ll have to install a pypy interpreter into Chrome Lite under Android before this is useful to me. That may be tricky.

6 Comments

  1. Johannes says:

    How about using a Python to JavaScript compiler? http://pyjamas.sourceforge.net

    Also: http://pyjd.sourceforge.net/

    Johannes (wuischke@Arch)

  2. dusty says:

    I have considered it, as well as the pyv8 and python-spidermonkey engines, but I don’t like any of them. pyjamas holds some interest to me as GWT seems to have some useful features (at least, that’s what I got from the wave demo), but I think its a step in the wrong direction — an unnecessary abstraction layer. Plus I hate the compile step. ;-)

  3. Johannes says:

    Well, I just regard it as a compatibility problem. Being dependand on a browser with Python support (of which there’s only one, which you have to compile yourself) kind of defeats the “write once run anywhere” advantage you cite.

    Don’t get me wrong, I love the idea of using Python instead of JavaScript (although since starting to use jQuery, I swear a lot less), but compatibility is an issue.

  4. Common Lisp has interesting facilities to get rid of JS as much as possible.

    There is Parenscript for writing Javascript in Lisp syntax and Weblocks (http://weblocks.viridian-project.de/) which lets you model most AJAX interactions directly on the server side with a super-thin JS layer (for the AJAX requests). It’s similar to Smalltalk’s Seaside (http://www.seaside.st/).

    That’s not Python though, of course.

    Leslie

  5. kensai says:

    Is good to read your way of seeing the whole Google Chrome OS announcement and the future of the web. You gave me enough good reasons to like the way Google is trying to take the desktop towards. In fact this new approach to the web is going to change the market share stats that has been so prevalent for the current OS in the market. I really am awaiting the ways in which HTML 5 is going. Good luck with accessing applications through phrakture’s hacked box.

  6. [...] storage. I’ve written about this before (I must be getting repetitive). My idea then was that offline enabled webapps are [...]