"toda unanimidade é burra" já dizia Nelson Rodrigues :P

É José, mas o comentário do nosso colega de profissão aí em cima, não bate com a realidade do Grails, parece até trollada comparando com o JSF 2, e aí mais os motivos, como se o grails fosse o scaffold rs.

O Java 8 vai engolir esse Groovy ai. kkkkkkkkkk

Oi Franklin, bacana: mas será que rola de enriquecer esta discussão com alguns fatos não meramente subjetivos como os que mostrou?

Algum tempo atrás tivemos uma discussão riquíssima aqui entitulada "O que você não gosta no Grails?". Talvez você possa dar uma contribuição mais rica aí pra gente, o que me diz?

Quais as dificuldades que você está tendo? Este tipo de coisa é massa, porque mostra pra gente como trabalhar melhor com o framework.

Interessante: você diz que não serve para sistemas complexos, mas eu mesmo já implementei diversos com ele. Poderia nos dizer a razão pela qual isto se aplica?

1 - Prefiro fazer minhas próprias páginas jsf do que fazer esse gsp's com um código horroroso que o grails gera e o layout nem se fala, Primefaces 2.0 é muito melhor, tem muito mais recursos e muito mais fácil de usar.

2 - Java esta muito mais evoluído do que esse grails, eu posso ter problemas na hora de configurar, mas a quantidade de livros e informação que eu tenho na internet é muito mais ampla que esse tal de grails. Todo mundo fala que grails é isso e aquilo, mas todo mundo só mostra o basicão, quero ver na hora de enfrentar os problemas.

De evangelistas o mundo tá cheio. Todo mundo que aprensenta o grails fala do scaffold como um recurso mais lindo do grails, as pessoas crescem os olhos com tanta "facilidade". Esse scaffold é a coisa mais ridícula que eu já vi.


Me desculpe.

Franklin, assim como no JSF você não precisa gerar nada com scaffold, você pode criar os seus Controllers e criar as suas páginas na mão, se você gosta de components existem alguns plugins grails como GrailsUI, daí você vai construindo a sua página do jeito que você quizer o Grails tem um sistema de templates que funciona de forma "parecida" com o facelets, daí você não precisa ficar com aquele layout que você achou horrível, faça o seu do jeito que achar melhor, o gsp é apenas um jsp, caso não queira usa os plugins, é só mandar ver no XHTML + JS e fazer a sua página do jeito que achar melhor, o Groovy gera bytecode então tudo do java você pode usar aí, sem restrições.

Mas se mesmo assim não gostar, poderia dar a sua contribuição, espero que não fique apenas no "Grails não presta porque eu não gosto, e o scaffold é um horror, o gsp gerado é horrível.", porque conheço algumas empresas que usam grails e nunca usam o Scaffold, ele é apenas um recurso, que te dá um esqueleto pronto, se não gosta do scaffold não use, mas diga algo que não consegue fazer aí no grails ou que é mais complicado, talvez o pessoal possa dar uma solução mais simples pra você.

Oi Franklin.
A argumentação ainda ta muito pobre. A questão não é o que você ou qualquer outro prefere, o que é muito subjetivo, mas sim o porquê, saca? Pergunto: por quê?

Com relação à comparação grails/java, provavelmente você está confundindo com groovy, não? Neste caso, tendo a discordar de você, por que o groovy foi criado justamente para suprir falhas no Java. Neste ponto, gostaria de saber da sua opinião quais pontos do Java superariam o groovy? Rola de postar aqui.

Com relação ao seu posicionamento a respeito de evangelistas também não entendi. Quem aqui falou nisto? Pode esclarecer melhor?

Se tem uma coisa que o rapaz ai conseguiu mostrar é que ele não sabe nada de Grails. :-)

Uma coisa que gosto muito da comunidade Grails é que trolls não conseguem se alimentar, pq o pessoal que utiliza é bem amadurecido profissionalmente ou foi bem mentorado. Mas depois da fama sempre vem pessoas opinarem aquilo que não conhecem.

PS.: Se for usar JSF 2.0, utilize o ADF Faces que é muito mais completo que o PrimeFaces.

Pois é brother!

Pela forma com que falou parece mais um desabafo, um "problema pessoal" com o groovy/grails, do que uma opinião! Realmente ninguém é obrigado a gostar ou concordar com a filosofia de determinada linguagem ou framework, vc pode escolher não trabalhar com ela e trocar de emprego! Já que a empresa na qual vc trabalha deve ser coisa de brincadeira de criança para escolher trabalhar justamente com grails! :D

respeito a opinião de não gostar, só não vejo a necessidade de tentar vir flamar aqui no forum

eu trabalhei por um bom tempo com JSF1, EJB3 e Hibernate...
Uma coisa que sempre me incomodou foi a quantidade de xmls e trabalho repetitivo

sobre coisas por baixo dos panos, o primefaces faz isso direto Oo
e concordo, é bom pro basicão, mas quando dá pau... pelo amor de deus

PS: parabéns a todos pela maturidade, em outros foruns que vejo por aí, já ia rolar maior internet fight

"2 - Java esta muito mais evoluído do que esse grails(...)"
Cara... a cada "evolução" do Java ele fica mais parecido com o Groovy... implementando facilidades que, as vezes, já intrinseco do Groovy desde a versão 1.

E meu... que postagem mais inútil...

isso sim é uma [abre aspas]
lixeira...lixeira...
...brincadeira de criança...
...coisa de quem não sabe programar...
...furada...lixeira....lixo...lixo..
merda...
...LIXO
...

Caros, e pensando bem, um post assim é exatamente resultado claro de como o Grails cresceu no Brasil.

Parabéns ao Kico e a toda comunidade! :-)

Em tempo, a única framework em que eu consegui de fato utilizar DDD (Domain-Driven Design) nativamente foi o Grails. Recomendo muito este livro do Eric Evans - e o Grails, claro!

Deixa pra lá iria escrever algo, mas a sessão do site foi para o saco, estou com preguiça de escrever novamente. kkkkkkkkkk.

outro dia continuamos.


Abraço a todos.

Sabem o que eu fico pensando?

Em como este post do Franklin é feliz e infeliz ao mesmo tepo (ou seja, é nada).

