I realize that this question has been asked before, but it has been a month with no decent responses... I'm looking at Aptana's Jaxer and I find the concept to be very exciting.
Here is a quick overview for those who are not familiar with it:
Jaxer is, in their words, "the world's first true AJAX server". It is based on the Mozilla engine so scripts are written with javascript and you have complete access to the DOM on the server-side.
Scripts are placed on your pages with <script> tags and you can specify a runat attribute (ala ASP.NET) to mark scripts for execution on the client, server, both, or as a "server-proxy" which makes the functions available on the client, but they execute on the server via AJAX. This also means that you can use your favorite client-side libraries (jQuery, Prototype) on the server as well as the client.
It also can be used to process documents that are generated in another language (e.g. php, ruby) which I imagine is not practical except to help in transitioning existing applications to use Jaxer.
- What are the pros and cons?
- How mature/stable is it the API?
- How good is performance compared to other server-side html preprocessors?
- Has anyone used Jaxer with another technology (php, pearl, ruby, etc.) and what were your experiences?
EDIT: I've posted another question regarding a drawback I discovered while playing with Jaxer: Defining objects when using Jaxer
I didn't use Jaxer for very long, but here's some things I found:
Pros
- Write the frontend and backend in the same code. Especially nice for writing validation logic.
- "Seamless" AJAX communication back to the server - it's just like calling a JS function.
- The ability to use JavaScript frameworks like jQuery to manipulate the DOM.
- The ability to generate or manipulate images using the Canvas API.
- You get to write your server JavaScript using whizzy new JavaScript 1.8 features like Array extras and getters/setters.
Cons
- I found their API to be unstable (they were transitioning to 1.0 when I was trying it so that kinda made sense) and the documentation was confusing, missing, or didn't match with changed functionality. I also found that it was very hard to debug my Jaxer server-side code, and when I got in trouble the error messages weren't very helpful.
- You don't get real MVC or even MVP (ASP.NET-style) separation between your presentation and your logic.
- I personally couldn't get E4X (xml in JavaScript) working, which was supposed to be a big draw.
- There's not a lot of framework built around it for building a whole application. You're starting from some pretty basic building blocks.
- It's not really providing any help in your view, so forget all the templating or reusable components you might use elsewhere. Not that you can't replicate that, but it's more difficult than having it out of the box.
Overall, I think Jaxer has the most promise as a postprocessor in front of another web framewok. It would be great to use Jaxer to layer all the spiffy AJAX stuff on top of an existing site. It would make it a lot easier to make a dynamic site with validation / page manipulation logic shared between server and client. I don't think I would want to write an application using only Jaxer. Also, it's young (and immature) - I'll be interested to see where it ends up.
I did come across this set of performance benchmarks.
It looks as though Jaxer performs better than Rails, but not as well as php...
@BRH: Great insight. I would echo all of the "Pros" and "Cons" 2, 4, & 5 and your final overview. I kind of get the sense that they didn't intend to displace any of the market for upstream frameworks ... but if they could do so and keep it as tight and comprehensible as it is, I hope they do! I like the way they think!
P.S. I don't know if it is new, but there is a <jaxer:include tag that injects fragments into the page prior to server-side script execution that might be a help in some code-reuse scenarios. There may be more for me to discover along those lines.
来源：https://stackoverflow.com/questions/98915/pros-and-cons-with-jaxer