The AJAX technology stack is gently establishing itself as a de facto standard for developing Rich Internet Applications. Though, AJAX sure needs to mature a little bit more to become mainstream and to let common usage and design patterns emerge. I recently went through an interesting blog entry on Joe Walker's blog where the author states that his current project contains 2% HTML code (~100 SLOC), 4% Java code (~200 SLOC) and 96% Javascript code (~4,500 SLOC).
(credit to Christian for providing the link)

What this tells me is that as AJAX applications will gain in popularity and be increasingly deployed across numerous academic and industrial settings, AJAX developers will not only need effective tool support for dealing with all that complexity but they would also greatly benefit from integrating technologies with proven added value, such as AOP, into their JavaScript code. I won't delve into the details of AOP now as there are currently enough resources on the web that you can read during your next 15 reincarnations.

When I look at a modern AJAX application what I usually see is lots of JavaScript code featuring functions, objects and prototypes where pretty much all concerns are mixed up. The only way of modularizing and organizing a little bit JavaScript code is by using distinct physical files that contain only related code and that can be included in HTML files when their code is needed. Period. You have actually no other choices than to mix your networking, event handling and layout concerns in the same JavaScript file. For this reason I have started writing my own AOP framework for JavaScript which hasn't been baptized yet. Then, as I was halfway through my AOP journey, I came across an interesting article that made my day on dotvoid.com titled Aspect-Oriented Programming and JavaScript, which explains that AOP support has been included into the Toxic framework. The support is still limited compared to what other frameworks, such as AspectJ, provide but in my opinion it covers 90% of the cases where aspectual code is needed.

Basically, the Toxic framework provides the following support for writing aspect-oriented JavaScript code:

• amendment of the static structure of JavaScript code by using the Aspects.addIntroduction() function.
• amendment of the dynamic structure of JavaScript code by using the Aspects.addBefore() and Aspects.addAfter()functions.
• modification of the control flow of JavaScript code by using the Aspects.addAround() function.

Introduction support is pretty complete whereas it is currently only possible to define an advice on method calls and nothing else. Moreover, there is no way to explicitly declare pointcuts. As I said, this is really far from being dramatic as Toxic AOP support should cover most of our needs for now. I thank wholeheartedly dotvoid.com for including AOP support into their Toxic framework. That should get me going while I finish up my framework since I don't have any a fixed release date planned as I have to deal with a pretty hectic schedule myself.

If anyone knows of any other worthy AOP frameworks for JavaScript, please drop me a comment.

Update:
[Added the link to Joe Walker's blog provided by Christian.]

In one of their recent post-JavaOne articles, eweek interviewed James Gosling about the future of the Java language and what we might find in the next two releases (i.e., Mustang and Dolphin) of the Java platform.

I have been very surprised (read disappointed) to discover that Gosling doesn't consider direct XML support a priority. Gosling says:

Direct language support for XML has been a debate for some time. All these things at an abstract level kind of sound like the thing to do. When it comes down to the details, one of the problems ends up being that using Java today you actually get pretty good access to XML. And really what it would end up being is sort of syntactic sugar that makes certain constructions simpler, but can you come up with something that actually makes people's life better by enough that it's worth adding that baggage?

I just hope that James was joking and that he gets his head out of his real-time Java stuff for a moment and looks at what people are asking for... I have already shown (+ here) that DOM programming is not at all simple and straightforward for developers to use and that something along the lines of IBM's XJ would be much appreciated.

In the meantime, Kirill Grouchnikov, a community lead in the Java WS and XML community, wrote a very nice blog entry on Dolphin's native XML support that somehow backs up what I wrote in an earlier entry on the need for native XML support in Java. Kirill goes one or two steps further, though, in that he asks for annotation support and XML autoboxing, two things that I find very, very cool, indeed. Thanks for your wise insights, Kirill!