Olá, Pedro.

IMO:
Groovy - Não exatamente um pronto fraco da linguagem quanto a seu uso, mas o próprio nome não soa como algo "sério". Não é um nome "elegante" como Java, Ruby, PHP. Pode ser besteira da minha parte, mas isso é um ponto negativo para o crescimento da adoção da linguagem. A mesma opinião tenho sobre sua "logo".

Grails
- IDE melhor na visão/controle: a STS e agora GGTS são muito boas, mas a falta de algum "editor visual" ou pelo menos "preview" de GSP ainda afasta muita gente. Um visualizador de fluxo também seria muito bem vindo.

- IDE melhor no debug: Mesmo com grande evolução, trabalhar em "modo debug" numa aplicação Grails ainda não é como e uma aplicação Java.

- Impossibilidade de geração de aplicação em pasta ao invés de .war. Acho que é impossivel apenas atualizar um arquivo (GSP, por exemplo) numa aplicação Grails. Deve-se sempre gerar o war e jogar no servidor. Para alguém que trabalha com um provedor remoto via internet e conexão não tão banda larga assim isso é um grande problema (upload de arquivo War grande).

- Engenharia reversa por padrão: acho que o plugin de engenharia reversa do banco deveria vir por padrão no Grails, pois penso que é bem mais comum o aproveitamento de bases legadas do que a construção do "zero" no mundo real.

- Algumas tags não são muito inteligentes: As tags de "form" e "submit" ajax são meio toscas, porque o que configura no form não vale para o botão. Até hoje não engulo essa regra.

- Falta de tags de formulário melhores: Tá certo que o scafold do Grails é ótimo, mas seria muito bom que tags como <g:textField> tivessem um atributo "label" que, ao ser preenchido, gerasse uma tag <label> antes do campo.

- O PIOR, na minha opinião: A necessidade de conversão manual de datas quando não se usa o nada eficiente <g:datePicker>. Até frameworks "arcaicos", como Struts2 fazem isso de acordo com o locale do cliente, sem trabalho para o desenvolvedor. Tá certo que manipular datas em Groovy é rápido, mas fazer isso em 20 forms com 5 campos data cada é ruim, não é? Criar um "filter" ou coisa assim já foge a filosofia do framework que é justamente tirar esse tipo de trabalho "não regra de negócio" das mãos do desenvolvedor, né?

Mas, mesmo com todos esses problemas, ainda amo o casal Groovy/Grails.

Man: o tal do José Yoshiriro é foda. Tive de dar uma saidinha antes de escrever sua resposta, dei refresh e ele postou tudo aqui. São basicamente estes os problemas.

O maior problema pra mim é adaptabilidade da equipe. Você tem de ter uma estratégia muito bem feita para que não ocorra um boicote acidental na adoção do framework. Coisas do tipo: "eu faço assim com a tecnologia X e vou tentar igualzinho no Grails". Isto rola muito, e é o principal fator de fracasso em projetos que acompanho nas consultorias que dou por aí.

Como estratégia, na minha opinião você tem de tratar primeiro da questão do medo. As pessoas tem medo de mudar, elas já estão acostumadas com um modo de trabalho com o qual se sentem seguras. Você precisa primeiro mostrar os ganhos que a linguagem Groovy têm a oferecer, justificar que vale à pena aprender o bicho. Sabe um ponto de partida bacana? Não o Grails padrão, mas a escrita de scripts de manutenção mesmo. Foi assim que aprendi a linguagem.

O segundo ponto é mostrar que você por estar usando um framework full stack não vai ficar perdendo aquele tempo horroroso montando o ambiente. No final, é isto: o maior problema é o convencimento da equipe. Convenceu, a equipe topou e tá animada, cara: você tem um dos melhores ambiente de desenvolvimento que conheço. Produtivo, estável, performance interessante pro que se propõe e fácil de trabalhar.

Sei que nesse momento choverão pedras na minha cabeça rs, mas vamos lá, eu vejo um movimento muito grande em torno do Ruby inclusive de desenvolvedores Java, quando o Groovy é muito mais Java Like com os mesmos ganhos(claro cada um com suas características) então porque mudar totalmente, se você pode reaproveitar a experiência profissional da sua equipe, acho que inicialmente o Groovy oferece para programadores Java, um ganho muito grande, a despeito do que é oferecido pelas linguagens dinâmicas, não sou contra o novo, mas se eu posso ter uma curva de aprendizado menor, e com ganhos consideráveis, porque ir para o caminho mais difícil.

