Rarely does a day go by, that I do not receive an article in my email or among the many RSS feeds I monitor, that compares various Internet software development tools and frameworks. Inevitability, the comments following the comparison turn into a war of words between the two camps compared. Each believes its framework or tool is the best. What strikes me is that rarely are the project requirements included in the discussion. It always seems to be based on the concept that there is one right framework for everything, and I cannot disagree with that more. Over my thirteen years of developing Internet applications I’ve used Perl, PHP, ASP, Javascript, XML, XSL, and Java (using JSPs, Servlets, Struts, WebWork). Now I’m learning and writing a applications with Ruby on Rails. Though Java has been my focus for the last nine years, I recently changed the title I prefer to use. No longer do I refer to myself as a Java Developer/Architect. Instead, I identify myself as being in the industry of Internet Software Development and Design. While the difference in the terms may seem insignificant, it is actually quite substantial.

There was a time when I believed Java was the only language anyone should use to write Internet software, but eventually I realized you can’t make that claim for any development framework. They all have their pros and they all have their cons. I don’t pick what is latest and greatest, because the latest is never guaranteed to be the greatest. Neither do I ignore the latest in defense of what I currently feel comfortable with. I do choose what fits my personality, what I enjoy working with, and what is best for the project at hand, including the ability to meet very tight deadlines. The key is: matching the language and the framework to the project. Many factors contribute to this selection. Here are some situations and the frameworks I generally use for each.

Static web sites with limited dynamic functionality
This category consists of an individual’s web site or a small business web site that is mostly static, except for a page or two with some functionality, such as a contact page, a location finder, etc. All that is needed is a simple form that writes into a database or emails a recipient. It would be foolish to roll out the Java framework and tell the owner of the site they need to pay for hosting that provides a JVM for such a simple application. Similarly, it would be overkill to build a Ruby on Rails application for such limited functionality. In these cases I sometimes recommend a simple PHP or a Ruby script. Almost all hosts support PHP and Ruby now, so there would be no need to relocate hosting or pay a higher fee for more services.

Another solution I have begun to use and recommend more frequently in this category is WordPress. While starting out as blog software, it really has developed into a very easy to use, yet robust Content Management System. I recently used the software to create a prototype for a web site I plan to write in Rails. By using WordPress, I was able to get the site up and running and begin gathering user feedback in much less time. I now have a better idea of how I want to design the final site. WordPress can be used to create prototypes, static web sites, and can even contain, without much work, many types of dynamic pages. Adding custom forms to gather information from users, for example, is very easy with certain plugins.

A third solution I’ve used for this type of project is to create the page using Ajax, pulling data from a static XML or even a database. An example would be the sermon listing for this church. There is no use of PHP or any other framework on the site. Just a quick use of Ajax and a flat XML file which the pastor updates each week with the latest sermon information. It was quick, effective, and most of all, inexpensive for the church.

Mid-tier dynamic and custom applications
In the middle of the application spectrum are applications with dynamic functionality, such as the many Web 2.0 service web sites like Remember the Milk, Freshbooks, Basecamp, etc. I think this level of application makes up the majority of web sites on the Internet that are dynamic. In this category I recommend Ruby on Rails. It performs well, and takes far less time to get to market, which is usually very crucial for this segment of applications. Though a somewhat new technology, it has very quickly been put to use by many sites and thus is very well tested. It’s proven, its solid, and it is a brilliant solution for this category of web sites and applications. It’s not without a learning curve (and what framework is), but the curve is enjoyable and intuitive.

Sadly, many are rejecting it without even taking a real look at it, simply because it’s not “enterprise”. But that rejection, I believe, is not based on facts, but instead on fears and misconceptions. I’ll discuss more on Rails in future articles, but for now, know that this is my recommendation for this category of project.

