the blog for developers

Comparing Helma and Grails

First let me congratulate the Helma team for their 1.6 release. Helma is an awesome piece of software with a long stable history. And the developers are friendly, innovative and clever. If you want server side Javascript, go for Helma. But I thought about how Helma does compare to other web application platforms? Especially to Grails, which I’ve been using for some time now.

I’ve written the first part of Reposita in both Helma and Grails to figure out what language and platform to use. It was a pleasant experience with both Helma and Grails. But there are differences in the platforms and it depends on what you want to do – as always – to choose the right tool.

Helma pros are:

- JavaScript on the server. This means only one language in your application
- Very fast, also on older hardware
- Skin support
- Change file, reload, view- cycle just works. Very productive
- Lean, clean feeling
- Notion of children, powerful and easy URL mapping. Children help you model applications faster, most applications need the concept of children in their domain model
- ApplicationServer, Manager, SQLshell applications when running your application
- On the fly API documentation creation during runtime (!)
- Powerful listRenderer and excellent Jala extension libraries
- Explicit root object
- Proof of success in several high traffic sites for years

There are also some cons for Helma:

- Different Javascript versions on client and server (1.5 and 1.6). The browser will always lack behind Rhino. This leads to programming problems because of the very similiar, but different languages (JS 1.5 vs JS 1.6 and beyond)
- Not enough documention, sometimes confusing documentation. There are far to few tutorials for Helma and the existing ones sometimes seem out of date
- Mapping and joins have only abstract examples, concrete examples (Book, Author,….) needed as everybody else does
- Features missing (Object querying, n:m mapping, perhaps reuse JPA). I know when you want to do many-to-many mappings you usually forgot to model an entity. But sometimes n:m is nice to have as a first hack
- Errors/Exceptions/Stack traces not descriptive enough. People seem to need a lot of inside knowledge to decipher stack traces
- Debugging hard, debugger didn’t work the way it should (also see above about stack traces)
- No clear class inheritance (the Javascript problem). That’s only an issue when you are used to OO inheritance . Often I don’t use OO inheritance but compositions, but in some situations it’s useful (infrastructure code mostly).
- Not as fast as Java

I’ve also done Reposita in Grails. The pros of Grails as perceived by me are:

- Grails packagable to WAR, Groovy compilable to .class. This makes Grails easy to integrate into existing applications
- Change file, reload, check – cycle very productive
- Things you need are there
- Little suprises
- Plugin architecture
- Very powerfull
- Enough existing documentation, some articles and tutorials. Excellent Grails book and Groovy book.
- Innovative and fast moving community

Some cons of Grails (hopefully they will be solved by 1.0):

- Stack traces too long. Sometimes the same applies as I said for Helma. Stack traces need inside knowledge to decipher, especially if the errors come from meta programming techniques in Grails
- Sometimes no exceptions are thrown, but the application does not work.
- Sometimes funny error messages (“list() not found”)
- Documentation feels like a patch work of texts. They should reorganize the documentation to be more coherent. See Hibernate for excellent documentation
- Community is moving too fast (Hey, wasn’t that a pro?). Concepts change very fast (from 0.3 to 0.4 to 0.5.6). It’s not clear what to use, some google finds show old solutions. Every sample should be tagged with the Grails version number. Some documentation is for 0.4 although things are different with 0.5.6
- Not as fast as Java

So which one is better? Which one will I use? Both are good, both are usable. I would prefer Helma if you already know Javascript or are a Javascript shop. Also for much better scalability, use Helma. It feels cleaner and there might be a white swan in the future, when Helma JS applications run the same code on the server and the client in the future. Otherwise if you’re a Java developer Grails might appeal more to you. Groovy is very similar to Java. There are more features in Grails and it’s moving faster. The community is bigger and Grails and Groovy might break into the Java mainstream. There are signs everywhere.

I’m not sure right now what to use (also because I have good access to Helma/Jala developers, one of them is a friend and lives here in Berlin :-)

