Ajax: A New Approach to Web Applications
A collegue of mine who’s a graphical designer (or art director, as his card tells us) refered to an article about Ajax. According to the article it’s based on HTML, XHTML, CSS, DOM, XML, XSLT, XMLHttpRequest and Javascript binding these technologies together.
I don’t care what the writer has to say about the technologies, but I think he has a point when he says that this is going to be the next big thing in the world of the web development. Or at least I hope so. He refers to GMail, Google Suggest and Google Maps. Although non of those websites has an awesome looking design like all Microsoft products have, the user experience certainly rocks my world! I cannot believe how fast GMail and Google Suggest are, how easy it is to work with them.
The article is a good read and it’s certainly something companies can benefit from, when adapted. Especially when they adapt early.
Dennis is an independent consultant and software architect who loves building distributed systems and the challenges they bring. What he learns he tries to share via numerous articles, blogposts, presentations and workshops.
Certainly a very nice article!
I love people (and companies) that try to widen technical boundaries.
And trying to make webapps more user friendly this way looks very promising…
But I’m stuck with a few questions:
1.
Is the ajax engine a standard tool? If not, does this mean every company has to build its own?
2.
It relies heavily on Javascript, right? (and probably XHTML, CSS and DOM manipulation)
Then I must oppose Jesse James by saying that a big challenge will be technical. Just try to make a perfect website for MSIE6, FireFox and Safari (Apple), the most popular browsers and you will run into more than one problem…
Anyhow, I DO like this Ajax, and I hope it forces MSIE, FireFox and Safari to agree on the same implementation of the W3C standards.
BTW: does anyone have a ready-to-use Ajax engine I could ‘borrow’…?
AJAX = Old technology 😉 At the bank I work for we have used a similar approach since 2000. We call our framework R***SCO. SCO stands for Server Communication Objects and R*** stands for part of the name of the Dutch bank that is to remain anonymous. Hard guess, hey?
Our technology dates back from before the XmlHttpRequest days. We designed a method using posting requests to and from hidden frames and returning data as client-side JavaScript code generated with ASP with server-side JavaScript. This can be fast because Internet Explorer is very good at parsing and interpreting JavaScript. With this data dynamic parts of the page presentation are generated using DHTML.
The reason we did this back in 2000 because we were confronted with the demand that the output of dynamic web pages could not be larger than 5-10 kB due to very strict bandwidth restrictions. So we had to separate presentation code from data. Static code was preloaded on proxy servers at remote locations. Some applications loaded some 400 kB of static HTML and JavaScript code from the proxy server or the browser cache on startup and just a couple of kB with dynamic data from the web server.
Unfortunately this technology is proprietary to the R*** bank so it cannot be borrowed. Heavy use of frames and clientside JavaScript has fallen out of favour with the enterprise architects of the bank. Also our code is very IE4-6 specific. So now we use plain old ASP.NET 😉
I know there are examples of stuff that’s like Ajax, pre Ajax or anything that resembles Ajax in any other ways. I did not know you guys at R*** created such a framework. Must’ve been h*** to create it, and all because of the low bandwith.
As you know, I’m at R*** as well, and our security webservice was transfered to another location in our little counrty. Some stuff takes 1000% longer to process! 😉