A Guide to selecting the most appropriate web language for your organization In Part I of this series, we looked at the importance of investing some time into selecting a programming language for your organization and the types of questions that should be discussed with your group throughout the process. In Part II, we paint a fairly typical scenario of an organization in which the decision to rally behind one programming language has been made but the question of which language remains unanswered.
We start by listing the more popular Web programming languages today and work from there. The list is presented in alphabetical order and in no way represents a preference for one over another.
Note
The following table and brief explanations of “popular languages today” is a subset of the possible languages to use when writing web apps and to an extent, desktop apps. The list was carefully selected and excludes such languages as C/C++, Perl, Erlang, and Clojure/Lisp. This article assumes that if your organization is in consideration of language other than the nine languages that follow, its needs are outside of the scope of this article.
Language Use Programming Style Runs on Year/Age Frameworks
ASP.NET Web, server side scripting Object oriented CLR 2002/12 ASP.NET MVC, Spring.NET ColdFusion Web, server side scripting Imperative/Procedural with support for Object oriented JVM, CLR 1995/19 CF Wheels, ColdBox, FuseBox, Mach-II, ModelGlue, some others Groovy General purpose, client and server side scripting Object Oriented, functional, and imperative JVM 2007/7 Grails Java General use; Desktop, Web, Client/Server Object oriented and imperative JVM 1995/19 Spring (specifically MVC), JSF, Struts, GWT, Tapestry, many more Node.js (JavaScript) Client/Server, Web, Real-time applications, scripting Object oriented, imperative, and functional Node.js / Google V8 Engine 2009/5 Express, Geddy, some others PHP Web, server side scripting Object oriented, functional, procedural, and imperative PHP Interpreter 1995/19 Laravel, Phalcon, Symphony2, CodeIgnitor, many more Python General purpose, scripting, Web , Desktop Object oriented, functional, procedural, and imperative Various compilers, VMs, and interpreters 1991/23 DJango, Grok, some others Ruby General purpose, Web Object oriented, functional, and imperative Various Ruby interpreters 1995/19 Rails Scala General purpose Functional, object oriented JVM 2003/11 Lift, Slinky, Sweet, some others
Now that we have narrowed the field of options from seemingly hundreds to nine likely candidates, let’s review a realistic scenario for which an analytical selection can be made.
Scenario
You are the division Director of Information Technology for a medium sized government agency. This scenario applies equally as well for non-profits. The agency’s core mission is not building software but the division is an integral, and therefore critical part of the providing daily services required by the agency. The software developed in-house is roughly 80% internal facing and 20% external facing. The internal community consists of 1,500 employees who use the custom software as part of their daily job duties whereas the external community comprises the entire world, yet more realistically about 20 million potential users. The developer pool is made up of about thirty programmers spread over six units/teams. The majority of programmers are familiar with Java, a small minority knows or understands the functional paradigm of programming, and everyone understands procedural/imperative as well as object oriented programming. Most internal applications are written in ColdFusion and all external applications have been developed in Java. Developer ages range from 18 to 55 but more than half are over 40.
You’re tasked with recommending to the Chief Technology Officer, a software development strategy that will 1) ease the recruitment of talented programmers by bringing the agency up to date with modern software development methods and by appealing to the up and coming programmer workforce, 2), reduce the agency’s technology fragmentation across each team and make assigning resources to inter-departmental projects easier 3) work within the existing network and server architecture with little or no modification, 4) take advantage of the existing agency talent to the largest extent possible, and 5) continue to meet or exceed the wide range of internal and external needs, from desktop applications to web portals, without impacting project deadlines and budgets.
Recommended Language and Framework
Groovy on Grails is our ultimate choice for the organization. Here’s how one might come to this conclusion.
Java
Java appears to be a natural fit. Given that there are already a number of applications running Java and ColdFusion, we know that some of the server infrastructure is already set up to deploy applications on a JVM. After all, ColdFusion is written in Java and runs on Tomcat. We also know that most programmers in the organization know or are familiar with Java so it would be a lighter lift if we choose Java outright. Not having to train both programmer and system administrators also helps tip the scales toward Java. Following these arguments, it’s easy to lean toward one of the four languages that run natively on the JVM: ColdFusion, Java, Groovy, or Scala.
Python, PHP, and ColdFusion
We can objectively rule out Python and PHP based on the aforementioned arguments but both are perfectly acceptable language options when examined without the considerations of the scenario. Python in particular has garnered the attention and respect of web developers in recent years due to its robustness as a language. Not only does it work well with frameworks for web applications, it can also be run as a scripting language on a variety of platforms, extending its usefulness as a tool for programmers. PHP and ColdFusion are effectively limited to the web world. Factoring in the need for web and non-web application development, languages that can be used on and off the web exhibit a more desirable quality.
.NET
ASP.NET can be ruled out based on the organization’s existing programming knowledgebase and on the existing support infrastructure. The .NET family of languages requires a Windows environment and while end users’ computers are mostly Windows, the servers are not. Introducing a new Windows infrastructure along with a new software infrastructure introduces additional technical and human resources costs. A switch to Windows-based development can be determined, for this scenario, time and cost prohibitive.
Node.js
Node.js isn’t as easily ruled out but when lined up with the remaining choices, one can start to chip away at it as the best option for the organization. For one, it’s very new and the available libraries are not as plentiful as the long established players like Java. For another, Node apps are developed in JavaScript and JavaScript applications require a very particular style of programming. The applications process data asynchronously and rely heavily on closures, callback functions, and use a prototyping method of objection-oriented design. Those concepts can be a lot for some programmers to wrap their heads around and unless there is a compelling reason to overhaul the organization’s approach to designing software, it’s probably best to appeal to the widest skills market possible.
A Closer Look at Ruby, Scala, Java, and Groovy
Ruby, Scala, Java, and Groovy are all great contenders for the needs of this organization.
A Focus on Spring
If we select Java, the most robust framework is Spring. Spring is the most prolific Java framework series because it offers developers more than just a framework for web. There are eighteen projects that comprise Spring. They’re maintained by Pivotal Software, the same company that maintains Groovy and Grails. The framework has been so successful that it’s currently being ported to Scala as a project aptly named, Spring Scala. It operates as an IoC container, i.e., a dependency injection framework and follows the Front Controller pattern for which every resource request is first handed to Spring, pre-processed and subsequently handed off to a part of the application configured to handle that request. The exact same pattern is implemented in Groovy on Grails and in Ruby on Rails.
Due in no small part to the offerings of the Spring framework, we can rule out Ruby on Rails and Scala. Rails was an incredibly successful pioneer in the convention over configuration approach to development. Fortunately, the successes of Ruby on Rails lead to the creation of Groovy on Grails (and later, Scala) which follows the same principle but is Java-based. Most native Java code is also syntactically correct Groovy code, making the transition for a Java programmer very straight forward and much faster than learning a wildly new syntax. The Grails framework is in fact the Spring framework applied as a convention over configuration. Everything Spring offers is directly available in a Groovy on Grails application with no special integration necessary.
The out-of-the-box availability of both Java and Spring within a Groovy on Grails app, makes it an excellent fit given our scenario above. Spring was designed as a fast and flexible way to develop Java web apps. Groovy was inspired by Ruby and to address the short comings of Java. And finally, Grails is to Groovy what Rails is to Ruby. The end result is the best of all worlds while minimizing the disruptions caused by transitioning to a unified language platform across the organization.
Analysis
The scenario might read as an oddly specific set of circumstances. However, its goal is to represent the more general scenario of recognizing a need to have a consistent software development strategy; a strategy that harnesses an organization’s existing resources yet doesn’t alienate the future workforce it will need to recruit and come to rely on.
General-use vs. Nuanced Language Constructs
The fictitious organization above is far better served by selecting a general purpose language without getting into the nuances of each language’s constructs.
Each of the nine languages and their corresponding frameworks provide value to building out software. Some are faster for development (e.g., ColdFusion), some are more scalable (e.g., Scala), and still others offer very fast execution speeds (e.g., Node.js).
General-use languages like Java and Python, by their very nature, aren’t necessarily designed to solve a single problem exceptionally well. They appeal to a wider audience and allow for a variety of approaches to software design. General-use languages are excellent choices for organizations that need this sort of flexibility.
On the other hand Twitter for all intents and purposes has a single product – Twitter. Twitter’s font-end was once written in Ruby on Rails and their tweet storage written in Scala. In time Twitter moved away from Ruby on Rails in favor of Java and moved away from MySQL in favor of Lucene only to notice a 3x reduction in latency. Unlike the organization in the scenario, companies with a near singular focus – like Twitter – have the luxury of selecting a language based on very specific and pre-defined requirements.
Patterns and Frameworks
The organization in our scenario should focus on languages with several very popular frameworks that implement today’s proven patterns. Look for frameworks that provide structure to an application and encourage sensible design strategies without getting in the way of the developer. Convention over configuration is one way today’s frameworks offer a competitive edge and nearly all language-communities today have such an option.
It’s often helpful to understand the motivations for a language’s creation when deciding if it’s a language worth considering. Languages appeal to programmers for a variety of reasons. Possibly the largest factor is the speed and simplicity in which a program can be written.
Patterns of development help keep programmers focused on the business problem by laying out a proven method of attacking problems. Such patterns manifest in the form of frameworks. The Rails framework for Ruby was a pioneer in modern approaches to web development. The success of Ruby on Rails has been recognized and repeated in other frameworks. The Rails framework uses the Active Record pattern for example. This pattern greatly simplifies the pathway from the physical data model to the logical data model by coupling them directly through domain objects. This flies in the face of traditional patterns like the Transfer Object Pattern that stress a decoupling of models. Both patterns accomplish the same goal but with different layers of abstraction. Even the abstraction community giant, Java, has adopted this realization in various libraries like JOOQ and QueryDSL. Abstraction was once seen as beautiful, scalable, neatly organized code. However, abstraction and today’s need for rapid application development (RAD) have a seemingly perfect indirect relationship; not ideal. As the RAD approach to software development continues to grow in popularity, languages and frameworks need to adapt and keep up or be left behind in favor the new kids on the block. In short, change in software development is unavoidable; accept it and use it to your advantage.
Successful frameworks within and across languages copy the best parts of each other. Java inspired Scala, Ruby on Rails inspired the creation of Groovy on Grails. Rails also inspired the CF Wheels framework. When patterns work well, they’re incorporated into software design and when software is designed with standard patterns, there is a direct correlation with maintainability and in-house portability.
Language Ownership
Since the organization will have to build a large breadth of application types, it’s likely to require a wide range of libraries. It is highly recommended to select a language with a large and organized community driven code repository.
When the community is empowered to have a direct influence on a technology, be it a language or a framework, the technology has a much higher likelihood of long-term sustainability. Open source solutions have this inherently built right in but a project doesn’t necessarily have to be open source to be successful. Java for instance, while now open source, continues to rely on a Java Community Process for bettering itself. It brings together many perspectives and through diversity, creates a product developers want to use. The Apache Software Foundation is similar in this respect and its projects are all open source.
To once again use ColdFusion as an example, it’s not open source and community requests are sometimes implemented poorly or not fast enough to keep pace with competitors. This may be due in part to the road it’s taken through corporate acquisitions when Allaire was sold to Macromedia and Macromedia was sold to Adobe. At one time, ColdFusion was a singular focus of a company. Now, ColdFusion is just another product in a massive corporate portfolio (though, perhaps the same can be said of Java and Oracle).
Java has a massive library offering and it’s organized through a series of Maven repositories. Node.js, while still new on the scene, has the NPM library offerings. Most languages have something similar but not all. ColdFusion does not have any such organized library manager.
The Human Factor
It’s not always possible and practical to select a language for a project or for an entire organization based purely on market and textbook research. Doing so misses something very important: the human element. In part I of this article, I placed a notable emphasis on the programmers. Their existing skills, aspirations, and opinions matter just as much as any analytic findings. Programming is an equal mix of art and science. If a programmer is unhappy with his or her tools, the product and ultimately the organization, will suffer.