He Chose Poorly…
Some of you may remember the title of this post as the famous last words in the epic Indiana Jones and the Last Crusade. The wise, aged Crusader dead-panned this line right after the evil villain crumbled to dust after drinking from the wrong grail. This post is about Grails, and that scene came to mind when I was writing it.
Turn back the clock four weeks. The president of our company decided we needed to add a new sales channel to our system, and we had to do it quickly to stay competitive. The deadline was set before we even saw the requirements and we just needed to “back in to it.” Ignore for a minute how insane this sounds. My larger concern was the impact to our system. My predecessors designed the entire application around two sales channels. Worse, it was handled via an infinite number of ‘if’ statements along the lines of if not (channel A) assume (channel B). We had just been asked to add Channel C.
Based on the compressed timelime, it would have taken us the entire schedule just to go through the code and unwind the “A or B” logic, nevermind actually adding the new functionality. So based on the narrow set of requirements, we decided to build a whole new application on the side. It was to be an 8-10 page website with a big form, web service calls, database access and some AJAX. Our currently application is a Java/Struts/Hibernate webapp deployed to Tomcat, so I wanted to stay in that comfort zone, but I saw this as a chance to test out something new.
The obvious choice for us was to try Grails. The five developers working on the project were all senior, with 5+ years of experience pounding Java code. We toyed with using Rails, but I didn’t want to introduce too dramatic a technology shift. We figured the project was going to take the team of five about three weeks to get to a testable state. Allowing for some ramp-up, that worked out to around 500 hours of effort for the team.
The team was excited about Grails from the get-go. Most of us had run through the basic tutorials, and were enticed by the prospect of increased productivity. We’re coming up on the end of our development this week, so I discussed our choice to use Grails with the whole team, and factored in my own impressions.
The general consensus of the team, now that they had used Grails in the real world, is that it really wasn’t worth it. Most would use it again, but the real-world productivity increase was more an illusion. The boost Grails gives is setting a clean project structure. Once it comes time to pound real code, that head start evaporates quickly.
One of the biggest gripes is poor tooling support. My team used a combination of Eclipse and STS. To a person, they all said the tools were very weak in helping them out when things went sideways in Grails. We ended up spending extra time trying to debug issues that would have been caught quicker in straight Java.
The dynamic nature of Grails is both a blessing and a curse. It can tighten up the code, but can lead to some difficult-to-troubleshoot errors. My favorite error was when someone used contraints {} instead of constraint {} in a domain class. That stopped us dead for half a day until someone finally noticed the error which the compiler was more than happy to digest.
The one part of Grails everyone appreciated was the web tier with GSPs. That piece works extremely well and really does make life easier. But one of my guys commented that we could pretty much get the same thing using FreeMarker with Spring MVC.
From a management perspective, I was disappointed with how quickly the productivity with Grails plateaus. I’m satisfied we completed the project on time, but I can’t credit it to Grails so much as our drive to limit scope and maintain focus. I believe we could have also reached the finish line using a straight Java/Spring/JPA stack and it would have been easier to work with.
For me, Grails fits in to the “conceptually cool” bucket. For “lone genius” coding, it can probably be very productive. But if I were doing the lone genius thing, I would just use Rails instead of Grails. The spot Grails is trying to fill is the “I want Rails but can’t” space. It is a way of introducing almost-Rails into an enterprise already using Java. Unfortunately, in a team development situation, I didn’t see almost-Rails buy us anything.
The one unintended side-effect of this project was that it piqued my interest in Spring Roo. I wasn’t convinced it was useful, but I’m thinking I could see the same quick start of Grails while keeping the project closer to the known quantity of Java. I’m going to have the team attempt to port this project to Roo when things calm down just to get a more educated impression of it.
If Grails floats your boat, more power to you. A lot of work has gone in to it by a lot of very smart people, and I won’t knock that. Dedication like that keeps the programming field interesting. But in the same way I don’t see a use for JRuby, I don’t see me using Grails again. If you’re good with Java, I would recommend continuing to master your tool over chasing the holy grail. We know how that can end up.
Thoughts on Node
I’ve been watching NodeJS for a while now. I thought that I wanted to get into Ruby on Rails for personal projects, since it is a cleaner version of the OO paradigm I’m used to with Java. But I’ve also been doing a lot of client-side JavaScript, using both JQuery UI and ExtJS.
After several false starts, Rails was just not sticking. It’s not the fault of either the language or framework, both of which are exceptional. It’s more a case of the whole “OO MVC” web stack is just feeling old. So I decided to update my Node and NPM installs and take a look at web development through a different lens.
Node stuck. I haven’t had this much fun coding in a long time. Node feels like what Java felt like in the JDK 1.1.x days. It has a lean API and begs to do anything you can throw at it. And like early Java, it is moving at the speed of light. The number of new projects popping up on GitHub around NodeJS is staggering.
Since I’m playing with web stuff, I’ve mostly been looking at the Express stack. It’s a lot like Sinatra for Ruby, but with JavaScript syntax instead of Ruby. It’s also very quick to code with. I’m using NodeJS and Express with Redis, and it’s a blast. I’m working on a sample project using JQuery Mobile just to get the hang of it.
The biggest surprise with NodeJS is how quickly the ecosystem is growing. GitHub and NodeJS projects were made for each other. You can now host Node applications on Heroku and Cloud Foundry. The package management system (NPM) is tight and easy to learn. The biggest shock was that Microsoft is even getting on board with helping to port NodeJS to Windows.
JavaScript is now the place to be playing and NodeJS really does make it possible to do it end to end. I’m having a lot of fun digging in to it, and we’ll see where it carries me.
The Kings
A decade ago, these were the technology kings. They drove developer and internet mindshare.
- Microsoft
- Yahoo
- Sun
- AOL
- MySpace
Today, the new kings are:
- Apple
- Amazon
It’s amazing how much can change in a decade. How many of today’s kings will have the legs to still be exciting us ten years from now?
Looping Out
Yes, I confess, I follow @DHH on Twitter. He can be rather opinionated, but he has an interesting point of view on things. Plus, it is a good way to keep up on the thinking behind Ruby on Rails. Just this evening he put a shot across the bow of JQuery with this tweet:
Since JavaScript library performance is something that interests me, I took a look at the benchmark he linked to. It is a pretty straightforward test of JQuery’s each() method compared to a custom function called quickEach(). On my MBP, the results look like this:
First, kudos to jamespadolsey for coming up with this. The speed difference is pretty shocking. But even more interesting, the test harness is extensible, so I decided to see how the latest Ext-Core stacks up.
First, I had to tweak the setup code a bit. It was creating a JQuery object which wrapped an array:
var a = $('<div/>').append(Array(100).join('<a></a>')).find('a');
I kept it simple and turned this in to:
var a = $('<div/>').append(Array(100).join('<a></a>')).find('a'); var b = a.toArray();
This gave me a real JavaScript array to work with. Then, I added a new test case which looked this:
Ext.each(b, function(item) { Ext.get(item); // Ext.Element });
Running the jsPerf test with this snippet gave these results:
My first reaction to this was along the lines of WTF! My faithful Ext-Core was getting its ass handed to it by JQuery. But then I spotted the error in my ways. Using Ext.get() is very expensive for operations where you plan on discarding the Ext.Element afterwards. It adds an id to the DOM element, then puts the wrapped DOM element into a cache to speed up subsequent operations. For cases like this, where we’re going to throw the Ext.Element away, the Ext.fly() method is what should be used.
Here are the results using Ext.fly() instead:
Now we’re talking! Using Ext.fly() gave some pretty good results, although there are probably some ideas to be borrowed from the hand-rolled JQuery quickEach() method.
Not being satisfied with a contrived example which was just discarding the wrapped DOM element, I then tweaked the test. I changed each of the test cases to add a class to the wrapped element inside the loops. For giggles, I added two additional tests. One using JQuery’s addClass() method against the set of elements, and one doing the same thing using Ext.select().
Here are the results:
Suddenly that speed difference in the first test cases starts to look a lot less significant when it actually comes time to do something in the loop. Adding the class to the DOM node wrapped in an Ext.Element using Ext-Core turns the first results upside-down.
Even more interesting was JQuery’s performance using addClass() on the JQuery element and not using the each iterator. It looks like JQuery is soundly implemented for set operations. So the lesson is treat JQuery more like SQL than code — if you’re trying to do each(), you might be thinking about the problem wrong.
I won’t even attempt to address the whole “beauty” angle. I’ve learned from the ExtJS-JQuery flame wars that beauty is definitely in the eye of the beholder. And if you want to dork with this yourselves, my playground is Revision 15.
Sencha Touch Initialization
I’ve finally had the chance to dig in to Sencha Touch. I was really impressed with the framework from what I saw at SenchaCon last year, but I had been too busy with regular web development to get very far with it. That all changed now that I’m working on a mobile website for work.
Sencha Touch is very well documented, and has a boatload of examples. Unfortunately, some of the examples don’t necessarily promote best practices. The first place I ran in to problems was on setting up an Application.
If you look at the documentation and the examples, there are three ways to initialize a new Touch application:
Ext.setup({...})Ext.ApplicationManager.registerApplication({...})new Ext.Application({...})
Most all the examples use the first method, including the more complicated GeoCongress app. Unfortunately, this isn’t the best method for real-world applications. It is designed for quickly setting up a Viewport and rendering a container. Yes, some of the more complicated samples use this technique, but doing so costs you a lot of the free stuff that come with using one of the other two approaches.
The second approach is used in the Kiva and Twitter examples. The end result will do the same as option #1, except you’ll have an Ext.Application object to work with. Ext.Application is one of those secret sauce objects that take care of a lot of the common setup tasks for you. When you initialize an Ext.Application, the object automatically creates a set of namespaces for your views, stores, models and controllers, prefixed by the application name. It also provides support for a load mask and sets up an Ext.History object for the application. Finally, it integrates with the Ext.Dispatcher object for handling custom routing of requests and registers the application with the ApplicationManager.
The third approach is nearly exactly the same as the second option, except you are directly instantiating an Ext.Application versus delegating to the Ext.ApplicationManager to create that application. This means that the Application will not be registered with the ApplicationManager. In practical terms, this really doesn’t matter. The Ext.ApplicationManager permits you to register multiple logical applications for a single physical Sencha Touch site, which is not something I see as being necessary.
While trying to sort this all out the first time through, I put out a query on Twitter to see what others thought. I was pretty much between options #1 and #2, but the awesome James Pierce (@jamespierce) from the Sencha team chimed in and recommended option #3 as the best going-forward approach.