The Accordian, the tree based navigation, calender and the Ajax polls are something which you might have come across on different Ajax sites already. But the image gallery is something unique to see. It has all the images managed into sets which are displayed on the bottom. On clicking a set, the images lying within are shown in a manner similar to a deck of cards.

When you hover your mouse on above each partially visible card it becomes visible. You can click it to view to view the larger image. A full screen mode switch and a Thumbnail viewer has also been provided. Information relevant to the hovered image is shown in the right.

Overall, I liked the Ajax features implemented in the site. The navigation is user friendly. However owing to my slow connection, the site proved heavy to load. If you are curious to know how the old NASA website looked like, then have a look at this image of the old layout. From where I got the image, remains a secret.

Related posts:

• 5 tips to use Ajax in the proper way
• Servlet 3.0 – The Journey Begins Now
• Ajax Frameworks – Server side versus Client side
• Optimal use of Ajax – use Ajax the smart way
• Xinu – Ajax Based Site Statistics Tool

If I picked a favorite of the lot, it would be Minesweeper. It is a single game which employs strategy over luck. But I miss it at my office since none of the computers come installed with it. But in the current age of web 2.0 who searches the program menu any way? Its all out there open on the web. And if you think that games are blocked as well you are pretty right. But when the provider itself is Google, who can come as a barrier. It was a startling revelation when I found Google did have its own version of Minesweeper implemented with Ajax.  Google Minesweeper comes in a Google Homepage Gadget. In fact there are 5 games that you can choose from from here.

If you however don’t like the layout of the minesweeper game in your homepage you can turn your heads to the more animated version offered by telerik. It has been implemented Microsoft’s Silverlight. For playing  it, first install the Microsoft Silverlight plugin and enjoy!

Related posts:

• Convert Date to String and String to Date in Java
• Hilarious Web 2.0 Song
• JSON Web Services – the XML JSON debate further ahead
• New Theme for TechTracer
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?

On a brief note the Servlet 3.0 specification has been approved in the form of JSR 315 is going to be a part of Java EE 6 as mentioned by SUN:

The JCP has approved JSR 315 (ballot) starting the process that will develop Servlet 3.0. Servlet 3.0 is intended to be part of Java EE 6 together with approved JSRs like JSF 2.1 and JAX-RS 1.0 and several more yet to be launched.

The new specification suggests to bring in the feature of asynchronicity to Servlets. We still can leverage the asynchronous nature in a JEE application with the use of Ajax. Experts think that the Ajax model has a problem in its working which can be seen in this JETTY Continuations theory . Having an inherent quality of server side asynchronous nature means that we wont be having the need of Ajax altogether! Somebody should correct me if I am wrong here.

If we presume that the server which will be based on the new specification, is bound to handle queues for loads of asynchronous requests, then in my opinion it will make the server performance a little slower. I am yet seen an implementation of of asynchronous JAX WS service, so it might be possible that I am bit outdated on that aspect.

But to all my JEE lovers, its a good news that finally we would have something more to cheer about. The good news is that majority of the JCP members have nodded their heads in favor of JSR 315. You can see through their polling results. I think I would need to get my certification for J2EE 1.4 upgraded but I have no complaints.

Related posts:

• Learn the Servlet API – A step by step approach
• Java EE – Exhaustive yet Enchanting
• Search Results
• The Struts Framework – Why choose it?
• Learn the Servlet API – ServletRequest and HttpServletRequest

Ajaxian recently reported about this tool by the name Xinu which is simply amazing. Some of the amazing statistics it provides are:

1. Page indexed by various search engines
2. Keywords listed in your site
3. Site ranking
4. Site linked in various social networks
5. Errors found in your site’s HTML or CSS code
6. Backlinks to your site from various engines

Isn’t this simply amazing to see the list of features? Although this tool is in Spanish the statistics are easier to understand and valuable. They give an insight even to the most overlooked aspects which might be crucial in getting more popularity to your site. Another nice feature of this tool is it gives you all the statistics in a downloadable PDF format.

The user interface of Xinu is completely Ajax based. So that’s an added advantage of faster response. One thing that you would particularly like is that the different satistics keep filling one by one and you can customise the flow. There are draggable blocks of statistics categories as in the above mentioned list and the the blocks are filled acoording to their placement i.e upper blocks will be proccessed first.

Although not very sophisticated enough the idea is very innovative and it would be very nice to have such facilities in an English version and with customizable statistics features! Feel free to share if you know any other such utilities available elsewhere.