Por isso a minha pergunta, eu de experiência própria(com ruby, apenas estudando, não em projetos reais) estou tentando montar algo que mostre isso para alguns amigos de comunidades Java, e uma comparação não seria real se eu não entendesse os pontos fracos do Groovy/Grails, mostrando como seria mais produtivo uma transição Java -> Groovy do que Java -> Ruby.

Se alguém mais puder ajudar, continuem a postar, seja a favor da comparação ou contra, mas postem para que possamos aprender.

Abraço a todos.

Sabe Pedro Henrique, pra mim um ponto crucial é sempre a equipe. Se o pessoal estiver acostumado com Java, Grails oferece uma curva de aprendizado mais tranquila e, portanto, fica mais fácil evitar os problemas que mencionei acima.

No final das contas, você vai ter aquela pergunta: Groovy ou Ruby? Minha opinião é a de que não faz lá tanta diferença hoje sob uma ótica meramente superficial.

Mas conforme você for se aprofundando, vai percebendo que o Grails é mais que o mero Groovy com algum framework alienígena por trás. É na realidade o Groovy em cima do Spring MVC e toda a plataforma Spring. Então, neste caso, você tem todos os ganhos desta plataforma quando pensa em Grails. E é uma puta plataforma, que já tem a eficácia mais que comprovada pelo mercado, que é quem realmente interessa. Além da plataforma Spring, vocÊ vai ver também outros componentes interessantes, como por exemplo Hibernate, aquelas biblioteca Commons, Log4J, etc. É um stack que conhecemos bem no mundo Java e que ta pra lá de válido.

Outro ponto que agrega valor é que você tem a JVM. Cara: é sem dúvida uma das melhores plataformas de execução já criadas. Ela realmente escala, é segura, performática e muito, muito boa.

Se for para optar pelo Ruby on Rails, leve em consideração o JRuby e verifique como o framework executa na JVM. Se não estiver bacana, ponto gigante pro Grails, porque a plataforma de execução do Ruby on Rails pelo que li até hoje ainda fica bem atrás.

No caso do Ruby on Rails

Isso Henrique, mas a questão não é Groovy vs Ruby, nem Rails vs Grails não não, não é isso.

Mas sim, para você programador Java que precisa de algo performático e dinâmico, existe um caminho mais "fácil" e seguro, realmente pelo menos para mim foi e muito, pelos motivos que você apresentou no post anterior, então é isso eu estou montando uma apresentação, para tentar passar esta ideia.

E você que chegou até aqui, não mudamos o foco não (tá só um pouquinho), se tiver um outro contra, :-) poste aí.

A intenção é mostrar que existe outros caminhos e que talvez sejam tão ou mais interessantes do que o da moda.

Amigos, interessante debate, mas acredito que muito do Grails x Rails se dá exatamente do "duelo" entre Groovy e Ruby. Porque você pode escrever uma aplicação web toda com Rails e gerar um .War JEE válido. Ou seja, "usar a JVM" não é mais vantagem exclusiva do Grails perante o Rails.

Particularmente preferi o Grails pela linguagem Groovy e pelo bem melhor suporte de IDE.

Quanto ao desempenho, minha monografia de pós foi uma comparação de desempenho entre Grails e Rails. Claro que é sempre complicado esse tipo de estudo porque existem infinitas configurações e combinações, mas o Grails se saiu muito bem nos cenários que testei e com as configurações padrão de cada framework.

Quanto a adoção aqui no Brasil, como o Rails nasceu antes e tem muito "hype" em cima, o Grails aqui só vai se estar nos "top used" quando a SpringSource tiver filial aqui pra ofecerer suporte e treinamento oficial, pelo menos IMO. Assim, para muitos gerentes e CIOs, o Grails ficaria com cara de tecnologia "profissional", como JBoss Seam, por exemplo. Do jeito que está o pensamento muitas vezes é: "Mas quem ensina isso é aquele 'Kiko' do site ou aquele 'Yoshiriro' de Belém/PA, onde se topa com jacaré na rua".

Sim, sem dúvida: mas será que Ruby ainda é "da moda" hoje?

Há algumas outras alternativas por aí: tem o Play, que parece ser interessante, mas nunca me aprofundei.

Sim, concordo, mas gerar um war é apenas um aspecto, vocês por exemplo não acham que para um programador Java aprender Groovy é mais intuitivo do que aprender Ruby por exemplo ?

Sem dúvida: o caminho para quem já é Javeiro mais fácil é Groovy.

