Entry tags:
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".
[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
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.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...
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.
[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
no subject
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.
no subject
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.
no subject
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.