É infeliz porque mostrou uma figura bastante infantil, incapaz de dialogar, e que mostra muito bem aquela postura do tipo: "a coisa é nova, não vou estudar pra aprender, e justamente porque não estou conseguindo entender (por que não estudei), eu odeio". Poderia ter sido uma discussão muito rica, mas infelizmente foi jogada no lixo (usando o jargão Franklin). Nenhum argumento crítico exposto, enfim, uma pena. Eu realmente queria ver pontos negativos ao Grails apontados aqui pra que a gente pudesse discutir.

Mas é muito feliz quando eu vejo o nível de maturidade em que chegamos. Nós não alimentamos o Troll, nós o matamos por indigestão, e isto sem baixar o nível, sem molecagem ou qualquer coisa similar. Apenas argumentação racional. ISTO é bacana, e é por isto que eu tenho tanto orgulho de todos vocês. :)

Pois é Henrique, eu trabalho com processamento de linguagem natural e data mining, sou pesquisador de IA. Algum tempo atrás estava em duvida entre escolher Python com Django ou Grails. Por influência de amigos e a interoperabilidade com java escolhi trabalhar com grails. Confesso que estou muito satisfeito com os resultados que estou obtendo. A comunidade vem me ajudando muito, tenho comprovado o poder desta ferramenta. Como dizia um grande amigo meu programador muito experiente: "A melhor ferramenta/linguagem de programação é aquela que você domina". E estamos aqui nesta comunidade buscando além disso o compartilhamento e desenvolvimento desta ferramenta.

O meu público agradecimento a todos que vem colaborando para o crescimento desta comunidade.

Eu trabalho com ecommerce, em projetos razoavelmente grandes.
Não tenho nem como discutir os ganhos de produtividade

Eu imaginava que o Grails (na verdade o groovy) ia ter problemas cretinos de performace, mas fui surpreendido. Aprendi que um código mal escrito é muito pior que as perdas de performace da linguagem.
O groovy te ajuda a escrever coisas mais legíveis por causa das coisas nativas da linguagem... MAS imagino que seja uma faca de dois gumes, pois escrever código mal em groovy deve ser BEM ruim. (ainda não peguei esse caso)

Uma coisa bem ruim do groovy é de não poder usar e abusar das closures =(
Vc usa um pouco a mais e já começa a dar erro de PermGen

E do Grails é a instabilidade dos plugins e a dificuldade de trabalhar com multiplas bases no grails 1.X.X

Falou e disse Kico.

O JSF 2 realmente é muito bom, mas o Groovy e o Grails foram uma das melhores coisas que aconteceram na plataforma Java. E eles são muito mais que uma framework de interface.

Scaffolding antes era muito simples mas hoje pode ser uma opção pois melhorou muito. Mas sem duvida entregamos resultados e temos prazer em desenvolver com ele por varios outros motivos como a arquitetura out-of-the-box que encoraja o uso de DDD para uma verdadeira orientação por objetos (melhor que o próprio Rails) que nos permite descer na abstração e usar Spring e seus benefícios.

Particularmente acho que o Groovy deveria se chamar Java Language 2.0, por ser compatível e trazer evoluções que entregam muita produtividade como a GDK (extensão de metodos nas classes base da plataformá Java, como date.format() e o list.each ) e as closures para programação funcional. Sem contar o AST que ainda é pouco explorado e muito poderoso.

Outro ponto forte é a facilidade de reuso de taglibs no GSP e a liberdade pra utilizar o excelente e agora padrão de mercado jQuery e sua excelente jQuery UI.

Na minha opiniao de desenvolvedor Groovy/Grails há 4 anos e conhecedor da maior parte das tecnologias de mercado por mais de 15 anos, é a framework mais "curinga" que conheço. No contexto Web, não consigo pensar em um cenário em Grails não se encaixe facilmente e seja uma boa opção.

As maiores conquistas não são somente os cases, mas a satisfação da comunidade em trabalhar com esta tecnologia que é uma das responsáveis por tornar a plataforma Java ainda mais atrativa e principalmente produtiva!Falou e disse Kico.

O JSF 2 realmente é muito bom, mas o Groovy e o Grails foram uma das melhores coisas que aconteceram na plataforma Java. E eles são muito mais que uma framework de interface.

Scaffolding antes era muito simples mas hoje pode ser uma opção pois melhorou muito. Mas sem duvida entregamos resultados e temos prazer em desenvolver com ele por varios outros motivos como a arquitetura out-of-the-box que encoraja o uso de DDD para uma verdadeira orientação por objetos (melhor que o próprio Rails) que nos permite descer na abstração e usar Spring e seus benefícios.

Particularmente acho que o Groovy deveria se chamar Java Language 2.0, por ser compatível e trazer evoluções que entregam muita produtividade como a GDK (extensão de metodos nas classes base da plataformá Java, como date.format() e o list.each ) e as closures para programação funcional. Sem contar o AST que ainda é pouco explorado e muito poderoso.

Outro ponto forte é a facilidade de reuso de taglibs no GSP e a liberdade pra utilizar o excelente e agora padrão de mercado jQuery e sua excelente jQuery UI.

Na minha opiniao de desenvolvedor Groovy/Grails há 4 anos e conhecedor da maior parte das tecnologias de mercado por mais de 15 anos, é a framework mais "curinga" que conheço. No contexto Web, não consigo pensar em um cenário em Grails não se encaixe facilmente e seja uma boa opção.

As maiores conquistas não são somente os cases, mas a satisfação da comunidade em trabalhar com esta tecnologia que é uma das responsáveis por tornar a plataforma Java ainda mais atrativa e principalmente produtiva!

O Groovy e o Grails tem o que melhorar? Claro! Toda tecnologia está em constante evolução.

@Musatto

A exceção de PermGen é um problema recorrente da Sun Hotspot JVM pra vários cenários, principalmente na execução de linguagens dinâmicas.

A JRockit JVM que tb é da Oracle e gratuita elimina este tipo de problema pois usa um GC bem mais eficiente. Já utilizei em muitos casos onde ela fez milagre.

A Oracle deverá unificar as JVMs a longo prazo, mas vc já pode usar a JRockit agora. É preciso avaliar o suporte do Groovy e Grails mais novos.

Outra questão importante é que a JDK 7 é otimizada para linguagens dinâmicas (invokedynamic) e além de eliminar este problema, nas linguagens que a suportam, como o Groovy mais recente, traz ainda mais desempenho - que nem é preciso na maioria dos casos onde já é muito rápido como mencionou. Mas agora dá pra usar Groovy até em cenários real-time.

Abraço!

Essa "trollada" é uma comprovação do crescimento do Grails Brasil ;), simples assim.

