Why Trails is better than Rails

I haven't used much of the new "Rails"type development kits yet. However, if I have to choose amongst them, I would be choosing Trails. The main problem with Grails (and Rails) is you are adding a new language to the mix. If all you have are highly skilled developers and not planning to do Global Resourcing then that's all cool. However, if you are building an application with a lot of use cases, its best to rely on as little changes to the development environment as possible. It is better to move your top developers off to new customers rather than repeating drudgery with each use case (you get cheaper GR resources for that). The problems with Ruby on Rails ... I've seen presentations and demonstrations of Rails and for the most part it is a great sell for those who are keen enough to learn new tools. Having a smaller LoC metric is good and all, but just because you can reduce something into a single line does not imply that it is generally readable.

I've done many shell and Perl one liners when I need to get things done but it does not mean I would really want to subject anyone to what I've written.

Although I would be sold and would probably use Rails if I needed to get something out quickly and don't expect people to manage what I write. That hasn't happened for a while, most of the applications I tend to build is part of a large team and not a solo flight. It may change sooner than later because they have relatively good Ruby IDE support now. What critical things haven't I seen with RoR (and why they are important).

• XA transaction support. I need to be a bit more specific with this one, as most people think that XA only involves databases. XA can support different resource types such as message queues and enterprise connectors. For the most part, in order to communicate with some legacy systems, a JMS type system may be needed. The message transport tends to be part of a larger transaction which may involve database activity as well.
• Attribute oriented web page development (like Tapestry). The only way that I have seen HTML customization done in the demonstrations I've seen are through RHTML. RHTML is basically HTML with Ruby code (shades of model-1 JSPs and old ASP pages). RHTML, JSP, ASP or ASP.Net pages are usually not viewable by the browser. I alluded to when I talked about my ideal web project. Although I hear there is an add-on for this.
• I18n support. Being in Canada we have two official languages English and French. So if you have to develop applications for the government or companies that deal with Quebec, you bet i18n support is important. Although I hear there is an add on for this too.
• Single sign-on. This is more the JAAS thing. If you've been in the industry long enough, you would have heard "How many times must we do the logon use case?" quite often. Although I have an extenstion to that which is "How many times must we do the user management use case?" Personally having to do that again isn't my idea of fun, and I'd rather delegate that to a product like Tivoli Identity Manager which I just get someone to customize the screens and leave all the backend user management stuff to the product. If you have a large enough project, you would probably save more money buying the product rather than waiting for it to be reimplemented again for your application.
• Database migration. From what I saw with Rails, updates to the database tables are done manually by the Ruby developer. This would be quite a chore if there is a large number of table updates that need to be done. Hibernate provides Java developers with "schema-update" which generates the SQL needed to migrate existing database tables as needed (though you should still get your DBA to review it).

So with the exception of Tapestry and Hibernate, the JEE environment already provides us with the necessary infrastructure out of the box. One key thing that Rails has over Java language solutions is the on the hot code change support. That may ween a lot of people over, myself included. But, I like to have as much of the infrastructure done for me when I do work and I would like to delegate work out to experts as needed. Much ado about Grails ... So far my experience with Grails has been limited to just some well done screencasts. However, most of it was quite a bore (not because of the presenter, he did a really good job), but because it looks the same just replace Rails with Grails and Ruby with Groovy. So as far as innovation goes it does not really help much. As I was perusing through the screencasts, I found some things that I didn't really like:

• Batch file/ant based application generation. After using Maven for a while, I haven't found a better way of structuring your source files than they did. It may be overkill, but at least it works well (with the exception of web content). An older version of Trails did this as well, thankfully they outgrew that and moved to Maven.
• Groovy Server Pages (GSP) It looks a lot like JSP files, which I would avoid because it cannot be sent back to the web development team once the Java guys put in all their tags and what not.
• Groovy Yet another programming language.
• Batch file to create new domain object. Rather than just creating a new class.
• Ant based build targets. Rather than leveraging more standard targets we have a new set of targets to deal with. This could easily be fixed by moving the development to Maven.
• I have to enter the domain class twice? Not sure why.

Like Rails, Grails support the on the hot code change support. Since Grails runs on top of a JEE stack, that may ween a lot more people over, myself included. However, it is not without its warts which I have listed above. So why Trails? Trails, although it is still in its infancy, is better geared for application development with a larger team and multiple roles (i.e., web developer, application developer) and can more easily leverage existing skills of Java developers. Here are the things that Trails has it going for:

• Maven integration. This means dependency management, builds and project layouts are more consistent. You also get the standard site reports as you need without having to deal with a lot of low level Ant.
• A smaller code base. Because it seems to delegate a lot of its work to other opensource packages like Tapestry and Spring rather than reinventing the wheel.
• Tapestry. So we can utilize web developers with their Dreamweaver or whatever other tool more effectively rather than forcing them to use a JSP editor which may not offer them enough artistic flexibility.
• Hibernate. So we get "schema-update"
• JEE based. So we get i18n and XA out of the box rather than an afterthought.

However, ... Trails is far from perfect Trails is the only one I have worked with the longest among the three so I do have some issues with it.

• Not too many users. I think a good indication of this is the activity on the Trails IRC channel. I am usually the only one there when I go on.
• Their web site does not render correctly in Internet Explorer. I normally use Firefox, but there are still a number of people that are using Internet Explorer. Having their side navigation going all the way down to the bottom of the page does not look very professional.
• No update on their website since September 7, 2006
• They use Maven, but their website seems to be hand coded HTML. Rather than using something like a Mavenized report. Yes it may look more plain, but at least it is consistent. It took me a bit to figure out what the subversion URL is.
• No hot code replace. Not really possible you need to regenerate and compile every time as well. This would make things go slower and slower as your application grows.
• Seems to be only one maintainer right now. Since I started Trails again, which is just a few weeks ago, it seems that only one person is actually maintaining the framework now.
• Still in SNAPSHOT. There is no 1.0 release of Trails yet. Right now all I've been working on is the SNAPSHOT version. Although the SNAPSHOT seems stable enough. They should make a roadmap they can say it is ready and people can plan to use it.
• An updated presentation. Trails used to have a 12 minute presentation that shows a many to many relationship. Someone needs to update this presentation. Maybe I'll do that myself if I have to present Trails to my peers.