Porquê Silverlight?

Prefácio

Perfil de uma aplicação Desktop
• Executa diretamente no sistema operacional (Delphi/C++/C).
• Ou através de bytecodes interpretados por uma máquina virtual que faz a compilação JIT (Just-In-Time) em tempo de execução (Java/.NET).
• Em ambas situações, toda a camada de apresentação é criada pela aplicação, que busca os dados em um banco de dados local ou em rede.

Perfil de uma aplicação Web
• Utiliza um software do tipo browser que é executado na estação do cliente que envia e recebe requisições http Get/Post a um servidor WEB http.
• O Servidor recebe as requisições e retorna conteúdo (response) que é interpretado pelo navegador que por sua vez cria componentes visuais de acordo com as intruções recebidas.

Perfil de uma aplicação RIA
• Une o melhor dos dois mundos: Executa na estação cliente e distribuíção é através da Web, com atualizações automáticas (ao carregar a página).
• Utiliza um navegador web que atua como um contêiner para a aplicação.
• A executada da aplicação é controlada por um plugin (Flash, Adobe AIR, Java, Silverlight).
• O plugin é executado no sistema operacional.


Experiências

Delphi

Antigamente eu desenvolvia aplicações utilizando Delphi. Fiz sistemas comerciais para desktop, gerando executáveis nativos para a plataforma Windows, acessando banco de dados Interbase/Firebird, Oracle e SQL Server.

• Prós: ótima IDE, facilidade e rapidez para criar uma aplicação, arrastando componentes visuais e configurando suas propriedades. Cumpre o prometido: RAD - rapid application development.

• Contras: As aplicações têm de ser distribuídas e instaladas diretamente nas estações dos clientes, gerando um trabalho extra e dor de cabeça quando era necessário atualizar versões.

Após a versão 8 do Delphi, muitos programadores passaram a desacreditar no futuro da linguagem, com a Borland vendendo o produto para outras empresas, gerando dúvidas e incertezas. Então os desenvolvedores mais prevenidos passaram a estudar uma outra linguagem, como VB.NET, ou migrar para o mundo WEB, como eu fiz.

PHP

Com a popularização da internet, surgiu uma demanda para criação de aplicações específicas para a Web, e com isso, a necessidade de aprender uma linguagem dinâmica. Dominar Html, CSS e Javascript se tornou essencial. O PHP então era a linguagem mais popular para aplicações web e tinha uma ampla comunidade de desenvolvedores.

• Prós: Ampla comunidade, muitos exemplos na internet e muito material disponível.

• Contras: Na minha experiência com PHP, percebi que não havia um padrão a se seguir, o PHP permite criar aplicações mal codificadas, mal escritas, código “macarrão” (html e código php misturado), e por si só não incentiva o programador a aprender a fundo a linguagem, não exige orientação a objetos nem separação de responsabilidades. É uma linguagem de script, interpretada a cada requisição. Para ter algum padrão, é necessário utilizar um framework. Caso contrário, basta copiar e colar qualquer exemplo de código já existente pela internet simplesmente porque alguém já fez e funcionou.

ASP.NET

Essa percepção “negativa” que tenho hoje do PHP aumentou depois que conheci a plataforma .NET, mais especificamente o ASP.NET, a plataforma da Microsoft para a desenvolvimento de aplicações do tipo “WebForms”. As aplicações WebForms abstraem o conceito de programação para a Web onde cada página é uma tela com componentes visuais, similar a um aplicativo desktop, mas renderizando obviamente conteúdo HTML.

• Prós: Separação de código HTML do código da aplicação, linguagem tipada, estática e compilada, não interpretada a cada requisição.

• Contras: O resultado final ainda é a renderização de HTML,CSS e Javascript que será interpretado no navegador, da mesma forma que qualquer linguagem para Web. Para manter o estado dos webforms e seus controles entre as requisições, simulando uma aplicação desktop), cada webform gera um overhead adicional, utilizando artifícios como Sessions, ViewStates, etc.


A web não foi feita para aplicações