Related posts:

• NASA adopts Ajax, Launches NASA 5.0
• 5 tips to use Ajax in the proper way
• Plagiarism – Black Listing of Sites is a Must
• Best Tools For Editing Your Photos Online
• Optimal use of Ajax – use Ajax the smart way

Ajax is not about XMLHttprequest Object
Most of the people think that if they know about the XMLHttpRequest (XHR) object then they are Ajax programmers. Only a part of this statement is true since the base of Ajax is about XHR. But Ajax is not just about XHR.

The article by Jesse James Garet (who originally coined the term Ajax) mentions the same as,

XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

Working with Ajax means that you intend to use asynchronous behavior in your web page. The next thing which comes into practicality of Ajax usage is the XHR object. Although asynchronous, your web page will be far away from using Ajax in the right manner.

Ajax was not just meant for providing asynchronous behavior, but to make a web page shed its primitive look from blocking a view whenever a request was made to a look, which more seemed as if a person was working on his desktop application, by a combination of features provided through CSS, DOM, etc along with the specialty of XHR. The driving force to the popularity that Ajax has received is majorly speed and natural responsiveness which means that a response is generated to only what is demanded keeping the other things constant without changing.

Thus a person gives a preference more to a quick responsive page rather than the one which takes intervals in each and every request initiated and makes changes to the other things as well. XMLHttpRequest might be the base but along with the asynchronous behavior that XHR inherently provides you should be using it carefully with a proper separation of concerns between DOM, JavaScript and CSS along with XML, XSLT and XHTML.

Ajax is not an acronym
The fact is that, Ajax is just a shorthand for Asynchronous JavaScript and XML. When the Ajax hype happened about a year ago all the work done in Ajax was a miracle for those who hadn’t been much into the user interface driven aspects like CSS, JavaScript and XML. With the advent of Ajax, people have recently become more enthusiastic about JavaScript which was once a hated language by programmers amidst all the heavy duty strict counterparts like Java, C#, etc.

However, people failed to realize that this comparison was baseless since JavaScript was client side UI driven technology and had nothing to do with remote technology that Java, C# provided. Both belong to the different paradigms and cannot be compared. The name might itself suggest, JavaScript is nothing more than a scripting language for browsers in order to make the DOM active in its response. It is UI related and not meant for server side. However if you have used ASP you might disagree with this statement. But that is a different thing concerning with familiarity of JavaScript users for ASP using JavaScript.

In the Story behind Ajax, Garett once again comes upfront to clearly mention this

I thought of Ajax as a convenient [term]. It was never intended as an acronym.

Ajax came into the popularity charts due its catchy term and powerful way of representing a number of different things under its hood. Many JavaScript libraries which were providing a set of dynamic functionality to a web page became full fledged Ajax Toolkits since the emergence of this term. However if you see the source of these toolkits, you would come to know that they are a pure blend of many complicated modules involving CSS, XML, iFrames, Closures,etc.

The only place where the asynchronous behavior comes into picture is where the XHR object is used or where a graceful degradation in the form of an iFrame is provided for old browser compatibility. Rest of the rich interface experience is brought by other prior existing features like JavaScript special effects and utilities. Now these have come into limelight due to the coinage of the term “Ajax“. It can be compared to as a brand name rather than an paradigm shift.

Ajax is not AJAX
When Jesse James Garett had coined the term Ajax it was used in camel case. But due to its expansion coming into the limelight as “Asynchronous JavaScript and XML” (notice the uppercase of the words) people represented it as AJAX and not Ajax. Much hue and uproar was made about this inclusion. Should Ajax or AJAX be used, is of more importance in the data driven aspects.

If you have a tool or search engine which you use to search case sensitive terms then using Ajax will fetch different results than AJAX. The same applies to using case sensitive switch cases in your applications which might be disturbing of search intensive applications. So it is required that people across the world stick to a single norm. The reference of the usage is correctly attributed to the creator of the term itself i.e Jesse James Garette. He used Ajax (camel case). Wikipedia also uses in the same way, alongwith many big vendors, so it ought to be Ajax and not AJAX.

Arun Gupta recalls his experience in making the changes at Sun Microsystems.

Ajax is a popular term for past few months but is still being written incorrectly as “AJAX” (all capitals) instead of “Ajax” (camel case). I started using AJAX but then corrected myself and have been using Ajax since then.