Quem acompanha este site vê que ninguém aqui omite os defeitos do Grails, como já lembrado pelo Henrique.

Enfim, vamos respeitar o que o colega acha do Grails. Há quem ache um "lixo" qualquer tecnologia, mesmo o "JSF2+Primefaces" enaltecido por ele.

@Wanderson
Eu sei que é uma coisa inerente da linguagem, mas é que com closure fica mais fácil acontecer isso até mesmo pra projetos pequenos.

Já do JDK 7 eu não sabia, e já uso o jrockit, valeu pela dica =)

Tem várias sacadas de performace da linguagem que se tiver no gatilho, ajudam pra caramba a longo prazo.......

Alias, taí um bom tópico né?

Qual o problema do java é configuração?? Porque nos artigos que vejo por ai sobre grails, todos dizem que o problema do java é integração de tecnologias e que o grails veio para solucionar esse problema, bem por um lado eu posso até concordar. Se o problema for esse, use um dos arquetypes do maven. Montei um projeto com Spring usando Spring Data( Que já tem find dinâmicos e etc) com primefaces em minutos. Bem pelo que eu vi, tem como usar primefaces com grails, mas alguém já usou?? É 100%? ou é bugado? Se vocês me garantirem que todos os plugins do grails funcionam 100 porcento eu já vou dar alguma credibilidade. No java hoje em dia pode-se demorar a fazer algumas coisas, mas há solução pra tudo.

A empresa que fez o projeto aqui é uma empresa terceirizada que escolheu o grails como framework, quando abri o projeto, vi um código totalmente horrível(achei a linguagem feia e sem nenhum padrão), cheio de código javaScript e me deu canseira de olhar aquilo. E olha que era um projeto pequeno. Agora eu quero imaginar quando eu ver o grande. Trabalhar com IDE no grails é uma droga, porque não vi nenhuma que tem autocomplete 100 porcento igual no java, mesmo aquela da Groovy Grails IDE. No grails eu posso declarar um atributo ou método qualquer como private e chamar de uma outra classe tranquilamente que não tem problema(Isso quebra o encapsulamento), mandei o cara fazer um teste e era isso mesmo(Não sei se o problema era bug da IDE).

O Ruby on Rails veio com a promessa também de substituir o java, quando isso veio foi uma febre total. Rails é isso, Rails é aquilo... Enfim... Todo mundo aderiu a pregação dos pastores até o twitter e o mais engraçado é que não deu certo e trocou pelo java. O mau do convertido é dizer que era ex viado, ex drogrado, mas quando se converteu a cristo tudo mudou, ficou milionário, teve mansões e etc. O discurso dos nossos amigos da comunidade são os mesmos: Quando eu programava em java eu era um retardado mental, um debilóide e etc.

Não vou ser escroto em dizer em que a linguagem groovy facilita bastante em algumas coisas, é claro que sim, como o nosso amigo falou, que o java vai evoluir pra isso, mas não tudo, vai ver o que tem de melhor e aprimorar, como ele sempre fez.

E outra eu quero usar jdbc no meu projeto grails tem como?? ou eu fico dependente do spring e do hibernate pra tudo??

Oi Franklin,

interessante suas colocações. Mas aí entra o seguinte:

* Se você pegou um sistema mal escrito em Grails, não pode generalizar dizendo que são todos assim. O mesmo poderia ser dito de qualquer linguagem, incluindo Java. Se quiser dar uma olhada em projetos melhor escritos, sugiro que dê uma busca nos open source, como por exemplo o Asgaard da Netflix, que é feito em Grails e usado para configurar as instâncias e deploy de aplicações daquela empresa. Ou então, um dia, quem sabe, o próprio código fonte do Grails Brasil que pretendo abrir em breve, ou mesmo os exemplos citados pelo Mussatto, que trabalha com projetos *realmente* grandes sem nenhum problema. Neste caso, a generalização não está acrescentando nada.

* Ainda sobre configurações, bem observado, você pode usar os arquétipos do Maven sem problema. E até aonde sei, uma coisa não exclui a outra, certo? São apenas opções para um mesmo problema.

* Com relação a dizer que todos os plugins são sem bugs. Nenhuma peça de software é, você deveria saber disto, e mesmíssima coisa você pode dizer de qualquer biblioteca Java. Basta olhar que raríssimas vezes você vai encontrar uma versão x.x.0 que dure muito tempo, sempre rola uma x.x.y com y bem maior que 3,4, certo? Então: novamente, argumentação injusta contra Grails ou qualquer linguagem. Aliás, aqui, novamente, não entendi o seu ponto no que diz respeito à configuração, mas eu respondo logo abaixo.

* Os plugins facilitam ainda mais a integração de bibliotecas Java em um projeto Grails, porque o autor do plugin já fez esta integração para você. Quando lidamos com Java diretamente, sabemos que nem sempre é assim quando queremos adicionar uma nova tecnologia ao projeto (na realidade, quase nunca é assim). Sendo assim, é uma solução interessante para este problema, e não um problema como você mesmo menciona.

* Com relação a trabalhar com JDBC direto. Fácil: basta acessar o próprio dataSource que já está configurado no Grails. Assim ó:

class ServicoService {
    def dataSource

    def metodo() {
        def conexao = dataSource.getConnection() // igual no Java
    }
}

ou, se quiser usar o mesmo contexto transacional da sua classe de serviço, tal como no exemplo abaixo:

class ServicoService {
  // injeta o session factory
  def sessionFactory
  def metodo {
       def conexao = sessionFactory.currentSession.connection()
  }
}

(só dar uma lida na documentação ou mesmo fazer uma busca básica no Grails Brasil ;) )

