Log in

No account? Create an account

Previous Entry | Next Entry

Another dose of shameless self promotion...

...as the Guardian prints my piece on AJAX, the technology behind Google Maps (and chunks of this site). So if you want a quick introduction to the future of the web, take a look at "Old dog learns new tricks".
The web has been wonderful for reading information but not so good for more complex tasks such as filling in forms or handling email. That's because everything has to be sent from the remote web server: booking holidays, online banking and similar applications often involve filling in the boxes, clicking a button, waiting for a result ... then filling in all the boxes again.

But this is starting to change with the arrival of responsive new systems such as Google Maps and Flickr. These are, effectively, applications which run inside your web browser, meaning you don't have to refresh the whole page to get the information you want.
Read on for what AJAX means for the future - and a little scoopette on what it means for Microsoft's Longhorn and its Avalon user interface...

[as always you can find an archive of my Guardian features here.]

I'm actually quite amused that I've got what's essentially a developer piece into a national newspaper


( 20 comments — Leave a comment )
Jul. 21st, 2005 03:28 am (UTC)
Or instead of Ajax, look at Greasemonkey - the future of disastrously unreliable browser exploits. After 1x1spacer.gif and all-pervasive Flash sites, it's the new stupidity for the new generation.
Jul. 21st, 2005 03:41 am (UTC)
The idea behind Greasemonkey is not necessarily bad, and the API calls which allow the exploit do also allow useful functionality in user scripts such as the excellent Book Burro, but I agree that it's a glaring hole that should never have been allowed in a release.

To some extent, GM user scripts should be installed with the same caveats that any browser extensions have. Do you know who wrote the code? Have you verified that the code is not malicious?
Jul. 21st, 2005 03:44 am (UTC)
The problem AIUI was that those GM_ API calls were available to all JavaScript, not just GM scripts.
Jul. 21st, 2005 03:59 am (UTC)
That's the most important part of the problem, but even if GM_* weren't available to the whole JS environment, there would still be opportunity for malicious user scripts.
Jul. 21st, 2005 03:58 am (UTC)
I don't trust Greasemonkey an inch. A bunch of web coders pretending to be real software engineers and in way out of their depth.

You don't fix exploits like that by testing and issuing patches. You do it by understanding what the hell you're doing from the outset and having an architecture that is robust from the outset. You know where the boundaries of trust are, they're so obvious that anyone can point to them, and they're followed through into the implementation. The attitude of "we'll have to add another little security test here, then it'll be right" has never worked. Just read your history from before '99 (ask your grandad)

We curse M$oft often enough for their buffer overflows and random holes, but at least they have some notion at recruiting time of the distinction between real engineers and someone who wrote a few lines of code that appeared to work.
Jul. 21st, 2005 04:13 am (UTC)
I agree. It's clear that the GM authors didn't take a principled stance on security, and the ad hoc way in which features have been added has led to the current state. It was obvious that they were getting into dangerous waters when they created GM_* equivalents for functions like XMLHttpRequest in order to get around the existing Mozilla security model.

Sentences like "Unlike the XMLHttpRequest object, GM_xmlhttpRequest is not restricted to the current domain; it can GET or POST data from any URL" (from Dive Into Greasemonkey) should have been ringing warning bells considerably earlier than they did.
Jul. 21st, 2005 04:51 am (UTC)
Absolutely. Allowing access to the user's own machine was one big problem - allowing JS from the page itself to use GM was another. The combination is fairly obviously lethal.
Jul. 21st, 2005 12:44 pm (UTC)
I see there is a "mandatory update" to Greasemonkey today...
Jul. 21st, 2005 02:19 pm (UTC)
Hardly "mandatory"

Now upgrading beyond Atom 0.3 That's hardcore mandatory - where the protocol authors actively hunt down and kill errant versions.
Jul. 21st, 2005 03:38 am (UTC)
Good article, that...
Jul. 21st, 2005 04:20 am (UTC)
Not bad for the Grauniad (home of Jack S, FFS), but it would look a bit ragged in a tech journal.

In 1998, Microsoft released Internet Explorer 5, which introduced XMLHTTP [...]The browser document object model arrived around the same time, and was used for Dynamic HTML.

