segunda-feira, 15 de fevereiro de 2010

Classicismo Tecnológico

Em Arte, o Classicismo refere-se, geralmente, à valorização da Antiguidade Clássica como padrão por excelência (...), que os classicistas pretendem imitar.

Até 2 semanas atrás, estava estudando / exercitando GWT 2.0 em um módulo de uma aplicação web que desenvolvo.

Naquele momento, o cliente fez uma solicitação que demandaria processamento local, algo como o usuário selecionar arquivos em sua máquina e os enviar para um servidor FTP. Porém esta funcionalidade deveria ser disponibilizada e integrada com as telas / workflows da aplicação (não bastava ensinar ao usuário como usar um cliente FTP).

Apesar de nunca ter desenvolvido applets para sistemas em produção, escolhi esse caminho. "Forçado" a desbravar o mundo das applets, fiquei surpreso com o grau de similaridade entre as API do GWT e do Swing. Foi possível usar uma arquitetura semelhante, adotar os mesmos padrões, etc...

Gostei de trabalhar com o Swing também pelo fato de as IDEs (Netbeans ou Eclipse VE) possuirem suporte visual para construção das UIs.

Caso a view seja pouco acoplada com o resto da aplicação (por exemplo adotando o padrão MVP), é possível desenhar toda a UI através desses editores visuais, sem que isso afete a lógica da aplicação.

Desta forma, foi possível construir toda a aplicação, desacoplada da View; enquanto, na base da experimentação, tentativa/erro, fazia e refazia a UI, até que ela chegasse ao formato desejado.

Algumas conclusões no final do trabalho - No Swing:

  • A curva de aprendizado pareceu menor (API madura e boa disponibilidade de documentação);
  • O suporte das IDEs (tanto Netbeans quanto Eclipse/VE) é bom;
  • Pode-se usar recursos locais da máquina do usuário - coisa difícil de se obter em uma aplicação web;
  • O tempo de download do applet (tanto pela página quanto pelo JWS) é similar ao tempo de download das bibliotecas-base do GXT;
  • Swing parece estável, enquanto no GXT já experimentei alguns bugs;
  • Menos problemas com licenças (o GXT é GPL);
  • O produto final ficou muito bom - visualmente e funcionalmente;
  • A barreira de instalação da JVM parece ser da mesma ordem de grandeza quanto a barreira de instalar o Flash ou de garantir que a aplicação se comportará de forma idêntica entre todos os navegadores disponíveis.

Depois de listar tantas qualidades, comecei a procurar defeitos, daí nasceu a pergunta que originou esse post no RioJUG.

Em nenhum momento estou dizendo que uma abordagem é boa e a outra ruim; apenas não consegui entender o porquê de uma tecnologia tão madura como Swing / JWS / Applets ser pouco utilizada nas aplicações atuais.

Também fiquei surpreso ao perceber que novas tecnologias, como o GWT/GXT se assemelham às antigas, e que as decisões de design para programar numa (web) ou noutra (swing) são muito parecidas.

Estaríamos vivenciando um momento de classicismo tecnológico, buscando inspiração em tecnologias do passado para ajudar a resolver os problemas do futuro?

