Monday, June 19, 2006

Speaking of Ajax

I was talking to a friend last night. We touched on a million things and we ended up pondering Ajax for a moment. If you aren't familiar with Ajax, look at Google maps for an example application, or read this quick article: Ajax: A New Approach to Web Applications.

This is definitely a geek topic, but if you are a geek you can see that developers are trying to solve a problem. Developers are definitely yearning for something here, but they are having a great deal of trouble getting to a clean solution. When you talk to developers, what you inevitably hear is how hard and/or tricky Ajax is. What they are trying to do -- create a custom user interface on a remote machine -- just shouldn't be this hard.

One thing we talked about was how, 20 years ago, we had our first system for creating user graphical interfaces on remote machines. It is called "X Windows" and it is still in fairly wide use today. Compared to some of the stuff you see today, X is an incredibly simple system, which is a good thing. Probably the main problem with X from today's perspective is that EVERYTHING is done on the server. So, for example, when you move the mouse, all the mouse motion events travel through the network to get to the server, which processes them. Definitely doable (it worked then and it works now), but it means the server has to do a lot of work that it should not have to do.

The problem with Ajax is that it is trying to graft into a browser window functionality that a browser window was never intended to handle. It seems like a poor fit.

So the question is, when will someone replace the browser with something far easier and more flexible? It feels like what you need is the ability to open a window on the user's machine. Then, as a developer, you choose which parts of your application will run on the server, and which will run on the client. One comment that came out of the conversation last night was, "why can't I drop a jar on the client machine and run it in a sandbox there?" That has shades of ActiveX.

It will be interesting to witness the technology that replaces the hodge-podge we have today. There is such a strong need, it seems like it should pop out of the ether fairly soon.

[PS - when this gets created, it should take the notion of 3-tier systems into account. Meaning that if you want to use something like Akamai, you should be able to run code on the server, and on any of Akamai's servers, and on the client.]

The problem I see with a fat client browser type interface is that it would have to be standardized and unless it was created by a private company there would not be the standarization that would be needed.

Likewise if an open source solution was created how would it be maintained? Look how many Java and Linux versions are out there. Sure, there are APIs out there for open source client software, but you have to muck through 5 million different class libraries to find what you want.

Without standardization you get what we have today with client side fat applications. No one ever has the right runtime environment on their computer and they have to download and install one for each technology that the application was coded in.

I think HTML and JS (or something like them) are the right levels of client and server based processing for a web based app. You get the minimum being sent to the client with the business logic and processing being done through requests to the server. What technology do you use? J2EE? PHP? Doesn't matter. In the end the client receives HTML and JS.
I may be mistaken but wouldn't XUL fit the bill?

Sample App
MB-- You have it backwards: The X server is local, not remote. The client application is remote, not local. Mouse movements only travel over the network when they convey significant information, e.g. "middle button down", that the client application has requested to be informed of.
"So the question is, when will someone replace the browser with something far easier and more flexible?"

A good option may be Adobe Flash:
- it runs inside the browser
- it is cross platform
- it is designed to run on the web
- it's programming language is becoming more and more powerfull
As a software developer, I have an opinion on this subject.

If something as pervasive as XWindows (or a multi-tier derivative) has not been able to establish itself as the de-facto solution to this issue, how likely will any new technology become the defacto standard?

HTML (as yet to be properly supported acrossed all browsers) has only achieved widespread use because there was such an overwhelming need for a more expressive system than Gopher and ASCII (think BBS systems). Now that the need is satiated by a giant mixed bag of technologies there is really no more 'pressure from neccessity'.

Look at airplane cockpits. The vast array of instruments service the purpose. The only real drivers of cockpit advancements are really just the 'gadget' factor. All pilots still have to learn how to use all the old instrumentation and once you learn it, you don't need (or even want) a 'glass' cockpit.

The point is, what is the 'driving force' behind the innovation? If the driving force is to 'AJAX is just too hard to implement', it seems a lot less strong than the forces that led to HTTP and HTML in the first place.

Perhaps I'm wrong (and I'd love to be) but I just don't see an overwhelming force with sufficient momentum to drive us towards a standardized model that would ever penetrate the market enough to 'stick' when we have no less than 5 ways of doing this now (ActiveX, Applets, AJAX, Flash, and RDP). End users don't care how hard it is, just like passengers on planes don't care how bizarre the cockpit is.
Something that helped html explode is "ease". It is so easy anyone can do it. The easier you make the coding, the more people can do it, and it spreads faster than a "difficult" system.

Any new system must have Google's support. One problem with Flash-based systems is that Google will not index them.
I use CakePHP as a PHP framework, and it includes built in AJAX support. It is actually pretty easy to work with.

Most customers want as big an audience as possible, enough people are javascript enabled that an AJAX site is attractive, but they still want fallback functions for non-js enabled browsers. Any new technology will depend on having an audience, a chicken and egg game.
My employer has decided to create a universal front end for their green screen systems using Internet Explorer. Not a good idea and we're practicaly jaded by snafus and crashes. Something better is muy necessary.
> It is called "X Windows"

No. It is called "X" or "X Window System" ( I remember it was explicitly mentioned in the documentation.
I'd say that something like that would be the "Java Web Start". I've been having fun with it to deploy clients to players of a game I wrote.

1. A player clicks a link on my page.
2. An authentication certificate is shown.
3. The client checks to see if the user has the current version of the application in their cache. If not, load only the parts needed.
* This means that if you break your app into multiple JARs, like a windows-specific.jar, a graphics jar, and an application jar. If only the application.jar has a new version, it is the only thing that will download.
4. The application starts up automatically as a full Java application.

It's a step up from a browser level bit of software, but is a heck of a lot more powerful running as a full Java app than an AJAX one.
I'm not quite sure how well this fits your discription, but Virtual Object System is trying to be a replacement (or at least supplement) to current network protocols and applications.
I think the browsers will continue to get more powerful, and the intersection of javascript dialects will just get faster. Also, I suspect the DOM model will get standardized at some point. In short, I think the browser will be the application host.
Post a Comment

<< Home
ARCHIVES © Copyright 2003-2005 by Marshall Brain


This page is powered by Blogger. Isn't yours?