6 Deadly AJAX Drawbacks: Are you aware?
AJAX combines the power of existing Web technologies to build powerful user interfaces that offer benefits often found in desktop applications. Over the past couple of years, Web developers have embraced AJAX in their own development efforts as well as via third-party toolkits.
Once you use an application built with AJAX, it’s easy to see the benefits: the user experience improves, as page reloads are reduced, and features such as automatic type-ahead facilitate data entry.
Some developers view AJAX as the silver bullet for every scenario. However, AJAX introduces its own set of hazards in various areas, which include: development time, browsing history and experience, search engine interaction, accessibility, server load, and security. Let’s take a closer look at each of these 6 areas.
1. Development time
It usually requires more development time to build an application using AJAX than using other approaches. Plus, learning a new technology like AJAX provides it own set of delays before properly understanding and using it.
Since it is a core feature, the amount of JavaScript contained with a page increases when an AJAX solution is tackled. Consequently, developers must be knowledgeable in JavaScript and related cross-browser quirks; as you probably already know, not every developer is especially fond of JavaScript. In addition, developers must be proficient in HTML and XML, as well as other technologies like CSS for style.
Another issue with JavaScript is that you have to consider what to do when a user has disabled JavaScript support within their browser. This requires extra development time to deliver an alternative solution (using the NOSCRIPT tag).
In addition, when developers jump on the AJAX bandwagon, you should make sure that they don’t use it for everything.
2. Browsing history and experience
The Really Simple History (RSH) JavaScript library highlights another major issue with Web applications that use AJAX: There is no browsing history, so Back/Forward buttons become useless. The lack of a browsing history emerges from the dynamic nature of an AJAX solution. Data is loaded asynchronously without a page reload, so no page access is recorded in the browser history. This means that users are unable to easily bookmark or navigate to and from the application using the browser’s buttons. RSH provides one way to build such functionality into an application, but it will add development time and testing.
3. Search engine interaction (Most Important)
Another issue emerging from the dynamic nature of AJAX is a lack of interaction with search engines. Search engines like Google require a page URL and use words on the page as one aspect of its approach to ranking pages.
Page data is dynamic within an AJAX application. Search engine spiders do not load a page and execute its JavaScript. This results in search engines ignoring an application or a page. This can lead to lost visitors, but it will not be an issue for internal intranet applications.
4. Accessibility
AJAX is not the most accessibility-friendly development paradigm. AJAX makes the browser act in a way that is different than its original design; for instance, Back and Forward buttons no longer work as expected, and there is no URL for some AJAX content.
These issues should remain in the forefront as you develop an application (regardless of whether it uses AJAX). You can apply the techniques I discussed in the section about browsing issues.
AJAX is not supported in browsers on mobile phones and PDAs, so these devices can be used as a reference point for developing applications that are accessible to everyone. O’Reilly’s Ajax: The Definitive Guide does an excellent job of stressing accessibility while using AJAX.
5. Server load
Server load and bandwidth can be an issue when delivering AJAX-based solutions. These solutions often use AJAX to provide features like type-ahead searching in text boxes or loading data in the background. The user may see fewer page reloads, but the server calls are still there.
It is worth considering whether the backend server can handle countless simultaneous calls to the server when many users are using the type-ahead feature. An overworked server can lead to an interrupted user experience with lags in loading data asynchronously. Displaying interim messages like “Loading” can alleviate user concerns because this lets them know something is happening rather than being presented with a blank page.
6. Security
Security has always been an important issue with Web applications, and AJAX is no different. Like any other application that uses the HTTP protocol, data is sent as clear text. For this reason, no sensitive data should take a ride via HTTP using AJAX or any other technology.
While JavaScript is a mature language, it does have security holes that must be recognized regardless of whether you’re using AJAX. Server-based security measures can be used to block such problems. Also, the issue of cross-site scripting — XSS is more pronounced with AJAX, as script may run in the background and access resources without user knowledge. Given these possibilities, all data must be protected to avoid malicious activity.
Make a well-informed decision
There are times when AJAX is applicable, and there are times when you should choose another approach. Be sure to consider potential issues with AJAX before putting it to use in your next application. A hybrid approach is usually the best solution with AJAX because it provides certain features in the user interface and other technologies used in other facets of an application.
6 Deadly AJAX Drawbacks: Are you aware?
AJAX combines the power of existing Web technologies to build powerful user interfaces that offer benefits often found in desktop applications. Over the past couple of years, Web developers have embraced AJAX in their own development efforts as well as via third-party toolkits.
Once you use an application built with AJAX, it’s easy to see the benefits: the user experience improves, as page reloads are reduced, and features such as automatic type-ahead facilitate data entry.
Some developers view AJAX as the silver bullet for every scenario. However, AJAX introduces its own set of hazards in various areas, which include: development time, browsing history and experience, search engine interaction, accessibility, server load, and security. Let’s take a closer look at each of these 6 areas.
1. Development time
It usually requires more development time to build an application using AJAX than using other approaches. Plus, learning a new technology like AJAX provides it own set of delays before properly understanding and using it.
Since it is a core feature, the amount of JavaScript contained with a page increases when an AJAX solution is tackled. Consequently, developers must be knowledgeable in JavaScript and related cross-browser quirks; as you probably already know, not every developer is especially fond of JavaScript. In addition, developers must be proficient in HTML and XML, as well as other technologies like CSS for style.
Another issue with JavaScript is that you have to consider what to do when a user has disabled JavaScript support within their browser. This requires extra development time to deliver an alternative solution (using the NOSCRIPT tag).
In addition, when developers jump on the AJAX bandwagon, you should make sure that they don’t use it for everything.
2. Browsing history and experience
The Really Simple History (RSH) JavaScript library highlights another major issue with Web applications that use AJAX: There is no browsing history, so Back/Forward buttons become useless. The lack of a browsing history emerges from the dynamic nature of an AJAX solution. Data is loaded asynchronously without a page reload, so no page access is recorded in the browser history. This means that users are unable to easily bookmark or navigate to and from the application using the browser’s buttons. RSH provides one way to build such functionality into an application, but it will add development time and testing.
3. Search engine interaction (Most Important)
Another issue emerging from the dynamic nature of AJAX is a lack of interaction with search engines. Search engines like Google require a page URL and use words on the page as one aspect of its approach to ranking pages.
Page data is dynamic within an AJAX application. Search engine spiders do not load a page and execute its JavaScript. This results in search engines ignoring an application or a page. This can lead to lost visitors, but it will not be an issue for internal intranet applications.
4. Accessibility
AJAX is not the most accessibility-friendly development paradigm. AJAX makes the browser act in a way that is different than its original design; for instance, Back and Forward buttons no longer work as expected, and there is no URL for some AJAX content.
These issues should remain in the forefront as you develop an application (regardless of whether it uses AJAX). You can apply the techniques I discussed in the section about browsing issues.
AJAX is not supported in browsers on mobile phones and PDAs, so these devices can be used as a reference point for developing applications that are accessible to everyone. O’Reilly’s Ajax: The Definitive Guide does an excellent job of stressing accessibility while using AJAX.
5. Server load
Server load and bandwidth can be an issue when delivering AJAX-based solutions. These solutions often use AJAX to provide features like type-ahead searching in text boxes or loading data in the background. The user may see fewer page reloads, but the server calls are still there.
It is worth considering whether the backend server can handle countless simultaneous calls to the server when many users are using the type-ahead feature. An overworked server can lead to an interrupted user experience with lags in loading data asynchronously. Displaying interim messages like “Loading” can alleviate user concerns because this lets them know something is happening rather than being presented with a blank page.
6. Security
Security has always been an important issue with Web applications, and AJAX is no different. Like any other application that uses the HTTP protocol, data is sent as clear text. For this reason, no sensitive data should take a ride via HTTP using AJAX or any other technology.
While JavaScript is a mature language, it does have security holes that must be recognized regardless of whether you’re using AJAX. Server-based security measures can be used to block such problems. Also, the issue of cross-site scripting — XSS is more pronounced with AJAX, as script may run in the background and access resources without user knowledge. Given these possibilities, all data must be protected to avoid malicious activity.
Make a well-informed decision
There are times when AJAX is applicable, and there are times when you should choose another approach. Be sure to consider potential issues with AJAX before putting it to use in your next application. A hybrid approach is usually the best solution with AJAX because it provides certain features in the user interface and other technologies used in other facets of an application.
6 Deadly AJAX Drawbacks: Are you aware?
AJAX combines the power of existing Web technologies to build powerful user interfaces that offer benefits often found in desktop applications. Over the past couple of years, Web developers have embraced AJAX in their own development efforts as well as via third-party toolkits.
Once you use an application built with AJAX, it’s easy to see the benefits: the user experience improves, as page reloads are reduced, and features such as automatic type-ahead facilitate data entry.
Some developers view AJAX as the silver bullet for every scenario. However, AJAX introduces its own set of hazards in various areas, which include: development time, browsing history and experience, search engine interaction, accessibility, server load, and security. Let’s take a closer look at each of these 6 areas.
1. Development time
It usually requires more development time to build an application using AJAX than using other approaches. Plus, learning a new technology like AJAX provides it own set of delays before properly understanding and using it.
Since it is a core feature, the amount of JavaScript contained with a page increases when an AJAX solution is tackled. Consequently, developers must be knowledgeable in JavaScript and related cross-browser quirks; as you probably already know, not every developer is especially fond of JavaScript. In addition, developers must be proficient in HTML and XML, as well as other technologies like CSS for style.
Another issue with JavaScript is that you have to consider what to do when a user has disabled JavaScript support within their browser. This requires extra development time to deliver an alternative solution (using the NOSCRIPT tag).
In addition, when developers jump on the AJAX bandwagon, you should make sure that they don’t use it for everything.
2. Browsing history and experience
The Really Simple History (RSH) JavaScript library highlights another major issue with Web applications that use AJAX: There is no browsing history, so Back/Forward buttons become useless. The lack of a browsing history emerges from the dynamic nature of an AJAX solution. Data is loaded asynchronously without a page reload, so no page access is recorded in the browser history. This means that users are unable to easily bookmark or navigate to and from the application using the browser’s buttons. RSH provides one way to build such functionality into an application, but it will add development time and testing.
3. Search engine interaction (Most Important)
Another issue emerging from the dynamic nature of AJAX is a lack of interaction with search engines. Search engines like Google require a page URL and use words on the page as one aspect of its approach to ranking pages.
Page data is dynamic within an AJAX application. Search engine spiders do not load a page and execute its JavaScript. This results in search engines ignoring an application or a page. This can lead to lost visitors, but it will not be an issue for internal intranet applications.
4. Accessibility
AJAX is not the most accessibility-friendly development paradigm. AJAX makes the browser act in a way that is different than its original design; for instance, Back and Forward buttons no longer work as expected, and there is no URL for some AJAX content.
These issues should remain in the forefront as you develop an application (regardless of whether it uses AJAX). You can apply the techniques I discussed in the section about browsing issues.
AJAX is not supported in browsers on mobile phones and PDAs, so these devices can be used as a reference point for developing applications that are accessible to everyone. O’Reilly’s Ajax: The Definitive Guide does an excellent job of stressing accessibility while using AJAX.
5. Server load
Server load and bandwidth can be an issue when delivering AJAX-based solutions. These solutions often use AJAX to provide features like type-ahead searching in text boxes or loading data in the background. The user may see fewer page reloads, but the server calls are still there.
It is worth considering whether the backend server can handle countless simultaneous calls to the server when many users are using the type-ahead feature. An overworked server can lead to an interrupted user experience with lags in loading data asynchronously. Displaying interim messages like “Loading” can alleviate user concerns because this lets them know something is happening rather than being presented with a blank page.
6. Security
Security has always been an important issue with Web applications, and AJAX is no different. Like any other application that uses the HTTP protocol, data is sent as clear text. For this reason, no sensitive data should take a ride via HTTP using AJAX or any other technology.
While JavaScript is a mature language, it does have security holes that must be recognized regardless of whether you’re using AJAX. Server-based security measures can be used to block such problems. Also, the issue of cross-site scripting — XSS is more pronounced with AJAX, as script may run in the background and access resources without user knowledge. Given these possibilities, all data must be protected to avoid malicious activity.
Make a well-informed decision
There are times when AJAX is applicable, and there are times when you should choose another approach. Be sure to consider potential issues with AJAX before putting it to use in your next application. A hybrid approach is usually the best solution with AJAX because it provides certain features in the user interface and other technologies used in other facets of an application.
6 Deadly AJAX Drawbacks: Are you aware?
AJAX combines the power of existing Web technologies to build powerful user interfaces that offer benefits often found in desktop applications. Over the past couple of years, Web developers have embraced AJAX in their own development efforts as well as via third-party toolkits.
Once you use an application built with AJAX, it’s easy to see the benefits: the user experience improves, as page reloads are reduced, and features such as automatic type-ahead facilitate data entry.
Some developers view AJAX as the silver bullet for every scenario. However, AJAX introduces its own set of hazards in various areas, which include: development time, browsing history and experience, search engine interaction, accessibility, server load, and security. Let’s take a closer look at each of these 6 areas.
1. Development time
It usually requires more development time to build an application using AJAX than using other approaches. Plus, learning a new technology like AJAX provides it own set of delays before properly understanding and using it.
Since it is a core feature, the amount of JavaScript contained with a page increases when an AJAX solution is tackled. Consequently, developers must be knowledgeable in JavaScript and related cross-browser quirks; as you probably already know, not every developer is especially fond of JavaScript. In addition, developers must be proficient in HTML and XML, as well as other technologies like CSS for style.
Another issue with JavaScript is that you have to consider what to do when a user has disabled JavaScript support within their browser. This requires extra development time to deliver an alternative solution (using the NOSCRIPT tag).
In addition, when developers jump on the AJAX bandwagon, you should make sure that they don’t use it for everything.
2. Browsing history and experience
The Really Simple History (RSH) JavaScript library highlights another major issue with Web applications that use AJAX: There is no browsing history, so Back/Forward buttons become useless. The lack of a browsing history emerges from the dynamic nature of an AJAX solution. Data is loaded asynchronously without a page reload, so no page access is recorded in the browser history. This means that users are unable to easily bookmark or navigate to and from the application using the browser’s buttons. RSH provides one way to build such functionality into an application, but it will add development time and testing.
3. Search engine interaction (Most Important)
Another issue emerging from the dynamic nature of AJAX is a lack of interaction with search engines. Search engines like Google require a page URL and use words on the page as one aspect of its approach to ranking pages.
Page data is dynamic within an AJAX application. Search engine spiders do not load a page and execute its JavaScript. This results in search engines ignoring an application or a page. This can lead to lost visitors, but it will not be an issue for internal intranet applications.
4. Accessibility
AJAX is not the most accessibility-friendly development paradigm. AJAX makes the browser act in a way that is different than its original design; for instance, Back and Forward buttons no longer work as expected, and there is no URL for some AJAX content.
These issues should remain in the forefront as you develop an application (regardless of whether it uses AJAX). You can apply the techniques I discussed in the section about browsing issues.
AJAX is not supported in browsers on mobile phones and PDAs, so these devices can be used as a reference point for developing applications that are accessible to everyone. O’Reilly’s Ajax: The Definitive Guide does an excellent job of stressing accessibility while using AJAX.
5. Server load
Server load and bandwidth can be an issue when delivering AJAX-based solutions. These solutions often use AJAX to provide features like type-ahead searching in text boxes or loading data in the background. The user may see fewer page reloads, but the server calls are still there.
It is worth considering whether the backend server can handle countless simultaneous calls to the server when many users are using the type-ahead feature. An overworked server can lead to an interrupted user experience with lags in loading data asynchronously. Displaying interim messages like “Loading” can alleviate user concerns because this lets them know something is happening rather than being presented with a blank page.
6. Security
Security has always been an important issue with Web applications, and AJAX is no different. Like any other application that uses the HTTP protocol, data is sent as clear text. For this reason, no sensitive data should take a ride via HTTP using AJAX or any other technology.
While JavaScript is a mature language, it does have security holes that must be recognized regardless of whether you’re using AJAX. Server-based security measures can be used to block such problems. Also, the issue of cross-site scripting — XSS is more pronounced with AJAX, as script may run in the background and access resources without user knowledge. Given these possibilities, all data must be protected to avoid malicious activity.
Make a well-informed decision
There are times when AJAX is applicable, and there are times when you should choose another approach. Be sure to consider potential issues with AJAX before putting it to use in your next application. A hybrid approach is usually the best solution with AJAX because it provides certain features in the user interface and other technologies used in other facets of an application.
GRID - 10000 times faster than Internet
The Matrix may be the future of virtual reality, but researchers say the Grid is the future of collaborative problem-solving.
More than 400 scientists gathered at the Global Grid Forum this week to discuss what may be the Internet’s next evolutionary step.
Though distributed computing evokes associations with populist initiatives like SETI@home, where individuals donate their spare computing power to worthy projects, the Grid will link PCs to each other and the scientific community like never before.
IBM’s Brian Carpenter suggested “computing will become a utility just like any other utility.”
Carpenter said, “The Grid will open up … storage and transaction power in the same way that the Web opened up content.” And just as the Internet connects various public and private networks, Cisco Systems’ Bob Aiken said, “you’re going to have multiple grids, multiple sets of middleware that people are going to choose from to satisfy their applications.”
As conference moderator Walter Hoogland suggested, “The World Wide Web gave us a taste, but the Grid gives a vision of an ICT (Information and Communication Technology)-enabled world.”
Though the task of standardizing everything from system templates to the definitions of various resources is a mammoth one, the GGF can look to the early days of the Web for guidance. The Grid that organizers are building is a new kind of Internet, only this time with the creators having a better knowledge of where the bottlenecks and teething problems will be.
The general consensus at the event was that although technical issues abound, the thorniest issues will involve social and political dimensions, for example how to facilitate sharing between strangers where there is no history of trust.
Amsterdam seemed a logical choice for the first Global Grid Forum because not only is it the world’s most densely cabled city, it was also home to the Internet Engineering Task Force’s first international gathering in 1993. The IETF has served as a model for many of the GGF’s activities: protocols, policy issues, and exchanging experiences.
The Grid Forum, a U.S.-based organization combined with eGrid - the European Grid Forum, and Asian counterparts to create the Global Grid Forum (GGF) in November, 2000.
The Global Grid Forum organizers said grid communities in the United States and Europe will now run in synch.
The Grid evolved from the early desire to connect supercomputers into “metacomputers” that could be remotely controlled. The word “grid” was borrowed from the electricity grid, to imply that any compatible device could be plugged in anywhere on the Grid and be guaranteed a certain level of resources, regardless of where those resources might come from.
Scientific communities at the conference discussed what the compatibility standards should be, and how extensive the protocols need to be.
As the number of connected devices runs from the thousands into the millions, the policy issues become exponentially more complex. So far, only draft consensus has been reached on most topics, but participants say these are the early days.
As with the Web, the initial impetus for a grid came from the scientific community, specifically high-energy physics, which needed extra resources to manage and analyze the huge amounts of data being collected.
The most nettlesome issues for industry are security and accounting. But unlike the Web, which had security measures tacked on as an afterthought, the Grid is being designed from the ground up as a secure system.
Conference participants debated what types of services (known in distributed computing circles as resource units) provided through the Grid will be charged for. And how will the administrative authority be centralized?
Corporations have been slow to cotton to this new technology’s potential, but the suits are in evidence at this year’s Grid event. As GGF chairman Charlie Catlett noted, “This is the first time I’ve seen this many ties at a Grid forum.”
In addition to IBM, firms such as Boeing, Philips and Unilever are already taking baby steps toward the Grid.
Though commercial needs tend to be more transaction-focused than those of scientific pursuits, most of the technical requirements are common. Furthermore, both science and industry participants say they require a level of reliability that’s not offered by current peer-to-peer initiatives: Downloading from Napster, for example, can take seconds or minutes, or might not work at all.
Garnering commercial interest is critical to the Grid’s future. Cisco’s Aiken explained that “if grids are really going to take off and become the major impetus for the next level of evolution in the Internet, we have to have something that allows (them) to easily transfer to industry.”
Other potential Grid components include creating a virtual observatory, and doctors performing simulations of blood flows. While some of these applications have existed for years, the Grid will make them routine rather than exceptional.
The California Institute of Technology’s Paul Messina said that by sharing computing resources, “you get more science from the same investment.”
Ian Foster of the University of Chicago said that Web precursor Arpanet was initially intended to be a distributed computing network that would share CPU-intensive tasks but instead wound up giving birth to e-mail and FTP.
The Grid may give birth to a global file-swapping network or a members-only citadel for moneyed institutions. But just as no one ten years ago would have conceived of Napster — not to mention AmIHotOrNot.com — the future of the Grid is unknown.
An associated DataGrid conference continues until Friday, focusing on a project in which resources from Pan-European research institutions will analyze data generated by a new particle collider being built at Swiss particle-physics lab CERN.