Java Sucks! Comparativo lado-a-lado de Frameworks para Aplicações Web

Encontrei um vídeo ontem que faz uma comparação direta entre diversas abordagens de desenvolvimento de aplicações para web e que chega a uma conclusão bastante ácida: “Java não é apropriado para o desenvolvimento de aplicações web”. O vídeo em questão foi feito por um profissional que trabalha com desenvolvimento de aplicações no Jet Propulsion Lab da NASA, está disponível no endereço http://oodt.jpl.nasa.gov/better-web-app.mov e tem 378,5 MB.

Como o vídeo é relativamente grande e está em inglês, o que pode prejudicar o seu correto entendimento, apesar da linguagem simples e descontraída do palestrante, vou transcrever abaixo alguns trechos juntamente com os screenshots.

No início do vídeo é feito um teste em cada um dos frameworks, demonstrando na prática a sua utilização, que na minha opinião deixou um pouco a desejar já que a abordagem utilizada pelo programador em algumas situações não é a mais correta e ilustra muito pouco do que pode ser feito com as ferramentas testadas. Em síntese é feito a comparação do J2EE (primeiramente utilizando JSP + Servlets + Hibernate, do framework feito em Ruby, Ruby on Rails e dos frameworks feitos em Python, Zope + Plone, TurboGears e Django.

Na segunda parte do vídeo as comparações ficam mais interessantes, e seguem abaixo algumas imagens e comentários:

Inicialmente o que se propõe é o desenvolvimento de uma pequena aplicação em cada um dos frameworks apontados inicialmente, para isso foi escolhido um exemplo bastante simples, que sugere uma aplicação de gerenciamento de tempo, conforme o diagrama abaixo.


A primeira abordagem a ser testada é a do J2EE (JSP + Servlets + Hibernate), e o resultado pode ser visto abaixo:


A aplicação gerada só possue interface de inclusão de dados, não tem nenhum mecanismo de segurança, internacionalização, validação de dados, etc. O seu desenvolvimento custou ao desenvolvedor o seguinte:


Foram 499 linhas de código, 14 arquivos editados, muito XML e na hora de rodar a coisa decorreu da seguinte maneira:

Para concluir:


Tradução: “Quando tudo o que você tem é um martelo, todos os problemas se parecem com um prego.”

Em seguida é apresentada a solução em Ruby on Rails:


A aplicação gerada possue interface de inclusão, exclusão e listagem das informações, porém não tem nenhum mecanismo de segurança e internacionalização, etc. possuindo alguns recursos para validação de dados mas obrigando o desenvolvedor a trabalhar diretamente com as tabelas em MySQL. Em resumo, desenvolver uma aplicação em Ruby on Rails consiste em criar um bom banco de dados, seguir as regras impostas pela ferramenta e obter resultados simples, porém rápidos.


Como pode ser visto acima só foi necessário editar 3 arquivos, nenhuma edição de XML foi necessária e apenas 29 linhas de código foram necessárias para ter a aplicação funcionando. Na hora de rodar a aplicação também não houveram grandes problemas.

Depois do mamão com açucar do Ruby on Rail veio a vez do Zope+Plone, cujo resultado pode ser visto abaixo:


Para escrever a aplicação é necessário apenas criar um diagrama UML contendo tagged values que descrevem diversos aspectos da aplicação, dessa forma foi possível atingir o seguinte quadro:


A aplicação criada possui validação de dados, internacionalização, mecanismos de segurança, busca, criação de metadados e tudo mais, inclusive a pia da cozinha. Entretanto pode não ser tão fácil quanto foi mostrado no vídeo numa situação real do dia-a-dia, além do mais a curva de aprendizagem do Zope+Plone é muito alta, fazendo com que a obtenção de resultados rápidos seja dolorosa no início, mas é bastante recompensador quando se pode criar aplicações com tanta qualidade de maneira tão simples.

Também convém citar que o Zope não trabalha com bancos de dados relacionais nativamente, e que as informações ficam armazenadas em um banco de dados orientado a objetos chamado ZODB, cuja performance não é das mais atraentes, mas por oferecer mecanismos de alta disponibilidade pode ser considerada uma “ótima” ferramenta/ambiente de desenvolvimento.

Depois foi a vez do TurboGears, com resultados muito próximos aos do Ruby On Rails, cuja aplicação final é mostrada abaixo:


Finalmente é desenvolvida a solução com o Django:


O resultado final é bastante parecido com o do Zope+Plone, entretanto a plataforma não possui tantos recursos quanto o rival, mas tem a vantagem de ser mais simples, oferecer recursos de validação de dados, segurança, interface administrativa auto-gerada, internacionalização, etc. Outra grande vantagem do Django é o fato de trabalhar com bancos de dados relacionais e de apresentar uma sintaxe de código mais “Pythônica” do que os outros dois frameworks feitos em Python.


Como pode ser visto acima, apenas 19 linhas de código e a edição de um único arquivo foi necessária para criar a aplicação. Na hora de rodar o software o resultado foi o seguinte:


No momento em que deveria ser feita a demonstração dos resultados obtidos com a utilização do JBoss seguem os seguintes trechos:


Conclusão bastante dura para os “Javeiros”, mas apesar de ácida (eu tinha avisado) eu creio que seja bastante realista. Afinal de contas é necessário que exista simplicidade no desenvolvimento de aplicações, e isso sempre foi algo que faltou nas plataformas Java. Segue abaixo o quadro comparativo dos resultados obtidos:


Apenas um ponto está errado nesse quadro que mostra as 4 plataformas “alternativas” apresentadas, já que o Django possue templates e internacionalização e o TurboGears possue autenticação e internacionalização.

Caso ainda restem dúvidas sugiro que assistam ao vídeo e que testem cada uma das plataformas citadas. Estou certo que se surpreenderão com o que verão em cada uma delas e com o quanto de tempo poderiam poupar se usassem Python ou Ruby ao invés de Java em suas aplicações Web. Happy Coding!


25 Comments

  1. rodrigo disse:

    Muito bom saber, jah ateh imaginava som com o pouco q ouvi falar sobre python.

    Python eh algo q estou muito curioso para começar a mexer “logo’… mas por enquanto tenho q me manter antenado no java e no c#. Faculdade… sabe como eh!!!!

  2. Saulo disse:

    é Minholi… ficou complicado agora começar a trabalhar com java depois dessa !!!!

  3. silfar disse:

    Minhole, vc diria que o django superou o TG ?

  4. Marcelo R. Minholi disse:

    Olá silfar. Na minha opinião o troféu vai para o Zope e o Django por motivos diversos, dentre os quais estão a geração automática de interfaces e recursos como segurança, entre outras coisas que são derivadas da criação de interfaces de gerenciamento de dados.

  5. Gleison disse:

    Cara, trabalho com Java há algum tempo e por muito tempo fiquei me perguntando pq tanto trabalho pra fazer coisas simples. Acho q como quase todo mundo comecei usando apenas Servlets e/ou apenas Jsp. Com o tempo conheci os frameworks… gostei mto do Webwork. Sua simplicidade me agradou muito e não parei mais de usar em conjunto com o Sitemesh.
    Como vc mesmo frisou, a escolha que fizeram para fazer os testes é bem controversa.
    Concordo que J2EE não é apropriada para pequenas aplicações, mas esse vídeo não é mto justo ao colocar a especificação padrão da Sun (jsp + servlets) lado a lado com frameworks completos como Plone e o próprio Django.
    Se era para comparar frameworks/CMSs, talvez tivesse sido mais justo fazer uma comparação de Plone com outros CMSs feitos em Java, como o Magnolia; ou de Zope com Webwork…
    Enfim… eu estou cada vez mais envolvido com Python e desenvolver webapp com Django é realmente mto mais prático (especialmente pelos recursos de administração criados automaticamente), mas nunca deixaria de considerar J2EE para grandes projetos, especialmente se eles necessitassem de integração com outras plataformas.

  6. Diogo Lopes disse:

    Parabens pelo artigo.
    Do trabalho nao da pra baixar o video.

    Vou estudar uma dessas linguagens para trabalhos freelancers, pois o mercado ainda deve demorar um pouquinho. (até o custo desses profissionais cairem)

    Pra voce , devo estudar RoR ou Python/Django?

    abcs

  7. Marcelo R. Minholi disse:

    Olá Diogo, a melhor coisa a fazer quando há alguma dúvida sobre qual ferramenta utilizar é fazer alguns testes com ambas. Eu acho que o RoR é muito interessante, mas o Django fez mais sentido para mim, talvez por já possuir experiência anterior com Python.

    Além do Django e do RoR existe o TurboGears que também é um framework bem interessante e mais alguns outros menos conhecidos. O negócio é testar cada um deles e ver qual você gosta mais. 😉

  8. Sergio Oliveira disse:

    RoR sucks too! Dá uma olhada no Mentawai e reescreva esse artigo:

    http://www.mentaframework.org/

  9. Rubem Azenha disse:

    Esse vídeo não é um comparativo entre frameworks, é simplesmente mais um querendo fazer propaganda anti-java. Ele programa em Java do modo mais estúpido possível neste vídeo.
    Sinceramente, montar um projeto maven, gerar o war e fazer o deploy do war no Tomcat e reinicar o servidor inteiro só para corrigir um detalhezinho?
    Qualquer um que tem um mínimo de experiência com Java Web sabe que o cara forçou muito a barra.

  10. Iron disse:

    Caramba, o cara comparou uma especificação(J2EE) com frameworks Web é isso?E para que ele precisaria de EJB se não para uma App distribuída?O indivíduo comparou facilitadores(como RubyOnRails) com uma especificação!
    Será que ele sabe que dá para programar para web sem seguir a especificação e evitar o uso de EJB´s em 99% dos casos?

  11. Mário disse:

    Não sou exatamente um fã de Java(ao contrário de Python e Ruby), mas dentre todos os artigos “java vai morrer” nunca vi nada tão tendencioso como isso.

    O cara já começa errado. Fala sobre criar em java uma aplicação de duas classes. Qualquer cara mais esclarecido sabe que usar Java nessa situação é usar um míssel pra matar uma mosca.
    Depois compara dois frameworks com uma especificação de plataforma. É o mesmo que comparar uma uva com uma laranja(Ora, as duas são frutas. E comestíveis!!).

    Atualmente estou fazendo alguns “brinquedos” com Ruby on Rails e estou gostando bastante e já está revolucionando o desenvolvimento pra web. E acho uma pena tal tecnologia acabar ficando relacionada a artigos com pouco ou nenhum fundamento consistente do tipo “I hate Java”.

  12. Marcos disse:

    Nada indica mais o seu conteúdo tendencioso que o próprio título, Java Sucks!
    Por que nao Django Rocks?! Por que é sempre um teste que desmereçe certa tecnologia. É o típico artigo Windows não presta. Fixa o grande foco na fraqueza de uma tecnologia, ao invés de mostrar as vantagens da alternativa. Nao digo que nao mostre, mas se preocupada mais em mostrar que o outro não presta. Parece propaganda política no Brasil, quando um candidato se ve atrás do outro nas pesquisas, ele apela pra tudo que é jeito de denegrir seu adversário. Nada contra esse artigo, tanto que eu nao tenho capacidade pra discutir seus resultados, mas o mesmo artigo com o foco redirecionado e um título revisto, seria bem mais interessante. Ah, e a propósito, o teste é da NASA né? psss.. Nunca uma agência envergonhou tanto um país como a NASA tem o feito.. Ponto de Impacto (Dan Brown). É quase como o Brasil querendo mudar regras do hóquei no gelo.. :p

  13. felipe disse:

    seria mais justo comparar com o click por exemplo
    http://click.sourceforge.net/

  14. Filipe disse:

    Mais um ignorante espalhando ignorância.

    JSP e Servlets são tecnologias de base, ótimas para aprendizado e para a construção de frameworks, não para serem usadas em produção. Se você não sabe disso melhor ler alguns livros, a começar por Expert One-on-One J2EE Design and Development.

    Existem dezenas de web-frameworks escritos usando Java. Alguns mais simples, outros mais robustos. Depende da necessidade e do gosto.

    Mas sim, EJB fede.

    Para os seguidores do Minholi, recomendo aqui:
    http://www.guj.com.br/posts/list/41545.java

  15. Marcelo R. Minholi disse:

    Agora tenho seguidores!? 😀

  16. Lucas disse:

    Java não foi feito pra se fazer telas CRUD, nem helloworlds, seja web, desktop, celular, ou o que quer que seja.

  17. Fabrício disse:

    É estúpido isso. Não sei se você já construiu algum sistema, ou só fez testes de frameworks em diversas linguagens… Mas a princípio parece que Java demora mais tempo, no entanto considere uma aplicação integrada com diversos módulos, sistemas realmente que precisam ter uma organização maior.
    Acho que você deveria olhar o http://click.sourceforge.net/ – O melhor e mais produtivo framework web que existe atualmente.

  18. Mário disse:

    Pra aqueles que quiserem maiores esclarecimentos sobre essas bobagens escritas nesse artigo.

    http://www.guj.com.br/posts/list/41545.java

  19. Jefferson disse:

    Vamos rodar agora sistemas que tem rodar em máquinas Fujitsu ou SUN com 64 processadores, e 16 instancias de Linux, ou até mesmo uma delas acessando ou usando Mainframe, garantindo balanceamento de carga, cluster e execução efetiva 24X7. Vamos também agora colocar a prova a segurança de ROI das empresas que usam Java.
    Se uma empresa/banco/telcom/ tiver seu site fora por 5 minutos e isto faze-las com que percam 20 milhores de reais ou dolares tanto faz…. Gostaria de ver se os famosos “molequinhos” birrentos, estariam a disposição para explicar os motivos pelos quais fizeram a tao linda aplicação desenvolvida com esses frameworks de meninos.
    Bom, se você quiser algo interessante e simples, aconselho também o menatwaai com Java Persistence API (algo bem menos podre que Hibernate), e usando a implmentacao TopLink.
    Outra coisa, é q a ausência de arquivos físicos, nao significa que não sejam criados e/ou carregados dinamicamente em memória, o que numa máquina virtual pode ter um custo de primeira vez, mas depois tudo fica em memória.
    Esssas discussoes sao alimentadas apenas por meninos que acham que conhece Java, ou a realidade que Java está acostumada a lidar….
    Ruby on Rails, Plone, ou qualquer outra coisas dessas, eu faco pra controlar os dvds de playstation do meu filho.
    Arrume um bom emprego e ganhe bem com uma dessas tecnologias, vá num grande banco no Brasil pedir emprego para trabalhar com isso….

  20. ricesp disse:

    Que comentário inúltil hein jefferson? Só porque trabalha com um tipo de tecnologia, acha que as outras são para “controles de dv’s”?

    É por culpa de profissionais como vc que este mercado de tecnologia é uma zona mesmo… ai ai ai

  21. Rafa Rossi disse:

    Jefferson, pense um pouco…. imagine um cara falando que java pra galera de C++ e Cobol a uns 10 anos atrás.

    Vi uma apresentação que dizia: “Python é a última linguagem que você vai aprender…. como antes foi o java e antes o Cobol e antes o C++….”

    Você me parece os caras do Mainframe falando mal do PC, e olhe agora… 🙂

    abraço

  22. Anonymous disse:

    Jefferson, te convido a entrar em http://www.python.org e conhecer quais empresas utilizam python.
    Acredito que empresas como: Google, Youtube, NASA, entre outras de mesmo porte. Estas empresas devem ser muito maiores do que a empresa que você trabalha. Acredito também que as empresas não adotaram está tecnologia sem um estudo de viavilidade.
    Todas as linguagens tem seu mercado, finalidade e importancia… é uma pena o mercado brasileiro ter a cabeça tão fechada quanto a sua e aceitar somente JAVA, sem querer falar mal de JAVA, mas existem tecnologias que poderiam agilizar o desenvolvimento web com a mesma qualidade, eficiência, portabilidade, robustez e todas virtudes de um programa bem desenvolvido e com um ganho de tempo de desenvolvimento.
    Não importa a linguagem e sim a qualidade do programador

  23. Anonymous disse:

    Só pode ser brincadeira!

    A coisa mais verbosa e menos confiavel/estavel/escalavel/extensivel/manutenivel é o código gerado pelo diagrama UML utilizado no plone/zope.

    Na boa, perde até mesmo pra implementacáo java.

    E quero ver quem diz que eu tô errado.

  24. xulapa disse:

    java sempre foi e sempre sera uma merda!


Deixe uma resposta