JavaScript notes: AJAX and redirects

More fun and games in my ongoing exploration of the world of JavaScript.

At the moment I am playing with AJAX, and found myself wondering how one would deal with calls from clients whose users were not logged in.

After a bit of experimenting I have found that if you do a plain redirect from the server, the browser happily follows it, but stuffs the result into the response passed to your beautiful AJAX code. So the user is left on the page that ran your AJAX, blissfully unaware of what is going on under the hood. This seems fair: the browser is leaving the decision making up to your AJAX code.

The problem being that if you write a nice filter to redirect all attempts to access protected content to a log in page, and your AJAX code is expecting a nice piece of JSON, there will be tears.

For my naked servlet experiment I have been forced to a slightly hacky solution: I have a created a servlet filter for JSON requests. If it finds that you are not logged in then it wraps the URL of the log in page in a piece of JSON and returns that. If the AJAX handler in the browser finds the redirectTo key in the returned object it promptly redirects the browser to the associated URL and does nothing more.

It would have been nice to handle the whole thing by popping up a log in dialogue (via an iFrame?) and not redirect the user to another page: but I am using Google App Engine as my servlet provider, and it would seem that the terms of service require me not to do this.

This doesn't seem very elegant. I am scratching my head to see if I can come up with a better way, but for the life of me, I can't see it. All hints and tips gratefully accepted!

The naked server

Twitter have abandoned Rails for some parts of their application. I didn't find their description of the move to be fully informative.  E.g.: just what do they mean when they say "we launched a replacement for our Ruby-on-Rails front-end"? Predictably the move got a few comments on the Ruby/Rails newsgroup that I subscribe to. The general consensus seemed to be "so what"? I think we might all be missing the bigger picture. Perhaps this is just a logical step in the progression of web applications? If so, what does it mean for their future? To explain my thoughts, some history:

• Way back when, pages viewed in a browser were fairly simple, being mostly static files that were dished up from directories by a dedicated server application.
• Then we needed to make those static pages more dynamic, and to reflect knowledge related to the identity of the person who was viewing those pages. However, browsers were geared to rendering static pages, so we controlled what we could and put the smarts on the server, building frameworks that allowed us to customize each individual page for the viewer. Our first efforts at these frameworks were quite awful, IMHO, but as time went by we got better at it.
• Now web browsers have an common embedded scripting language (ECMAScript): and can create and change whole pages, dynamically, on the fly.

See the flow here? The complexity started on the server, and then tunneled down those tubes to the browser. Currently it is spread across the browser and the server, with JavaScript frameworks, and server side frameworks being combined to produce an application. Do we still need those server side frameworks to compose and build web pages? Surely we can now start to strip the server side of the equation back? In this vision of the future we would create the bones of the site using HTML and CSS, mix in JavaScript, and serve these as static files to the browser, that then makes the magic happen. The browser fetches any data required from the server in an easy to digest format, such as JSON.  The server loses the complexity that it gained to build dynamic web pages. I'm going to call this vision of the future the naked server.  If correct, I predict two things:

• JavaScript/HTML/CSS is going to grow dramatically in importance (and that seems to be happening).
• node.js is going to become popular. Because if you know JavaScript, and you simply want to fetch some data from the server, or write some back, why not use the same language and, possibly, files, on both sides of the tubes?

Over the next few weeks I am going to see if I can write a simple naked server application. Not being a JavaScript guru yet, I think I might stick to my knitting, and use naked servlets for the server side of the equation. Then I plan to add to my knowledge and to build a node.js cloud based application. This should be fun!