No decorrer de 2009 iniciei um projeto cujo principal objetivo técnico consistiu em levar ao extremo o que consigo fazer atualmente usando Grails na camada de controle e domínio e a dobradinha HTML/CSS/Javascript na camada de visualização (atualmente, só de ver uma interface 100% baseada em campos textuais e caixas de seleção já começo a bocejar).
Na camada de visualização quis ver o quão próximo do desktop eu conseguiria chegar usando HTML, CSS e Javascript (muito JQuery neste caso). Nos primeiros momentos, fiquei bastante surpreso com o que estava conseguido: muito drag and drop e uma interface bem diferente do feijão com arroz que estava habituado a produzir. Porém, conforme o projeto progredia, algo ficava nítido pra mim: na camada de visualização estava usando ferramentas erradas. Sendo assim, parei de me auto enganar e resolvi aceitar um fato: HTML não foi feito para se criar aplicações ricas.
É importante que nos lembremos das raízes históricas da web: sua estrutura foi construída ao redor do que se intencionava ser um mecanismo de distribuição de documentos, e não para se criar aplicações (só pra lembrar, é Hypertext Transfer Protocol). Resumindo: faz muito sentido usar HTML para se expor conteúdo textual, mas muito pouco para se criar aplicações com interfaces ricas (o que é o meu caso).
O pesadelo do HTML (os tais “web standards”)
A verdade é: usar HTML para criar aplicações com interfaces ricas ainda é (e vai continuar sendo por um bom tempo) um pesadelo.
Sim, é verdade que as coisas estão melhorando, e temos alguns bons indícios disto:
- Google tá puxando o HTML 5 no Chrome, e o Firefox e Internet Explorer já estão começando a oferecer algum suporte
- O maldito Internet Explorer 6 está começando a desaparecer
- Bibliotecas como jQuery conseguem minimizar a discrepancia entre as diferentes implementações do JavaScript presente nos navegadores
- Aplicações como Google Maps expõe que de fato é possível criar aplicações ricas usando “apenas” HTML, CSS e muito JavaScript
Yeap: mundo lindo né? Só que tem alguns “pequenos” problemas.
Microsoft Internet Explorer ainda domina
Ainda não sairam as estatísticas do quarto trimestre de 2009, mas é fato: até o terceiro trimestrede 2009 quase 70% das pessoas ainda usam o maledeto IE. (fontes: NetApplications, W3Counter, StatCounter). O IE8 é mais próximo dos padrões do W3C, é verdade, porém sabendo um pouco de história, fica nítido que será temporário, e em pouco tempo a Microsoft irá incluir novas “features” no seu navegador. (pior: IE6 ainda é o browser mais usado (fonte: NetApplications).
Os browsers ainda não são todos 100% compatíveis com os padrões web
Se você quer criar uma aplicação rica usando apenas web standards, ou seja, HTML, CSS e Javascript, no mínimo os navegadores devem ser compatíveis com o padrão, certo? Atualmente apenas o Chrome 2 e o Safari 4 conseguem passar no Acid3 (fonte). Juntos correspondem atualmente a algo em torno de no máximo uns 9% do mercado. (só pra “animar”, o IE8 conseguiu passar com nota 10/100).
HTML 5 ainda está longe de se tornar realidade
O HTML 5 cuja especificação começou em 2004 vai ter a sua primeira versão candidata publicada (talvez) em 2012 E vai ser recomendado pelo W3C a partir de 2022 (fonte). Ok: então se o mundo não acabar em 2012, teremos de esperar “apenas” mais 10 anos.
Claro, nada impede que os navegadores comecem a implementar o padrão, certo? De novo, não é lá muito animador, basta ver o que temos hoje (fonte (yeap: Wikipédia mesmo, porém as fontes indicam ser um post confiável)). Seu cliente topa esperar todo este tempo?
Nada contra os web standards (muito a favor!), desde que sejam usados no lugar certo
Se o seu trabalho não exige uma interface rica (com drag and drop, multimídia de fato e interação que vá além de meros campos textuais e caixa de seleção), e serve apenas para expor conteúdo, web standards é o canal (aliás, o único que conheço), pois apresenta diversas vantagens:
- Maior compatibilidade entre navegadores (sempre relativa)
- Carregamento mais rápido
- Facilidade de indexação por motores de busca
- Código limpo
Quer usar apenas web standards para criar aplicações ricas? Ok! Faça um jogo que valha à pena usando apenas Javascript, HTML/CSS compatível com todos os navegadores e depois ma apresente. :)
Como acabei optando pela plataforma Flash
O caminho natural para o meu caso, que sou especializado de fato na plataforma Java seria o JavaFX. No entanto, alguns fatores pesaram muito a favor da solução da Adobe:
- Flash é uma tecnologia madura
- 98% dos computadores possuem o Flash Player instalado (fonte)
(multiplataforma e PADRÃO é ISTO) - É lingua franca entre designers (com os quais a cada dia que se passa, tenho tido de interar mais e mais), pois é completamente integrado às ferramentas gráficas da Adobe (que são as melhores)
- ActionScript é uma linguagem que se mostrou surpreendentemente poderosa para mim, que até então a esnobava com a maior tranquilidade (bem feito pra mim!)
- Foco na parte visual
- Flex é agora completamente open source (se não o fosse, estaria usando JavaFX agora)
- Flex e Air
O que me fez realmente me apaixonar de fato, confesso, foi o Flex. Conforme ia estudando a tecnologia, fiquei fascinado com a riqueza que ela me oferece. Basicamente, é o Flash, porém com uma roupagem mais próxima da que desenvolvedores de aplicações como eu estamos acostumados. O projeto que mencionei no início deste blog está sendo atualmente refeito em Flex: e o resultado está sendo maravilhoso.
Com Flex consigo acessar via HTTP (e também por WebServices, bancos de dados, etc) de uma forma MUITO simples tudo o que preciso, ou seja, é fácililimo de integrar com meu código legado. Existe inclusive um plugin para Grails bastante interessante (fonte). Ou seja, continuo trabalhando no backend com as mesmas ferramentas que usava antes: a única diferença é que agora uso Flex na camada de visualização quando preciso de algo mais elaborado.
Além disto, outro fator importantíssimo foi o Air, que nos permite transformar a nossa aplicação web em uma aplicação desktop de uma forma incrívelmente simples.
Conclusões
A conclusão que chego é a seguinte: se sua interface será simples, e não requer nada que vá além do que o HTML 4 de hoje com JavaScript e CSS podem te oferecer, fique com os padrões web de hoje. Eles te atenderão perfeitamente. Abrace-os e defenda-os com unhas e dentes.
No entanto, se sua aplicação requer uma interface rica, que vá além dos controles HTML, e não é algo cujo principal propósito seja expor informação textual ou pictórica, opte por alguma tecnologia RIA (Silverlight, JavaFX e Chrome Frame (considero o Frame uma plataforma RIA, visto que é um plugin assim como os demais) são MUITO interessantes também), pois irá lhe poupar MUITO tempo e, querendo ou não, é a ferramenta certa para este tipo de trabalho.
Acredito em um meio termo: nada impede misturar web standards com algum framework RIA, pois no caso do projeto que mencionei, é exatamente o que estou fazendo neste momento.
Neste ano estou apostando no Flex. Aguardem por vários posts a respeito conforme me aprofundo na ferramenta e, mais importante: Feliz 2010!
PS: agora, por caridade: não empolgue e faça seu blog ou página corporativa usando apenas algum framework RIA ok? Assim você quebra a bicicleta! :)
Update setembro de 2013
As coisas correram bem diferente do que eu imaginava: o HTML 5 acabou se tornando muito mais adotado pelos browsers, ao ponto de que simplesmente não precisei mais pensar em Air/Flash para desenvolver apllicações ricas.
Então pode-se dizer que nem deu tempo de abandonar direito o HTML 5: acabei ficando nele mesmo e abandonando o Air, mas muitas das coisas que disse neste post ainda se aplicam: não há ferramentas visuais tão boas para HTML 5 quanto há para Flash, e o suporte ainda não é 100% (provávelmente nunca será), mas tá bem lá pelos 80, 90% chutando por alto.
É: acabei abandonando o Air. :) https://devkico.itexto.com.br/?p=1550
Deixe uma resposta