* Com relação à IDE: isto você sempre vai ter com qualquer linguagem dinâmica, mas há opções, como por exemplo o excelente JetBrains IDEA que supre este problema 120%.

* Com relação à integração dos componentes. Esta é a vantagem de qualquer framework fullstack. Ele já vêm com os componentes mais comuns relacionados a determinado nicho (pequeno ou grande) do mercado pré-configurados para que o programador não perca tempo. Há alternativas do lado Java também, se fizer seu "para casa" vai encontrar fácil.

* Com relação a métodos privados: dê uma estudada na linguagem primeiro e, antes disto, procure entender quais os problemas que ela soluciona e por que foi criada. Assim fica bem mais fácil.

E pra finalizar...

É muito comum este comportamento de rotular como ruim algo que não conhecemos talvez por estarmos acomodados com um modo de trabalho anterior. Minha sugestão profissional para você é dar uma estudada direito antes de tomar este tipo de atitude. Isto vai aumentar sua moral profissional e, quem sabe, até mesmo te ajudar a passar uma impressão mais madura (o que infelizmente não vi nos seus argumentos até agora).

@Franklin

Seu post confirmou como sua atitude foi passional e imatura pois realmente conhece muito pouco sobre o Grails pra fazer algum julgamento de valor. Não saber que dá pra usar JDBC como o Kico mostrou ou com GroovySQL mostra como sua opinião (nada baseada em fatos) não contribui em nada pra comunidade e não resolve seu problema.

Mas um trecho em especial é chocante: "O discurso dos nossos amigos da comunidade são os mesmos: Quando eu programava em java eu era um retardado mental, um debilóide e etc."

É um absurdo sem tamanho que não faz o menor sentido. Novamente está fazendo julgamento de valor sem nenhum fato pra suportar a opinião e o pior, de pessoas que são colegas de profissão e podem trabalhar com você em alguma ocasião.

Reforço o que disse o Kico com uma frase mais direta: procure ser mais humilde e educado. Você nunca vai resolver um problema esbravejando ódio ou colocando a culpa em alguém ou em alguma coisa, pois esta é uma atitude amadora e nada profissional.

Se o programador que desenvolveu o projeto não o fez da melhor forma, compartilhe com a gente. Todos podem aprender, principalmente você que precisa disso pra resolver o seu problema. Este é o conceito de comunidade.

Boa sorte!

Na verdade este post não foi de todo inútil. Para mim, teve duas utilidades básicas:

A primeira: obter um conhecimento no qual reforça a minha opção pela tecnologia Grails.

A segunda: dar muitas risadas com todas as palhaçadas que li aqui (rsrsrsrsr).

Abraços a todos.

fsdfsdfsdfdsfsfsdfdsfdsfsdfdsdfdsfdfds

O Renato e o franklin são duas crianças?

Kiko, bloqueia, porque as vezes eles possuem algum impedimento mental, ai pode atrapalhar os demais.

Com certeza é amiguinho um do outro, ai junta a turminha pra tomar fanta uva e falar mau das coisas que não dão conta. ehheheheheh

Me tira dessa amigo, eu nem conheço esse cara!!! Eu não iria chegar nesse nível de sacanear dessa forma.

Abraço!

Mas sabe o que é legal? Foi um belo teste de performance, carga e stress e o nosso servidor nem cambaleou. Muito obrigado Renato Parili, acabo de te bloquear no Grails Brasil.

Por via das dúvidas bloqueei o Franklin também, porque é muito suspeita a sua resposta
"fsdfsdfsdfdsfsfsdfdsfdsfsdfdsdfdsfdfds"

Resolvido novamente o problema do BABACA do Renato Parili.

De novo Renato, muito obrigado por ter me dado algumas dicas sobre como melhorar algumas coisas aqui pelo Grails Brasil. ;)

Franklin,

entraram em contato comigo. Me desculpe pela conduta que tive com você.
Reativei sua conta.

Henrique,
Agora sim estamos caminhando como uma comunidade de debate para corrigirmos erros, sugerirmos mudanças.

Vivendo e aprendendo Rogerio Dória.

Flood é triste em........

Agora, esta postura de atacar o fórum com flood é execrável.

Primeiro porque com ela não se provou nada a respeito da qualidade do Grails, apenas foi encontrado um bug em código que eu escrevi. Framework algum no mundo consegue evitar isto.

E segundo e mais importante: danificou um objeto de comunidade, de uso público.
Tiro do meu bolso o dinheiro para manter este site e, com isto, ajudar outras pessoas a aprender Groovy e Grails. É um trabalho que, pode soar cafona, mas do mais puro amor.

Então, a partir do momento em que este tipo de coisa começa a contecer, perde-se a vontade de continuar. E o atacante, que quis mostrar "Um ponto", na realidade apenas desmotivou aquele que sempre se esforçou por criar uma comunidade open source FORTE aqui no Brasil.

Agi errado com o Franklin? Com certeza.
Mas era o que me veio à cabeça na hora do aperto. Importante salientar que a "pessoa que vos escreve" é humana e passível de falhas. E que errou não por pura sacanagem - como o ataque ao fórum - mas por bobagem mesmo.

Inaceitável este tipo de postura.

Bem o evangelista, que o Franklin falava chegou.

Agora podemos conversar heheheheheh, veja que o pessoal do RIO esta mesmo interessado neste post.
Franklin existem algum item que vc queira colocar em pauta? Ou alguém queira colocar em pauta?

Se existir vamos tentar organizar os itens de forma a respondermos item por item.
Bem responder ou tentar é claro, não sei tudo de Grails e reconheço que só tem fera aqui no site, então certamente alguém aqui saberá responder aos questionamentos.

Abraço.

@Kico @Mussatto

Flood é uma falha inerente da arquitetura web, assim como XSS e outros. Qualquer framework Web está aberta a estes problemas. Eu poderia mostrar vários outros aqui que afetam Grails, PHP e Ruby principalmente. Tenho um amigo onde o trabalho dele é ganhar dinheiro avisando sobre falhas desta natureza para grandes sites. Ele encontra em média 10 falhas por semana. É um profissional de segurança que ajuda as pessoas e ganha dinheiro com isso, e não um imaturo que tenta prejudicar e acaba ajudando de graça e só ganha a antipatia dos colegas.

