if you're in visualforce, and are using any of the ajax tags a lot (actionfunction, actionsupport, etc), you would be wise to bind any "sticky" UI list elements to variables that are set in a constructor, rather than having properties or getter methods that directly query the DB to get the data.  this is because whenever you call the "action" of one of these ajax methods, all getters are called, which causes your ajax stuff to appear slower than it normally would.

Example (unoptimized)

public class myclass{
public list<account> getAccounts(){
	list<account> acc = new list<account>();
	acc = [select id, name from account limit 10];
	
	return acc;
}
}

<apex:page controller="myclass">
	<apex:repeat value="{!Accounts}" var="a">
	{!a.name} <br />
	</apex:repeat>
</apex:page>

 the above example, once extended with other public methods/properties, would call getAccounts for every ajax action you put into the page, regardless of whether you wanted to refresh that accounts list or not.  Since this scenario would be more useful if getAccounts() were only querying once (for instance, on render/page load), we move it out of a getter method, and instead populate a variable via the constructor.

public class myclass{
public myclass(){
	list<account> l = new list<account>();
	l = [select id, name from account limit 10];
	if(l.size() > 0){
		accts = l;
}
public list<account> getAccounts(){
	return accts;
}
private list<account> accts = new list<account>();
}
<apex:page controller="myclass">
	<apex:repeat value="{!Accounts}" var="a">
	{!a.name} <br />
	</apex:repeat>
</apex:page>

 in this version, the accounts list is populate via the constructor, so other page interactions will not trigger additional SOQL queries, which, as you build richer pages, can severely bog down the performance when using actionfunction/actionsupport/ajax in Visualforce.

Rule of thumb, if it's something that's populated on page load, and doesn't need to change via ajax, do it in the constructor, not a getter/property.

Doing the above via initialization code achieves the same effect in my experience, but I prefer creating the custom constructor definition vs. standalone initialization blocks.  With the constructor, you also have complete control over the order of operations as the page is rendered.