Como você já leu o tópico deste post, já sabe do que vou falar. Então já começo perguntando:

Porque praticamente todas as aplicações hoje são web?

É bom notar que, quando falamos em aplicação web no mundo Microsoft isso geralmente significa ASP.Net WebForms, opcionalmente com Microsoft AJAX. Essa combinação domina provavelmente mais de 90% do mercado. Até existe WebForms com outras libraries de Javascript, ASP.Net MVC, Silverlight, etc. Mas a maior parte é WebForms + MS Ajax.

Voltando a pergunta, vocês conhecem as respostas tanto quanto eu. As mais comuns são:

1. É a que o time conhece.
2. É mais fácil de instalar e atualizar.
3. É o padrão da empresa.

Todos esses motivos são justos, e ninguém conseguiria colocá-los em dúvida. Mas a questão é: será que são o suficiente para uma empresa escolher que uma aplicação deve ser baseada, principalmente, em html, css e javascript?

Vamos analisar então uma a uma:

1) É a que o time conhece

Faz sentido trabalhar com uma tecnologia que o time já conhece. É mais fácil iniciar o projeto, não há necessidade de treinamento, e o time já conhece os problemas e oportunidades da tecnologia. Escolher outra tecnologia significaria ter que treinar o time ou contratar outro time, e lidar com novos problemas que a empresa não está acostumada. Ainda assim, escolher a tecnologia errada pode custar muito mais caro do que treinar o time em uma tecnologia mais apropriada. A produtividade de desenvolvimento de uma aplicação Windows ou WPF é tão maior que a do desenvolvimento de uma aplicação ASP.Net, que o custo de treinamento seria pago na diferença entre uma tecnologia e outra.

2) É mais fácil de instalar

É verdade que uma aplicação web é mais fácil que instalar que uma aplicação Windows. O usuário sequer precisa instalar a aplicação no cliente, precisamos apenas instalá-la no servidor, o que é muito mais fácil, já que as configurações de hardware e software são mais controladas, e a instalação é feita uma única vez. Ainda assim, tecnologias de atualização de aplicações, como o ClickOnce, tornam trivial a atualização de aplicações. Inúmeras empresas utilizam o ClickOnce na instalação, recentemente me lembro de tê-lo visto na aplicação de aluguel de filmes da Saraiva, e no aplicativo de backup do BlogEngine (que roda este blog). Nos dois casos são aplicações que serão utilizadas por centenas de pessoas, e ainda assim as empresas optaram por utilizá-la. Porque então as empresas escolhem criar uma aplicação web, quando esta será utilizada às vezes por 5 ou 10 pessoas, em ambiente controlado?

3) É o padrão da empresa

Criar padrões corporativos para a construção de aplicações significa acreditar que todas as aplicações são semelhantes. E nenhuma aplicação é semelhante a outra, nunca. Cada aplicação é única e deve ter sua arquitetura endereçada individualmente. Esse é um dos motivos para a existência do arquiteto de soluções: as aplicações são únicas e alguém precisa definir as tecnologias e padrões mais apropriados. Definir que toda aplicação deve utilizar Entity Framework, ASP.Net WebForms, e MS Ajax, é dizer que toda aplicação é idêntica, e que esse conjunto de tecnologias é suficiente para resolver todos os problemas. E não é. Se fosse, a própria Microsoft não estaria investindo na criação de frameworks alternativos, como o Silverlight, e, no próprio ASP.Net, o ASP.Net MVC. Entendo que esses padrões engessados resultam da iniciativa imatura de tentar simplificar o que é impossível simplificar. Em vez de um livro de padrões, o que seria muito interessante é de um livro de recomendações, que avaliasse cenários, e propusesse soluções, mas nunca fechando a questão, e sempre validando tudo com um arquiteto experiente. Isso é o ideal, e sei que ainda estamos longe deste momento na maioria das empresas, que mal reconhecem o papel do arquiteto de software. É nessas também que (por coincidência?) é maior o índice de retrabalho e perda.

Há tantas opções hoje em dia para a tecnologia de interface gráfica que jogar todas as opções fora para ficar com apenas uma em todos os casos demonstra uma tremenda preguiça da empresa que faz as coisas assim. Só para citar algumas das opções:

1. Windows Forms;
2. WPF;
3. Console;
4. ASP.Net WebForms;
5. ASP.Net MVC;
6. Silverlight;
7. XBAP;
8. Sharepoint;
9. OBA;
10. Windows Mobile.

Há diversos cenários em que uma aplicação web é a pior escolha. Uma aplicação que dependa de uma interação visual muito forte pode ser feita com Silverlight. Só que isso implica em uma comunicação toda baseada em web services. Além disso, o Silverlight possui apenas um subconjunto do .Net para rodar, além de ter limitações em comparação com o WPF, não rodar (ainda) fora do navegador, e (ainda) não ter suporte a 3D, entre outros. Será que uma aplicação WPF com Clickonce não resolveria? Se a aplicação vai ser usadas em poucas máquinas por poucos usuários, não há porque fazer web.

Outro exemplo são aplicações que demandam muitos dados disponíveis no cliente. Nesse caso, uma aplicação cliente que faça uso de um cache de dados local talvez tenha um ganho de performance e responsividade muito superior a uma aplicação web. Lembrando que o objetivo é deixar o cliente feliz. Porque não criar uma aplicação Windows?

Aplicações Windows ainda tem a enorme vantagem de serem stateful, enquanto aplicações web são stateless (menos as RIA, como o Silverlight, que estão no meio do caminho). Ter uma aplicação stateful é algo que facilita muito o desenvolvimento de qualquer aplicação, e eu trocaria a qualquer momento uma aplicação web por uma Windows se o objetivo fosse produtividade.

Uma dúvida que sempre me interrogou é porque permitimos que o time de infra-estrutura determine o que vamos poder ou não rodar. Já vi empresas tão preocupadas com segurança que simplesmente não permitiam que nada além do básico fosse instalado, o que engessava demais qualquer aplicação. Não que segurança não seja importante, mas paranóia não faz bem a ninguém. Já vi empresas em que os DBAs, em vez de trabalharem junto com os desenvolvedores, na verdade eram seus carrascos, impedindo, por exemplo, o uso de qualquer ORM simplesmente porque qualquer acesso ao banco de dados devia ser feito via stored procedures, algo mais anacrônico que desenvolver com ASP2 clássico. DBAs existem, IMHO, para manter a base segura, otimizada e disponível, e parte do seu trabalho é trabalhar com os desenvolvores para atingir isso. E tem que gostar!

Trabalhar com uma aplicação cliente também trás a enorme vantagem de poder distribuir o processamento. Em uma época que máquinas com 2 núcleos e 2 GB de RAM ficaram tão comuns, porque deixar todo o trabalho para o servidor?

Há cenários em que aplicações web realmente são a melhor opção. Ainda assim, o ideal é avaliar o cenário e ver se esse tipo de aplicação realmente se encaixa. Não é um trabalho exatamente simples, mas nem por isso passa a ser precindível.