O custo para montar uma suite de teste de segurança de 99,99% só é viável para sites que não estão armazenando informações sensíveis como cartão de crédito por exemplo. Com certeza para uma comunidade GrailsBrasil que é um trabalho voluntário é inviável e desnecessário uma vez que o Kico ajuste o erro sob demanda em tempo hábil - como sempre acontece.

Valeu Kico pelo esforço voluntário que tem dado resultados muito positivos.

@ThiagoLP86

Bem vindo ao debate! O Franklin já foi convidado para expor seus problemas de forma mais amadurecida pois todos estão prontos para ajudar e muitos aqui tem larga experiência.

Mas gostaria muito que esclarecesse os pontos que o Franklin lhe acusou, se são realmente fatos ou simplesmente um exagero emocional, pois alguém rebaixar o outro devido a uma escolha (ex.: quem tem ou uao isso não é inteligente mas quem usa o que eu uso é) é tão imaturo quanto os posts do Franklin até o momento - que espero ter aprendido a lidar melhor com os colegas depois do acontecimento.

Sou recém-chegado no fórum, entrei por curiosidade neste tópico porque apesar do título esdrúxulo imaginei que as respostas seriam interessantes.

Primeiro, parabéns aos responsáveis por elevarem o nível da discussão e transformar um ataque absurdo em conteúdo aproveitável.

Vou deixar um testemunho aqui: acabei de criar uma rede social utilizando o Grails 2.2, com uma implementação de API REST, serviços rodando em background, acesso a múltiplos databases, isso tudo em mês e meio de programação, e posso afirmar com certeza absoluta que não seria possível sem o ganho de produtividade que o Grails + SpringSource GGTS. Comparo com os demais frameworks que trabalhei recentemente, principalmente Stripes e JSF2 (Primefaces).

Problemas existem, claro, mas não existe almoço grátis, tem que estudar e se aprofundar na plataforma, se possível contribuir, é assim que funciona.

Abraço,
Uilian.

Boa notícia Uilian!

Publica ai o link de sua rede social e sua experiência no desenvolvimento Grails.

Vamos demonstrar que grandes aplicações também podem ter suas bases em Grails.

@Rodrigo

Sobre grandes sistemas fui líder técnico e projetei a arquitetura de 3 grandes sistemas web para o governo, inclusive uma rede social. Todos com Grails 1.x. Imagino como seria excelente se fosse com Groovy & Grails 2.0!

Uma experiência interessante foi adotar Groovy/Grails em um sistema que já utilizava Java e outras frameworks. Todos os módulos evolutivos foram desenvolvidos em Grails e integrado com os módulos feito com outras frameworks, incluindo a segurança (login) utilizando o padrão JAAS deixando tudo transparente pro usuário final. Hoje em dia utilizo serviços que implementam o padrão CAS.

Enfim, Grails tem muitos cases mundiais de sites com alto volume de acesso como eHarmony.com (maior rede social de relacionamentos do mundo), Sky (video.sky.com e tv.sky.com/tv-guide) e vários outros aqui (http://grails.org/Success+Stories) sem contar em sistemas corporativos (internos) que não podem ser acessados publicamente.

Definitivamente não daria pra fazer os sites citados acima com JSF (se alguém tentasse fazer iria sofrer bastante), pois a arquitetura do JSF é orientada para maior produtividade em sistemas corporativos na plataforma web. À propósito, comparando com outras plataformas para desenvolver sites, o Grails consegue uma produtividade tão alta quanto de um PHP ou Rails mas com uma arquitetura, escalabilidade e desempenho melhores devido a plataforma Java.

No Brasil temos vários casos de sucesso, desde websites até sistemas corporativos, como muitos citados nos comentários deste post e também os listados no Grails Brasil em http://www.grailsbrasil.com.br/caso.

Recomendo todos que estão acompanhando a atualizar a lista de cases do Grails Brasil!

Sabe o que eu acho mais bacana no Grails?

Sistemas gigantescos eu já vi e atuei em diversos, que lidam com milhares de requisições por dia e até um que lida com dezenas de milhões.

Agora: o que mais me impressiona DE VERDADE são aqueles que são mínimos: que consomem o mínimo de memória, em máquinas pequenas, simples, baratas. Sou suspeito pra falar sobre isto: adoro criar este tipo de coisa minimalista (http://miocc.itexto.com.br).

Mas tenho um caso bacana pra contar: para um cliente fiz um sistema que era executado em uma máquina de 128Mb de RAM. Yeap: vocês ouviram direito. Só isto. Não era um sistema lá com muitos acessos: era para uma intranet bem simples inclusive.

O que é interessnate neste caso é o seguinte: nunca caiu, nunca deu pau, nunca deu pau de memória, e em alguns momentos ele precisava fazer umass coisas bem complexas para aquela máquina.

Então, o que eu quero dizer com este post é o seguinte: um aspecto massa do Grails é que o bicho escala de verdade, de máquinas mínimas até trambolhos gigantescos de uma forma maravilhosamente tranquila.

É possível conseguir isto com outros frameworks? Com certeza. Mas o lindo do Grails é que você faz isto de uma forma fácil, muito fácil.

Só uma observação: eHarmony.com é em PHP (não sei porque consta no site do grails.org como um "case"). Basta usar um analisador de requisição para constatar isso rapidinho.

@Kico

Realmente é impressionante, mas isso é mais méritos da plataforma Java. Por isso ela considerada a melhor plataforma do mercado, principalmente em escalabilidade e uso de recursos.

A vantagem é que o Grails roda na melhor plataforma! :-)

Sobre o assunto, o que me impressiona muito é a velocidade do Groovy 2.0 na JDK 7, mesmo com metaclass, AST e tudo mais que uma linguagem dinâmica tem direito.

@Yoshiro

A utilização no eHarmony é interna para uma grande tarefa, como você pode ver neste Estudo de Caso.

@Wanderson,

sim: é o mérito da plataforma Java sem dúvidas.
Mas a vantagem do Grails é que ele já vem com uma arquitetura pronta que te permite ter este ganho de escalabilidade.

Se você for trabalhar só com a plataforma Java, obter este ganho de escalabilidade é bem mais difícil.

Estou começando a estudar o grails, ainda não tenho um conhecimento muito aprofundado mas concordo em algumas coisas que o grosso do Franklin disse. Achei que a forma de trabalhar com o .gsp muito confusa. Comparando ao JSF + Primefaces, vc cria uma página bem mais fácil e limpa sem precisar ter conhecimentos muitos aprofundados em html,css e JavaScript.

A curva de aprendizagem fica um pouco extensa em entender como vc relaciona os campos da "tela" com seu código dos controladores. Outro ponto que concordei foi que das IDE´s que utilizei nenhuma trouxe a função de autocompletar o código, uma pena, para quem está iniciando ajudaria muito as sugestões da IDE.

Gostei bastante das simplicidades do código Groovy e a forma que persistência de dados com o GORM. Métodos básicos muitos simples de trabalhar. Agora, sobre o scaffold, serve mesmo apenas para aprendizado, acho que ninguem fazia uma aplicação utilizando isso...

Espero ter contribuído com uma visão de quem está querendo aprender o framework.

"Agora, sobre o scaffold, serve mesmo apenas para aprendizado, acho que ninguem fazia uma aplicação utilizando isso..."
Se você estiver se referindo ao scaffold padrão do grails pode até ser, mas se você modela-lo de acordo com suas necessidade ele te poupará um tempo enorme e garante um bom padrão inicial para os seus projetos.
Particularmente utilizo uma versão customizada do scaffold que serve para toda a base do sistema que estou construindo. Uma vez gerado apenas adiciono particularidades específicas de alguma interface.

Não trate o scaffold como algo estático, tente entender como funciona e perceberá que ele é bem poderoso e pode ser uma (ou duas) mãos na roda ;).

