Meeting with Aptana’s Kevin Hakman – Talking Jaxer

Regular readers of this blog will know I am a big fan of Javascript on the server. Through its Jaxer project, Aptana has been at the forefront of the server-side Javascript renaissance. As I’m in SF right now (mail or tweet me if you’d like to meet up), I was pleased today to be able to catch up with Kevin Hakman, a great talent in the Ajax world who runs community relations and evangelism for Aptana.

I wanted to get an overview of the state of Aptana and Jaxer, and also understand how it might be used in a TiddlyWiki context to help with accessibility.

We discussed a range of things Jaxer – I will list them below. Kevin reviewed a draft of these points and gave me some links and corrections.

  • Jaxer – as you probably know, Jaxer is an Ajax engine. It’s server-side Javascript, but more than that, you can perform DOM manipulation on the server, and then it spits out HTML from there. Very exciting for all the rasons I’ve mentioned in previous blog posts – using a single language, making proxied cals from client to server, etc. The great thing about Jaxer is it’s open source – you can download a version with Apache that “just works” – download, install, and start the server in one click and the sample apps are up and running. Aptana runs a cloud host for Jaxer (as well as Rails/PHP etc), so you can host with them if you don’t want to host it yourself. They have some interesting value-adds around their host, like support for different environments (dev/test/etc with different parameters, such as extra debugging), which you can easily spin out and turn off again.
  • ActiveJS – ActiveJS is a Jaxer-powered framework modelled on Rails and close to beta. The most mature part is ActiveRecordJS (ORM), but there is now ActiveView and ActiveController as well. As with Rails, you can use them independently. This is exactly what I’ve been hoping for and it sounds like it’s mature enough to start hacking against. Kevin is realistic about uptake and expects it to be a long process.
  • Microformats – Kevin directed me to this this Jaxer project which filters parts of a form depending on who is viewing it. You just use a different class name to indicate who can view what, and the server chooses which parts to output. This got me thinking about microformats and how Jaxer could help render them – with a single library, dynamically in the browser and statically from the server. There are a number of microformat libraries which might already be useful sitting in a Jaxer server.
  • TiddlyWiki – Taking TiddlyWiki based apps and using Jaxer to make them come statically from the server. Since Jaxer supports DOM manipulation, it should certainly be possible. Kevin said accessibility is certainly an argument for Jaxer, though there’s no significant demo to date, so a TiddlyWiki project would make a good demo. His intuition is that it will be a 90-10 – 90% straightforward, the remaining 10 will cause some complications. Would definitely make an interesting project to do a simple version, e.g. initially just get Jaxer to output each Tiddler, showing title and wiki markup.
  • Demo app – Aptana TV is implemented in Jaxer+ActiveJS and there are plans to open source the implementation and make it Jaxer’s “Pet Store”.
  • Interoperating – Jaxer can interoperate with other languages using browser extensions/plugins, since the server is basically Firefox; these are not extensions users have to install, but act as enhancements to the server. Just as a user can install a plugin to Firefox so web apps can make calls to Java for example, a developer can patch the server with the same plugin (or similar, but with the same API anyway?). Kevin said most of these kinds of components are XPCOM, but I guess Jaxer should accept regular Firefox extensions and even Greasemonkey scripts. DotNet COM example. In a simpler sense, you can call out to other languages using the OS command line. System commands have always been possible from the Jaxer server.
  • FF bugs – Jaxer shares the Firefox’s bug set and fixes, when you think about it!
  • Performance – Likewise, Jaxer benefits from all the stuff you read about sky-rocketing Javascript performance in the browser. Jaxer will be inheriting the performance boost from TraceMonkey promising to be silly-fast at 20x to 40x speed improvements for JS according to Moz.

Server-Side Hosting Options

I’ve been thinking about what language and framework to use for my next hobby projects. There has always been a frustrating trade-off between language quality and ease of hosting. The languages I know best are: Ruby (+Rails), PHP, Java, and Javascript. So these will be my options.