Atualmente estamos em uma dúvida considerável na empresa em que trabalho. Decidimos abandonar, ou pelo menos minimizar, o uso de JSF, especialmente por questões de performance e produtividade. Inicialmente cogitamos Ruby On Rails, Grails, Spring Roo e Play, logo descartamos o Ruby On Rails devido a uma maior curva de aprendizado necessária, considerando a "distância" em relação ao Java. Nos restou as outras três tecnologias pra decidir. O Spring Roo pelo menos pessoalmente não me agrada muito pelo fato de haver pouquíssima documentação a respeito, até mesmo em inglês é um pouco carente, embora de certa forma seja um equivalente para Java ao Grails em realação ao Groovy. Pessoalmente estou bastante interessado no Grails e no Play o primeiro devido a uma quantidade maior de documentação em relação ao Play e ao Spring Roo e o segundo por que tem um pouco mais de documentação em relação ao Spring Roo e ser mais próximo ao Java.

No geral eu acho que esses frameworks e especialmente o Ruby on Rails revolucionou o desenvolvimento Java Web e isso contribuiu e muito para melhorar as nossas ferramentas de trabalho usadas em ambiente Java e pricipalmente o desenvolvimento em Java Web.

Pessoal, vou falar de minha experiência.

Sou gestor de T.I. de uma empresa com filiais em 17 estados e tudo começou assim (rsrsrs): Historinha, rsrsr.

Quando entrei na empresa, havia apenas 2 filiais e nenhum sistema. Ai eu criei a primeira versão do sistema em struts (puts, fiquei chocado com a facilidade, uma vez que eu vinha do php). Para a 2a versão eu conheci o Mentawai (www.mentaframework.org), cara até hoje um dos melhores frameworks java que conheço, ficando atrás apenas do Grails e do Play. Esta foi uma ótima descisão, porém, precisávamos evoluir mais, visualmente e também no servidor, então depois de muita observar o mercado e fóruns e tals, decidi por ir ao JSF2, mais pelos componentes visuais e forma de desenvolver a view do que qualquer outra coisa.
Comecei a migrar a ferramenta para o JSF2. Ai começaram a cair meus cabelos, talvez por falta de conhecimento, talvez por incompentencia, sei lá. Só sei que derrubei a aplicação que estava com o JSF2 e voltei para o mentawai que está até hoje. Também tenho alguns projetos em Ruby on Rails, mas eu vou migrá-los em breve.

Mas agora voltando ao assunto principal (GRAILS). Através do blog do Kiko, conheci o grails (isso não tem nenhum um ano), vi alguns vídeos e fiquei maravilhado, "putz, tudo que eu queria, velocidade de desenvolvimento, curva pequena e etc. E o melhor, nada de xml ou outros do genero". Então fui montando o ambiente, instalei o groovy, grails e o sts. Tudo ia bem até o dia que precisei debugar, ir mais além do que o básico (para o infinito e o além, hehheh).
Quase desisti por causa do sts, não dá, é lento, não debuga bem e outras coisas que acontecem.
Então conheci o IntelliJ (pago), vendo alguns vídeos, decidi comprar, até porque o investimento se pagaria rápido ($100). Ai sim ficou bom, agora não tenho do que reclamar, tudo se encaixa. O Danado consegue achar meus atributos de objetos nas views, métodos javascript e outras coisas muito boas (vale cada centavo de doletas).

Então, depois da historinha para fazer vocês dormirem um pouco, eu resumo assim:
- Grails é ótimo, groovy é ótimo, tudo nele é ótimo. Recentemente juntei Twitter Bootstrap com o grails, agora fechou porque minha view ficou lindona e com pouco trabalho. Todos os meus projetos agora são com eles. Então se o problema era trabalhar com a View, esse problema não existe mais.

É isso pessoal, um pouco da minha experiência.

Olá, Carlos.

Amigo, só por curiosidade, qual a configuração de máquina que usou no STS? E era SO de 32 ou 64b?

É que eu usava STS e agora GGTS com performance muito boa. Só demorava para abrir a IDE, mas com ela rolando era tranquilo. E fazia quase tudo isso que você disse, só não o autocomplete de javascript.

Em todo caso fiquei interessado nessa IntellijIdea depois desse seu depoimento. Vou tentar uma licença acadêmica, pois dou aula (dentre outras coisas, de Grails) numa faculdade.

Oi Leandro,

