Discussion on:
View:
Show:
In my experience there are more trips to and from the server, but it's much more transparent to the user so it *feels* like fewer round trips which, of course, if the big benefit.
I am not sure there is a fair comparison between AJAX (and client-side processing in general) and server-side only processing.
When one goes to client-side processing it is to enhance the user interface over what would be provided in a pure server-side only approach. Due to the addition of functionality, there will probably be an increase in trips to the server. If the same functionality were implemented in both AJAX and pure server-side, I suspect the number of trips would be the same, but the AJAX trips should carry significantly less data.
The intent of AJAX is provided enhanced user interfaces while maintaining an acceptable level of performance, both to the user and as load to the server. This will always be a highly subjective measure.
When one goes to client-side processing it is to enhance the user interface over what would be provided in a pure server-side only approach. Due to the addition of functionality, there will probably be an increase in trips to the server. If the same functionality were implemented in both AJAX and pure server-side, I suspect the number of trips would be the same, but the AJAX trips should carry significantly less data.
The intent of AJAX is provided enhanced user interfaces while maintaining an acceptable level of performance, both to the user and as load to the server. This will always be a highly subjective measure.
Unless I'm misunderstanding something, I've been doing this for years with Perl, Javascript, and IFRAME tags in order to update only the changed parts of a page instead of having to reload the whole thing.
I occasionally get the feeling that some of these "new" technologies are being invented by people who just don't know that something can already be done - without grabbing more memory and creating more complexity by adding Yet Another Leggo to the toy box.
I occasionally get the feeling that some of these "new" technologies are being invented by people who just don't know that something can already be done - without grabbing more memory and creating more complexity by adding Yet Another Leggo to the toy box.
1. Inline frames don't work with some browsers for which AJAX does work.
2. You still get page load delays that look clunky with iframes where you don't with AJAX.
3. You can't have dynamically variable reloading areas with iframes.
4. There are a lot of people who greatly dislike frames of any kind and won't have any issue with AJAX.
5. You can't do all the same stuff in terms of how the page loads differently with iframes (for an example, have a look at how Google maps work).
6. I'm sure there's more, but that's what comes immediately to mind at this moment.
2. You still get page load delays that look clunky with iframes where you don't with AJAX.
3. You can't have dynamically variable reloading areas with iframes.
4. There are a lot of people who greatly dislike frames of any kind and won't have any issue with AJAX.
5. You can't do all the same stuff in terms of how the page loads differently with iframes (for an example, have a look at how Google maps work).
6. I'm sure there's more, but that's what comes immediately to mind at this moment.
I've written both internal and external business web apps using this approach ever since the XML 3 Active X parser came out three/four years ago (or so). What I have learned:
1. People (remember non-techies who use these apps every day) loved! not having to wait (as long) for the updated screen. Even dial-up tests were "faster" because only necessary portions of the UI and/or data were redrawn or sent/received.
2. You can balance client side processing of data and maintain secure business logic on the server. So, it's a mini form of "distributed computing" if you will. Client would package XML, send to server. Server code opens packages, consumes, calls SP and sends XML child node of form data to DB.
3. Once on a screen: Only need to package form data to ship back to server (Like #2, used XML as it's handy). When a request for data or a new screen was required, could use a query string or XML request and only needed to ship XML record from DB through ASP code to client. DHTML (generic Javascript function) parsed XML and dropped values into input controls (based on type) onscreen.
4. Any backend server side logic should be usable. ASP, ASP.Net, PHP, Pearl, etc. Assuming you have the XML Active X component (or write to handle Firefox, etc.). Which, I know is as evil as a snake bite to some developers. (Glad to see other browsers are adopting the concept though.)
5. Your DHTML (DOM) skills will increase four fold and you'll wonder why it's never been done like this before. Really, I was surprised.
6. Less data is transferred from server to client and vice versa per request. Network people will like that bar-none.
7. Development time was actually reduced in some areas while using ASP classic because of code reuse on the client and only needing one server side ASP file to get and push data to the DB.
8. If engineered correctly, menu requests will redraw the "lower 2/3" of the screen. Submit buttons will only package and ship form data results to the server. Only a bit flag and/or error message is necessary as a response which is then handled on the client. All while maintaining security.
9. I actually got to the point where I could put error messages in Stored Procedures and pipe that back to the client to appear on an alert box. Need to change the message? Update the SP (in one spot), error messages propogates wherever the SP is used and no code changes required.
What was bad:
1. Like the article said, server side debugging was a pain (when it was actually necessary) as you had to go through a few steps to include the page to actually get the error message to pop-up with the correct line number. I liked reading about the debugging features in the new Atlas concept.
2. Other developers unsure of the concept because it was so "foreign" to them. Also see bad #1. Take the blinders off already. Not every developer is Garth from "Wayne's World"...'We fear change.' Are we?
3. Public apps back a few years ago required IE/XML object to work right. Touchy subject so architecture analysis was used was determined up front based on client feel and browser type.
4. Not every environment is conducive to the technology architecture. So, it's another tool in the belt and can be used where appropriate.
1. People (remember non-techies who use these apps every day) loved! not having to wait (as long) for the updated screen. Even dial-up tests were "faster" because only necessary portions of the UI and/or data were redrawn or sent/received.
2. You can balance client side processing of data and maintain secure business logic on the server. So, it's a mini form of "distributed computing" if you will. Client would package XML, send to server. Server code opens packages, consumes, calls SP and sends XML child node of form data to DB.
3. Once on a screen: Only need to package form data to ship back to server (Like #2, used XML as it's handy). When a request for data or a new screen was required, could use a query string or XML request and only needed to ship XML record from DB through ASP code to client. DHTML (generic Javascript function) parsed XML and dropped values into input controls (based on type) onscreen.
4. Any backend server side logic should be usable. ASP, ASP.Net, PHP, Pearl, etc. Assuming you have the XML Active X component (or write to handle Firefox, etc.). Which, I know is as evil as a snake bite to some developers. (Glad to see other browsers are adopting the concept though.)
5. Your DHTML (DOM) skills will increase four fold and you'll wonder why it's never been done like this before. Really, I was surprised.
6. Less data is transferred from server to client and vice versa per request. Network people will like that bar-none.
7. Development time was actually reduced in some areas while using ASP classic because of code reuse on the client and only needing one server side ASP file to get and push data to the DB.
8. If engineered correctly, menu requests will redraw the "lower 2/3" of the screen. Submit buttons will only package and ship form data results to the server. Only a bit flag and/or error message is necessary as a response which is then handled on the client. All while maintaining security.
9. I actually got to the point where I could put error messages in Stored Procedures and pipe that back to the client to appear on an alert box. Need to change the message? Update the SP (in one spot), error messages propogates wherever the SP is used and no code changes required.
What was bad:
1. Like the article said, server side debugging was a pain (when it was actually necessary) as you had to go through a few steps to include the page to actually get the error message to pop-up with the correct line number. I liked reading about the debugging features in the new Atlas concept.
2. Other developers unsure of the concept because it was so "foreign" to them. Also see bad #1. Take the blinders off already. Not every developer is Garth from "Wayne's World"...'We fear change.' Are we?
3. Public apps back a few years ago required IE/XML object to work right. Touchy subject so architecture analysis was used was determined up front based on client feel and browser type.
4. Not every environment is conducive to the technology architecture. So, it's another tool in the belt and can be used where appropriate.
Hello!
I need to note that when we want to have static page and reload only part of content then yes - ajax is power, and a lot of programmers try to use it where it is possible. But it is difficult to rebuild old libraries for framework 1.1(i have a lot of one) to implement fully nice system on ajax technology. So i and rest asp.net developers are waiting for the first issue of ATLAS from Scott Guthrie's band. You can read a lot of blogs from Scott about every idea that they developed on this moment here: http://weblogs.asp.net/scottgu/
Sincerely, LukCAD
I need to note that when we want to have static page and reload only part of content then yes - ajax is power, and a lot of programmers try to use it where it is possible. But it is difficult to rebuild old libraries for framework 1.1(i have a lot of one) to implement fully nice system on ajax technology. So i and rest asp.net developers are waiting for the first issue of ATLAS from Scott Guthrie's band. You can read a lot of blogs from Scott about every idea that they developed on this moment here: http://weblogs.asp.net/scottgu/
Sincerely, LukCAD
The article mentioned Ajax.NET library from http://ajax.schwarz-interactive.de/csharpsample/default.aspx, but there is better implementation "My Ajax.Net" by Jason Diamond http://jason.diamond.name/weblog/
See features of "My Ajax.Net" highlighted at http://west-wind.com/weblog/posts/2658.aspx
See features of "My Ajax.Net" highlighted at http://west-wind.com/weblog/posts/2658.aspx
I am not a programmer but a UI designer.
When I saw the new Google interface for the personalized home page (which I assume is Ajax) I was blown away. I think we are about to see a major shift in the UI paradigm for the web.
I wrote a brief article about why I thought it was so important. If anyone is interested they can read it at http://www.customercentric.biz
Charlie
When I saw the new Google interface for the personalized home page (which I assume is Ajax) I was blown away. I think we are about to see a major shift in the UI paradigm for the web.
I wrote a brief article about why I thought it was so important. If anyone is interested they can read it at http://www.customercentric.biz
Charlie
i dont think its a big paradigm shift...Flash Remoting / RIA's have focused on better UI systems for years.
and its quiet mainstream.
and its quiet mainstream.
It can't be ajax, I use the google customised homepage and I do not allow ANY clientside scripting.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
