Why I use Grails

A lot of CTOs and technical people get asked what they use for their personal projects.  So to be completely honest, I use Groovy/Grails.  Do I think it is the best thing out there?  Maybe not, but let me explain why I use it and what I expect.  The thought process would be useful for anyone making choices about technology platforms for oneself.

So I started way, way back with PDP RSTS Basic and soon moved to Apple Basic. I realized I could not write games and dropped into 6502 assembly for which I will always hold a sweet spot.  My first “real” language was K&R C.  Yep – pre-ANSI standard.  I stayed with C through college, grad school and well into my first job.  I would drop into Motorola 68K assembly, 80×86 assembly and other close the metal languages.  Of course like any proficient Unix guy, I would script in ksh and eventually bash.  I developed decent abilities to use awk, sed and other utilities (make files with tabs anyone?).

By the dawn of the internet age, in 1995 I start to use Perl for a lot of coding.  When I was writing CGI, I realized the speed of development overrode the absolute speed of C.  Given the choice of writing a makefile, compiling a program and the random segfault vs. popping into an editor and getting a working script, it was obvious that much of the development for the web would head towards interpreted, RAD systems.  However, Perl did suck in so many ways and when Java was born, it was a natural fit for an old C hand like me.  I dove in and wrote Java since before the 1.0 release up until now (Java8).  I did not appreciate the bloat with each release and the slowness to adopt good trends in languages.  The J2EE standard with its endless XML configuration files really started to grate on my sensibilities.  The beauty of the JVM and the simplicity of the Java language were overshadowed by the monstrosity of the J2EE container.  At the same time ORM and other developments got rid of a ton of cut and paste code that was prone to errors.

Sometime later a friend, Jim White, introduced me to Groovy.  It was a language with just the right amount of syntactical sugar and the development speed of an interpreted language.  Even in its early form, it did a lot right.  After a while, this MVC framework called Grails came to be – I started using it with the 1.01 release.  Modeled on Ruby/Rails, it leveraged the maturity of the JVM, the convenience of Hibernate and the newfound paradigm of convention over configuration.  I was hooked.

It was rough in a lot of places – the stacktraces were often mysterious.  Built on top of the Spring framework, it had lots of great features like IOC, but also grew as Spring grew.  But what I loved about it was that I could use tons of mature Java libraries as first class citizens of the framework.  The templating language was a good natural extension of JSP.  The plugins in the ecosystem were robust and written by really sharp folks.

Most of all I was really productive in it.  Groovy as a language has continued to lead the way in everything from syntax to closures, to lambda (functional programing), mixins, and reactive programming.  It is always ahead of Java in this regard and I find the concise nature of Groovy so much better than the verbosity of Java.

With a skeleton crew, the Grails team has tracked a lot of the thought leadership in frameworks – so I can continue to grow while still having a comfortable and productive set of functionality to fall back upon.  I think it is still best suited to RAD style projects – I love doing quick sites and projects in Grails.  It works well up to a pretty healthy size and then one can still pop into a number of more performant ways to solve specific bottlenecks.  I find myself less enamored of ORM over time.  I still find parts of Grails that drive me nuts and those will be the source of more writing

Have I tried other platforms?  Of course – I have challenged myself with Node.js/Angular, Python/Flask, Scala/Play and many, many others. Each has its own strengths and weaknesses.  But it comes down to productivity, and for me nothing has beaten Groovy/Grails in that regard.

Currently Vice President of Technology at Verifi a Visa company. Michael has been involved in the Los Angeles technical community since leaving UCLA graduate school in Computer Science. He has started 3 companies including WebEasy, Storitz and ParqCity and has consulted on many others. He has worked in industries as diverse as Banking, Insurance, Internet, High Frequency trading and Telecommunications. When not twiddling bits, Michael enjoys music, baking and running.

2 comments On Why I use Grails

  • Isma'il ibn Thomas-Benge, III

    This article has been very inspiring to me.
    I came in contact with Grails in 2011/2012 and I loved it … especially because I have this long desire to move to becoming a software developer from being a software test (automation) engineer.
    I have actually been developing a test automation framework/application all.written in Grails and thus far I am satisfied with the results and a few people I have shown small parts of it to really like it and want to see more features.
    I would to be a part of the efforts here if you don’t mind having a very enthusiastic newbie tag along.

  • Given the specifications of Java 8 and Java 9, I wonder if groovy/grails will eventually become technical debt for companies that expect longevity throughout its technology stack. There are a few common issues that remains to be a hindering outliar within groovy/grails:

    – It works well with GORM but no other ORM!
    – Like other type safe languages, when declaring everything with “def.” It’s becomes hard to maintain.
    – On very large projects, you’re subtly bound to an IDE like IntelliJ.
    – Typically, interpreted languages are heavier on memory during run-time compared to a fully typed languages.

    For small projects this is great but for large projects it can introduce technical debt that can be very costly in the long run for any company.

    -my 2 cents.

    -dag

Leave a reply:

Your email address will not be published.

Site Footer

Copyright © 2016 WNX.com