Jaxer is dead technology. Some hacker-necromancer may resurrect it, but it doesn't look likely.
Jaxer 1.0 was released in January 2008, and only received a few minor upgrades after that, mostly fixing typical 1.0 bugs and limitations. The last release, 1.0.3, is about three years old, as I write this.
Three years is a long time to wait for an update to an open source product, particularly given that Jaxer died pretty much right as the whole Javascript speed race began. Jaxer is based on Firefox 3.0, so it does not have the TraceMonkey and JägerMonkey advances Mozilla has made since that release.
Jaxer's code has since been placed into a public source repository, but no substantial commits have been made since that initial checkin.
The old support forums are closed and the new Jaxer mailing list carries little content. It mostly consists of unanswered questions.
Aptana — the company that created Jaxer — was bought by Appcelerator, a desktop-focused company. Appcelerator's Aptana acquisition FAQ says they intend to continue developing the server-side Python, PHP and Rails products. Jaxer is left out of this, being described as "in maintenance mode" with announcements to come in late Q1 of 2011. Since then, crickets.
Before the Appcelerator buyout, Apatana dropped Jaxer from the Studio download. You could then and still can download it separately, but that's small comfort given that the support for it seems to be, "if it breaks, you get to keep both pieces."
Even if Jaxer were a healthy, thriving project, it still has some serious drawbacks:
Browser Javascript, the platform Jaxer is built on, doesn't know how to run code in trustably separate sandboxes, so you need a separate interpreter for each site hosted on the server. That costs memory, one of the biggest drivers of higher hosting fees.
That wouldn't be so bad if the core technology was a parsimonious user of RAM, but it's not: it's Firefox, a RAM-hungry program. While debugging a server crash due to it running out of memory, I found that the core problem was that launching an external process ballooned the VM use by 35 MB. It was a one-time hit for the first launch only, not a memory leak, but multiply that by the number of Jaxer processes you have serving connections (3, by default, with more better for performance) and you're already over the 64 or 128 MB limit for some cheap hosting plans. Absolute bare minimum to host a functional Jaxer site is 256 MB, and 512 MB is a lot safer.
You can get around some of the RAM hungry nature of Jaxer by running on a virtual machine technology that lets you have swap space, so things like the GUI libraries Jaxer uses (!) don't stay in RAM, but many do not. Often you have to use more expensive hosting to get something like Xen, rather than a more efficient VM system like OpenVZ that doesn't let you use swap space.
Because Jaxer isn't being patched any more, there are still bugs in it that can crash or hang the server. I ran into one where some random bot out on the 'net was accessing random URLs on my server, causing Jaxer to run for each one, eventually running the system out of resources. I had to rearchitect the way my site was built so the bot's hits were served only by Apache, restricting Jaxer to a single sub-tree of the site. That's just a workaround, though, because all you'd have to do to start crashing it again is to access lots of random URLs in the new sub-tree. Every month or so, I have to reboot the VPS because it's consumed all the RAM, probably because someone's stumbled across this weakness in the design.
Bottom line, Jaxer is completely unsuited to cheap, shared hosting.
Lest you think I'm some Jaxer hater, let me pre-defend myself by pointing out I was an early adopter of Jaxer (pre-1.0), was one of the most active posters on the original forum, and have two sites running on Jaxer. Yes, I'm upset, but mainly because one of those sites was migrated off one dead technology onto another that died within a year of that move. (The other was created from scratch after I successfully migrated the first.) Now I'm stuck wondering whether I now have to move again, or keep trucking along on a platform that looks like it won't move forward ever again. You don't want to be in this same boat, much as I might like the company.
