A key aspect of AJAX based development is the use of javascript to provide the A in the Jax, all the buzz over web 2.0 is boiled down to one single javascript object now implemented in all major browsers that was first conceived (amazingly) by Microsoft.
XmlHttpRequest
This object allows the set up of an asynchronous http request, essentially a request that is not tied to the state of the currently requested page resource by the users. Allowing separating of requests from the resource allows us to retrieve resources at different times , hence the that Asynchronous word. Anyway , the object is great , has simple methods for passing in the url and does what it was made to do but because javascript forces some interesting issues to crop up.
Closures:
In javascript the closures allow a function declaration to persists the current state of a calling function in order to await a response from another objects execution. Since XHR objects process asynchronously they are tailor made to be used with closures in order to perform important functions. (Like allow background updates to sections of an html page without refreshing the whole page) There you go, all of web 2.0 bubbles out of clever use of this object to provide the illusion of more responsive web applications. Unfortunately, closures are not very elegant programming constructs and as implemented in javascript , they can lead to the leaking of resources (memory) especially when periodic polling using the XHR object of server resources continue to await asynchronous results. Since the reference to the XHR object is always contingent on a previous asynchronous result being returned they (more specifically the associated resources for any variables defined in the XHR asynchronous call object scope) end up piling up in the memory of the browser and in time reduce the responsiveness of the application.
I spent all day today trying to come up with a solution for the slow leak that results from the necessary use of closures and XHR objects in my management UI, what struck me is just how many articles there are online that have a mistaken understanding of what is going on. There are a few great sources and then a ton of misnomers, many believed that simply setting objects after use would solve the problem but the particular invocation steps taken by javascript thwarts that potential solution. This brings me to a funny truth, the media is all in a tizzy sometimes over making a distinction between AJAX and javascript and anyone who has done AJAX knows you do it with javascript (that's the "J" ) It is funny how often this mistake is made in the trade magazines that are supposed to keep technology professionals aware of the latest trends. It just underscores an observation I've made since I was an undergraduate electrical engineering student.
Things are a lot easier than most people believe them to be.
Learning a thing always brings it from the stratospheric realm of the impossible to the trivial the difference in perceptions lies in how much relative work is done by individuals to get to a given level of understanding of the topic, but once that knowledge is had ..what was hard or impossible, many times looks exceedingly easy.
XmlHttpRequest
This object allows the set up of an asynchronous http request, essentially a request that is not tied to the state of the currently requested page resource by the users. Allowing separating of requests from the resource allows us to retrieve resources at different times , hence the that Asynchronous word. Anyway , the object is great , has simple methods for passing in the url and does what it was made to do but because javascript forces some interesting issues to crop up.
Closures:
In javascript the closures allow a function declaration to persists the current state of a calling function in order to await a response from another objects execution. Since XHR objects process asynchronously they are tailor made to be used with closures in order to perform important functions. (Like allow background updates to sections of an html page without refreshing the whole page) There you go, all of web 2.0 bubbles out of clever use of this object to provide the illusion of more responsive web applications. Unfortunately, closures are not very elegant programming constructs and as implemented in javascript , they can lead to the leaking of resources (memory) especially when periodic polling using the XHR object of server resources continue to await asynchronous results. Since the reference to the XHR object is always contingent on a previous asynchronous result being returned they (more specifically the associated resources for any variables defined in the XHR asynchronous call object scope) end up piling up in the memory of the browser and in time reduce the responsiveness of the application.
I spent all day today trying to come up with a solution for the slow leak that results from the necessary use of closures and XHR objects in my management UI, what struck me is just how many articles there are online that have a mistaken understanding of what is going on. There are a few great sources and then a ton of misnomers, many believed that simply setting objects after use would solve the problem but the particular invocation steps taken by javascript thwarts that potential solution. This brings me to a funny truth, the media is all in a tizzy sometimes over making a distinction between AJAX and javascript and anyone who has done AJAX knows you do it with javascript (that's the "J" ) It is funny how often this mistake is made in the trade magazines that are supposed to keep technology professionals aware of the latest trends. It just underscores an observation I've made since I was an undergraduate electrical engineering student.
Things are a lot easier than most people believe them to be.
Learning a thing always brings it from the stratospheric realm of the impossible to the trivial the difference in perceptions lies in how much relative work is done by individuals to get to a given level of understanding of the topic, but once that knowledge is had ..what was hard or impossible, many times looks exceedingly easy.
Comments