Grails weak points

Hi Dave,

We all know what Grails is good at, and what gap it is trying to fill. We can all read about the great features and what not, but... In your opinion what are the weak points of Grails? Where is Grails lacking, vulnerable or still a bit wobbly? Can you name say 3 points? And is anybody trying to strengthen these weak points in the (near) future?

Cheers,

Johan

Now this is a tough question. I can come up with three weak areas but two of them are based more on what I've heard from others than from my own experience.

The first one is a practical limit of one datasource for domain classes. There is a plugin that helps with this somewhat, but there are still limitations. I don't know if anyone is working to improve this other than the developer of the plugin in question.

Next, is the testing. This has improved significantly and I don't have any complaints about it but I've heard that Rails has better testing support baked into it, I know that there are several plugin developers working to improve the Grails testing story and they are coming up with some cool stuff.

Third, is the large stacktraces that you get with errors in Grails. They do get huge, but this doesn't really bother me (at least once I increased my console buffer size). This has also gotten better with some stacktrace sanitization in recent versions of Grails, but I still hear people complain about it.

There are other difficulties involved in using Grails, but nothing else comes to mind that could be pinned on Grails. There are just the inherent difficulties in web development. Grails alleviates many of these difficulties but not all... yet.

I hope that helps,
Dave

Dave Klein wrote:

Third, is the large stacktraces that you get with errors in Grails. They do get huge, but this doesn't really bother me (at least once I increased my console buffer size). This has also gotten better with some stacktrace sanitization in recent versions of Grails, but I still hear people complain about it.

Interesting and Informative. Thanks Dave!

I find this post interesting:
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
It looks Groovy/Grails consume a lot amount of memory.

John Todd wrote:I find this post interesting:
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
It looks Groovy/Grails consume a lot amount of memory.

They do. I'm not sure if I personally would consider this a weak point. Memory is cheap and throwing more at an app is a simple fix. Future versions of Groovy, I'm sure this can be improved along with the help of the JVM. It's always a trade off though. I feel more productive with Grails most of the time and if that means I need more RAM, so be it.

Addtion:-

1. Memory :- I do not believe this was expected. Double the size of war file <not a big issue> and amazing amount of heap space and objects it holds. Brought down my production tomcat (shared with other Spring web applications). I have generous amount of memory, processing power and heap size (tuned)

2. Legacy database support *** :- I do not want to use standard id based tables or simple String. I had to do a lot of coding to take care of Complex composite keys with foreign key relationships. Also I do not like the way you have to query other tables (not in the domain)

3. Plugins :- Need to be more mature. Some basic plugins like searchable, filter pane, export work for basic feature. Well - I don't think any user uses these basic features and then you need excessive customization to get these to work for tech savvy user. For eg. Ms Access can perform better searches and filters. I have identified some bugs (may be fixed in the newest release)

4. Documentation and more examples :- I know the basics but some plugins and strategies don't always work as given in the documentation. Need more complex examples and tutorials.

So this is arguable not a weak point. Most Grails users would consider this a strong point and feature of grails, but I find it to be somewhat of an anti-pattern. I don't like the fact that in a grails GSP I can write groovy code. So for example...



Note Book.list(). This goes against everything I learned while growing up with JSP and the EL. You now have the ability to call arbitrary methods on objects directly in the view. And I think this is a horrible thing to do. I suppose this could have also gone in the Grails best practices thread in that I'd say a best practice is to avoid scripts in GSP like the plague.

I'd also like to +1 on the issue of Grails not supporting multiple data sources. Most (if not all) non java web frameworks do support this and while I understand this isn't an easy task, I'd hope to see it by Grails 2.0.

Excellent points Gregg

Gregg,

I agree with your distaste for code in pages, JSP or GSP. That's one of the reasons I am so thrilled about GSP custom tags. They are so easy to create that there is never an excuse to put Groovy code directly in a GSP. For example the example you showed can be replaced with something like this:


Then in your GSP all you would have is this:

I know this is a contrived example but it does show just how easy it is to create a custom tag and keep code out of your pages.

It's also worth noting that you can add as many custom tags to that TagLib class as you want. Each one is just a named closure. And if you don't to use the g: for your tags you can add a namespace with a single line in your class:

then you would do this on the page:

You gotta love it!

Dave

I do love it. I just wish Grails was A) promoted with doing this as demos and examples and/or B) didn't allow the alternative poor design choice. My opinion of course.

Thats a good example and explanation Dave. Thanks.

I agree with both A & B more and more examples