Jaxer is dead technology. Some hacker-necromancer may resurrect it, but it doesn't look likely.
The current release of Jaxer, 1.0.3, came out a year ago. A year is a long time to go between updates, for an open source product, particularly when the core technology got a major update half a year ago, when Firefox 3.5 came out. Jaxer isn't a huge sluggard when it comes to processing, but it's slower than PHP, so we certainly could use an update to the new TraceMonkey engine.
The code has since been placed into a public source repository, but no commits have been made since that initial checkin.
The old support forums are closed and the new Jaxer mailing list carries more spam than content.
The company that created Jaxer no longer lists Jaxer as an active product. It no longer comes as part of Aptana Studio, though you can still add it after the fact.
Even if Jaxer were a healthy, thriving project, it still has some serious drawbacks. The main one is that prodigitalson is right, it is completely unsuited to cheap shared hosting:
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.
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.