Enterprise” class applications
On the final end of the spectrum is what is termed the “enterprise” class of applications. I would say these make up a much smaller segment of the online applications than most developers realize or are willing to admit. It is not so small a segment that it is insignificant, and while small in percentage, they are usually very crucial applications for their respective companies and within their industries. In fact, this segment probably employs the greatest percentage of developers with the largest IT budgets. They have important requirements that must be met, have less room for failure and more severe consequences, and must be very sound to meet high performance needs. For the last 10 years, this has been where 90% of my development work has been and I’ve enjoyed much of it.

For this level of application, I fully endorse Java. I think without question it performs the best at this level, but, with some qualifications.

I do not believe that all, or even most, corporate applications or web sites fall into this category. Just because you are commercial or corporate does not make your application an “enterprise” application. Many of the corporate applications I have developed over the years could have been written in Rails or Ajax (or something similar) because their feature set, usage and performance requirements are such that Java was complete overkill, as was the $50k spent on developer training in Java, UML, etc. The twenty developers hired to code the year long application using EJBs and the “latest and greatest” was totally driven by IT magazines and online sites claiming companies just had to use Java for corporate development. The same application could have been written in Rails with 1/3rd the team, 1/10th cost, and 1/4 the time. I think that some companies, IT departments and developers feel the need to call their applications enterprise in order to get a larger budget, and to pad their resumes. Also perhaps due to the idea that if everyone else is using a certain framework it must be the best.

The question to ask instead is will it make you more valuable to your company? Why not meet your requirements with the lowest time to market and lowest cost possible? Isn’t the goal to make money, not spend it needlessly? Isn’t it better in the long run for you as a developer, designer, or architect, to impress your employer with how little time it took you to meet the requirements, how little money was spent, and how easy it will be to maintain in the future? I think that makes you a greater asset to your company than being able to spout complicated pattern names and use such complex diagrams that no one can understand them (not even the rest of the development team).
My current project is an enterprise level ESB, which currently processes millions of transactions a day. I would never, ever have suggested this ESB be done in Rails. It would be foolish to do so. By the same token, it would have been foolish to use any MVC framework, because we have no need for 99% of the functionality they provide. And this is what irritates me about this segment of applications: 80% of the functionality added to these Java applications is for 20% of these situations.

But even in the situation of this ESB, we did not use Java 100%. The decision was made before I came on board to purchase and use IBM’s WebSphere DataPower, an SOA hardware appliance. Had I been asked, I would have pushed back on the decision…but I would have been wrong. It’s an excellent piece of hardware and helps unload from Java some functionality it doesn’t do as well as the hardware device can. I’ll go into more detail on the benefits of DataPower in a future article, but its an excellent example of finding the right tool for the right job.
Even if Java is the best solution for the business logic layer, such as an ESB, that does not mean there is no place for the other solutions at this level.

An example of where I would recommend usage of Rails at a corporation would be to build administrative gui’s for maintaining user profiles, viewing reports, etc. These types of projects are perfect for a quick development framework like Rails even with the Enterprise. Internal applications like HR apps, project management, time logging, etc, are all excellent candidates for a Ruby on Rails solution.
In other cases I would recommend a fully AJAX front end which consumes the already now existing services of the ESB. I love separating the front-end (which can now be HTML, CSS, and AJAX) from the back-end (a sound ESB, receiving and sending XML, using Java and/or DataPower, which performs data validation, enforces business rules, and then persists the data into the right Enterprise data storage). The combination of these technologies, such as Rails, AJAX, and Java can make for decreased development time and as a group of tools, conquer any project’s requirements.

The point to all this is that you must use the right tool for the right job. Think of each solution as a different tool in a toolbox. If you were asked what one tool you would use to build something with, answering “hammer” would sound quite foolish. Instead, having a selection of tools that fit the current challenge is the best recipe for success. Don’t dismiss PHP, Rails, Ajax, or Java, but do dismiss building more than you need, overusing technology, and building an enterprise class application when you don’t need one.

You can choose to be a Java Developer and not an Internet Software Developer, but if you do, at least acknowledge the fact, and don’t bash other tools that might be a better fit for certain situations simply because you choose to restrict your toolbox to only one or two tools.