Uma empresa como a Macromedia, quando lança um produto, não o faz ao
acaso. Existe toda uma pesquisa envolvida e fatores como tendências e
demanda de mercado são, certamente, levados em consideração. Estes
podem ser alguns fatores que determinam o preço estabelecido de um
produto.

Considero que a comparação que vem sendo feita entre Flex e Flash é
simplista demais. Se é que podemos compará-los, é preciso fazê-lo
dentro do contexto das RIAs e do desenvolvimento de aplicativos
coorporativos.

Um dos principais objetivos da Macromedia ao desenvolver o Flex era
permitir que os desenvolvedores Web J2EE e .NET utilizem os seus
conhecimentos para programar para a Flash Virtual Machine (Plug-in do
Flash).

Como, então, programam estes desenvolvedores Web? Resumidamente
falando, eles utilizam uma linguagem de programação (Java, C#, Visual
Basic .NET, etc) para a parte lógica e uma linguagem de marcação para
definir a interface (o HTML que é gerado pelo JSP ou ASP .NET). Estes
programadores também trabalham basicamente com arquivos texto e podem
utilizar o IDE de sua preferência. Quando é necessário alterar algo na
camada de apresentação, basta editar um arquivo texto (JSP, ou ASP
.NET) que se encontra no servidor de aplicativos Web. Digno de nota
aqui é o fato de que esta maneira de trabalhar independe de ser J2EE
ou .NET.

Não é difícil perceber que a modo de desenvolver um aplicativo no IDE
do Flash foge muito disto. Além do esquema de Deployment ser diferente
você está restrito a um único IDE pelo fato do FLA ser um arquivo de
dados binário e não um arquivo texto como a maioria das tecnologias de
desenvolvimento Web. Isso sem falar da timeline, que para um
programador Web tradicional é o equivalente a um bicho de sete cabeças.

No Flex você usa uma linguagem de marcação (MXML) para definir a
interface e uma lingaugem de programação para fazer a parte lógica
(ActionScript 2.0). Ambas as linguagens são baseadas em padrões – a
primeira nada mais é do que uma aplicação XML e a segunda é baseada no
ECMAScript. O Flex também trabalha com os padrões SOAP, CSS e HTTP.

