Já tem um bom tempo que pretendo escrever sobre isto, a ferramenta correta para o problema correto. Resolvi finalmente escrever sobre este assunto devido aos questionamentos que surgiram na minha palestra do RailsForKids, perguntado como escolhemos as tecnologias para nossos projetos.

Este post também é uma resposta ao flamewar sem sentido que apareceu na comunidade Flex por causa de uma levantamento pragmático sobre a tecnologia.

Gostaria de apresentar como costumamos decidir as ferramentas de um projeto. Então eu gostaria de apresentar a caixa de ferramentas e coisas com que trabalhei nos últimos anos:

• Ruby
• Rails
• Javascript
• Jquery
• Prototype
• XHTML/CSS
• Flex
• Flash (AS3 e usando frameworks como Gaia e Mate)
• PHP
• Delphi
• Java (J2me)

Eu não listei tecnologias relacionadas a design (como Adobe Photoshop, Adobe Illustrator, 3D Studio) ou infra-estrutura como GIT, Capistrano, sistemas Unix, Apache. Também não falo de metodologias e conceitos como TDD, BDD e outros. Também não listei tecnologias que estudo por diversão mas que nunca cheguei a utilizar em projetos reais, como Capuccino, Sproutcore, Smalltalk, Lisp, CouchDB, MacRuby, Objective-C, Adobe Air e etc. O foco aqui é mais linguagem de programação/marcação e mostrar a importância de conhecer bem mais de uma ferramenta.

Obviamente não sou fluente e nem especialista em tudo isto, mas posso dizer que apesar de tentar estudar várias coisas diferentes eu tento me especializar em apenas 2 coisas no máximo, Rails/Ruby e design de interfaces. Porém, em algumas linguagens/ferramentas tento me manter atualizado e estudando, em especial tecnologias que componham o ambiente de um sistema web (que por padrão é multi-disciplinar), ferramentas como XHTML/CSS, Javascript(e frameworks) e Flash( + derivados).

Sou a favor que todos (inclusive designers) devam ser especialistas generalistas. Em qualquer área é muito importante saber quais as ferramentas existem, conhecer as vantangens e desvantagens de cada uma, abrindo o leque o máximo possível, mas mantendo-se realmente especializado em uma ou no máximo duas coisas.

Você não nasceu com um cérebro deste tamanho para aprender só uma coisa, certo? Da Vinci só sabia pintar? Einstein era só físico? Michael Jackson só sabia dançar? Não! E todos foram extremamente bem sucedidos. E este era o trabalho deles, o que não é diferente para você. Entender suas ferramentas é o seu trabalho.

Então se você abrir sua visão será capaz de optar por uma ferramenta melhor para um problema específico.

Atualmente trabalho em uma empresa muito pequena, exatamente por que é onde eu posso tomar este tipo de decisão. E esta liberdade é o que me permite estudar todas estas tecnologias e saber que não estou preso a uma tecnologia pois a empresa é partner ou tem certificação de algo em especial.

No RailsForKids o Daniel Willian e outras pessoas pergutaram como escolhemos entre Flex e XHTML/CSS (repare que é uma dúvida restrita a front-end). Para responder, primeiro vamos entender o backend.

Aqui tentamos adotar a seguinte posição, somos desenvolvedores Rails por opção e evitamos utilizar PHP ou Java ao máximo pois são imensamente piores para manutenção se comparado a clareza e abstração do Ruby.

E descobrimos isto bem no início, uns 3 anos atrás, quando percebemos que gastavamos 6 meses para criar um portal ou um sistema razoávelmente complexo em PHP mas serve qualquer tecnologia">PHP e no final apesar de termos um código OOP (pseudo OOP como qualquer código PHP) e muito bem organizado ainda não era lá grandes coisas para o padrão desejado.

Nós também não queríamos crescer, não queríamos contratar gente e produzir resultado rápido por força bruta. Queríamos ser produtivos, mas com qualidade. E usando o leque de ferramentas que estavamos testando (eu já desenvolvia em PHP a anos) seria impossível manter o negócio rentável. Não falo de amor por uma linguagem ou dogma, meu trabalho é exclusivamente gerar lucros para o meu cliente e consequentemente para nós mesmos.

Então o que fizemos foi abrir o leque e correr atrás de outras coisas. Python(Django), Smalltalk(Seaside), PHP e Ruby(Rails) foi o que procurei conhecer. Nitidamente a última solução era melhor para o nosso problema além de ser uma alternativa robusta por ideologia. E esta ferramenta se encaixou perfeitamente para o backend de praticamente todos os nosso projetos, seja site ou sistema, seja simples ou extremamente complexo. O Rails resolve muito bem o seu objetivo.

Obs.: Também utilizo Wordpress que é PHP, por que ele é atualmente a ferramenta correta para blog, não por seu código (que considero ridículo, basta ler o fonte do projeto) mas por sua comunidade e gama de ferramentas que envolve o serviço do Wordpress (mas meu sonho é que ele fosse re-desenvolvido em Rails).

