Slashdot Mirror
Better Web Apps With Ajax
An anonymous reader wrote to mention an article on IBM's site detailing the fundamentals of Java-based Ajax. From the article: "This article gives you a good understanding of the fundamental principles of Ajax, and a nuts-and-bolts knowledge of the client and server side components that participate in an Ajax interaction. These are the building blocks of a Java-based Ajax Web application. In addition, you will be shown some of the high-level design issues that come with the Ajax approach."
I'm glad to see another serious technical article on the pros and cons of implementing an AJAX solution. Most everyone who says the acronym "AJAX" usually falls into one of two camps - either the "OMFGZ teh AJAX is so amazing! It will change the interweb!" How? Oh, it allows parts of the page to be updated without a refresh. How interesting. Perhaps you could go a little more in-depth? No? Thanks...
The other camp... too many Slashdotters, IMO... feel the need to flex their superior understanding of the fundamental dynamics of the internet and development and offer this gem: "AJAX is just an assortment of pre-existing technologies. Nothing to see here".
The automobile was just an assortment of pre-existing technologies, and it radically changed the world. It also introduced a whole bevy of new challenges, both technical and otherwise, that we still haven't fully figured out yet. It was not a transportation panacea, and AJAX is no cure-all. But just because it doesn't solve every problem doesn't mean it doesn't have the power to be revolutionary.
Rex is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Okay, let me try to understand this. I'm putting together a brand spanking new web application that would greatly benefit from this technology. But to me, simplicity is the cardinal rule. Why do something in 50 steps, translating data from one langugage to another, when you can just keep it in one?
I have over a decade of experience writing programs that spit out HTML. Why not have my Perl scripts spit out garden variety HTML which can then be substituted appropriately on the page?
It seems to me that would be simple, clean and functional. And it might be a simple matter of saying my content type is text/html instead of application/xml.
Why put the burden on JavaScript on the client, when I already know how to do it on the server? In terms of server processor time, it's just as easy to spit out HTML directly than it is to spit out XML and translate it to HTML on the other side.
And if it is easy to do this, I'd appreciate a link to a tutorial.
Many thanks for your time and ideas.
D
Not so. In both IE and Mozilla XML parsing is done in native code, and is pretty darn fast. Granted, accessing the nodes in that resultant document can be tedious from a development standpoint, but if it's performance you care about, then XML will most certainly be faster. While JSON may be more terse, and easier to deal with as a developer, the browser still ends up having to create a lot of objects in interpreted code, which is a lot slower.
<head>
<title>Ajax app</title>
<script type="javascript" src="ajax.js">
</head>
<body onload="ajaxInit()">
<noscript>
We are very sorry but we, the developers of this website don't understand the web. We would like to provide a non-script alternative for the visually impaired, disabled and people with security smarts but "Ajax" is the future of the interweb and you are not. If you do happen to be visually impaired, disabled or security conscious then fuck off because we are too busy fapping to the latest buzzword to give a shit about you.
</noscript>
</body>
</html>
XML is longer and hard for a javascript interpreter to interpret. Why does everyone want to use it as a wire protocol?
XML might be hard for a Javascript interpreter to interpret, but you don't interpret the XML with Javascript. The XML parsing routines are built into the web browser itself, you just access it with the DOM, same as with all the other Javascript you write.
Yes, that's marginally harder than having i as a native Javascript object, but it has the benefit of being reusable no matter what language you are using. If I also want to manipulate the data with a script, I can write that in any language, using standard XML APIs, not just one that can interpret Javascript.
Given that the difference in effort between the two is so minimal, I prefer to use the more flexible approach.
OK I admit I have a vested interest in this. I wrote an API that did exactly this (custom strings) in IE4 & NN4. This is before IE5 came out and before I'd learned to read w3c specs properly. The API sucked more suckily than anything has ever sucked before. It was a multi-car pile-up of an API. I spent months writing this crap and nearly lost my job and those of my project manager and line manager over it. It was the code no-one else would touch, despite extensive documentation. I wrote this... thing, it used invisible frames or invisible iframes (no I didn't know what XML was supposed to do either), it was supposed to implement some sort of windowing system within a browser.
Now picture this. A windowing system, to run in IE4 or Netscape 4 written by someone who doesn't know what they're doing. You want memory leaks? We had 'em. Most of the clients' machines would die after ten minutes running this. You want race conditions? Yup we those had those ose se e as we.
ll
This thing was so asynchronous it would frequently try to write to HTML elements that didn't exist yet... or that did exist but that the browser had decided they'd disappeared. Netscape 4 was the best at this. If a string was too long suddenly the rest of the dom disappeared into recursion hell and you couldn't drill down into the necessary layer.
In the end I had to write JavaBeans to write the HTML which would then modify itself or not as the case may be...
It was not merely a dog. It stank, whatever way you looked at it. Consequently the company never touched a DHTML project again and when they finally decided to upgrade the site they simply wrote a flat HTML version.
I get flashbacks just thinking about it.
But as a result I learnt that using a non-standard, custom server response may reduce project maintainability. And may reduce the likelihood of you keeping your job.
No.
...
You're thinking, no doubt (?), of trademark law. Trademarks are technology specific. So unless "someone" is creating a cleaning solution and "passing off" that product as Colgates (?) Ajax
Colgate could still sue. But they shouldn't win!
For me (I am the author of japano, an MVC/JSP engine also containing dynamic javascript integration features), the following additional principles are were important:
while (!asleep()) sheep++