Bruce Eckel ataca novamente!

No artigo a conclusão dele é favorável ao flash e suas variantes mais recentes voltadas para RIA.

O engraçado é que propus o flash a cerca de 3 anos atrás como solução para uma aplicação “séria” (front-end para uma central de atendimento) e acharam que era algo “muito arriscado”.

Felizmente tive outro projeto de automação bancária onde a idéia vingou, e hoje está em produção. A arquitetura básica foi a descrita no artigo: um front-end em flash acessando serviços via (no meu caso)XML-RPC.

A grande dificuldade foram as limitações da versão pré-flex da ferramenta da então Macromedia, muito mais voltadas para a criação de animações do que uma interface de usuário. De qualquer forma, no caso particular de automação bancária, o paradigma do “time-line” mostrou-se interessante, pois permitia mapear diretamente os estados de um diagrama de atividade nas telas correspondentes do terminal, simplificando a geração de protótipos.

Outros pontos negativos:

• IDE que só roda em Windows e Mac
• Player stand-alone com alguns bugs irritantes em Linux, obrigando o uso de um browser - junto com todo o overhead que isto significa - apenas para carregar o plugin.
• O player não possui mecanismos de extensibilidade via plugins.
• Tendência a “vazar” memória com o tempo, exigindo alguns cuidados na criação dos scripts

Vantagens:

• Facilidade no desenvolvimento, principalmente na geração de protótipos navegáveis
• Excelente performance da interface (ponto crítico e que, sozinho, justificou o uso do Flash na ponta) aliado a baixo consumo de recursos no terminal

nem me fale em incompatibilidade de browsers

agora nós não desenvolvemos para web e sim, para IE ou não-IE

Agora?

Pôxa vida. Tem uns 5 meses que voltei para o mundo de de verdade (e não sistemas com interfaces toscas que tinham que ser web sem nenhum motivo real) após cinco anos e pela primeira vez em dez anos eu vejo que existe algum nível de compatibilidade razoável entre browsers.

pcalcado,

Acredito que esse ponto de compatibilidade não seja algo tão visível assim, até por que, se não fosse assim, não precisaríamos fazer as gambiarras chamadas de CSS Hack. Outro problema que bruce apresenta em seu texto, é também o fato do Java ter tentando a muito tempo atrás “usar” o Applet, como sendo a revolução de interface “dinâmica” para a web, como todos nós já sabemos e já falamos a muito tempo antes, isso é claro que não deu certo, e não foi para frente.

Acredito que trabalhar para a web hoje em dia seja tão ou igual trabalhoso como antes (5 anos atrás), porém com o advento do Ajax, possa surgir frameworks que minimizem esse trabalho.

psevestre,

De fato sim, ele defente o uso do flash para aplicações comerciais, o problema que nesse aspecto sou um pouco cético. Não conheço o flex (diga-se, programar nele), mas já fiz alguns testes com Laszlo e siceramente não gostei muito, não pela ferramenta em sí que é bem interessante, tem uma documentação boa, e boas cosias surgindo a respeito, mas minha questão foi no desempenho, na performance, as aplicações ficam visivelmente mais lentas, pode ser que melhorem ou tenham melhorado em partes, mas esse ponto, para mim, foi crucial.

Grinvon:

psevestre,

De fato sim, ele defente o uso do flash para aplicações comerciais, o problema que nesse aspecto sou um pouco cético. Não conheço o flex (diga-se, programar nele), mas já fiz alguns testes com Laszlo e siceramente não gostei muito, não pela ferramenta em sí que é bem interessante, tem uma documentação boa, e boas cosias surgindo a respeito, mas minha questão foi no desempenho, na performance, as aplicações ficam visivelmente mais lentas, pode ser que melhorem ou tenham melhorado em partes, mas esse ponto, para mim, foi crucial.

Tambem não gostei do Lazlo, mas esta foi uma impressão resultante de cerca de uma hora de testes feitos logo que o lançaram.

O que andei fazendo com Flash foi usando a IDE da própria Macromedia (agora Adobe). Diferente da sua experiência, no meu caso o resultado final foi uma aplicação muito mais “ágil” em comparação com o que seria uma abordagem tradicional com acessos HTTP em cada passo de uma transação, já que a navegação entre “telas” correspondia, na verdade, a uma simples transição de keyframes do mesmo SWF.

O tempo de resposta das transações que envolviam acesso a dados no host tb. foram simplificadas, gerando apenas o XML relativamente compacto do padrão XML-RPC (!= SOAP).

Você poderia fornecer alguns detalhes adicionais dos problemas de performance que vc. enfrentou ? Qual a arquitetura da aplicação ? Usou algum dos componentes de acesso a dados do Lazlo ?