Então restou o front-end, atualmente temos diversas tecnologias para front-end e diferente do backend díficilmente você poderá usar em 90% do caso uma única ferramenta. Então vamos listar as principais, seguidas de suas vantagens e desvantagens:

XHTML/CSS/ Javascript (nunca sem um framework):

Alternativa extremamente difundida, simples de aprender e ainda conseguimos designers que entendam um pouco de HTML e CSS. Ainda tenho a vantagem de ter javascript por padrão em todos os browsers sem um plugin e sem ser compilado. O projeto pode crescer horizontalmente sem me preocupar com o tamanho de um único arquivo, exatamente por não ser compilado. Ainda tenho a vantagem de ser amigável aos mecanismos de buscas e comportamentos que se tornaram padrão como URL’s, Bookmark, avançar e voltar no Browser e etc.

Também consigo criar algumas animações e um certo nível de assincronismo utilizando um framework de Javascript como Jquery. Afirmo que você nunca deve desenvolver em JS sem um framework pois é impossível manter seu projeto cross-browser já que todos os browsers possuem erros no DOM e os frameworks abstraem isto. Seguindo esta regra, também não tenho discrepância entre navegadores e Javascript.

Mas agora aparecem as desvantagens, manter as coisas exatamente igual em todos os navegadores no ponto HTML e CSS não é tão simples, isto graças ao Internet Explorer. Porém já existe o IE8 e este cenário esta mudando.

Outra desvantagem(ou vantagem) de HTML/CSS/Javascript é que eles abraçam o protocolo HTTP como ele foi pensado, então não é simples manter um assincronismo em um patamar maior. Logo se você precisa de algo como o Treinatom ou PhotoshopExpress sem dúvida o HTML/CSS/Javascript não é uma boa alternativa, gerando muito código e consequentemente algo impossível de manter.

Flash

Flash, diferente do que muita gente pensa é uma tremenda ferramenta de programação. Possui uma linguagem robusta e uma “VM” (o FlashPlayer) muito bem desenvolvida. Ele permite resolver o problema que apresentei o sobre HTML. FlashPlayer não abraça o HTTP e não navega entre diversos arquivos e urls. Desta forma é possível manter um assincronismo e ao mesmo tempo ter animações robustas. O que o torna perfeito para animações, jogos, interatividade e ainda 3D.

Mas ele também possui desvantagens, por não abraçar o HTTP perdemos coisas como url’s, botões do browser e indexação (já que o swf não é um arquivo de texto). Porém tudo isto pode ser implementado, mas tem um custo e este custo poderá pesar em sua manutenção futura.

Outra desvantagem é por ser compilado, o que pode tornar o seus arquivos finais bem grandes e fazendo com que estes arquivos cresçam mais a cada nova necessidade. Porém isto também pode ser resolvido, mas tem um custo, como dividir em vários swfs, externalizar fontes, imagem, aúdio e video. E este trabalho não é tão trivial assim sendo uma coisa que o html já faz por nascença.

Vale lembrar que o Flash adota AS3, e ela não é uma linguagem enxuta como Ruby. Basta correr o olho em qualquer projeto flash maior e verá dezenas de getter, setter, definição de varíaveis e consantes. Recentemente analisei o fonte de um StockImage em Flash e fique realmente assustado. Por este motivo os custos que falei podem se tornar imensos e resultando em um projeto inviável.

Flex

Mais uma vez, diferente do que muita gente pensa Flex não é Flash. Apesar de ser um framework de AS3 e compilar um swf, o fluxo de trabalho e forma de desenvolver do Flex é totalmente diferente do trabalho de um desenvolvedor Flash.

Flex não é tão bom para animações complexas e nem para jogos como o Flash. Isto ocorre por possuir seus componentes e classes bem definidas, criando uma limitação (mas uma limitação boa para seu objetivo).

Componentes, que por sua vez são pensados com o objetivo focado em aplicações semelhantes ao desktop. Grids, botões, janelas, menus e tudo que uma aplicação desktop costuma ter pode ser encontrado no Flex.

Outra vantagem, o Flex tenta trazer o bom do desktop para o web, então ele é por natureza assíncrono (já que roda no FlashPlayer). Por ser assíncrono e focado em aplicativos você terá facilidades para implementar coisas como o Treinatom ou Photoshop Express.

Mas tem um porém, você também perde url’s (ok, estou cansado de saber que é possível usar coisas como DeepLinking e HistoryManager mas isto tem um custo, que em html não existe). E você tem que tomar os mesmos cuidados do Flash e dividir seu projeto em vários arquivos e externalizar assets. Consequentemente, por ser um swf você tem as mesmas desvantangens do Flash em relação a estrutura.

Outros