What I’m looking for is a hosting environment which will scale well as I add new sites, each with their own domain and database. I want to deploy new sites almost with a single click, but realistically in an hour or less. And I don’t want to pay for each new site I deploy – in virtual hosting and cloud style, I want to be paying for overall consumption, not for the number of applications.

(Update: A couple of people suggested I should add Python, so it’s now here for completeness.)


I say Ruby, but really I mean Ruby on Rails. The only other feasible frameworks for Ruby are Camping and Merb. The first is too simple and the second is too immature and lacking web host support.

Hosting for Rails has been a tragedy for me. I developed a site a year ago and tried to outsource deployment to Amazon EC2, and both suppliers gave up on the job. This was after I deployed it myself on SliceHost, requiring much effort, and then found it couldn’t handle the load. There are big Rails-specific hosts, EngineYard and RailsMachine, but they are very expensive and not practical for hobby projects. When I was working on Quizr, I also spent ages getting it deployed on RailsMachine; it was not turnkey as some people expect it to be. All I wanted was a server, a backup server, and a DB – so a fairly standard config. That’s not a criticism of RailsMachine, but don’t expect it to be trivial if you want more than one server (this was 18 months ago, it might be different now).

Rails is a super coding environment and would be a no-brainer for all of my projects, if only hosting was simple and reasonably priced. With a virtual environment like SliceHost, I found it takes several hours to set up a new site, and you also end up with a lot of config files to maintain (ie mucking about with apache modules and load balancing). You can also use a grid solution like Heroku. This is a fantastic way to keep things lightweight. The downside, though, is there’s always some little tasks you need that are outside the sandbox. e.g. setting up a cron job or adding some custom C library. Right now, Heroku doesn’t have a commercial model and apparently doesn’t let you use your own domain name. This rules it out for anything too serious.

I think the ideal for me would be a virtual Linux environment like SliceHost, with some VERY high level scripts that deploy a Rails app in a single click. These would have to be client-side scripts. I found Deprec is close to this and might get there at some stage.


PHP isn’t the best language, but it’s certainly easy to get something up and running. I find for small projects, it’s quite maintainable too, even without using PHP5’s OO. However, I’d like to use one of the Rails-inspired frameworks, e.g. PHP on Trax, in order to speed things up and ensure it’s easily maintained. This is where things get more tricky, because there are so many clones to choose from, and the community for each suffers as a result. As many have pointed out, Rails benefits from being the only serious contender in Ruby space, and the same cannot be said for any other server-side language. With PHP, you don’t need any framework at all, so in fact each framework is probably only used by less than 1% of PHP developers. In contrast, Rails is probably used by > 99% of Ruby programmers. Less community means less documentation, support forums, books, and information about hosting and capabilities.


Well, I mostly mention this for the sake of completeness. Java’s an okay language for web development, especially if you choose your framework right, but hosting has mostly been restricted to enterprises. I find it funny, given Moore’s Law, how much Java hosting still costs in 2008, but it’s still pretty silly and not easy to just keep adding domains and applications without expense. Furthermore, I find it funny that Sun missed the boat on grid hosting for Java. So while there are consumer-focused solutions for grid hosting Rails and Javascript, no such thing for Java. On the whole, consumer-focused Java hosting is a cottage industry. Given that the language itself isn’t so brilliant, not worth the effort.

Where Java might get interesting is the VM. You could use it to host Groovy or Rails projects via JRuby. However, until it’s really, really, mature, I feel like JRuby is going to be one of those open-source things that sounds good on paper, but feels less enticing at 4am and with 26 open browser tabs pointing at pertinent blogs and support forums. I will reserve judgement for now.


Python has a number of modern web frameworks, with Django being the most prominent. The fragmentation didn’t help, as compared with Ruby with its one gigantically popular framework, so it helped when Guido blessed Django. I’m sure Django (and others like TurboGears) is a good framework, maybe even better than Rails from what I hear. However, as I already know Ruby, I don’t have that much interest in taking the time to learn it – the languages and frameworks are similar enough that it wouldn’t be worth the effort. Moreover, I like the whole Ruby and Rails community and all the web presence and docs and books around it. It’s more fun and focused on the things I care about, like usability, aesthetics, and being opinionated. Also, there is simply a much greater volume of resources.