Thanks for listening,

Peace
-stephan

You can leave a Reply here. Of course, you should follow me on twitter here.

You can share this post!
Do you want to tell others about this article? Use the social bookmark icons to submit this artice to the service of your choice. Thanks.

About the author: Stephan Schmidt has more than 15 years of internet technology experience and 10 years experience in agile. He was head of development, consultant and CTO and is a speaker, author and blog writer. He specializes in organizing and optimizing software development helping companies by increasing productivity with lean software development and agile methodologies. Want to know more? All views are only his own.
Leave a reply.

Comments

Have you seen whitebeam?
http://www.whitebeam.org/

or TrimJunction?
http://code.google.com/p/trimpath/wiki/TrimJunction

I’m currently looking for a server-side javascript solution.

stephan

I’ve tried TrimJunction but thought it wasn’t mature enough, the templating approach is nice though.

I didn’t know whitebeam, I’ll take a look. Thanks.

Peace
-stephan

stephan

The whitebeam site says:

“LATEST NEWS: 5 October 2005, Version 0.9.37 has made a number of significant changes including a new template specifically aimed at storage and retrieval of site-wide global data in a server farm environment.”

:-)

Whitebeam has been in continuous development, despite the lack of formal releases! There have been frequent CVS changes though.

We got our act together just before Christmas ‘07 and released 1.1.5.

The latest release has a license change (to BSD license) and includes the SpiderMonkey 1.5 release, which includes E4X (XML support as part of the JavaScript language)

It also includes other goodies like the ability to manipulate graphic images, framework support for building a chat-server, native PostgreSQL interface and a host of other things.

We’ve now integrated the latest (Oct ‘07) release of SpiderMonkey which is under CVS and we’ll be making a new release shortly including that along with improved PostgreSQL library support.

We also added an RPM release for Fedora to make life a little easier (although we’re a little new to RPMs and support will improve with experience or suitable volunteers!)

http://www.sourceforge.net/projects/whitebeam

Leave a Reply

What people wrote somewhere else:

Additional comments powered by BackType

Guide to CodeMonkeyism

Over the last 4 years I wrote many articles on this blog. To make it easier for you to find the relevant ones, I've organized them into topics.

Top 10

6 reasons why my VC funded startup did fail

Go Ahead: Next Generation Java Programming Style

Java Interview questions: Write a String Reverser

The dark side of NoSQL

7 Bad Signs not to Work for a Software Company or Startup

Is Java dead?

Scala vs. Clojure

Never, never, never use String in Java

No future for functional programming in 2008 – Scala, F# and Nu

Clojure vs Scala, Part 2

Java Developer

Is Java Dead?

Go Ahead: Next Generation Java Programming Style

Be careful with magical code

All variables in Java must be final

Never, never, never use String in Java

Bending Java: More readable code with methods that do nothing?

NoSQL Guy

NoSQL: The Dawn of Polyglot Persistence

The dark side of NoSQL

Essential storage tradeoff: Simple Reads vs. Simple Writes

Sharding destroys the goals of your relational database

The unholy legacy of databases

Startup/CTO

Development Dream Teams

6 reasons why my VC funded startup did fail

American vs. European style of Software Development

12 Things to Reduce Your Lead Time and Time to Market

The high cost of overhead when working in parallel

Essential storage tradeoff: Simple Reads vs. Simple Writes

Job Seeker

Another Good (Java) Interview Question

7 Bad Signs not to Work for a Software Company or Startup

Java Interview questions: Write a String Reverser (and use Recursion!)

Java Interview questions: Multiple Inheritance

As a Manager: What I value in developers

Top 10 Tips (+1) to Get a Pay Raise

Agilist

What Developers Need to Know About Agile

5 Practices Better to Change in Your Scrum Implementation

Scrum is not about engineering practices

ScrumMaster and ZenMaster: The joke of certification

What is Trans-Scrum?