Existem outras coisas como Capuccino, SproutCore, Open laszlo, Silverlight, JavaFX, Gear e etc. Mas não vou entrar em detalhes pois acabam se encaixando no que foi dito acima.

Agora que sabemos as vantagens e desvantangens podemos imaginar os cenários:

Websites, portais, sistemas:

XHTML/CSS/JS é perfeito para websites e portais. Pois são projetos que precisam ser indexados com magnitude, precisam funcionar bem com o browser(urls, botões, histórico, etc) e não devem conter nenhuma barreira que exija usuário instalar algo(ok, flashplayer esta em 90% das máquinas, mas ainda é algo para instalar).

Já que são de acesso público (normalmente). Sites e portais, crescem exponencialmente todos os dias, e em html podem tirar proveito de técnicas de cache que criam arquivos html estático e evitam processamento no backend. Também podem crescer em número de arquivos sem se preocupar com o tamanho de um pacotão compilado que precisa ser sub-dividido.

É perfeito também para sistemas com muito conteúdo em texto, porém pouca mídia (video e aúdio) e sem muita necessida de assincronismo. Para um nível pequeno de assincronismo, algumas chamadas Ajax resolve bem o problema. E você continua com as vantagens que citei.

Melhor ainda se seu sistema precisa fazer uso de urls para organização (coisa comum em arquitetura REST) pois html abraça HTTP. E no fim você ainda poderá utilizar formas de otimizar performance via http e sairá no lucro.

Hotsite, jogos e interatividade

Hotsite, Jogos ou peças de marketing interativo na grande maioria das vezes não precisam ser indexados, não precisam de urls e fazem uso intenso de animações complexas e assincronismo.

Algumas vezes precisam aceitar bem fórmulas matemáticas e desenhar algo com isto.

A maior parte do tempo não terão formulários ou muito texto. Também não é algo que vai crescer exponencialmente e precisar de manutenção diária, e também normalmente são projetos com curto tempo de vida.

Logo Flash encaixa como uma luva, e não tem ferramenta melhor.

Sistemas desktop like

Se você precisa de algo online, mas que se comporte exatamente como uma app desktop, permitindo que ao mesmo tempo que um video é transmitido, um desenho seja feito e salvando estas coisas de forma permanente então Flex é melhor opção.

Flex foi pensando para aplicativos, normalmente fechados ou intranets onde você não tem a necessidade e enviar uma url para o twitter. Também é comum ver sistemas Flex rodando em um ambiente previsto, onde você sabe que todos terão o player instalado, que todos terão uma internet razoável e que não haverá problema dividir o projeto em vários arquivos de 250kb, além de um loading inicial de 500kb (que vai ficar no cache eternamente).

Para nós (Area) ainda existe um player diferente na história, o Rails que é uma Full-stack Framework e traz ferramentas para resolver facilmente os problemas do html e javascript. Além de ser REST por padrão e abraçar muito bem URL’s (diferente do PHP com mod-rewrite no Apache).

Então como optamos por Rails quase sempre também acabamos optando por HTML e Jquery mesmo para sistemas, claro se não houver a grande necessidade de assicronismo.

Obrigado David Hansson e comunidade Rails, que é formada por grandes desenvolvedores.

Mas existem casos extremos e aspectos externos, como por exemplo um cliente exigir que o site seja em Flash pois terá uma música (nesses casos tentamos rejeitar o projeto), ou você prestar serviço como desenvolvedor para uma agência ou designer que criou um layout impossível de ser criado em html (e sem te mostrar antes) ou está no contrato uma transição entre cada página com animação. Neste caso Ajax ou Js pode não ser a resposta e você mais uma vez é obrigado a adotar uma ferramenta não muita adequada se não quiser perder o cliente (nem sempre é possível rejeitar um projeto).

Mas no fim do dia a regra para nós é o seguinte:

• XHTML/CSS para sites, portais e apps menos assincronas.
• Flash para jogos, hotsites animados com tempo de vida e com tamanho limitado (sem muito db, forms ou texto)
• Flex para apps assíncronas
• Rails para quase tudo, exceto blogs (sobrou wordpress :( )

• AIR, Bowline e Shoes para desktop multiplataforma
• MacRuby para desenvolvimento Mac
• Rhodes ou Rails para mobile

E em nosso dia a dia tudo isto que falei é permeado por versionamento em GIT (e Github ), Mac’s ou Linux (nunca Windows) para desenvolvimento e Linux no Host. Além de usar BDD ou TDD em muitos casos (na verdade quando código é Rails ou Ruby).

Mas se você vai usar Flex para tudo, ou HTML para tudo ou Flash o problema é seu, ou melhor, do seu cliente. Para nós, no fim do dia o que importa é ter o cliente satisfeito e lucrando e conseguindo manter isto em um custo acessível, sendo pragmático para manter a nossa diversão trabalhando.