![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
...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
pleased
(no subject)
(no subject)
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?
(no subject)
(no subject)
(no subject)
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.
(no subject)
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.
(no subject)
(no subject)
(no subject)
Now upgrading beyond Atom 0.3 That's hardcore mandatory - where the protocol authors actively hunt down and kill errant versions.
(no subject)
(no subject)
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.
(no subject)
precisely. I'm somewhat taken aback by the fuss about it - it's just a new acronym really. Buzz buzz buzz.
(no subject)
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."
(no subject)
(no subject)
The original title was "The Oldest New Technology In Town".
(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.
(no subject)
It's all compromises all the way down...
(no subject)
http://www.livejournal.com/poll/?id=507379&qid=1&mode=ans
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.