Capping IT Off › I thought I've seen it all...

Capping IT Off

Capping IT Off

I thought I've seen it all...

6 Comments
Category : Custom Software Development

There are these moments in your life when you are in awe of what technology allows us to do. I remember a couple of years ago that a user on a forum was asking how to do some server side stuff in his web browser but without reloading the browser. We “experts” were all rolling our eyes and thinking, gosh yet another newbie that does not understand how web development works. You can imagine when the whole XMLHttpRequest and Ajax stuff became mainstream that we had to rethink the way we were designing our web applications. In my current project, we have to write complex validation code for validating complex form input. The very annoying thing is that we have to write the server-side Java validation code, but replicate identically the same validation code with client-side JavaScript. This results that sometimes there is a small difference between the server- and client-side validation.. As you can imagine, leading to frustrating debugging sessions. I remember that I said to my colleague “It would be so cool if we had for instance the same JavaScript validation code that we could reuse on both client- and server side. True, we could send our client-side validation to the server with Ajax, but that would require some server roundtrips and alas, most banks are not really eager to use Ajax. So I sadly continued wondering why there are so many issues with getting the same buggy Double check in JavaScript and Java 1.4… Yesterday, I bought a new Apple computer and I was happily installing and configuring my Eclipse environment and of course the must-have for every web-developer: Aptana! One of the big problems with JavaScript and Ajax programming is that there are barely good development environments. Syntax highlighting can be handled by most IDEs, but when it comes to complex code completion and assistance, nothing can beat Aptana as far as I know. You can either install it standalone or as an Eclipse plugin. So I surfed to the website of Aptana to get my plugin, but suddenly I stumbled on Aptana Jaxer. What caught my I was the following sentence: “Jaxer, The world’s first Ajax server”. My heart stopped beating, my whole (young) life passed by and I was thinking: “gosh, I thought I’ve seen it all…” Here a short feature list from the website that says it all:

  • Write entire applications or presentation layers in Ajax
  • Full DOM and JavaScript on the server
  • Seamless communications between browser and server
  • Access existing pages written in other languages like PHP, Java, or Ruby on Rails
  • Share validation code on the browser and server (my favorite!)
  • Database, file, and socket access from JavaScript
  • Open-source, standards-based, and uses the APIs you already know
Basically, Aptana made it possible that the typical client-side concepts like DOM and JavaScript functions become first-class citizens on the server side. You can easily write a function that can be shared by both client- and server-side and on the server you can manipulate the client-side DOM elements. So basically, you share some kind of common namespace between the server and client. Watch this screen cast for getting an idea. So where can this take us? I don’t think that this will conquer large financial institutions or other companies with large web applications running on Java. Most of them are still struggling with taking a stand towards plain Ajax. However, I do see a big market at first for these little applications that run on platforms like Facebook or OpenSocial, widgets, mashups, etc. I don’t know the product well enough to judge how everything is arranged with security and scalability. I can imagine that it could give developers some more head aches related to security and hacking, since it became easier to pass malicious data to the server. It would be interesting if Aptama would rebuild the (in)famous Pet Shop Store with this technology or if they can announce a major website that adopts this technology… Aptana, take the challenge!

About the author

L. Provoos
L. Provoos
View all my posts
6 Comments Leave a comment
Uri Sarid:
OK we will!
There are a few Ajaxified pet shops already, but the Ajax aspects have always been restricted to the browser, with something else happening on the server. With Jaxer we'll have a thoroughly Ajax app, end to end.
But we'll also explore a different approach: we're working with DWR (Direct Web Remoting) to offer Java integration on the server side, so we could take the Java pet shop and Ajaxify it too, *without* exposing any Java APIs to the internet.
That's actually part of the security advantages of Jaxer. You're right that Jaxer makes it easy to pass data to the server, but that doesn't make it less secure: actually when everyone has to invent their own data-passing mechanism they're likely to introduce holes. With Jaxer it's simply JSON and it all goes through the same path through the framework so if you like you can enforce extra security there. In fact Jaxer makes for a very interesting AOP framework for security, compliance, monitoring, etc... we've just begun discussing it at <a href="http://www.aptana.com/jaxer/security" rel="nofollow">http://www.aptana.com/jaxer/security</a> and we'll have a lot more to say about it soon.
As for major apps, Jaxer's just been out for a few weeks but we certainly hope to show major web sites adopting it. Our approach has been a grass-roots one, letting the technology prove itself. We're working to show some benchmarks and illustrate scalability not just by talking about it but by deploying our own scalable apps.
Stay tuned!
Mark Nankman:
Audible Ajax (http://media.ajaxian.com) has interviewed the Aptana boys.
Personally, I am not convinced about Jaxar's value yet. I share Lee's amazement. Picture me in the train, listening to the interview on my iPod and suddenly saying rather loudly: "No Way!"
On the other hand, I have been preaching on my own blog that my ideal environment for RIA development is centered around a single programming language. One language for both frontend and backend. Why couldn't that language be Javascript? For now, I will just ignore the (indignantly spluttering) classic software engineer inside me...
Lee Provoost:
I'm glad to see that Mark (one of our thought leaders in the RIA space at Capgemini!) shared my "wow" reaction :) However, as a more back-end engineer I do share the hesitation that Mark expressed in his last sentence. I can imagine that software architects at large financial institutions will think that this is a security nightmare :-) On the other hand, banks and adopting new technology.... So Uri I can only say: prove that our hesitation is unnecessary!
We'll follow this with a close eye...
Lee Provoost:
ps Mark, I can perfectly imagine you already scaring the people around you in the train... :-p
Mark Nankman:
It is interesting to see that Javascript, in spite of its shortcomings, is seeping through to the lower application tiers.
There exist several Javascript engines for several programming languages: Mozilla's Rhino for Java, Mozilla's SpiderMonkey for C (based on Tamarin: <a href="http://www.mozilla.org/projects/tamarin)" rel="nofollow">http://www.mozilla.org/projects/tamarin)</a> and Javascript::Engine for Perl (these are just the ones that I know about, are there more?)
Both the C en Perl engine claim that they implement the pure ECMAscript standard. This means real OO and type safety (the SE inside me whoops).
Lee Provoost:
Mark, don't forget the implementation of the JSR-223 spec in Java 6 where you can use for instance JavaScript code in Java.

Leave a comment

Your email address will not be published. Required fields are marked *.