Arun has mentioned a set of nice resources which prove the need of using a globally accepted term. Its analogy can be put forward to the acceptance of English as a global language. Even this site needs to make the changes to the usages of the term AJAX wherever used. So if you are in the AJAX bandwagon it would be better to jump on to the Ajax one, due to the global directives.

Ajax is not Web 2.0
Web 2.0 is a conceptual term and rather a representational term which in recent times is being used on a tremendous scale to put forward the freedom of data usage on the web. Earlier the web was used to share data statically and allow limited interactions in the form of feedbacks from the user. But today if we see the web, its a lot more interactive and user has the power to generate content, publish at ease and choose various alternatives to acquire it.

The web sites today cater more to the user inputs rather than passive information being pushed to the users. The result being the increasing number of blogs, forums, social networks and communities. In addition to the increasing user interactions, Web 2.0 is about using data freely. There is no limitation to getting data only in a pre-specified format or a pre-specified contractual terms.

The user is free to choose how he can receive the same data in various ways. The proof of the fact is the number of technologies that are being built to cater to this aspect. Web Services, RSS Feeds, Webcasts, Podcasts etc. Spreading of data more accurately and in a wide spread manner is another aspect of Web 2.0. Tagging, Online bookmarking are only the beginning of such techniques and the web is about to see a lot more than this.

In his article, De Witt Clinton tries to showcase this is a rather detailed approach on how communication has evolved,

Web 2.0 is about giving up control. It is about setting the data free. It is about providing services that work with other people’s data. It is about having a valuable resource and making no presumptions about how or where that resource will be used.

In my opinion, the web just might become obsolete in the near future. The fact being it might be something closer to having online desktops. It might be possible that computers will be replaced entirely by mobiles which would become more handy than a computer, with power packed business and multimedia features.

Ajax can be considered to as a part of the implementation process but not a concept of Web 2.0. Web 2.0 is also just a term used to replace long statements indicating the changing nature of the web and not a replacement to the existing characteristics of the web, just like Ajax did to the underlying technologies. You might read about this aspect in Wikipedia’s information on Web 2.0,

The argument also exists that “Web 2.0″ does not represent a new version of World Wide Web at all, but merely continues to use “Web 1.0″ technologies and concepts.

The term Web 2.0 showcases how data can be shared and used freely without any sort of restrictions while Ajax makes it possible to make innovations which attribute to the growth of Web 2.0. It’s more of a marketing strategy when you see Ajax and Web 2.0 used as synonyms just to derive maximum popularity owing to the two latest terms coined. Web 2.0 shows the way to use and spread data while Ajax is a practical approach to present the data in an effective and interactive manner.

Related posts:

• NASA adopts Ajax, Launches NASA 5.0
• 5 tips to use Ajax in the proper way
• The birth of AJAX – an amazing story
• Servlet 3.0 – The Journey Begins Now
• Ajax Frameworks – Server side versus Client side

Looking at the features of Ajax that hundreds of frameworks today provide, you might get sometimes tempted to use them all. Its pleasing when the user interface is more interactive and more user friendly at the same time attractive. To make these you have to use the framework which provides such eye candy. But before you decide on a particular you must have these things in mind.

1. Size of the total number of JavaScript pages
2. Check for frameworks or API for memory leaks
3. Don’t bloat your code
4. Use interactivity only where required
5. Don’t try to use Ajax where bookmarking is heavily used
6. Test your Ajax code properly

Let’s see each one in detail.

1. Size of the total number of JavaScript pages
This is one of the most important aspects when you go for deciding a framework. The JavaScript in the pages is nothing else than the code which the client has to download, in order to make available the features for the frameworks. If you find the download of a particular framework package very heavy then it would be the same feeling that the end user would be getting if you use the same framework API. This is because for using the eye candy features for the framework the end user’s browser would first download the JavaScript files and then execute the features.

2. Check for frameworks or API for memory leaks
This is the second most important thing you should watch out for. Normally while you program you work with an IDE. The IDE automatically alerts you when you make an infinite loop in your code accidentally. But when you code either in raw JavaScript or use any framework you do not have any IDE because there are not many good IDE’s that handle JavaScript well. So it might happen that you leave out a loop in a infinite manner or you could introduce a recursive functions which never ends. This often results in memory overloading on the client side thus crashing the browser or system. The other reasons for a memory leak might be the framework itself.

If you had seen the DOJO toolkit site earlier which works on DOJO you might have sometimes cursed the loading time for the site. Many a times my browser has crashed the moment I opened the site. This is because frameworks like DOJO implement the Ajax behavior and other features using a lot of code. And hence when the site loads the features use up the system memory for rendering the widgets in the browser.

