As part of my research for the new Lynda.com course I am doing on Visualforce, I have been going through posts on the Salesforce forums. I ran across this one in which the poster was asking what was the best way to select multiple checkboxes on a Visualforce page when a “Check All” checkbox was selected.
The best answer that was chosen was a recommendation by someone to use the ActionSupport component. The accepted responder even provided sample code. While the response was technically correct, I did not think it was the best solution. The reason I say this is because if you execute the sample code provided, you will note that there is a significant delay between the time you select the “Check All” checkbox and the time the other checkboxes are selected.
What causes the delay?
The ActionSupport component, which adds AJAX support to another component, allows that component to be refreshed asynchronously. While you might first think, “Asynchronous, that executes on the client and that is good and fast, right?”, that is not really the case. You see, when you use ActionSupport, or ActionFunction, or any of the action tags, you are essentially invoking server-side logic that is contained in your controller. This means that the AJAX request includes the pages view state and this can affect performance, as it did in the very simple example from this post.
So why use these controls?
Well, they are much easier to use than some of the other alternatives (which you can read more about here) and typically result in less code. But, if you are a good software developer, then you should not just blindly accept the path of least resistance. The other alternatives (namely Visualforce Remoting) will certainly perform better, but then they do require more code to be written. There is always a trade off, you see.
So, what is the best solution for this problem?
Well, I know you are going to be annoyed when I say this, but the answer is, “it depends”.
You could say the best alternative is one that was suggested by another responder on this post. That responders suggestion to use client-side 
Javascript (such as is provided in this post) was not accepted as the solution, but if you execute the code provided it does execute extremely fast. The difference in performance between the two suggestions is day and night (IMHO). But, this requires you to write and maintain the extra Javascript code.
If you are just sold on the whole, “it is better to use the built-in Action components provided by Visualforce because they simplify the code”, then you might want to consider adding an ActionStatus component right below the ActionSupport component. This is used to provide a message to the user telling them when the process starts and ends. That would prevent the user from just sitting there dumfounded for 1 – 3 seconds while the code was executing.
You might also want to consider using some of the other Javascript alternatives suggested in this excellent Developer Relations post on Using Javascript with Force.com.
You see, it really all depends on what you are trying to accomplish and what skills you already have. If you are blessed to have the time to consider other options, then I suggest you do so. There are often many ways to accomplish the same thing and rarely is one way always the best way.
by Wade Wegner and Richard Seroter. As a .NET developer, I was excited to see a new way of connecting Salesforce via .NET. But, I was REALLY excited when I heard that the new toolkit was open-source and provided native libraries that utilized the async and await model in .NET.
saramorgan.net 