Written By:Aaron Lewing
July 22, 2016
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:
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.
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.
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.
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.
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.
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.
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?
Check back for additional posts about how things go as we get the application up and running!