Caros,
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. A seguir, tentarei mostrar "Por que Flex?". APLICATION MODEL FAMILIAR E PROGRAMAÇÃO BASEADA EM PADRÕES 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. []'s Beck Novaes --- Em [email protected], Jan Cássio <[EMAIL PROTECTED]> escreveu > > Bruno obrigado pela resposta. > > Em um ponto eu concordo com vc, estive observando alguns dos recursos > do Flex e vi que ele realmente tem essa vantagem do raid, mais não > vejo tanta vantagem por ele ter mais componentes que o Flash > simplesmente porque primeiro, os componentes da Macromedia são bem > pesados, algumas vezes não muito funcionais (são poucos), por isso, > vejo que o Flash hoje não é só uma ferramenta de animação mais também > é uma ferramenta de desenvolvimento. Segundo, eu acredito que se você > desenvolve um conteúdo RIA com a integração Flash & ColdFusion você > obterá resultados bem mais favoráveis e confiáveis, e uma coisa muito > importante, não precisa ser nenhum expert para conseguir isso como > Flash e ColdFusion concorda? > > Então não vejo motivos para a Macromedia querer o Flex acima do Flash > & ColdFusion para desenvolvimento de aplicações RIA, até porque você > precisa de um servidor de aplicação rodando por tras (sem maldade :p) > do Flex para interagir com base de dados e acho isso uma falha > grave!(pelo menos foi isso que eu vi, se eu tiver enganado ignore esta > colocação). Claro tem o J2EE rodando no back-end mas veja só, o preço > que você paga pela licença do Flex você consegue adiquirir umas 3 > licenças do Flash (eu acho pq o preço dessas coisas nunca está > estável) e a licença do ColdFusion Server é free para desenvolvimento, > então seria bem melhor vc adiquirir o uma do Flash e com o troco vc > investiria em um treinamento para você ou para seu desenvolvedor por > exemplo. > > Então no meu ponto de vista acho que o Flex tem muito a dar ainda para > estar a frente do Flash (e do ColdFusion tamém) para desenvolvimento > de aplicações RIA ou outro tipo de aplicações que envolva essas > ferramentas, é isso! > > E por favor, não pensem que estou metendo pau no Flex ou na MM, estou > apenas fazendo comparações. > > --- Em [email protected], Bruno Martins <[EMAIL PROTECTED]> > escreveu > > Olá jancassio, > > > > O lance da macromedia é concorrer com ela mesma, ela lança varia > > ferramentas para desenvolver a mesma coisa so que de modo diferente. > > Mas oque eu acho mesmo é que ela ta querendo deixar o flash para oque > > ele sempre foi, como uma ferramenta de animação, e o flex como uma > > ferramenta de desenvolvimento, pois como vc mesmo viu o flex eh > > extremamente estruturado e otimizado para o desenvolvimento de > > aplicações. Outra vantagem que vi no flex é que alem de aprensentar > > diversos componentes que o flash nao possui eu vi em um artigo que > > futuramente o flex implementara componentes que possibilita criar > > sistemas que rodem semi-online, ele ira rodar no cliente sem a > > necessidade de estar o tempo todo online, e acredito que eh uma grande > > vantagem. > > > > Bem essa eh minha opnião. Aceito outras ideias sobre esse tema... > > > > > > On Apr 4, 2005 5:28 PM, Jan Cássio <[EMAIL PROTECTED]> wrote: > > > > > > Olá galera tudo bom? Acho que é a primeira vez que publico algo neste > > > forum pois realmente não sou usuário nem desenvolvi nd com o Flex. > > > > > > Eu trabalho com programação há algum tempo e geralmente o Flash e o > > > ColdFusion fazem parte dos meus trabalhos. Quando o Flex foi lançado > > > eu achei que seria uma revolução no conceito RIA mas, eu pensei o > > > seguinte, se eu posso desenvolver conteúdo rico com mais qualidade, > > > desempenho e segurança para o cliente com o "casal Flash e ColdFusion" > > > pra que então usar Flex??? > > > > > > Claro, o Flex é uma alternativa ao RIA mas não vejo vantagens, a não > > > ser o tempo de desenvolvimento pois achei o código dele bem > > > simplificado (coisa que o ColdFusion ja tem há muitos anos). > > > > > > Não quero que interpretem mal o que eu estou publicando, apenas quero > > > saber quais são as vantagens do Flex comparando aos produtos Flash e > > > ColdFusion. > > > > > > Obrigado, até mais! > > > > > > > > > > > > > > > > > > Esse grupo faz parte da Comunidade Brasileira Flex > > > Sente confortavelmente e bem vindo ao Flex-Brasil > > > > > > > > > Yahoo! Grupos, um serviço oferecido por: > > > > > > > > > > > > > > > ________________________________ > > > Links do Yahoo! Grupos > > > > > > Para visitar o site do seu grupo na web, acesse: > > > http://br.groups.yahoo.com/group/flex-brasil/ > > > > > > Para sair deste grupo, envie um e-mail para: > > > [EMAIL PROTECTED] > > > > > > O uso que você faz do Yahoo! Grupos está sujeito aos Termos do > Serviço do > > > Yahoo!. Esse grupo faz parte da Comunidade Brasileira Flex Sente confortavelmente e bem vindo ao Flex-Brasil Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/flex-brasil/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