3. Don’t bloat your code
Using some multiple free script’s is good but using multiple frameworks is a big no no. This is because of the same reason as stated in the earlier example. Bloating of code takes time to get downloaded and you can sometimes leave some part of the code unattended which results in memory leaks. Bloating of code can also occur if you unnecessary import all the necessary JavaScript file required for the entire website in a single page itself.

This is a common phenomenon since we generally put the import tags in the header files of the site. These header files are included in every page for displaying the header. But behind the load of each page the JavaScript files unnecessary get loaded into the browsers memory on the client side which slows down the execution of the site. In order to avoid this it is important that you just import the required JavaScript files in the appropriate pages and thus make the execution of the pages faster.

4. Use interactivity only where required
Never think in the manner that since your site is having the web 2.0 feature each and everything in it should be made via scripts. This is bad thinking. Ajax promotes interactivity hence it is must that you just make the page interactive when there are many components on the page. If you have personalized the Google homepage you might probably know about this very well. In the personal homepage you can see how convenient it is to modify a single component without disturbing the others. So Ajax fits in the picture in such a case.

Now lets take the example of a blog. On the homepage of a blog you see a list of posts and when you click the title of a post, the post page loads up. Now whether you simply load the page in the normal fashion or if Ajax is used in here, the time taken is the same. No fast loading takes place nor nothing on the site looks more appealing if Ajax is used in such situation since the data to be fetched from the server does not change.

The point I am trying to make is that Ajax should be used in those places where it solves some purpose and not in the places where it seems unnecessary. It is just a waste of time to put the efforts in this case.

5. Don’t try to use Ajax where bookmarking is heavily used.
If you are a blog owner then you might understand the importance of trackbacks or permalinks. Those are the blog’s savior since they are universally unique and reachable to any person who uses it whenever required. Ajax has a very undesirable feature which might make a blog less popular i.e Ajax pages cannot be bookmarked. If you use Ajax to load a post as I had mentioned in the example of point number 4. then the post loads up the same page without changing the URL. This is because it is loaded asynchronously.

Now if a person looks at such a loaded page and likes the content he might immediately bookmark without a second thought. But when he requests for the same page again.. voila! he doesn’t see the post. Instead he sees your homepage. Of course you can avoid this by explicitly specifying the trackback URL but you can never gaurantee that the reader of your content might be even knowledgeable of what Ajax is and what trackbacks are used for. Hence your blog traffic might suffer.

6. Test your Ajax code properly
There are not many testing tools available in the market nor very well practiced approaches for testing but you can be sure of making your code work properly by using some utilities which target the JavaScript behavior in the browser. One such utility is the FireBug which is absolutely marvelous when it comes to checking the Ajax code. I have not explored it completely but it helped to cure many bugs when I had worked in Ajax for a web application. It is freely available and comes as a plugin for Firefox. So make sure that you test the Ajax code to the maximum since a bug in the Ajax code can have many side effects.

Related posts:

• NASA adopts Ajax, Launches NASA 5.0
• 5 tips to use Ajax in the proper way
• Servlet 3.0 – The Journey Begins Now
• Ajax Frameworks – Server side versus Client side
• Xinu – Ajax Based Site Statistics Tool

XML is document-oriented and JSON is data-oriented. So if you want to deal with highly structured documents that requires a complex structure, binary data, exact ordering of elements and be able to render itself then use XML. If you are focused on light-weight data exchange then JSON is the way to go.

In my opinion too JSON is handy only for light weight data transfer and nothing more than that. But with more nesting of data JSON can get utterly complex than XML. With XML you can define Schemas, form standardized document structures , extend exisiting document structures or import them when needed. The namespaces concept of XML has been very well established and incorporated in today’s applications and libraries.

XML Dominance
XML got more acceptance due to the already well established markup languages like HTML. Due to standardization by W3C it got quickly incorporated into the big vendors tools. Even a well documented JSP is purely XML. The main advantage of XML success is the XML Schema defintion language (XSD) which has given rise to numerous other standards like SOAP, WSDL etc. It is a very flexible and extensible language.

If you look behind the scenes a bit, XML has been reigning from the past and its usage in the industry has become massive. You might not be aware but all the big applications use XML either for storage, transfer, presentation or configuration of data and also meta data. MS SQL uses XML to transfer data from one database to other. MS WORD uses XML to provide formatting of user input content in the documents.

