Why Jaxer Doesn't Matter

August 6, 2008 · 12 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

12 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.

Andrew Powell

Into The Mind of A Solutions Architect