DOM and DHTML came in with IE 4, two years earlier. The difference was that IE 4 could manipulate "the page" and "the window", but that was the limit of its scope. IE 5 and XMLHTTP (actually some controls did this as early as '97) extended this by allowing HTTP requests from within the page. That's the crucial piece that AJAX is using, not dynamic page tweakery in general.

Without this feature, the web is based around a single-threaded synchronous model. You request by HTTP, you receive by HTTP, you get a page that then sits there with no external influences. AJAX isn't new DOM stuff, it's new HTTP stuff - that's the crucial difference, you're freed from this single-threaded client model.

Of course there's nothing new in AJAX either, just some welcome standardisation. I've been doing these things commercially myself since '99. Before The Crash there was a bagful of push technologies and client integrated subordinate requestors around as well, thankfully all dead and buried now. AJAX just took the one obvious right way to do stuff, wiped its nose and wrote the book on it.

developers need to add complex business logic to handle asynchronous connections,

I have no idea what that's meant to mean, but it's written by someone who doesn't know what "business logic" means.

AJAX does NOT "provide" new business logic. It might transport some server-side business logic out to the client, it will more likely proxy some server-side BL so that it appears to be executing on the client and it integrates better with a client-side user experience. It's not a business-logic layer though and business logic has nothing to do with the core of this asynchronous transfer business.

The XML data sent between client and server can be made up of snippets of data, rather than a whole page of HTML. This keeps server load to the minimum

Or alternatively, your server gets hammered to death in an orgy of trivial round-tripping.

AJAX _can_ be used for good. What it will actually do in most businesses is to have clueless developers (go read "Bitter Java" for a good background on this problem) build badly architected AJAX apps that hammer a new server request after every keypress.
Jul. 21st, 2005 04:41 am (UTC)
> Of course there's nothing new in AJAX either, just some welcome standardisation.

precisely. I'm somewhat taken aback by the fuss about it - it's just a new acronym really. Buzz buzz buzz.
Jul. 21st, 2005 04:55 am (UTC)
The community and buzz is new though. The existence of AJAX is causing stuff to happen that wasn't happening beforehand.

Mid-2001 I had no end of PHB resistance to doing "AJAX-alike" stuff, even though it was a damn good solution. Now I could just say "Ah, AJAX is the obvious roadmap solution to this problem space" and away they go.

The Grauniad article could be paraphrased as "New tech stuff this week: AJAX. It does some web programmy thing. Not just a toy - people in suits will employ people in cheaper suits to use it."

Jul. 21st, 2005 05:19 am (UTC)
all fair points
Jul. 21st, 2005 12:42 pm (UTC)
Yup, Which is what I was saying in that piece!

The original title was "The Oldest New Technology In Town".
Jul. 21st, 2005 12:41 pm (UTC)
developers need to add complex business logic to handle asynchronous connections

I have no idea what that's meant to mean, but it's written by someone who doesn't know what "business logic" means.

I think you misread me. AJAX just provides the call back framework - you need to write the code to actually handle and display the data (and handle process flow statefully). That's adding business logic - and it needs to be complex to marshal possible responses from different sources at different times. Sure, it's just an MVC pattern at heart, but the asynchronous callback model isn't something for the neophyte.
Jul. 21st, 2005 02:40 pm (UTC)
AJAX does not provide platform tools to implement business logic. Any AJAX application that does build business logic into it is badly mis-designed. AJAX just isn't the place to do that stuff.

You can delegate business logic, which is what tools like <bigwig> and PowerForms do. AJAX doesn't have much support for this, but you can do it - it's useful too. What AJAX mainly does though is to proxy business logic. The logic remains on the server, the logic itself is never deployed to AJAX, and AJAX just makes rapidly interactive querying of it. This is a good halfway-house - you trade bandwidth (pipes and servers) for simplicity. But none of this is moving the business layer into AJAX.

More obviously, relating "business logic" to "asynchronous connections" is just plain wrong. I appreciate the shortness of this article and the need to address the relevant audience, but why waste words on things that are irrelevant or just red herrings ? When did it ever take 3 seconds to move to a mouse, and haven't you heard of keyboard shortcuts?

Nor is AJAX particularly an MVC tool. We've got plenty of those already - AJAX is something new. Of course it can do that too, but that would be like explaining AJAX's masterful new ability to pass XML fragments around the web (oh, you did - funny you didn't mention SOAP). MVC is 20+ years old and we've moved beyond it. AJAX is the toolset so that you're no longer limited to a simplistic MVC and can do more interesting things through a smarter Viewer.
Jul. 21st, 2005 04:51 pm (UTC)
You're still misreading.

All I'm saying is you need code in addition to any AJAX implementation to actually do anything useful. You're going to need client sode code as much as you need server-side code - I'm talking about putting code alongside AJAX, not inside it...

With regards to some of your other points...

Sure on the SOAP front I could have mention the IBM work on using E4X for handling SOAP in AJAX, but I'm more of the opinion that AJAX is best for working with raw XML data-snippets. Until we get E4X into every browser we won't be able to handle the WS-* protocols that will be driving the SOAP world - at least not without massive and unwieldy libraries.

The three-second thing, well it was more about using AJAX for new user experiences. We need to experiment, and I found it an interesting attempt - and potentially useful for call centres.
Jul. 21st, 2005 12:44 pm (UTC)
If I was doing it for my web column in ADA it would have been substantially longer, with plenty of sample code. However, we have to work with the limitations of the medium - 1100 words and no code - and target a non-technical audience.

It's all compromises all the way down...
Jul. 22nd, 2005 10:59 pm (UTC)
All well and good Simon, but when do I get my request from here...


answered? ;-)

If nothing else, the article generated an interesting thread here, from which I possibly learnt more about AJAX, but then I'm not the target audience of your article. I doubt I'm the target for AJAX either. I guess I'm just too much of a purist, and it seems a trifle cludgy.
( 20 comments — Leave a comment )