14 June 2008 10:57


About a year ago, a small firm called Fotango launched a server-side JavaScript web development environment called Zimki. At the time, they were offering a MacBook Pro for the best application developed using Zimki, so I had a play with it. It was missing some critical features including database transactions, but I managed to make some simple stuff work with it.

Part of the Fotango's plan was to open-source the code powering Zimki, so that other providers could also host applications developed with it, making it a safer choice for development. But whilst this was the CTO's wish, the owners eventually decided they did not want to release the code, and at this point the CTO left. Soon after Zimki announced that they would be shutting down their service.


JavaScript as a server-side language is an interesting choice. It has the obvious advantage that it's well-known, standard and familiar to the vast majority of web developers. That's not true of any other language. And it's not as bad as you might think, since the latest version of JavaScript, as was being used for Zimki, is much better than the elderly versions which have to be used for client-side programming. But at the same time, that means that in many ways it's not the same language that developers know (and hate). In fact, the latest version of JavaScript feels like it's nearly half way to being Python from the early versions.

But the real weakness of using JavaScript is not the language itself but the selection of libraries available for it. Whereas Python and PHP have a vast set of libraries available for web development, JavaScript has relatively few. And writing web applications without libraries for common tasks such as form validation is a pain.

Web-based development

When Zimki first appeared, my first thought was that it was about time, and wasn't through-the-web the obvious way to do web development? I often spend about half my time on system administration, just to create another environment that's basically the same as that thousands of other developers have set up. And by having a hosted setup, data backups are automatically made, and the application can automatically scale across multiple servers. The advantages are certainly significant.

But then, the flexibility of configuring my own system started to become apparent. Installing image libraries, running a mail server, and many more things are going to cause problems if you can't do them. And, perhaps most critically, the development environment is probably never going to be as flexible as developing on your own machine.

After a little while, I wondered how Zimki could possibly be used for anything significant. The lack of libraries and configurability was too limiting. And no-one was going to choose a framework which they couldn't be sure was going to provide the flexibility they needed. So it wasn't a big surprise to me when Zimki announced that they were stopping their service.


But now there's a new company in the same game, AppJet. Doomed to go the same way? Well, I'd have thought so, but they are funded by Paul Graham, so I thought I'd look a bit more closely before drawing any conclusions.

So, what does AppJet offer? Does it address Zimki's shortcomings in a lack of mail and image processing libraries? What about form handling and database transactions? Ability to host your site at your own domain?

Well, there's no sign of transactions, making the data storage of dubious value. Interestingly, there is no templating language in appjet. You can print strings, or you can generate tags like this:

print(UL(LI("Ice cream"),
        LI("The sound of the ocean"),
        LI("That song by Bobby McFerrin"),
        LI("The movie ",I("Gone with the Wind")),
        LI("Elegant code"),
        LI("The color ",SPAN({style:"color:green"},"green"))));

which looks a bit smelly. Seaside (Smalltalk) and Uncommon Web (LISP) both have XML tree generation like this, but it doesn't seem right here. There's also something similar in Python called Breve, which I've been intending to look at for a while.

Request dispatch is an interesting topic. The Pylons web framework uses a port of Rails' routes, which defaults to a /controller/action/id style scheme. Zope uses the URL for object traversal, and when that matches your application it's excellent. TurboGears uses a similar object traversal dispatch mechanism from CherryPy. Django uses regular expression to match incoming requests.

AppJet? Well, if you call the dispatch() function, then the url /name will call the function get_name. So there's a way to go there. Similarly the form library doesn't do validation.

So, does AppJet have anything that might make it attractive for some kind of web development? Well, there's a library for accessing the Facebook API. So it might make it easy to produce pointless Facebook applications. But I can't see them making their authors much money, so there won't be much to come back to AppJet.


I'm quite surprised that there isn't anything about AppJet that makes me optimistic. I'm still not convinced that the idea of a hosted application development environment can't work. But AppJet seems to be no nearer than Zimki was.


I've been wondering how hard it would be to set up a Python-based TTW environment. IMO the whole hosting environment must be installable on your local machine so that standard development tools can be used. Editor wars are still fun, after all! At this point, what's the point in a hosted system? Well, as soon as you move to a live server --- maybe by just running a script --- then you could have the scalability and backup issues automatically addressed. But then if you changed the data strucutres? What would happen to the database? Hmmm. I still think that there ought to be mileage in this general idea.

The primary reason that I think the system needs to be available locally is so that people can develop and test the libraries they want to use. Maybe if it is possible to install any eggs needed for your application on the server, that would be enough. That might start to address what in my opinion is the biggest issue facing hosted application development.

Hosted systems are always going to be more restricted than having full control over a system, but it is interesting to see how flexible they might manage to become.


A few days after writing the above, I was watching a screen-cast on database migrations in Rails. It was quite impressive, but I was as ever intimidated by the need to remember all the conventions (which avoid the configurations) in Rails. But it made me think that maybe Rails is the obvious technology to be offering hosted development for. The vast majority of Rails developers don't try to use their own ORM/templating system/form library. In my opinion, there's much more mileage in hosted Rails development than in hosted JS development. As far as I can make out, no one is doing so as yet. I'm tempted. [Note: I'm not going to develop it in Rails, though. Rails is shockingly slow in some of the screen-casts.]

Leave a comment