That said, Python has gained a lot of momentum due to Google App Engine, which exclusively hosts Python. But Google loves Java and I’m sure it will expand to at least support Java at some stage, if not more generic stuff like EC2. Providing a Java runtime would allow for stuff like Scala, JRuby, and Rhino.


I consider server-side Javascript the holy grail over the next few years. I’ve explained why before – in summary, it’s the fact that you’re using the same language on both sides and the synergy that results. It’s not just that it’s simpler for you, the human programmer, who only has to speak in a single tongue. It’s more about the code you end up with. You can have a single module representing a web page, which contains both client and server code. It says “show the user two buttons. If they clicked button 1, do this; If they clicked button 2, do that”. So the code is very much combining client and server sides; and unlike high-level web-app compilation services, the code is actually what gets executed on both sides.

The main problem with server-side Javascript is immaturity. It will get interesting when we get Rails like models, the kind of stuff Steve Yegge has talked about. However, it shouldn’t be too similar to Rails; otherwise, you’d miss out on the synergetic effect described above. For now, though, server-side Javascript does suffer a lot in comparison with Rails, due to lack of a cohesive MVC model.

The main options for hosting are AppJet and Jaxer. AppJet is a nice, easy, grid solution, but doesn’t yet have enough info on commercial hosting and custom domain names. Jaxer has a lot of promise, but the Linux module will need to come out, be not too processor-intensive, and be supported by web hosts. There is also the upcoming Aptana Cloud solution, but this is similar to AppJet. For now, can’t host your own domain. These grid solutions are very handy, but I want to be able to release new apps and domains willy-nilly, and I suspect the grids, when they do become fully commercial, will impose a charge for each new app/domain.

The Javascript Grid

Google App Engine launched this week and one controversial aspect was that it only works for Python. It wasn’t a big deal to me. Firstly, it’s a good way for Google to limit the initial market. Secondly, Google specialises in Python and not Ruby – quoth Yegge: “One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript.” After all, Google has Guido but not Matz or DHH. (I wonder how many times someone has asked that guy if he’d consider a position at Google!) Thirdly, who cares? Do you really think it will stay Python-only for long? Heavens to Murgatroyd!!!

Dion’s take (read his post for the full detail):

Anyway, I have a dream and surprisingly it doesn’t involve Ruby and unsurprisingly it does involve the magic bullet that is server-side Javascript.

How cool would it be if Google bought Aptana or AppJet – or did their own work with Jaxer or Rhino – and made a robust, elastic, server-side Javascript platform? Then roll in Rhino and Rails, hopefully reworked from Rails considerably to take into account the synergies delivered by dual-side Javascript. Backed by BigTable of course!

That’s the tipping point right there!

Dual-Side Templating

Ajax, Ajax Patterns, Javascript, Server-Side Javascript

As server-side Javascript continues to gather momentum, patterns will start to emerge. Dual-side templating, which I’ll explain below, is a pattern I’ve been harping on about for a while because you can kinda sorta use it already with a product like Rails. It will be a lot more powerful with OFL (our favourite language) on both sides of the wire.

The timeline looks like this (with milestone times neatly accelerating towards the singularity :):

  • c. 1995: Server-Side Templating. This is the standard templating used in Java’s JSP, Perl’s Mason, PHP, ASP, etc. ie some html code with <?= “language” ?> code embedded in it.
  • c. 2005: Browser-Side Templating. This is an Ajax pattern where you have a block of HTML that includes some custom syntax (e.g. <% ${} %>) which are then processed via Javascript.
  • c. 2010: Dual-Side Templating A single template is used on both browser and server, to render content wherever it’s appropriate – typically the server as the page loads and the browser as the app progresses. For example, blog comments. You output all existing comments from the server, using your server-side template. Then, when the user makes a new comment, you render a preview of it – and the final version – using browser-side templating.

