As is usually the case with anything “new” there’s a lot of FUD and confusion out there with people who have not used Grails yet, that may be stopping them using it. Here’s a quick list of some of the more common falsehoods being bandied about:

1. “Grails is just a clone of Rails”. Ruby On Rails introduced and unified some great ideas. Grails applies some of them to the Groovy/Java world but adds many features and concepts that don’texist in Ruby, all in a way that makes sense to Groovy/Java programmers.
2. “Grails is not mature enough for me”. The increasing number of live commercial sites is the best answer to that. Its also built on Hibernate, Spring and SiteMesh which are well-established technologies, not to mention the Java JDK which is as old as the hills. Groovy is over three years old.
3. “Grails uses an interpreted language (Groovy)”. Groovy compiles to Java VM bytecode at runtime. It is never, ever, ever interpreted. Period. Never. Did I say never ever? Really.
4. “Grails needs its own runtime environment”. Nope, you produce good old WAR files with “grails war” and deploy on your favourite app container. During development Grails uses the bundled Jetty just so you have zero configuration and dynamic reloading without container restarts.
5. “My manager won’t let me use Grails because it isn’t Java”. Smack him/her upside the head then!** Grails code is approximately 85% Java. It runs on the Java VM. It runs in your existing servlet container. Groovy is the greatest complement to Java, and many times more productive. You can alsowrite POJOs for persistence to databases in Java and include Java src and any JARs you like in a Grails application, including EJBs, Spring beans etc. Any new tech can be a hard sell in a cold grey institution, but there’s rarely a more convincing argument than “Hey Jim, I knocked up our new application prototype in 1hr in my lunch break with Grails - here’s the URL”. [** comedy violence kids, not the real kind]
6. “Grails is only for CRUD applications”. Many demos focus on CRUD scaffolding, but that is purely because of the instant gratification factor. Grails is an all purpose web framework.
7. “Scaffolding needs to be regenerated after every change”. Scaffolding is what we call the automatically generated boilerplate controller and view code for CRUD operations. Explicit regeneration is never required unless you are not using dynamic scaffolding. “def scaffold = Classname” is all you need in a controller and Grails will magic everything else and handle reloads during development. You can then, if you want, generate the controller and view code prior to release for full customisation.
8. “Grails is like other frameworks, ultimately limiting”. All Grails applications have a Spring bean context to which you can add absolutely any Java beans you like and access them from your application. Grails also has a sophisticated plugin architecture, and eminently flexible custom taglibs that are a refreshing change from JSP taglib.
9. “I can’t find Grails programmers”. Any Java developer is easily a Grails developer. Plus there are far fewer lines of code in a Grails application than a standard Java web application, so getting up to speed will be much quicker.
10. “Grails will make you popular with women”. Sorry quite the opposite, you will be enjoying coding so much you won’t be chasing any women for a while. We should put this as a warning in the README actually, along with a disclaimer about any potential divorce that might result from hours spent playing with your Grails webapps.

– Marc Palmer, Anyware

Tags: Grails, Marc Palmer

In our last post I fawned over Ruby on Rails (RoR) like a schoolboy smitten by the new girl (let’s call her Ruby) at school. So, like the schoolboy’s heart wrenching realization that he mistook Ruby’s “hello, world” smile for a tender “will - you - be - my - boyfriend” countenance, I present a handful of potential RoR letdowns.

Skills Demand > Skills Supply …There appears to be considerably more demand for Rails programming than there are Rails programmers (irrespective of whether they are good programmers or mediocre ones). The theoretical speed of development and speed of enhancement (read: potential cost saving) as well as the trendiness (let’s face it) of Rails has inspired a legion of business visionaries to increase their demand for Rails programmers in order to get their own facebook-meets-amazon mind bender to market faster than the other guy.

Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 - $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours]

The Visual Basic effect … A corollary to the fact that “pretenders” are besieging the market is that Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases. Like Visual Basic in the mid/early 1990s, Rails allows non-computer scientists to put together seemingly impressive applications. However, as a project progresses or application matures the truth becomes clear: (1) Rails helps bad coders write unscalable, unmentionable code faster, ergo (2) Rails helps organizations fail faster.

No Swiss Army Knife … Ruby on Rails was developed to do one thing and one thing well: help teams write web applications with user interfaces that perform basic operations on relational databases. Period. If you have complex processing needs such as message queuing, quantitative optimization, etc you’ll need to either (a) look somewhere else (b) write it into the framework (not likely as the shepherd of the framework are zealots and opinionated about protecting it from “unintended uses”) or (c) find a way to integrate with other technologies which support your business requirements.

No Throat to Choke and a Chasm to Cross … If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you’ve got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice. There are no/very few established vendors backing Rails at this point either from an implementation or education standpoint. This makes adoption of the technology and its ability to cross the technology chasm questionable. Rails is still early on the S-curve. It may make inroads into enterprise application environments the way Linux did through techie revolutionaries. However, for it to truly become a technology that is well understood, well-supported, and, consequently, well entrenched, it will need the backing of a behemoth or two. Perhaps RoR will gain the support of IBM or an equivalent, but the backing of a programming framework — at least on the surface — seems a heck of lot more pock-marked with landmines (variability in installations) than supporting and advancing the kernel of an operating system that has been in existence for decades.

The Java Defense … Perhaps the biggest reason to not choose Rails is, well, Java. The “old guard” Javaists are adapting. They may not be benefiting from the “hoola hoop” craze that is all things Ruby. However, they’re not taking the RoR attack lying down. In fact, in a very Zen-like fashion, they are borrowing from the “one thing well” manifesto of RoR to develop equivalents including Groovy on Grails, Trails, and the like (We’ll write about some quantitative benefits of these developments which we’ve seen first-hand in upcoming posts; suffice it to say, Groovy/Grails is proving itself to be a formidable challenger). In enterprise-friendly terms this means companies will be able to “maximize and enhance their existing Java technology investments.” And, with Java you get the Swiss army knife.

– ALTERthought

Tags: Grails