A Web inicialmente não previa a execução de aplicações, como no desktop. Na verdade ela previa apenas a apresentação de conteúdo. Com o tempo, a web foi se adaptadando para simular aplicações. O protocolo HTTP evoluiu, depois surgiu o javascript, a seguir os browsers adicionaram suporte a javascript e plugins, etc. E o que temos hoje é uma mistura de várias linguagens e tecnologias trabalhando em conjunto para fornecer ao usuário um ambiente próximo a um aplicativo desktop. O resultado disso é que cada navegador implementa de maneira diferente essas tecnologias, obrigando o desenvolvedor a prever qual browser o usuário está utilizando, e enviar HTML/CSS/JAVASCRIPT específico para tal navegador (Chrome/IE/Firefox/etc).


Com a Web, sua estação de trabalho é um terminal burro

Vamos resumir o ciclo de vida de uma aplicação Web:

1 – Abrir seu navegador preferido.
2 – Informar a URL do site que contém a aplicação que desejada.
3 – O navegador resolve o endereço IP e encontra o servidor web onde a aplicação está hospedada e envia uma requisição do tipo HTTP/Get.
4 – O servidor web, independente da linguagem em que a aplicação foi feita, vai processar a requisição, executar as instruções necessárias e retornar ao navegador um “Response” contendo o HTML gerado pelo servidor.
5 – O navegador recebe a resposta, e partir daí começa a executar todas as instruções que o código HTML determina. Provavelmente isso vai demandar novas requisições para buscar imagens e outros “includes” como javascript/css, num ciclo interno até que finalmente a página possa ser renderizada no navegador.
6 – Esta página que está sendo exibida, pode conter links para outras páginas, nesse caso, ao clicar num link, inicia-se novamente a partir do item 3.
7 – Esta pagina pode conter um formulário que irá submeter dados ao servidor. Nesse caso, o navegador enviará os dados do formulário para o servidor, através de uma requisição do tipo HTTP/POST. O servidor web receberá esse formulário, a aplicação irá tratar as informações, executando as intruções necessárias e devolverá uma resposta novamente ao navegador. Voltamos então a partir do item 4.

Assim, vemos que uma aplicação web se resume a um navegador que envia requisições do tipo GET/POST, em que todas as respostas geradas pelo servidor web incluem novamente todo o conteúdo necessário para se renderizar uma página com imagens, textos a serem exibidos, código javascript, código CSS para formatação de estilos, etc.

O tráfego de informações que é gerado entre uma requisição e outra não se resume somente aos dados utilizados pela aplicação. Por exemplo, se você solicitar 10 vezes a mesma página ao navegador, todo o ciclo será repetido, e nas 10 vezes você receberá todo o mesmo conteúdo novamente.

Por isso costumo entender que de certa maneira, seu computador quando navega na internet é praticamente um terminal burro conectado a um grande mainframe, em que o mainframe processa toda a informação e envia instruções para o cliente exibir as páginas.

Silverlight – Rich Internet Application

Desenvolver com Silverlight é como desenvolver para desktop, utilizando processamento local para formatar telas através de instruções compiladas, com a facilidade de distribuição e atualização que a web oferece. E ainda com a vantagem de reaproveitar todo seu conhecimento em .NET, sem se preocupar com HTML, Javascript e CSS.

Uma aplicação Silverlight incialmente é um objeto carregado dentro de uma página Html. Após esse objeto ser carregado, a aplicação é gerenciada pelo runtime do Silverlight, dentro de uma área isolada e protegida conhecida como sandbox. Nesse ambiente, o silverlight por padrão faz requisições e recebe as respostas através de sua própria implementação de cliente http. Todo o conteúdo necessário para exibir e renderizar as telas e controles não precisam ser carregados ou interpretados novamente, tudo o que a aplicação precisa já está no objeto que foi carregado dentro do navegador. A comunicação com servidores Web se resume apenas a troca de dados, e não mais formatação de telas e regras de negócios.
Portanto, com o Silverlight, você programa praticamente como se programasse para desktop, utilizando uma única linguagem (no meu caso, C#), sendo que a distribuição da aplicação é direto pela Web, unindo o útil ao agradável.