JSON- Some Facts
Coming back to JSON, the main fact which goes against JSON is it is not standardized. But now if JSON wants to establish its presence then the only field in my opinion would be SOA web services and AJAX where, it has received a lot of attention. Lately the debate on using web services with JSON has started. XML being heavy puts somewhat a hindrance on the acceptance of web services since the network infrastructure needs to get upgraded to get quicker adoption of XML RPC web services. With JSON, if web services give a higher throughput then it might be time to cash upon its acceptance for data transfer. Alexander writes about JSON pros and cons in his blog MyArch,

One of the keys to SOA success is that it should be easy to consume a service, i.e., the entry barrier for service consumers must be low to support “grass root” SOA adoption. While a top-down SOA effort may succeed, it will certainly take longer than bottom-up (“grass-root”) approach when developers are able to consume services as they see fit. AJAX/JSON fits this bill perfectly – it is easily understood by developers and it does not require any Web services -specific tools or infrastructure.So overall I’m pretty enthusiastic about JSON.

Advantages of JSON
The advantage of using JSON instead of XML is in the inheritent quality of data structuring in JSON. JSON is more closer to being a HashMap as in java or an associative array in some other languages like PHP. Hence it does not require parsing libraries in an application as XML does. The time spent however, on parsing XML into the native language, is not so much significant considering the fast processing power of machines today.

The comparison of XML and JSON lies more on the network bandwidth aspect. JSON can take almost half of the bandwidth as XML for transferring the same data. It can achieve the same throughput as passing simple objects in the network in a distributed computing environment.

JSON Web Services?
It would be interesting to see how would a SOAP message with JSON look like. You have to remember that WSDL is an extensible language and till date only HTTP Bindings and SOAP Bindings have been defined for it. It wont be long before we see JSON Bindings coming into the WSDL documents. Who would not want a quick data transfer while using web services into the application?

AJAX with JSON has got accepted well since JavaScript has the inbuilt capability to handle JSON data and if JSON web services start getting acceptance it might get well flourished to reach the popularity charts as XML did. Is the web service industry looking for a paradigm shift or are we just building a castle in the air?

Related posts:

• BEA Aqualogic Data Services Platform – First Glimpse
• Web and Desktop Apps – the 3rd World War!
• SCDJWS preparation – a kick start guide
• SCDJWS study material and resources – The most searched thing
• Working With JAX-WS in JDK 1.6

In order to make things simple, the overall horde of Ajax frameworks can be classified into two major leagues:

1. Server Side Framework
2. Client Side Frameworks

Server Side Frameworks
Server side frameworks as the name suggests are used on the server side. But you would ask as to how Ajax, which involves JavaScript is used on the server side. Its not actually JavaScript that is used in such frameworks on the server side. In fact you use the same language API’s provided by the framework to do your client side activities and on deployment these client side activities coded on the server side get translated to normal Ajax functionalities when deployed. Confused? Let me clarify your this with an existing server side framework.

Google Web Toolkit (GWT) is such a server side framework which is used as a normal Java Swing kind of programming on the server side in web pages using the GWT API. The GWT provides a tool for deploying your web application having such pages. During the deployment of the web application the GWT tools help in translating the Java syntax into the corresponding Ajax functionality to be brought on the client side.

Advantage of Server Side Frameworks
The advantage of using a server side framework is that you use the existing language you are working in. You do not have to dwell in the wild wild world of JavaScript. Its easier to use a server side framework rather than to learn JavaScript.

Other server side frameworks are : Yahoo Toolkit, DWR

Client Side Frameworks
You must have done Ajax in the normal fashion using the XMLHTTPRequest object in a JavaScript file and then provided some callbacks to do the asynchronous requests. Providing this much is good enough for a simple Ajax page to do one or two requests. But in a large application much more functionality is required. I would list out some of these functionalities as follows:

• Cross browser compatibility – When you code its always a necessity that the code works independent of the browser type requesting it
• Mutliple request handling – Multiple asynchronous request have to handled properly when doing the callbacks
• Graceful degradation – You don’t want your code to fall flat on its face in case the browser does not support the XMLHTTPRequest object
• Exception and error handling – You should be able to catch the exceptions in your code instead of displaying it to the user

To do all this yourself is very tedious and requires a lot of JavaScript expertise. To avoid all this mayhem you have client side frameworks to your rescue. They provide packages and API’s which help you to implement all of the above functionalities and also provide a lot of extra features which currently can be either found in free JavaScript code snippets over the net.

