Why Jaxer Doesn't Matter | Andrew Powell's Flex, Java, ColdFusion, and AJAX Blog

Home

Post

Feeds

RSS

Aug 6Why Jaxer Doesn't Matter

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.

Posted by: Andrew Powell

Categories: Java , ColdFusion , Ruby on Rails , AJAX

Comments

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.

Jim Priest
08/06/08 11:33 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.

Daren
08/06/08 11:40 AM

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.

adampasz
08/06/08 12:28 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. =)

Sammy Larbi
08/06/08 4:41 PM

Greetings!..n

Kiz Oyunlari
08/07/08 7:49 AM

@ "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