

Grails 3.0 Released and the Road Ahead - blktiger
http://grails.io/post/115110650393/grails-3-0-released-and-the-road-ahead

======
beachwood23
I'm interested in anyone's thoughts on Grails as compared to RoR. Which one is
easier to pick up, develop in, has better tooling, etc.?

~~~
thom_nic
In my experience, go with RoR unless you're already in a deeply-committed Java
shop. Rails has much more momentum & community support (even if Node is slowly
chipping away at it.)

With Grails by comparison you're more likely to find plugins that haven't been
updated in years and be constantly fighting dependency conflicts. At least
that was my experience.

If you go the Grails route it's also inevitable that you'll need to learn all
of the various "layers" underneath Grails nice veneer. E.g. Grails wraps a lot
of existing Java technologies which are fairly complex on their own like JEE,
JPA, etc. Rails seems to be "shallower" and easier to grok by comparison.

As an aside, I personally love the Groovy language and syntax too, and how
easy it is to interop with any java libraries.

Don't get me wrong, if I needed to write a Java-based, user-facing web app,
Grails is the first option I would look at. But short of the Java requirement
I would choose RoR or even Sails.js (not as mature but rapidly improving it
seems.)

~~~
vampirechicken
You can take advantage of the JVM (JIT compilation, etc) by deploying under
JRuby, the Ruby runtime implemented in Java.

------
btreecat
I never felt comfortable in the behemoth of a framework and the plugin system
always seemed a bit odd.

We have stopped building new applications/sites in Grails where I work but
still have a handful of ones running on 1.x and 2.x still in operation.

~~~
thom_nic
Curious to hear what you've chosen as an alternative? It seem to me that all
java web frameworks follow this same "behemoth of a framwork/ plugin system"
where "behemoth" is really just an indicator of how much the framework makes
choices for you out of the box.

If you take something like vert.x in comparison, sure it feels more
lightweight unless you need ORM and robust view layer and the things you would
need for a front-end framework.

I'm not saying your observation isn't valid, but it feels like a catch-22 in a
lot of cases.

~~~
btreecat
Well we never were a Java shop, and we already had a lot of python in play so
awkwardly enough I settled on web2py for the time being. We happen to have
some legacy code that is just easier to incorporate than rewrite which did
lead to some of the initial decisions to use groovy/grails.

Some other devs had taken Django on a tour back in it's 1.1-1.2 days and hated
it so I was pushed to look at something else. Did not care for Pyramid and
didn't have the time to "do it all" with flask so I settled on web2py.

Turns out to have been a great choice for us so far. The framework is still
bloated by comparison, so I don't like it when what we should be building is
really an API.

However not having a plugin dictate what version of jQuery I am using has been
a boon for fronted productivity.

To more directly address my issue with the plugin system, another commenter
said it well "With Grails by comparison you're more likely to find plugins
that haven't been updated in years and be constantly fighting dependency
conflicts. At least that was my experience."

This mirrors my exact experience on several projects I started and maintained.
I just assumed it was because I didn't know how to use grail well. Then I
inherited a medium sized code base from some developers who were born and
bread java EE devs and _love_ groovy and grails and seemed to always know the
"right way."

Only problem was, once I started following the code, it was all just java in
groovy syntax and just as crusty and hard to update to new versions.

I eventually gave up following groovy releases and just froze all my projects
on the 2.3.x line. I was spending more time every week upgrading plugins and
fixing issues that never existed before upgrade (like broken JSON and XML
parsing).

When it comes to an ORM, I often just try to avoid it unless I am dealing with
an application that has data that I know will be very regular and work well as
a spread sheet in a simpler context. Anything more complex and I just research
it online or start poking my DBA's for proper design/access patterns. This
again leads me to why I like web2py, the DAL is very similar to SQLAlchemy's
core design. Just a simple abstraction layer for generating queries and
maintaining connections/pooling.

We have talked about vert.x, and it seems promising. My reservation is that I
am still not a fan of groovy, Jython is not version 2.7 yet, and I don't know
scala or want the verbosity of java. So it just is not my first choice
although certainly seems promising.

I am tinkering with flask as well. I don't mind the more DIY approach but
having to stitch _so many_ things together just for basic functionality makes
me glad I am keeping it for my pluggable API idea which hopefully will replace
the DB calls in all our grails applications with API calls to the flask app.
But that is another story.

TL;DR

Have yet to settle on a single replacement although web2py is serving nicely
at the time being. Our primary concerns are ease of maintenance and number of
DB drivers supported which is why Java/groovy based framework seemed to make
sense at the time but python based framework and tools make more sense now.

Additionally, Node JS DB support is still pretty iffy, No one here likes using
PHP or want's to deploy more of it than they have to, Scala is out because
Groovy, C# is already used else where but not the best fit for our web-apps
and automation, no one here knows more Ruby than what is required to write
Puppet modules, Go isn't bad but can't be used to build a pluggable system
AFAIK, one one person knows Perl.