sobre a documentação por trás do Spring Roo, a questão é a seguinte. O Roo não é um framework, mas uma ferramenta de desenvolvimento. Sendo assim, você só vai encontrar documentação para os comandos básicos.

O interessante é você conhecer os frameworks que ele manipula: Spring, Spring MVC, Hibernate/JPA.
Pra estes, a documentação é farta (e pros dois primeiros eu tenho inclusive um livro escrito http://www.casadocodigo.com.br/products/spring :D). Esta é a principal confusão na hora de trabalhar com o Roo.

Olá José Yoshiriro,

Eu usei ele no Windows 64 e também no MACOS.
No windows eu tenho 6GB e no macos eu tinha 8GB (tinha porque vendi o danado ehehe).

Muito interessante esta discussão pessoal.

Sugiro a todos voc?s que a divulgem no Twitter para que possamos enriquecê-la ainda mais ok?

Grande abraço!

Pra mim uma desvantagem em relação ao PHP por exemplo! É ter que reiniciar a aplicação... quando rola algumas alterações de configurações ou nos services! É um tempinho que acabo perdendo o foco! :D

Oi Gabriel, mas quando está no ambiente de desenvolvimento você não precisa fazer isto.

Mais ou menos, Henrique... tá certo que a partir do Grails 2.x isso melhorou muito, mas ainda há algumas mudanças que só funcionam se reininciar a aplicação mesmo.

Nesse item (não reininciar a aplicação) realmente o PHP é imbatível! Só o Rails chega perto.

Aliás, já que o tópico são os pontos fracos do Grails esse é um: o tempo que leva para levantar uma aplicação.
Tenho um Corei3 com 4GB e um simples Helloworld não leva menos de 2 minutos pra iniciar. Em Rails não levaria nem 15 segundos e em PHP nem 5.

Fiquei curioso com o post do José Yoshiriro e fui testar, hhehehhehehe

Tenho uma aplicação que funciona em um shopping daqui de gyn e mandei executar do zero.
Banco mysql: 2 segundos
Aplicação: 40 segundos
Browser: 3 segundos

Então no meu caso foram 45 segundos para ter a aplicação executando e já na tela de login.

E como isso é no desenvolvimento, não vejo como um problema. Claro, para o meu caso.

Aproveitando o assunto, a um tempo atrás, mandei gerar um reverse do banco que tenho um ERP e fui tentar desenvolver, acabei desistindo, não deu, hehehehee.

Agora sobre o php, se for php puro, realmente não tem como brigar, porque no momento que está subindo, ele não tem que verificar nada, e nem compilar. O Grails leva tempo compilando.

E sobre a opção de alterar e ter que reiniciar a aplicação. Comigo só acontece quando eu altero o datasource, config, models e etc, para controllers, service e views não preciso.

Com relação ao DataSource, tem uma alternativa interessante. Use JNDI para obter o objeto ao invés de usar a configuração padrão do Grails.

Assim você altera o datasource pelo servidor de aplicações e não precisa reiniciar sua aplicação, porque na prática ela sequer sabe que você trocou os dados da sua fonte.

Já que comentaram em desempenho... Na opnião de vocês, qual é o melhor cenário para o desenvolvimento?
Quantidade mínima de RAM, Processador indicado...

Sempre que se tem este tipo de comparação 1 vs 2, seria legal comparar as coisas da forma mais parecida possível como assim parecida, comparar uma app PHP ou um servlet puro seria uma boa comparação mas o Grails é um framework fullstack, e sem contar as diferenças já citadas, como um compila o outro não, etc.

No meu caso uso um i7 com 4Gb de memória e trabalho com Java e Groovy/Grails aplicações que rodam na minha rede apenas, estou satisfeito com o desempenho tanto no que diz respeito as funcionalidades que ajudam pra caramba, quando no desempenho na hora de rodar a aplicação.

Concordo com o Pedro, comparações desse nível são complicadas. Nós já abraçamos esta tecnologia, já percebemos que a curva de aprendizagem se comparada ao Rails é bem menor... Uma questão abordada também é a motivação do mercado em abraçar a tecnologia. No DevRates o grails está no topo da lista, mas são poucas as empresas e grandes produtos que cairam de cabeça no grails.
Não é uma tecnologia "recente", mas o que falta para consolidar? Na opnião de vocês, o que é necessário para tornar o Grails uma tecnologia respeitada no mercado?

Um dos pontos contras do Grails é a seriedade (pelo menos no Brasil) da tecnologia.

Quando citei o PHP, minha intenção não era fazer uma comparação! mas citar algo que sinto falta no desenvolvimento grails! :)
No momento trabalho num projeto que necessita de mais 3 projetos grails rodando e possui mais 3 dependências java que estão no respositório maven! As vezes preciso modificar os projetos e as dependências! Aí alguns minutos depois! vejo que "algo de errado não está certo!", então preciso refazer todo processo! Isso me toma um bom tempo por dia! :)