Leonardo, os motivos que você descreveu com sendo o ponto fraco do Grails se aplicam a todo framework "Action Based", tais como Rails, todos os fws PHP, Play, etc...

Na verdade se não quer lidar com HTML, CSS e JS diretamente, só lhe restam: GWT, JSF e .NET além de outros ilustres desconhecidos por aí.

A questão não é querer lidar com HTML, css e JS, e sim não perder tempo reinventando a roda. Para que irei ficar escrevendo código para criar algo que o primefaces me dá com uma linha apenas?

Não sei se entendi direito.

Mas acredito que você entende que o jsf com o primefaces é produtivo por causa que existem tags que facilitam o trabalho de escrita dos arquivos de visão.

Primeiro, ninguém quer te convencer do contrário, cada um deve saber qual é a ferramenta que melhor lhe atende.

O que me gera uma certa dúvida é que toda a "produtividade" que você diz ser superior no desenvolvimento da interface com o usuário, você perde na implementação de controllers, services e até mesmo na definição de classes de domínios.

Outra questão é que existe inúmeros plugins que te proporcionam tags que facilitam as interfaces com o usuário.

Como você gostou do primefaces acredito que o Vaadin 7 Plugin vai te dar está produtividade.

Mas existem outros: kendoui, easyui basta encontrar aquele que melhor se adapte.

Opa,

esta discussão voltou: ótimo, porque talvez seja uma das mais produtivas aqui do fórum.

De lá pra cá algumas coisas aconteceram que valem à pena mencionar:

* Suporte de IDEs: o Groovy and Grails Tool Suite (http://grails.org/products/ggts) da Pivotal melhorou bastante. Na realidade, foi um choque pra mim: não levava a sério a ferramenta e levei um susto alguns meses atrás quando vi o recurso de auto completar funcionando para finders dinâmicos e outros recursos do Grails. Vale à pena experimentar, especialmente porque o gap entre ela e o IDEA da Jetbrains está diminuindo MUITO com o tempo.

* Questão da produtividade dos frameworks orientados a componentes. É o que o Yoshiriro falou, são dois paradigmas diferentes. Pessoalmente, prefiro usar o HTML mais puro possível por me dar mais controle.

Sobre componentização, é importante lembrar que, apesar de não ser um framework baseado em componentes, há reutilização de código na view em Grails (e qualquer outro action based que foque no HTML puro). O mesmo resultado que você obtém com o Primefaces hoje é possível obter (e ainda superior) com ferramentas como jQuery UI, Angular.js, etc. Então, realmente, não é preciso reinventar a roda.

Ainda sobre este assunto: um ponto que pouca gente menciona mas que vale à pena frisar: Grails trabalha com bibliotecas de tag padrão Java EE.

O curioso é que aquilo que EU considero defeitos mesmo do Grails nenhum dos "do contra" mencionou aqui:
1. O tempo que leva um "run-app". Tudo bem que depois de estar no ar quase não precisa fazer novamente. Mas quando precisa...
2. O tempo que leva tanto para testes unitários como para testes de integração (este considero muito mais estressante!)

Agora quanto ao Primefaces, numa coisa ele é imbatível: A variedade de componentes. Acho que nem somando todos os plugins de UI do Grails dá 70% da quantidade que o PF oferece. Tá certo que a customização e desempenho deles ficam muito a desejar em alguns casos, mas na variedade, é imbatível!

Bom praticamente li todas as questões aqui e posso ganhar o prêmio de escavador do ano por reabrir este tópico.

Depois de inúmeras discussões como estão vocês com Grails?

Começei a estudar e trabalhar no início de 2016 1 ano agora e estou muito satisfeito e animado com o que posso aprender e criar.
Ja comprei o livro do Kick (mercham aqui em)

Mas ainda esbarro em algumas coisas mas vamos que vamos.
Mas ja tenho 2 aplicações estáveis 100% grails rodando perfeitamente.
1 intranet da empresa de ti
1 sistema de tickets.

Vamos falar como estamos hoje com grails ae galera.

Interessante é que lá no inicio o cara sugeriu abandonar o Grails e partir para Spring.... Só que Grails é basicamente spring.
E ninguem te obriga a utilizar nenhuma das facilidades: Não gosta do mapeamento automatico do gorm? Pode fazer na unha. Não gosta dos métodos de consulta e persistencia do gorm? Utilize hibernate ou qualquer framework de persistencia na unha. Não gosta de data binding? Não use. Não gosta do controle transacional dos services? Não use. Não gosta de scaffold? Não use.
Usem o que vocês acharem que está facilitando a sua vida, façam o resto como preferirem e sejam felizes.

Me "cocei" pra tentar não disparar esse e-mail pra cima novamente, mas quem chegar e ler todo o histórico vai sentir o mesmo que eu ao lê-lo, ou seja, vai perceber o quanto o Framework evoluiu e não para de crescer durante todo esse tempo.

Incrível que após algum tempo sem usar (final de 2014 -> início de 2015) eu volto ao Framework (última versão devido ao meu "TOC") e percebo uma evolução absurda... Que sirva de exemplo para alguém que venha ler esse post no futuro, o Framework pode passar ainda por muitas variações, provavelmente acertarão em algumas coisas e errarão em outras, mas a equipe está de parabéns. Mesmo que um dia não evolua mais e quem sabe, morra (bate na madeira) terá cumprido seu papel longe de ser "o lixo" como o colega (de forma muito infeliz) diz no post inicial.

É isso aí, eu estou apanhando e muito pra versão 3.x... Rsrsrsrs :)

