HTML + Windows = BFF

Quando a Microsoft anunciou que o Windows 8 permitiria rodar nativamente na nova interface Metro, além de .NET e C++, também HTML e Javascript, vimos respostas muito diferentes. Alguns adoraram, outros odiaram. Mas hoje isso já é uma realidade, o Windows 8 deve sair esse ano, e o suporte virá. Quem está com o Beta (aka Consumer Preview) e a próxima versão do Visual Studio (aka Dev11) já está fazendo seus testes e algumas aplicações até já aparecem no marketplace do Windows 8. Quero discutir porque a Microsoft está indo nessa direção.

Coloque-se no lugar do estrategista mor do Windows, e tente descobrir o que o motivaria em tal caminho. Vamos fazer esse exercício.

Como principal estrategista seu objetivo final é vender mais licenças do Windows. Há muitas formas de fazer isso, e uma dela é aumentar o número de aplicações que rodam no Windows, tornando o sistema operacional mais atrativo aos clientes, dado o maior valor agregado por tais aplicações. Vamos focar nessa meta. Para alcançá-la, alguns problemas devem ser resolvidos. Ainda não existe um segmento significativo de tablets com Windows, o que diminui a importância deste mercado. O marketplace ainda é uma ideia desconhecida, e isso impacta tecnicamente e afasta novos desenvolvedores Poucas aplicações de fato existem, diminuindo o efeito manada. Estamos diante do problema do ovo e da galinha: precisamos de mais aplicações para tornar o marketplace atraente para desenvolvedores, e precisamos de desenvolvedores fazendo aplicações para tornar o marketplace atraente. Além disso, como atrair desenvolvedores de outras plataformas, que já escrevem aplicações para tablets Android e iPads, onde o mercado já está mais consolidado? Melhor: como atrair desenvolvedores que já desenvolvem aplicações para outras telas que não sejam tablets (celulares, desktop, web) sem muita dificuldade para portá-las para o novo marketplace?

É nesse cenário que o suporte a HTML e Javascript brilha. Eu até acredito que a Microsoft está suportando tais tecnologias para ser mais inclusiva, mas não acredito que esse seja o objetivo final. Eles o fizeram para diminuir a curva de aprendizado entre os milhões de desenvolvedores web e facilitar a escrita de aplicações. Se uma empresa já tem uma aplicação na web, é muito fácil portá-la para o Windows. E muito mais fácil do que portar para iPad ou Android. Simples assim.

Some-se a isso o fato de que a única tecnologia que todas as agências de publicidade do mundo conhecem profundamente é HTML e Javascript. Suportando nativamente dentro do Windows o ambiente mais utilizado no mundo, a Microsoft acabou por transformar qualquer web designer ou desenvolvedor web em desenvolvedor de aplicações do Windows 8. Genial.

Imagino que veremos nos próximos anos uma avalanche de aplicações no Windows 8. Ainda que não seja um líder no segmento de tablets, o Windows é um líder incontestável no segmento de computadores pessoais, tendo o Mac e o Linux como distantes competidores. Com um marketplace facilitando o processo de publicação e instalação de aplicações e uma ferramenta conhecida para desenvolvimento concretizada no HTML e Javascript, não há motivo para não abraçar a plataforma, e seria um risco não fazê-lo. O efeito manada virá não só baseado no fato de que muito será falado sobre o fato, mas do receio de que o concorrente já estará suportando ou se preparando para suportar o novo ambiente.

Não é a primeira vez que a Microsoft faz isso. Para migrar desenvolvedores de Visual Basic 6 para o .NET, ela criou o VB.NET. Para migrá-los para a web, criou o ASP.NET WebForms e o grid layout (lembram dele?). Para migrá-los para o XAML criou o Silverlight.

O passo é significativo, e não ficarei surpreso se Apple e Google se movimentarem na mesma direção com o iOS e o Android. Já há rumores de que o kernel do Windows 8 estará presente no Windows Phone 8, o que habilitará o desenvolvimento de aplicações com HTML e Javascript como cidadão de primeira classe também para o celular. Ao que tudo indica, o Javascript será a linguagem mais predominante em qualquer device, não o Java, e não o C#.