3 comentários:

  1. Grande Sahid,
    Historicamente o Swing caiu em desuso por alguns motivos:
    - Era lento. Hj ele roda bem, mas ele não mudou do que era antes. Se hj ele roda bem, mas ainda é um pouco mais demorado, imagina nas máquinas mais antigas..
    - Era feio, comparado as aplicações nativas.
    O applet entrou na crista da onda por permitir interatividade. Mas sofria do mesmo mal do Java:
    - Era lento pra carregar. Cada applet rodava numa jvm, e as jvms nunca foram conhecidas pela performance inicial.
    - Obrigava a instalar uma JVM na máquina cliente.

    O que era difícil. Vale lembrar a briga histórica na Microsoft com a Sun.
    Lembra? O IE tinha uma jvm da microsoft só pra rodar as applets. A microsoft chamava de J++, tinha o Visual J++ pra fazer applets.
    Só que eles começaram a mudar a linguagem, a Sun não gostou, começaram a ter problemas de compatibilidade com o J++ e o Java puro, aí a microsoft saiu. Tirou as JVMs e o applet começou a perder mercado.
    Desde a JVM 6 a Sun começou a fazer Vms q fossem fáceis de instalar, ou seja, com pouca interação com o usuário (tipo o flash) mais rápidas pra baixar (core menor, sempre baseado no flash) mas ainda não conseguiu o resultado desejado.
    Dava pra voltar ao applet? No RioJug um cara comentou, a Sun tirou ela até da certificação. mas pra internet daria pra usar tranquilamente, aprendendo a colocar as configurações novas que a Sun ensina pra q o usuário possa baixar a jvm mais facilmente.
    O JWS dá pra usar bem na intranet, com rmi ou até com ejb eu já usei. Fica ótimo. O JWS é ruim pela internet, teria q usar um protocolo tipo REST ou JSON pra interagir com o backend, alguns problemas de segurança, mas tb é possível.
    O problema é: td mundo sabe web. tds os browsers brigam pra quem tem o mais rápido javascript, mais rápida renderização, mais e mais.. Vai jogar td essa base fora? Não vai... Tirando q qq servidor de internet pra rodar java cobra super caro..
    Acho q vou copiar essa resposta pro meu blog... :)
    Abraços!

    ResponderExcluir
  2. Valeu Zé Pedro!

    Voltar para o applet, eu também acho difícil - ele tem seu lugar em contextos bem específicos, por exemplo o exemplificado no post (necessidade de processamento local, e integrado com uma aplicação web) ou em aplicações intranet, como mencionado no RioJUG.

    Além disso, o usuário final está acostumado com páginas web, com vídeos no youtube, com fotos no picasa, com aplicativos sociais interativos, etc; não dá pra lutar contra a cultura (web) já estabelecida.

    Também chamou muito a atenção a grande similaridade que o GWT tem com relação Swing - por exemplo é possível usar as mesmas best practices e o modelo de tratamento de eventos.

    Por isso o título do post - "Classicismo Tecnológico", como se algumas das tecnologias recentes, como o GWT, estivessem levando para o browser o mesmo modelo de programação que já existia no desktop.

    No final das contas, mesmo nos dias de hoje, "não há almoço gratuito", cada tecnologia cobra o preço pela merenda:

    - Applet requer JVM; Apps Web/AJAX requerem navegadores atualizados e download de JavaScript (dependendo do caso, pode sair pesado); e às vezes, o Flash.

    - Customizar Look-And-Feel de Swing é mais limitado, porém ele já traz LFs Metal ou System, que se assemelham ao LF do sistema; Em apps Web, vc tem mais liberdade de customizar tudo usando CSS, porém o preço é testar em todos os browsers (tem horas que é impossível fazer funcionar em todos).

    - Nunca é possível garantir compatibilidade de código JavaScript entre navegadores, é preciso testar sempre...

    - O Swing já possui uma coleção padrão de widgets, bem diversas, e parece bem estável; no GWT, o número de widgets ainda é limitado. Cheguei a testar as extensões GXT e Smart GWT, mas não me convenci totalmente de usá-los.

    E se a comparação aparenta estar tão equilibrada, a melhor explicação para o pouco sucesso das applets é que elas fracassaram justamente na sua origem, como vc mencionou! Surfaram na crista da onda, caíram da prancha e perderam terreno...

    tópico interessante esse hein?
    abs!

    ResponderExcluir
  3. Em termos de design o Swing sempre foi exemplo de design puro OO. Não é a toa que vários outros copiaram o modelo.
    Existem vários frameworks que fazem assim, como vc falou. GWT, Wicket, Click, Eclipse RAP e até um q transforma o próprio Swing em web (AjaxSwing) tão aí pra serem usados. Devem ter mais, isso sem falar de outras linguagens que rodam na vm.
    Tem problemas as applets e o Swing? Tem. Sem duvida. Mas esses q vc comentou, CSS é um problema sério, as vezes não dá mesmo. Javascript é uma linguagem difícil, tem q usar bons frameworks pra conseguir q rode nos vários browsers. Tem mtas best pratices (como eu mandei no twitter: http://developer.yahoo.com/performance/rules.html), etc. É mto difícil fazer web.
    Isso sem falar do JavaFX. Como eu mandei no twitter: http://bit.ly/bk59YL. Ele roda em cima de um applet.
    Agora, não dá pra fazer design com o Swing. E vê o q eles fazem com as páginas web... Nesse quesito é difícil disputar.
    Abraço!

    ResponderExcluir