What’s In a Name

We’re no strangers to frameworks. We were using a front controller driven framework back in 2000, complete with database mappings to tie pages to their drivers and layouts. Of course the mappings were stored in the application scope for quick retrieval. This framework served us well for many years.

Eventually our business needs changed and we created what we felt was an even better framework, similar to our old one, but without all of the hard wiring. That, too, worked great for a while. We still use it today for most of our projects.

As public frameworks become more popular, or at least, more common, we eventually asked the question “should we switch to a community supported framework?”. The most compelling reasons to switch would be:

1. Offload development, support, and testing resources. Someone else is doing the work of fixing issues and developing new features.
2. Easier to find developers who were already familiar with the framework when hiring new employees.
3. Marquee value.

But do these reasons fit our business requirements?

Offload Development Resources

It sounds great to be able to get back some of that time spent on maintaining the framework. But how much time do we really spend on maintaining it? We never actually quantified that before. Looking back, it’s easy to say “not that much”. Our framework was targeted to our business. It was lean. We had added new features to it gradually over time, but these were usually features we needed for the project at hand. Moving to a new framework means that we would probably spend more time than we did before with evaluating and integrating new releases. Sure, you don’t need to take every new release, but the farther behind you fall, the harder it is to update when you finally do need to. It also meant that we would either have to wait for new features, or find some way to integrate them ourselves, hopefully by extending the community framework and not actually having to modify it. Finding ways to incorporate changes via extension often takes longer than if you can just make them natively. And then there is the risk that the framework implements a similar feature, but in a totally different way.

Ready Trained Developers

The idea of hiring employees that are already trained sounds great, if you find yourself constantly turning over employees, or if you need to staff up quickly for a bunch of “churn and burn” projects that you really expect no longevity out of. We do neither. Our attrition rate is basically zero, and on the rare occasion where we do decide to expand our team, it’s for the long haul. Community frameworks may come with lots of fancy documentation, but they usually come with additional features that we don’t need. As I already mentioned, our framework is lean, and it is targeted to our needs, so the ramp up time needed to learn to use it effectively is very small.

Marquee Value

Marquee value? Seriously? We can just as easily give our framework a name and boast to a potential client that we are using “such and such” framework, and here are the benefits it provides. The important thing is that you *are* using a framework. And to be honest, we did give it a name.

Another consideration is the fact that we primarily develop web applications, not websites. I understand that a framework should be able to serve both, but there is something a little more comforting about having full control over what changes are made to this fundamental layer. Especially when other businesses have put such absolute trust in us to service their needs.

Taking the Plunge

We looked at several of the major frameworks, and analyses that people had performed comparing one to the other. We had already come to the revelation years ago that convention suited our needs better than configuration, which helped narrow the list down to a few key contenders.

After careful consideration, we decided to go with ColdBox. It had all of the features we were looking for, and an impressive amount of documentation. There was also something very appealing about the polish of the website itself. It had a great number of features that we didn’t need, but that didn’t seem to be an issue at the time.

Initial development with ColdBox went well, but we quickly recognized that we were going to need a thin “helper” layer on top of the framework to encapsulate some of the common functionality that we would need with each new application. That was a relatively easy task, and it helped set in motion what seemed to be a new and improved work flow.

Things weren’t perfect, though. An occasional scan of the debugging output kept pointing back to the fact that this framework was doing way more than we needed it to do on each request. The template list showed a total count of 519 calls with an execution time of around 65 ms. A similar page in our custom framework would have produced around 40 calls and been around 20 ms. That’s not really comparing apples to apples, though, as this was a different application.

FW/1 showed up on the radar a few months back, and I really liked what I saw. Here was a lean, mean, conventions based framework that did little more than handle the nitty gritty of processing requests. We were going to have a “helper” layer on top of whatever framework we used, so this seemed like the perfect fit.

In a bit of a skunk works project, I set up a sandbox to see what it would take to convert our ColdBox application over to FW/1. Within about 30 minutes I was able to get the basic application initialization and home page loading, with a little bit of abstraction. The results were even better than I was hoping for. The home page loaded with only 11 template calls, and 3 ms of processing time. Wow. Again, this wasn’t a fair comparison because there were a few features that I had stripped out to get the sandbox app running. But it was enough to convince me that the change would be worthwhile.

I sat down late Friday evening, with a fridge full of caffeine and the mindset that I was going to do the entire conversion in one night, no matter how long it took. And I did.

The entire conversion took about 4 hours. I’m not usually one for cutting corners, and one of the major objectives of this conversion was to improve the efficiency of the system, so I tried to minimize how many abstractions I added to make FW/1 more “ColdBoxy”. I also took the opportunity during this time to clean up a few aspects of the helper layer.

After I started browsing around the newly converted app, I discovered a problem. There is no limit to how deep you can nest controllers and views in ColdBox. In addition to the normal “user.edit” actions, we have a few areas of the app that extended into actions like “admin.user.edit”. Either I wasn’t fully comprehending how FW/1 works, or nesting actions deeper than “section.item” isn’t supported.

This was pretty much a deal breaker. I certainly didn’t want to go back and refactor our application to only have one level of nesting, and I didn’t want that to be a design limit for future applications. I didn’t see any easy way to extend the functionality of FW/1 in this regard, without replacing a couple of the key functions, which would basically defeat the whole purpose of using the framework.

Long story short (too late, I know), the final solution was to take what we had learned from several years of using our own custom framework, along with the new experiences of developing under ColdBox and FW/1, and create our own new custom framework.

Revelations

So was it worth all of this just to save a few milliseconds per page request? Well, if that had been the goal, then I would say “no, not really”. But the goal was much bigger than that. We build web applications. That is what we do. It’s why we come to work in the morning, and it’s why we get paid. The framework that our applications sit on is one of our primary development tools. Your choice of framework is almost as important as your choice of language. The support it provides for your particular business, and the direction it allows you to go with future applications, is critical to your success.

The fact that our new framework loads the same 519 template, 65 ms page with 98 templates and 20 ms isn’t too bad of a side effect either.