The extra features include widgets or even an IDE. Widgets are small interfaces or components which can be incorporated in an application easily through the client side frameworks. These widgets might compose of the following:

1. Auto completing combobox
2. A Menu system
3. An accordian
4. A tabbed pane windows
5. Effects like fade, zoom in /out

Advantages of Client Side Frameworks
Besides the above specialties the advantage of a client side framework over a server side framework is that you have the complete flexibility in your hands. You can mix and match the widget features and at the same time provide extra flexibility as you have the world of JavaScript at your disposal. Some frameworks like TIBCO GI even provide a GUI to build your web pages with Ajax components in a complete drag n drop style.

The examples of a client side framework are Prototype, DOJO Toolkit, Rico, Script.aculo.us, etc.

Going out to choose a framework in the Ajax field can be a bit overwhelming since you might think all look the same. But if you keep in mind the above classification then you can well have a feature matrix in front of you and also take less time in deciding on going for a particular one.

Related posts:

• Plagiarism – Black Listing of Sites is a Must
• First step in Ajax – Choosing the right framework
• 5 tips to use Ajax in the proper way
• Optimal use of Ajax – use Ajax the smart way
• Servlet 3.0 – The Journey Begins Now

Considerations
All the frameworks compete with each other in their implementation as well as the methodologies of request/ response. You might be less considerate on this aspect of technicalities but the thing which might be of more consideration is the number of rich features which they provide. The rich features comprise of the widgets like, an auto completing text box, a customizable calender, fade effects, an accordian , a dynamic menu etc which is most commonly required by a web application. The frameworks which I mentioned might provide some or the other combinations of these widgets. So for settling on a particular framework, you will have to work out all your features meant to be implemented in your application and only then finalize.

My own example
For an application I had chosen the DWR framework. The DWR framework allows an easy technique to expose your JAVA program function as JavaScript calls on the client side. The call made through JavaScript is requested on the server side through the DWR framework and the output coming from the Java function is passed on to the requesting client through it. I was happy working with DWR until I was having JAVA functions. When I was given the task of doing the client side request for bringing in a JSP output from the server side with the help of AJAX I was not having any option to do so with DWR as the framework only supported only exposure of Java functions and not JSP/ Servlets. This made me to change my framework to DOJO which made it possible to get content from JSP/Servlets, but it didnt expose normal Java functionalities like DWR did, anyways I didn’t require it. But the point I am trying to make here is that I had to remove all the dependencies in my application which were concerned with usage of DWR just to make everything work with DOJO.

Think Twice
You must not combine a multitude of frameworks if you like features from many of them. All of the frameworks come with their own rich features as well with their own drawbacks. In order to finalize on a particular framework always compare and contrast the features of the frameworks so that you don’t have to jump to another one in the middle of your developmental efforts when you don’t find the current framework much of use.

Conclusion
Avoid the unnecessary pain that can be caused due to hasty decision of choosing a framework. You should not chose one just because the other guy told you that he found it cool. It might have been for his particular reasons but that isn’t the same for you always. Just choose one framework which best suits your needs. Its easier to maintain and use.

Related posts:

• Optimal use of Ajax – use Ajax the smart way
• Ajax Frameworks – Server side versus Client side
• 5 tips to use Ajax in the proper way
• The Struts Framework – Why choose it?
• NASA adopts Ajax, Launches NASA 5.0

This does not mean that all of the page content should be brought asynchronously as it would be the doing the same old things in a new fashion. AJAX promotes interactivity i.e. where in a web page which has a lot of components along with data to display to the user, some of the components can be dynamically updated without having to move the user away from the page for refreshing or doing some other activity. The user can access other components of the page while the update is in progress, which adds to the richness of the site or application. Web applications developed in this manner are called as a Rich Internet Applications (RIA).

The 5 tips to use AJAX in the proper way are:

1. Choose the right framework
2. Decide on a server side or a client side framework
3. Never bloat your code
4. Never try to ajaxify all the pages
5. Test your code properly

I will be elaborating on each of these tips in the coming posts since they are have a detailed explanation and I will be providing some examples that I myself have come across and will relate the explanations to them.

Related posts:

• Techtracer 2.0 is Coming
• SEO for Wordpress Beginners
• Resolving the “Unsupported major.minor version 49.0″ Error
• NASA adopts Ajax, Launches NASA 5.0
• 5 Rules For A Good Web Design