Why Jaxer Doesn't Matter

August 6, 2008 · 17 Comments

It looks as if Aptana is getting closer to rolling out Jaxer with the release of their RC "B" version. Many of you may be asking: "What the hell is Jaxer?". Well, Jaxer is billed as an AJAX server. Basically, it is a server platform that gives you the ability to write your server-side code in JavaScript. Is this really what we need, another server?

Let's see a show of hands. How many of you out there in the RIA space are only JavaScript coders and know NO server-side language? Do you really want to rely on JavaScript for your server-side code? I sure don't. We have many platforms that do the server-side really well: J2EE (I'm including ColdFusion here), .NET, Ruby On Rails, PHP, etc. Why do we want to leverage JavaScript on the server? Someone please tell me the benefit. That makes about as much sense to me as the people who want to leverage AS3 in ColdFusion. At what point do you just take the plunge into a high-level language?

We already have these great server-side solutions that do their job really well. The new middle tier's job is going to be quickly and efficiently delivering data to RIAs and less and less focused on generating HTML for the browser. It's coming. Just watch. With all the solutions we have, and where the middle tier is going, Jaxer is not going to be a viable solution. It can't handle web services well, it can't handle any sort of Flex remoting, and we still don't know how it performs under load. Jaxer is, and always will be, a way for client-side developers to get their hands into the server-side of things. I think RIA developers are looking for more. Will Jaxer be able to deliver? My guess is no.

Why Jaxer Doesn't Matter

Tags: Java · ColdFusion · Ruby on Rails · AJAX

17 responses so far ↓

1 Jim Priest // Aug 6, 2008 at 11:33 AM

I think this would be great. I can write my jQuery validation code once and run it both on the client and server side. I agree there are a lot of unknowns but I think it has it's uses.
2 Daren // Aug 6, 2008 at 11:40 AM

"Jaxer is, and always will be, a way for client-side developers to get their hands into the server-side of things" ... I seem to remember people saying the same about CFML a few years ago. I for one am very excited about JS on the server - Haxe almost hit it, I've done my share of tinkering with Rhino and too much writing and rewriting code libs for CF to mimic tags in cfscript. Going back to C/Perl based CGI stuff is a tad masochistic for me. I love JS - it's a fantastic little language and I'd be very keen to see what happens if all the client-side RIA folks versed in ECMA-ish languages get a decent, well thought-out JS engine on the server. I won't be giving up my beloved CF/Java mix anytime soon, but I can really see a place for JS on the server....*especially if it's Open Sourced with care*. My point does have more to do with JS than Jaxer.
3 adampasz // Aug 6, 2008 at 12:28 PM

Some possible uses for Jaxer: 1. As a "training" language to help people learn server scripting. 2. As a Middle Tier layer that allows you to leverage an existing client-side codebase written in JavaScript. 3. As a way for web designers who don't have a desire to learn other languages to get involved with server coding. 4. As a way to build prototypes when you haven't settled on a backend platform yet. 5. As a way to build small projects that only have minimal server interaction. Will this replace PHP? No. But clearly it has its audience.
4 Sammy Larbi // Aug 6, 2008 at 4:41 PM

"Why do we want to leverage JavaScript on the server?" I'll almost echo what's been said: I'd want to use it because javascript is an awesome language. =)
5 Kiz Oyunlari // Aug 7, 2008 at 7:49 AM

Greetings!..n
6 Kevin Hakman // Aug 7, 2008 at 2:29 PM

@ "Can Jaxer do Flex remoting?" As of Jaxer 1.0 it can. Jaxer 1.0 lets your return content types other than HTML. One case that clearly makes sense is using Jaxer to return JSON data to Flex or Flash, where it can be natively consumed via ActionScript. We've heard from many in the community that doing this using JS natively on the server would be great so that they need not have to know, use, support, staff for another language. Further with Adobe's contribution of Tamarin to The Mozilla Foundation, the Mozilla engine at the core of Jaxer is on track to inherit the capabilities of that JavaScript JIT to compile JavaScript into high performance bytecode, further boosting performance. FWIW-- Jaxer also supports E4X and makes XML services pretty easy as well. Automated SOAP and WSDL stuff ... probably not for Jaxer at this moment in time. --Kevin H @ aptana
7 Carlos Osuna // Feb 13, 2009 at 5:11 PM

Jaxer matters right now mainly because SOAP is being replaced by REST. It's what John Crupi of JackBe calls the "New Front-Tier", that is the tier where you mashup AFTER the server side code has done it's job. In that place you do pagination, screen-scraping (both HTML and Socket-based) and ultimately, integrate client-side Ajax frameworks (like EXTjs and jQuery) with semi-server side code. My two cents.
8 Andrew Powell // Feb 14, 2009 at 11:24 AM

@Carlos I still don't buy it. Just b/c REST is supplanting SOAP doesn't make it matter. Following that logic, ANY application server matters more now. They can all do REST. ColdFusion, J2EE, .NET, Ruby....all of them do REST and do it well. Bottom line is that I've still not seen a convincing argument that tells me Jaxer is worth my time.
9 Aaron // Mar 10, 2009 at 6:57 PM

Ive been using Jaxer for sometime now. The largest benefit I find is how well you can use and display result data. A lot ajax scripts with javascript and php use responseText and so forth. With the javascript, you can easily return arrays, strings, and what ever else. Then take that info, and use DOM code to display it.
10 edward royce // Mar 14, 2009 at 4:20 PM

I've got a lot of complaints about Javascript so I am not one of the ones that want to program the server-side with JS. I think the last think anybody needs is yet another scripting language on the server that has so few rules that enforce good programming practices. Look at the horrifyingly sloppy code used client-side. Now goofing up the client-side makes the app look bad. Goofing up the server-side is infinitely more dangerous.
11 Craig // Sep 1, 2009 at 11:32 PM

As a developer of 15 years, I have touched many languages and maintain the typical disgruntled attitude that any tenured developer would have towards new languages. However, this is not a new language, it is an extension that I actually have a valid use for - parsing "garbage" HTML files server side without using the buggy PHP DOM. With this implementation, I can use jQuery to parse remote content far easier and quicker that I could with PHP.
12 mario // Oct 11, 2009 at 11:14 AM

Agree!!! Data Services (REST, Remoting) to RIAs is the future. We're still in the infancy of web. Browsers are basically the dumb terminals of years past. The browser will be the desktop of the future whether rendered in Flash, HTML 5+ & AJAX, Silverlight, etc.
13 Iulian // Feb 25, 2010 at 11:14 AM

Yap, this would be great. One will learn JavaScript and use it both on server or on browser. There is always great to see new efforts in developing the technology, and YES we need another server.
14 Juan Mendes // May 5, 2010 at 10:12 PM

You seem to be a javascript hater, or at least someone who writes as little javascript as possible and thinks that there are no serious (or smart) javascript developers. However, my RIAs include a whole lot OO javascript. Using the same language on the server and client can allow for better code reuse. There also those of us who happen to love javascript, I wish I could mix in statically typed elements. Another benefit is that I can write a whole website with javascript, and if javascript is not supported, I can use the same rendering methods to render html on the server... I could keep going. @mario, Flash and Silverlight are not the future of the web, HTML 5 is here to make Flash and Silverlight obsolete.
15 Andrew Powell // May 6, 2010 at 6:36 PM

@Juan Welcome to the party, two years later. As far as HTML being the future of the web, did you already forget the browser wars? Are you telling me that HTML5 will be implemented the same across IE, WebKit, and FireFox? Get real. We've been down this road before and we know how this song goes. The Flash Platform and Silverlight let us do so much more than HTML5 ever will. How well did that HTML4 implementation go across browsers?
16 David // Jun 28, 2010 at 6:40 PM

After implementing multiple algorithms in three languages on a recent project, SS JavaScript is beginning to look appealing, particularly for Ajax heavy applications. I'm not giving up PHP, yet, but the idea seems more and more meritorious. Jaxer probably still isn't quite ready for prime time, but I'm sure it is much further along than when this article was written two years ago. As for JavaScript being a sub-optimal programming experience, sure. However, the libraries that have come out in the last few years (e.g. JQuery, Prototype, etc.) have really helped, and I think give the language a much better future.
17 Paul // Jul 16, 2010 at 3:55 AM

I was drawn to this article by its critical dismissal towards server side JS, having searched and found Jaxer as the most promising option. Basically, with libraries like jQuery etc, JS is now much more powerful and geared to AJAX on the client side. So why not leverage the libraries and skills on the server side. It is 2 years on from the original article, and for me it seems time to take this more seriously. The obvious benefits are already highlighted in other comments: same code to verify form data on client and server. This saves duplication of effort and focusses on quality of the code on both ends. Customization from users preferences - do it dynamically on the client, save the state; next time user visits the sever can directly generate the same html+css to the users first page load. In any new RIA, you want client side JS providing optimal responsiveness, and only getting the minimal data from the server to produce that experience. Incrementally the page changes with AJAX using JSON. So with a REST style JSON data access, dynamic updates, dynamic loading of JS, why would server side JS not make a lot of sense. Your middle tier is working with exactly the same data format and functions as the client side. That has to be a big benefit to productive development. So what about the existing alternatives: well the problem is there are many choices with RoR touted as one AJAX friendly and developer friendly framework. I look at this though and am loathed to learn a new language - Ruby - a framework - Rails; and think about optimal client side experience. Perhaps there should be a consideration to further frameworks that gear to rapid and agile development in one language. Maybe that is JavaScript because it is the only client side language. The proliferation of client oriented frameworks shows that its not such a bad language for professional work despite its oddities compared to stricter OOP models. Once you settle on a framework, you work inside that with confidence. As regards HTML5 vs Flash/Flex or Silverlight - there is certainly some synergy from the closeness of ActionScript 3 to JS and a smart body of framework libraries could bridge multiple deployment to both. I have to say I have never looked at Silverlight, so cannot comment - except I don't expect to see that on the iPhone anytime soon anyway ;-)

Andrew Powell

Into The Mind of A Solutions Architect