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.