Quando faço uma ordenação, pesquisa ou até paginação no AJAX.NET é feito um postback "via Ajax" para o server, ele processa e me retorna um HTML (deveriam chamar o AJAX.net Server Centric de NAJA.NET). Já com a nossa biblioteca os dados são armazenados no cliente (inteiros ou on demand, dependendendo do caso) e ordenações, pesquisas e paginação são feitas 100% no cliente, sem nenhum acesso ao servidor, sem overhead etc. Esse exemplo é apenas um dos vários que podemos imaginar.

Assim, para cada interação complexa existe um postback e para cada postback um tempo de espera. Você provavelmente estará destruindo a usabilidade de seu site e a paciência de seus usuários.

Em um exemplo simples, basta imaginar um formulário com quatro combos encadeadas e algumas validações. A página executará no mínimo quatro postbacks. A página inteira irá quatro vezes para o servidor e retornará ao cliente. Haja paciência.

Solução aos postbacks?

O modelo ACSC (Asynchronous Client/Server Communication) é muito mais interessante para o usuário que o modelo WebForm/Postback do ASP.NET e abre um leque de possibilidades de interação antes impraticáveis.

O amadurecimento e a consolidação das tecnologias ACSC (e a popularidade da implementação desse modelo com o AJAX), onde o recarregar de páginas inteiras é substituído por requisições assíncronas do cliente ao servidor e atualização somente da parte onde ocorreu interação com o usuário, obrigou a Microsoft a atualizar sua arquitetura para suportar o modelo ACSC, de modo a evitar que o ASP.NET não perdesse seu mercado.

Para manter a compatibilidade com códigos já existentes em ASP.NET 2.0, a Microsoft desenvolveu parte do Atlas baseada em sua antiga arquitetura, a centralizada no servidor (Server centric), onde o comportamento de postback dos WebControls é modificado, mas ainda assim a lógica do negócio fica toda no lado servidor. Isso é contrário ao verdadeiro modelo ACSC, onde a lógica do negocio é dividida entre o cliente e o servidor e centralizada no cliente (Client centric).