Aqui vai contribuição ao post.

Há anos venho acompanhando a evolução desse post, trabalho com grails desde a versão 1.3.7 e posso dizer o seguinte:

Sim, Grails é horrível para um monte coisas, eu detesto coisas mágicas, coisas mágicas podem dar problema, ai vc vai ver o que é problema de verdade.

Testes unitários (quem não faz deveria levar várias chibatadas todos os dias), use e vc irá ver como é ruim de se escrever testes unitários para Grails, os métodos dinâmicos são para f.. a vida do peão.

O bendito active record, cara, eu detesto isso, acho uma das coisas mais nojentas que existem. Qualquer parte do sistema vc faz um get, altera alguns atributos e save, que bom hein :( ...

GSP, lixo, lixo, lixo, do mesmo jeito que JSP com qquer coisa que utilize taglib, isso é coisa da década passada, há anos eu vinha tentando sair desse mundo e com a "evolução" RESTFull, tudo começou a melhorar, JSF, Prime, qquer coisa do gênero deve ser descartado, saia disso. Aprenda que frontend é uma coisa, backend é outra, se vc ainda está nessa, vai ficar pra tráz num futuro não muito distante e só cuidar de legado (credo).

O que o grails tem de bom:

- facilidade em acessar dados na base (consultas)
- muito rápido de se criar projetos
- groovy
- convenção sobre configuração
- não ter que criar 'n' métodos nas domain class
- contraints
- command object + contraints
- e algumas outras

Mas todo esse lado bom está sendo engolido, Spring Boot  + algumas coisinhas já faz quase tudo isso ai e vc tem um controle maior do que está acontecendo.

Mas o que eu mais detesto mesmo é essa arminha (Grails) nas mãos de crianças, quem já trabalhou em projetos grandes com outros devs, sabe que não é fácil, o camarada sai na controller colocando regras de negócios e outras coisas....

Há, ia me esquecendo, nunca, mas nunca, mas nunca mesmo, deixe de atualizar o grails, estou trabalho num projeto na versão 2.2.4 que está transformando minha vida num inferno.

Bom é isso.

Sem dúvidas! Também acho completamente desnecessário, há dois anos quando esse post foi escrito o javascript não era tão popular como é hoje. Hoje em dia realmente não faz mais sentido usar nem GSP e nem JSF já que tem o Angular que facilita e muito o uso do JavaScript. Hoje em dia mudei a minha concepção sobre a forma de fazer aplicações, mas não usaria o Grails em meus projetos e nem JSF com Primefaces. O problema para mim no Grails naquela época era o uso do JavaScript, sendo que o Primefaces fazia esse trabalho sujo.
Usaria também o Java e não o Groovy, até porque a maioria dos developers aqui no Brasil é Java, então é mais fácil procurar gente que dê manutenção.

Tecnologias que usaria em novos projetos.
-Angular.
-Java1.8
-Spring Boot
-Rest.

Cara sem dar  hate nem nda , REST é padrao de arquitetura não uma tecnologia,  Grails 3 ta uma camada acima do spring boot já que usa ele como base ,  Groovy  roda em cima da jvm logo tudo que  java tem é implementavel em groovy , Angular é FW Front end  . Alguem que fala que  o uso de javascript no Grails  era um problema é um baita preguicoso que queria ficar preso no scaffold , JSF te dava o componente pronto e te deixava amarrado   a ele  só isso , do lado do Grails  era so implementar html e javascript  , ohhh que dificil .
Não que grails seja  a solução pro mundo mais nego  joga merda no ventilador em falar mal de uma tecnologia por não saber  utilizar .

"Qualquer parte do sistema vc faz um get, altera alguns atributos e save, que bom hein :( ..."
Se você acha inapropriado manipular dados num controller por exemplo, simplesmente não faça.
Quanto à manutenção de código de terceiros, será um inferno se o tal terceiro não tiver competencia para escrever algo com boa manutenção, isso não tem nada a ver com a tecnologia utilizada e sim com o profissional.
"Spring Boot  + algumas coisinhas já faz quase tudo isso ai e vc tem um controle maior do que está acontecendo."
Grails 3 é justamente "spring boot + algumas coisinhas", mas vc não é obrigado a utilizar nenhuma das "coisinhas",
nem o próprio gorm vc precisa utilizar.
Sobre testes unitários eu concordo com vc, e isso se deve à mágica do Grails. É tanta coisa que o framework monta automaticamente na aplicação,
que quando vc precisa testar uma unidade isolada acaba tendo problemas, isso me levou a testar tudo em ambiente de teste de integração

Como eu disse:

Tem o lado bom e o lado ruim, eu particularmente acho que grails é sensacional, mas infelizmente num projeto com 'n' devs, se vc não tiver um lider que define uma boa arquitetura e modo de trabalho, cara, vira uma salada.

Vcs tem razão, vc não precisa usar, mas acabam usando e na boa, comecem pelos testes unitários e verão como as coisas são trabalhosas e dolorosas.

E outra, se alguêm pergunta-se pra mim, devo aprender Grails, Rails e por ai vai, diria, aprenda PHP ou Java ou .Net, não invista seu tempo agora, num futuro, quem sabe, afinal, temos que pagar as contas.

"Alto acoplamento", se seu código não for bem escrito (GORM espalhado por tudo quanto é lugar), vc casou com o grails, e não separa mais, a coisa mais linda é vc programar para a interface e com grails, é natural que isso não aconteça.

Bom, JAVA/Spring é uma coisa, vc trabalha dum jeito, Grails, muda bastante, pois tudo já está pronto e é natural vc querer tirar proveito de seus facilitadores.

Outra coisa, detesto isso -> "def bla(def param) {", cara isso é nojento, vc não sabe que tipo de param o método recebe, vc não sabe que tipo de retorno. Ai vcs vão dizer, basta vc definir, e direi, concordo mas leia o segundo parágrafo.

Olha, minha discussão favorita voltou a ficar interessante!

Bom, vou dar meus pitacos aqui.

"num projeto com 'n' devs, se vc não tiver um lider que define uma boa arquitetura e modo de trabalho, cara, vira uma salada."
Este não é um problema do Grails, e sim do RH. Já vi isto em Spring, .net, JSF, PHP, VB, COBOL, Clipper, Delphi, Python, JavaScript...

"Alto acoplamento e ficar preso no Grails"
Na realidade estamos lidando aqui com um framework. Com qual frequência você troca o framework da sua aplicação? Normalmente só quando vai ser reescrita. E isto ocorre com qualquer um, até com o Spring.
O grande lance é entender como o framework organiza os componentes. No aso do Grails, temos as classes de domínio que contém os métodos do GORM. Isto por que não se adotou o modelo anêmico de OO, tal como costuma ocorrer com os POJOs do Java. É uma questão de gosto: pessoalmente, prefiro o modelo "fitness". 
Em qualquer framework, o fundamental é entender as decisões tomadas por aqueles que o criaram. No caso do Grails, temos o acoplamento entre classes de serviço e domínio. Não é para ter regras de negócio em controladores ou taglibs, por exemplo. Se isto está rolando, é sinal de que a equipe não estava bem treinada OU, novamente, problema de RH.

"Renderização de páginas do lado servidor"
Aqui temos de prestar muita atenção no contexto. No caso de telas cadastrais, aquelas que servem só para criar os registos no banco de dados e não tem muita regra de negócio (se é que há alguma), scaffolding não é uma mão na roda, é um exército inteiro!
Pessoalmente, usei muito pouco o scaffolding nestes 12 anos de experiência com Grails, e recentemente tenho usado cada vez mais um modelo de interface gráfica baseado em SPA. E, bem: com Grails.
E a razão pela qual uso Grails é por que escrever APIs com ele é muito simples, muito tranquilo e muito mais fácil que com o Spring, por exemplo. 
Aliás, é interessante observar uma coisa: Grails sempre te possibilitou trabalhar com HTML puro: esta foi inclusive uma das razões pelas quais migrei do JSF para o Grails mais de uma década atrás: eu podia jogar na mão do frontend o que ele conhecia: o HTML puro, e ele se virava, e bem.
E este é um ponto interessante aliás, por que a partir do momento em que você conseguiu separar a view da aplicação, você pode usar qualquer coisa do lado servidor (e isto é lindo)

"Testes unitários"
Há uma curva de aprendizado aqui que vale à pena. Pessoalmente, DETESTEI quando no Grails 2.2 (se não me engano), do nada trocaram o framework de testes do Grails pelo Spock sem avisar o resto do pessoal. Lembro de ter feito o upgrade no projeto e, do nada, meus testes falharam.
Entretanto, conforme o tempo passa e você vai pegando o jeito com o Spock, difícilmente volta para outras alternativas. Testes unitários com mock são um saco? Com certeza, eu pessoalmente odeio e, digo mais: em 90% das vezes escrevo testes integrados, pois a interação com o banco de dados é importante.
O grande ponto negativo na minha opinião é que infelizmente eles demoram MUITO para serem executados no Grails. Sobre isto, entretanto, há melhorias, e devo escrever a respeito em breve.


"

"Testes unitários com mock são um saco? Com certeza, eu pessoalmente odeio e, digo mais: em 90% das vezes escrevo testes integrados"
Ao saber que um cara como o Kico também adota essa prática, fico mais seguro de fazer isso e assumir publicamente kkkkk

Prezados membros,
Acompanhei um pouco desta discussão e gostaria de somar ao coro dos que são entusiastas e praticantes do Grails.
Já programei em tantas linguagens e estava precisando colocar um projeto pessoal na Web. Nesta época fui convidado para coordenar uma equipe na Petrobrás. Era um grande projeto escrito em (poxa vida!) Grails! Foi um sucesso. Eu não conhecia a linguagem, mas desejei saber mais e vi que era o que eu precisava para meu projeto particular.
Minha cararcterística pessoal é de me aprofundar muito no que estou fazendo, e já se vão 3 anos de aprendizado. Estudei o scafold a fundo, e digo que é maravilhoso. Isto porque você não precisa seguir o padrão que vem "de fábrica", comprei um bom template bootstrap por apenas US$ 17,00 e coloquei a mão na massa do scafold. "Ensinei" para minha aplicação como interpretar a maneira que eu quero que ela apresente meus domínios em diversos contextos, e tudo funciona muito bem. Parametrizo meus padrões e digo para o Grails: construa a aplicação, e ele faz tudo direitinho.
É claro que em determinados momentos sentimos falta de alguma documentação que abranja o nosso pequeno quadrante neste espaço infinito de conhecimento,  mas paciência - quando o vento não sopra agente tem que pegar uma flauta e soprar solitariamente...
Para terminar gostaria de expressar meus agradecimentos ao Kico, que para mim não é um evangelista das conveniências porque o que ele ensina é prático e traz resultados. Kico é um guru porque ele lança luz em pontos fundamentais para o progresso de nossos projetos.
Obrigado a esta comunidade valiosa! Contem com minha humilde contribuição.

Oi Pedro Gentil, sem palavras...
Obrigado!