É verdade que com exceção à utilização de uma linguagem de marcação
para definir a interface, o Flash também contempla estes padrões. Além
disto, levados por experiências frustrantes com o HTML (que é uma
linguagem de marcação) as pessoas poderiam dizer que “preferem”
construir a interface do aplicativo em um IDE como o Flash. De fato,
já ouvi muita gente falando que “esse papo de usar XML para definir a
interface não pega”. Porém, aqui entra o que eu falei no início com
relação às tendências. É uma tendência utilizar uma linguagem de
marcação para definir a interface dos aplicativos. Um exemplo claro
disso é o que a Microsoft está preparando
(http://www.ondotnet.com/pub/a/dotnet/2004/01/19/longhorn.html). E não
foi só a Microsoft que percebeu esta tendência
(http://xul.sourceforge.net/counter.html).

Não entrarei no mérito da questão sobre o fato de ser desejável ou não
definir uma interface programaticamente. O meu objetivo é apenas
mostrar porque uma linguagem de marcação é conveniente para definir
interfaces ao invés de uma linguagem de programação tradicional.

Ao contrário da moda, as tendências tecnológicas não são ditadas por
gostos subjetivos, mas sim pelo que prova funcionar ou não. O fato do
HTML ter se mostrado ruim para uma série de coisas não implica que as
linguagens de marcação são ruins para definir a interface. Uma
demonstração de que as linguagens de marcação são boas para definir a
interface pode ser vista no exemplo que segue. Os dois trechos de
código abaixo resultam na mesma interface. Qual deles é o mais legível?

Este?

import mx.controls.Label;
import mx.controls.TextInput;
import mx.controls.Button;
import mx.containers.Panel;

public var btnSubmit:Button = null;
public var txtFirst:TextInput = null;

public function initApp( Void ):Void {
var pnlHello:Panel = null;
var init:Object = null;

init = new Object();
init.verticalAlign = “middle”;
init.direction = “horizontal”;
init.title = “Hello World”;
pnlHello = Panel( createChild( Panel, “pnlHello”, init ) );

init = new Object();
init.text = “First name:”;
pnlHello.createChild( Label, “lblFirst”, init );

init = new Object();
init.text = “Macromedia”;
txtFirst = TextInput( pnlHello.createChild( TextInput, “txtFirst”,
init ) );

init = new Object();
init.label = “Submit”;
btnSubmit = Button( pnlHello.createChild( Button, “btnSubmit”, init ) );
btnSubmit.addEventListener( “click”, this );
}

Ou Este?

<mx:Panel title=”Hello World” direction=”horizontal”>
<mx:Label text=”First Name”/>
<mx:TextInput id=”txtFirst” text=”Macromedia”/>
<mx:Button id=”btnSubmit” label=”Submit”/>
</mx:Panel>

A comparação chaga a ser covardia. Creio não ser preciso provar que a
legibilidade é importantíssima para o desenvolvimento de software, mas
devo mencionar apenas que, do contrário, as linguagens de programação
ainda teriam duas ou três letras para todas as palavras reservadas.

É conveniente, portanto, utilizar uma LINGUAGEM DE MARCAÇÃO para
definir a interface. Porém, as LINGUAGENS DE MARCAÇÃO não são boas
para fazer a parte lógica do aplicativo. Desvios condicionais, laços
de repetição e definição de classes com hierarquias complexas são
melhores codificados em LINGUAGENS DE PROGRAMAÇÃO tradicionais. Por
isto existe uma linguagem de programação e outra de marcação no Flex.

PRODUTIVIDADE

Diversos fatores fazem do Flex uma ferramenta muito mais produtiva que
o Flash. Tente, por exemplo, desenvolver um aplicativo em Flash capaz
de reorganizar o layout dos componentes de interface de acordo com o
tamanho da janela do Browser – eu disse reorganizar o layout e não
“esticar” os componentes.

O Flex trabalha com Containers para gerenciar o layout do aplicativo,
possuí um elegante sistema de Data Binding, possuí um recurso
denominado Validators para auxiliar na validação dos dados de entrada,
possuí um esquema de gerenciamento de dados (Data Management) no
cliente que lhe permite implementar as melhores práticas de Orientação
a Objetos, possuí uma “abordagem padrão” para comunicação com o
Back-End independente do seu serviço remoto ser um Objeto Java, .NET
ou um Webservice , além dos Formatters, Behaviors, etc. Porém, ao
invés de simplesmente enumerar as vantagens do Flex com relação a
produtividade, creio que conclusões mais úteis poderão ser tiradas se
compreendermos como a Macromedia chegou até estas vantagens.

Durante a fase de levantamento de requisitos para o desenvolvimento do
Flex a Macromedia abordou as empresas que melhor estavam fazendo uso
do Flash para o desenvolvimento de RIAs com perguntas do tipo: “O que
é mais comum nas RIAs que vocês estão desenvolvendo? O que dá mais
trabalho de implementar no Flash e que vocês precisam fazer
frequentemente?”. Foi assim que a Macromedia chegou ao Flex
Application Model, que permite às empresas construir RIAs
manuteníveis, escaláveis e seguras dentro de padrões de mercado e sem
precisar reinventar a roda.

Estender um componente visual no Flex, por exemplo, é simplesmente uma
questão de substituir a tag Application por uma outra tag qualquer a
qual será a classe pai do novo componente visual que está sendo
criado. Componentes em XML? Oras, eu já mostrei que as linguagens de
marcação são convenientes para definição da interface, se o componente
é visual, então também é conveniente usar uma linguagem de marcação.
Sim, você pode também ter componentes não visuais, provavelmente para
alguma lógica da interface. Neste caso, use o ActionScript.

LOOK AND FEEL

Muitos vêem como um ponto negativo o fato dos aplicativos em Flex
serem “semelhantes”. Eu vejo isto como um ponto forte do Flex. Mais
uma vez é preciso fazer a pergunta: Por que a Macromedia fez assim?

Certa vez um designer me disse que não gostava muito do Flex porque
ele achava que o Flex daria origem a um monte de sites iguais na Web.
Oras, isto demonstra que ele não compreendeu o conceito RIA cuja
ultima letra do acrônimo significa “Applications”. Discutir a
diferença entre um site e um aplicativo pode levar a um outro debate,
por isso, concentro meus esforços em mostrar porque os aplicativos
Flex possuem a aparência “default” que possuem.

A Macromedia tem uma equipe focada em pesquisas na área de Interação
Homem-Máquina. Embora este seja um assunto frequentemente ignorado nos
cursos de Ciências da Computação, sua importância tem ganhado força
com a popularização da Usabilidade. O ponto de partida desta equipe
com relação às RIAs é que uma RIA não é uma Web Application, tampouco
é um aplicativo desktop. Ou seja, trata-se de uma nova geração de
aplicativos que precisa ser “padronizada”. Para alguns designers, isto
pode soar como uma limitação à sua infinita criatividade. Não gostaria
de perder muito tempo argumentando contra isto, mas gostaria de deixar
algumas perguntas no ar: por que os aplicativos de desktop são, de
certa forma, semelhantes? Por que o botão salvar dos aplicativos do
Office se localizam na mesma posição? Ou seja, qual a importância da
consistência no Design de Interface?

Voltando a falar do trabalho da equipe de Design da Macromedia, o
fruto de alguns destes estudos é algo que eles denominaram Halo
Experience Model
(http://www.macromedia.com/devnet/flex/articles/halo.html), que
podemos imaginar como um conjunto de boas práticas de design para as
Rich Internet Applications. O fato é que quando você desenvolve um
aplicativo em Flex é provável que este aplicativo resulte em uma boa
experiência para o usuário. Isto porque os componentes do Flex são
como são baseados nos estudo de Interação Homem-Máquina e não no gosto
subjetivo de algum designer cujo ego é maior que a sua capacidade de
compreender algumas coisas. Um bom exemplo disto é o componente Panel.
A idéia de ter um componente destes não é arbitrária. O componente é
embasado em um dos princípios da Gestalt
(http://en.wikipedia.org/wiki/Gestalt_psychology), o agrupamento:
dados agrupados podem permitir uma melhor organização da informação
com resultados positivos para quem vê. O componente Panel, também tem
uma outra parte denominada “Control Bar” que tem por objetivo separar
o conteúdo e os controles de interface. Se você não entendeu nada do
que acabei de falar, tenha em mente apenas que as decisões da
Macromedia de desenvolver os componentes do Flex com aquele Look And
Feel são baseadas em pesquisas. Deste modo, se você usar bem, estará
tirando proveito delas. Agora, se você ACHA que o usuário ACHA melhor
outra coisa é melhor começar a rezar para que você esteja certo.

Eu não estou dizendo que você não deve mudar nada com relação ao Look
and Feel. De fato, o nível de personalização que é possível conseguir
só com o uso de CSS no Flex é impressionante. Porém, não é difícil
alguém sugerir que o componente Panel, por exemplo, deve ser 3D porque
vai ficar mais “bonitinho”. Enfim, se você estiver querendo fazer algo
completamente diferente sugiro que pense bem se isto vale o esforço.
Estamos falando de APLICATIVOS e não de obras de arte. A beleza é
importante, mas se ela for muito mais um objetivo do que uma
conseqüência o resultado final pode ser o equivalente a uma Ferrari
com motor de Fusca.

FLEXIBILIDADE

Um argumento comum de um desenvolvedor em Flash é que o Flash é mais
flexível e por isso ele é melhor que o Flex. Mas sempre o que é
flexível é melhor? Será que não existe um ponto onde flexibilidade
demais atrapalha?

Para responder esta pergunta posso mencionar o caso “Go to”. Nos anos
70 muito se debateu se a instrução “Go to” era benéfica ou prejudicial
às linguagens de programação. Quem teve a oportunidade de programar em
uma linguagem com o “Go to” sabe que é possível representar qualquer
laço de repetição (for, while, do while, repeat) apenas com esta
instrução. Ou seja, o “Go to” oferece uma grande flexibilidade ao
programador. Mas o problema da flexibilidade é o abuso. Constatou-se
que os programas que usavam o “Go to” davam origem a um código
ilegível, terrível de manter. Por isto o “Go to” foi abolido da
maioria das linguagens – embora, em nível de máquina, os laços de
repetição têm a sua semântica traduzida para um “Go to” equivalente.

Creio que algo parecido nós podemos dizer com relação à flexibilidade
do Flash. Certa vez um designer me fez perder algumas horas
programando um “Accordion Horizontal” por que ele achou mais bonito.
Depois de pronto ele ainda quis adicionar algumas outras
funcionalidades. Como eu não havia previsto que ele iria querer mais
funcionalidades houve uma hora que nem eu entendia o meu código.
Perdemos muito tempo fazendo algo que o designer ACHOU que ia ficar
mais bonito quando poderíamos usar o Accordion que já existia e
dedicar o restante do tempo para criar outras funcionalidades que
podem realmente melhorar a experiência do usuário. No Flash, este tipo
de “viagem” acontece com freqüência. Todos sabem que dá para fazer
muita coisa e muitos não resistem à tentação de fazer algo diferente
mesmo que isso no futuro prove não ser tão eficiente quanto o que já
existe. Gostaria de saber por que as pessoas insistem em ignorar os
efeitos colaterais do “achismo”.

Enfim, eu diria que o Flash tem o nível de flexibilidade desejável
para trabalhar as RIAs em baixo nível – criar coisas que fogem dos
padrões de interface já identificados nas RIAs e prontos para serem
usados no Flex. Já o Flex, tem o nível de flexibilidade desejável para
o desenvolvimento de RIAs coorporativas, manuteníveis, extensíveis e
escaláveis.

PREÇO

O benefício de uma RIA pode ser muito grande. Elas permitem que o
potencial da Web seja finalmente aproveitado para o desenvolvimento de
aplicativos. O Flex não tem como objetivo pequenos projetos cujo
retorno sobre o investimento não é capaz de cobrir o preço de uma
licença. Muitas empresas já compreenderam isto e estão saindo na
frente (http://www.macromedia.com/software/flex/customers/). Não houve
um Happy Hour na Macromedia onde um Zé Mané qualquer disse que o
produto deveria custar X. Houve uma pesquisa do valor agregado e da
demanda no mercado. Sabemos que há uma tendência de um produto novo
baixar de preço conforme ele deixa de ser novidade. Porém, muitas
empresas não se importam com esta diferença quando ela é compensada
pela vantagem competitiva de estar na vanguarda. Além disso, um
“projeto de Flex” que for feito em Flash provavelmente vai estourar no
prazo, vai ser difícil de manter e vai ter mais bugs, de modo que
todos estes problemas medidos em homem-hora pagariam perfeitamente uma
licença de Flex.

OUÇA A VOZ DA EXPERIÊNCIA

Eu não gosto muito de argumentos por autoridade. Porém, devo abrir uma
exceção neste caso. A IterationTwo (http://www.iterationtwo.com) é, em
minha opinião, uma das empresas que melhor desenvolve RIAs no mundo.
Por que será que eles adotaram o Flex?
(http://www.iterationtwo.com/interactive_technologies.html)

Quem gosta de programação de verdade tem que dar uma olhada no
Cairngorm (http://www.richinternetapps.com/archives/000094.html), um
conjunto de Design Patterns para RIAs que tornam o sonho da OO para a
Web uma realidade.

CONSIDERAÇÕES FINAIS

A palavra Rich do acrônimo RIA bem que poderia ser um indicativo de
quão Rico é o assunto. Alguns pensam que as RIAs aposentam o HTML.
Outros acreditam que as RIAs jamais serão realidade. Eu sempre digo
que nenhuma tecnologia resolve todos os problemas e aquela que se
propuser a tamanha empreitada será extensa demais para este mundo tão
especialista.

Umberto Eco foi brilhante em uma apresentação
(http://www.inf.ufsc.br/~jbosco/InternetPort.html) no MIT onde ele
mostra que o surgimento do novo não implica necessariamente na
extinção do velho. Novo e velho podem coexistir mesmo que funcionando
de modo diferente. Um exemplo disto é que os livros digitais
dificilmente substituirão por completo os livros em papel. É verdade
que um manual de referência é bem melhor em sua versão digital (você
pode localizar as informações mais rapidamente e pode haver hiperlinks
entre elas), mas experimente ler um romance em frente ao computador.

Acredito que algo parecido pode ser dito com relação às RIAs e também
com relação ao Flex e o Flash. Nada aqui é excludente. Só precisamos
compreender onde entra cada um deles. Para isto devemos abandonar
alguns pré-conceitos e ter uma visão mais horizontal da tecnologia.

Espero ter contribuído de alguma forma para a discussão.