Muitos criticam as RIAs da Plataforma Flash por não serem RIAs que seguem os padrões Web (Web Standard). Mas eu tenho a impressão que se olharmos esta questão com mais cuidado vamos concluir que justamente por não seguir os padrões estas RIAs possuem a tendência de serem muito mais viáveis que as RIAs que utilizam os padrões. Vejamos por quê.

1. ActionScript

Apenas recentemente o ActionScript apareceu entre as 20 linguagens de programação mais usadas. Quando eu falo nos treinamentos de Flex que as pessoas tem que usar uma “nova linguagem” muitos torcem o nariz. Mas primeiro é preciso ressaltar que o AcionScript foi desenvolvido respeitando os mesmos padrões (ECMAScript) que o JavaScript – o que diminui a curva de aprendizado. No entanto o ActionScript não é JavaScript e se no curto prazo isto pode parecer um problema (ter que aprender uma nova linguagem) no médio prazo você verá que isto é um grande benefício.

Quem já teve a oportunidade de usar o Browser do Google deve ter percebido o quanto algumas aplicações rodam mais rápido. Isto se deve ao fato do JavaScript ser “pré-compilado” no Chrome depois do primeiro acesso. Em outras palavras, parece que só agora as empresas estão percebendo que para aplicações complexas interpretar o JavaScript já não é mais viável. No entanto, o ActionScript, que já é compilado há muito tempo, continua sendo infinitamente mais rápido que o JavaScript no Firefox, no Internet Explorer e no Opera.

Além disso, o ActionScript 3 é muito mais Orientado a Objetos e já tem suporte total ao E4X, funcionalidades estas que ainda aparecerão no JavaScript um dia (ninguém sabe quando). O fato é que é muito mais fácil para a Adobe introduzir novas funcionalidades no ActionScript do que uma nova versão do JavaScript ser aprovada e todos os browsers a suportarem.

2. W3C

Assim como deve demorar para o Firefox, o Internet Explorer, o Chrome, o Opera, e outros browsers suportarem a versão mais recente do JavaScript demora para eles suportarem a versão mais recente do HTML e outros padrões. Eu não sei se você sabe, mas para um conjunto de tags no HTML ser aprovado leva um bocado de tempo. São quatro fases até alguma coisa ser finalmente recomendada pelo W3C. Isto quer dizer que por mais que as novas Rich Internet Appications exijam novas funcionalidades elas só se tornarão realidade na medida em que o W3C for mais ágil na evolução dos padrões.

No caso da Adobe é diferente. Ela controla o SWF e pode adicionar novas funcionalidades muito antes do W3C. Inclusive, funcionalidades que talvez nunca existam nos padrões Web.

3. Flash Player

Se o usuário quiser ver um vídeo no HTML sem ser Flash Vídeo você estará dependendo do Windows Media Player ou do Quick Time ou de outro formato de vídeo qualquer se é que eles existem ainda. Além disso, pode acontecer dele ter o Windows Media Player mas não ter o Codec. Quer coisa mais chata do que isso? No Flash Player o usuário tem áudio e vídeo integrado. Ele não precisa de outro player nem um codec específico porque ele já tem o Flash Player.

Agora, imagine também que você pode compartilhar com segurança bibliotecas de Interface de Usuário entre aplicações mesmo elas estando em diferentes domínios. Imagine também poder persistir objetos complexos nos Cookies além de simples strings. Imagine também poder fazer duas interfaces de usuário conversarem entre si de uma maneira segura mesmo estando em diferentes domínios. Eu estou falando de Runtime Shared Library, Shared Objects e Local Connection. Tudo isto são funcionalidades desejáveis para atender alguns requisitos das Rich Internet Applications que você não tem com os padrões Web mas tem na Flash Platform.

4. FXG vs. SVG

A próxima novidade da Adobe que fará muita gente torcer o nariz é o FXG (Flex Graphics). Em muitos sentidos FXG faz o mesmo que o SVG. E o motivo pelo qual a Adobe resolveu não seguir este padrão pode ser lido na integra aqui.

Falando de forma resumida, a Adobe resolveu não usar o SVG porque ele é limitado demais para o que a Adobe quer oferecer de funcionalidade nas RIAs da Flash Platform. O FXG vai permitir tirar melhor proveito do Data Binding, terá uma sintaxe mais concisa e poderá tirar bom proveito das novas funcionalidades do Flash Player 10 como o 3D.

Enfim, creio que a Adobe fez muito bem em não adotar o SVG dada a lentidão que os padrões evoluem. Para se ter uma idéia o SVG está em desenvolvimento desde 1999 e ainda tem um suporte muito fraco nos browsers. O SVG mal foi adotado e já está ultrapassado.

Conclusão

Equipes extremamente talentosas como a do Google podem desenvolver boas RIAs viáveis usando os padrões Web. Mas sabemos que no mundo real as coisas não são bem assim.

É verdade que as RIAs da Plataforma Flash tem uma grande empresa no controle e isto incomoda muita gente. Parece que num mundo onde grande parte das coisas funcionam com base na confiança as pessoas de TI ainda vivem na utopia de que a tecnologia deve ser “imparcial” em si. Por isto, elas tem medo de que grandes empresas estejam no “controle” de determinadas tecnologias. Tal medo nas pessoas é até justificável. O problema é que vem a mente uma série de “e se” que por medo as fazem recusar algo que não é necessariamente ruim: “e se a Adobe resolver não dar mais suporte ao Flash Player”; “e se a Adobe resolver cobrar pelo uso do Flash Player”, etc. Bem, ao invés de me preocupar com estas hipóteses baseadas no medo eu prefiro me voltar para os indícios. E nos últimos quatro anos eu não vi muitos indícios capazes de me fazer acreditar nestes “e se”. Mas vejo sim o W3C lento demais para saciar a minha sede de desenvolver boas RIAs viáveis. Seria perfeito poder desenvolver boas RIAs viáveis utilizando só os padrões Web. Mas infelizmente o mundo não é perfeito.

OBS: Este post foi originalmente publicado aqui.