I continue to be bullish on server-side Javascript and am expecting a lot of design patterns to emerge in the next couple years. AppJet and Jaxer are already available, but the real impact will be (a) enterprise-friendly stack, probably Java-based; (b) commodity hosting stack, probably Jaxer based.

Server-side Javascript: Hope and opportunity

Update: See also

Dion’s cartoon resonated with me:

Resonated because only last night I was thinking it’s about time I actually started playing with server-side Javascript, and wrote my first, extremely dumb, AppJet app. I will hopefully make it, like, actually do something at some stage.

I’ve discussed the potential of server-side Javascript before, and the more I think about, the more I like it. Javascript is a sophisticated language and, by now, a language very familiar to many professional web developers.

The real gap is in server-side frameworks and hosting. There’s no “killer app” Javascript server, a la what Rails did to Ruby. I haven’t even heard of most of the SSJS frameworks listed in Wikipedia. Furthermore, try finding a virtual host that supports Javascript! You would practically need one that support Java, so you can run Rhino or whatever, and few virtual hosts do that. At least Python and Ruby were running on many virtual hosts before Django and Rails showed up. For that reason, the model pursued by AppJet seems worthy. If they can come up with a solid virtualisation environment for Javascript, they may be on to a big winner. They could be the BEA or JBoss of 2015 (2010 seems a bit early for all that!). And if the rumour is true they’re using Scala, they’ll get doubleplus-coolness votes for language selection.

Phobos – Server-Side JS Redux

On Ajaxian, Dion points to Sun’s Phobos project, an attempt to build a new platform for server-side Javascript. Phobos came out six months ago, around the time of the May Ajax Experience.

No-one has taken server-side Javascript seriously since it died a premature death in the mid-90s. But there is great potential…

  • Server-side Javascript would allow for code sharing between browser and server. The most obvious application being validation code, but since no-one really bothers with server-side Javascript, there are probably many other patterns as well. One pattern I came up with a while ago is Dual-Side Templating, where you have the same parametized HTML template on both the server (for initial page load) and the browser (for subsequent additions to the page). I implemented the server templating in Ruby, but it would have been a lot easier if the server was running JS. That’s just one example.
  • Server-side Javascript would keep us Ajax types more sane. Right now, an Ajax developer has to constantly flip between JS and [insert favourite server-side language here]. True, you always have to flip over to other “languages” too, viz. HTML, CSS, SQL; but there’s always a special place in the programmer’s head for the core language of the day. With Ajax, you have two such languages. If those languages are quite similar (e.g. Javascript and PHP), it gets frustrating because of all the subtle differences (new Array() versus array()). If they’re different (Javascript and Ruby), you’re trapped in a Whirf-Brock disconnect, constantly flipping between two different worldviews. Slight exaggeration as it’s certainly do-able, but it would be a lot easier if programming in one main language.
  • Server-side Javascript would pose less of an issue for IDEs. With new improved Javascript, IDEs are being forced to support Javascript in order to keep up. It’s far more important than supporting SQL etc; so basically, IDEs now have to provide solid support for at least two serious languages…it would be easier if it was only one.

Now a framework like Phobos has much to offer the world compared to the server-side Javascript of the mid-90s:

  • Phobos is apparently inspired by new frameworks such as Rails. With the right libraries and improved patterns for OO, inheritance, etc, Javascript can compare admirably against Ruby. Not in every regard, but then there are actually some aspects of JS that are superior (e.g. functions as opposed to blockism; dynamic member creation).
  • There’s a lot more known about Javascript now, and it’s almost certainly the most widely understood language in the industry, even though it’s not the primary language for many (cf. English).
  • Because of all the JS code now running in the browser, there are probably a bunch of synergies with server-side JS – these could be exploited by a well-considered server-side JS framework.

As an open platform, Phobos has the best chance right now to make server-side flourish. But I agree with Dion, that there is reason for concern about whether it will happen.

Sun may already have this. Will they be able to market it? Unfortunately, the track record isn’t there, so it will probably languish. Buy maybe not.