Two developers. One problem. Well, one big problem, but we all know web application development is a collection of problems to solve. For the purposes of this post, we will consolidate our list of problems into one: how do you choose a language to build your web application?

Two developers, we know Java, Rails, Grails, PHP. We have some varied interests, and we know enough about other languages to ask ourselves should we choose one of them to build our next application. Do you pick something you know and experiment with new features or releases or do you go for something totally new and make something familiar in a new way?

We thought it would be fun to think about this problem in a series of blog posts, and maybe we can prove some assumptions correct and look very wise…or we might find we are wrong and look foolish and then we can begin questioning other things we think we know. This could get uncomfortable. Embarrassing. Uncomfortably embarrassing.

What are we going to build exactly?

We don’t have to think about supporting many users, but we will be doing some text processing and presenting data to users for additional editing. We will ingest some documents, index them to build some dictionaries, then we will present all this data back to users and have them modify it a bit and repeat. Does it sound fun? I think so.

We have some assumptions.

We will assume that our web application is operating system agnostic, we haven’t made a decision about where will host the application yet. Chances are the servers we will deploy to will be Linux, but we will not make that a firm determination until we evaluate all the application languages. Having said that, we will make a decision to use a relational database, particularly, MySQL. Why? Because this is a look at languages and frameworks, and anything we will consider is going to have a MySQL connector.I mentioned we will be indexing some documents and building dictionaries, so that means Lucene/Solr for our app. Solr offers an interface we can access with a number of languages, so we are able to consider a few options.

So, which languages?

We are going to consider the following languages and frameworks:

Ruby/Rails
Java/Spring
Groovy/Grails
Javascript/Node
PHP
C#/.net
Python/Django
We know this is not a comprehensive list, but it offers us a decent spectrum of technologies to consider. We have some experience supporting clients who had made decisions to use some of these technologies, but since this is an internal application, we don’t have to go with whatever a client has already chosen or a preference from a CIO.

Ruby/Rails

Convention over configuration. We’ve all heard it. Spend time doing fun stuff, use Rails and never know pain, etc. Rails uses Ruby and that means the programming language is not very verbose. You don’t have to write a lot of code to get a lot of features. This is rapid development for people who know what they want, and if those people also hate spending a day configuring a framework to do something useful, then Rails is a good choice.

If you have invested heavily in an infrastructure like Java or .net, adding Rails development can be a challenge since the Ruby language is structurally very different from Java or C#. Developers may feel uncomfortable and development could suffer as competency and mastery of Ruby is achieved.

Java/Spring

You already know the language and Spring framework. You have IT infrastructure already hosting Java apps. You like verbosity of code. Java is a very popular language, so developers and resources are abundant. Are you doing Android development as well? If so, your development team already knows the language.

If you don’t already have Java web apps, then learning Java and Spring can be a lot of heavy lifting for a simple web application. Spring can be complex for beginners and a lot of effort will be spent preparing the framework to do something as simple as a Hello, World example. If you don’t know Java or C#, the verbosity can bog you down while learning and other frameworks provide similar benefits with much less code written. Performance can be an issue depending on efficiency of the code.

Groovy/Grails

Rapid development. Grails uses Groovy, and Groovy is a more terse language than Java, but one Java developers will feel comfortable using. Grails actually uses Spring MVC under the hood, but it is abstracted in such a way that a developer does not need to spend a lot of time configuring it. So, writing Java-like code but less of it. It offers something akin to Rails…convention over configuration.

Not as mature a platform as Java, but it also will ruin Java developers when they realize that they don’t have to write all that code.

Javascript/Node

You know Javascript, and you want a way to write only Javascript. Congrats. There are a lot of packages written by the Node community and those are feature rich.

Javascript as implemented in Node is not going to handle heavy duty workloads like Java or Ruby. Node package management can create a lot of headaches when you suffer from unsatisfied dependencies…reference the node package that was removed and broke nearly every website.

PHP

You are new to web development? You know HTML and want to access more features in a familiar context. Many more free or cheap web hosting options for PHP applications. It is easy to learn and that matters to people who want a result fast.

Not a lot of frameworks to leverage. It is not useful for CPU intensive operations. It does not fit into the current design trend for single page applications. Limited usefulness outside of web application development. There is a strong bias against by some developers who feel the language implementation is either inconsistent or incomplete. No closures for anything older than version 5.3 for example.

C#/.net

You are a Microsoft Windows infrastructure. You want the power of a language like Java but a more modern implementation which means happy Windows developers. The Common Language Runtime is akin to Java’s Virtual Machine.

It is not supported on multiple platforms. If you need to port to an infrastructure that is not Windows based, you are stuck. (although this will change as C# spreads to linux, but come on, not an option now). Three words: VENDOR LOCK IN. The Common Language Runtime is akin to Java’s Virtual Machine.

Python/Django

Rapid Development. You want to program in Python. You want a lot of features out of the box similar to Rails. It has a lot of packages available for developers to use.

Complaints about it not evolving quickly. It is “too monolithic”, an architecture decision made to make things simple can make developers crazy when they have a performance problem to address.

So, what are we going to do?

We discussed our options and we decided on Ruby on Rails. It is something we know, so we can get a prototype working pretty quickly. The truth is, we could have probably been just as happy with Groovy and Grails, but this is where our preferences play a role. We don’t want to spend a lot of time configuring the framework, so that eliminated Java. We are not in a position to tie ourselves to a Microsoft platform, so there is no reason to select C#/.net. Python/Django fails the comparison to Rails and Grails test in terms of bang for the buck. This left us PHP and Javascript/Node, both are not built to handle intensive server side operations like what we will require, so that is that. A different project at a different time, we could go another way, but this works for us now.
Check back for additional posts about how things go as we get the application up and running!