E aí meu Brother Gabriel, não se sinta censurado, pense que foi apenas um complemento a sua exposição, outras pessoas falaram sobre PHP aí no tópico, pesquisando sobre performance outras vezes na net, ouvi pessoas reclamando dos seus frameworks PHP (Rails like como CodeIgniter e Symfony quando a app cresce), então pode não demorar pra eles como demora pra você no Grails, mas isso mostra que quando você goza dos benefícios de algum framework eles também trazem coisas que você as vezes não usam e que pesam na carga, então realmente é complicado, mas com certeza se você usa e tão entusiasmado ajuda as pessoas aqui no fórum com certeza tem gostado também de outros aspectos.

E se fosse comparação também não teria problemas, apenas acrescentei mais variáveis, pois as comparações nos ajudam muito a ter referências.

Abração.

Fala Brother!

Pedro Henrique! levei a mal não! :D só justifiquei pq achei que eu não tinha me expressado bem! :D

Abração!

Com relação ao tempo de inicialização e consumo, bom: depende muito do modo como você trabalha.
E o Grails Brasil é um excelente exemplo disto, conforme mostro neste post: http://www.itexto.net/devkico/?p=1097

Memória consumida: algo em torno de 200, 256 Mb (em momentos de pico)
Tempo para iniciar e subir: 5, 10 segundos no máximo
Tempo de resposta: imediato como podem perceber

Com relação a estar ou não sendo adotado pelo mercado, ele é tão adotado quanto os demais frameworks que não são oficiais (os não JSF), tal como ocorre com Tapestry, VRaptor, etc. O único que foge da regra é o Struts porque foi o primeiro framework de fato por trás de tudo. O que temos de evitar é cair na armadilha do "Framework Maria vai com as outras", conforme trato neste post: http://www.itexto.net/devkico/?p=948

Como alguém que trabalha com Grails diáriamente, eu vejo um crescimento significativo do framework. O número de pessoas que me procuram para tratar desta questão tem aumentado bastante de uns tempos pra cá, por exemplo. Aliás, o tamanho da comunidade brasileira já é um bom sinal: mais de 1500 membros.

E com relação ao PHP, sou suspeito pra falar.
Não sei se vocês se lembram, mas a primeira versão do Grails Brasil era feita em... PHP :)

No caso, o phpBB, que ainda hoje considero um dos melhores fórums do mercado. Só saí dele por que tava na hora de mudar o formato do site e ele não se encaixava mais.

Realmente, a demanda está aumentando. Mas acredito que a falta de cursos e certificações oficiais no brasil criam uma barreira para este crescimento ser mais acelerado.

Talvez falte também uma grande aplicação de peso desenvolvida na plataforma, temos o exemplo do twitter em RoR... no Grails eu desconheço, vocês sabem de alguma?

Esse post está rendendo uma boa discussão... =)

O LinkedIn e eles ainda dão um bom testemunho no blog, não sei hoje, se ainda é porque o post é de 2008.

O sistema de deploy automatizado da Netflix é em Grails, se chama Asgaard e tem inclusive o código aberto.

Outros exemplos bacanas são o site da Wired. No site do framework havia uma lista grande de sites, incluindo o Grails Brasil (que não sei porque foi retirado).

Depois da uma olhada: http://www.grails.org/websites

Eu tenho visto muito Grails sendo usado internamente por empresas que queiram a robustes da plataforma Java EE mas sem as dificuldades inerentes desta. Infelizmente não são divulgados, mas é aonde o forte do framework se encontra atualmente.

Olá pessoas,

Eu trabalho na Nova Ponto Com, do grupo Pão de Açucar e posso afirmar que grandes sistemas de ecommerce são feitos em grails (sim aqui no Brasil!)

Tem várias partes do mercado livre que são feitas em grails tbm.

A falta de treinamento e suporte é um dos pontos fracos para o grails ser adotado em maior escala.
Ficar "amarrado" é uma situação bem complicada.
Também diria que um problema é a quantidade de plugins "descontinuados".
E pro grails 1.X.X a ausência de multi-datasources nativo, apesar de existirem técnicas não muito simples pra contornar isso.