This could be a risky post for me to make. At the end of it, I could come off as an old man that simply doesn’t want to learn new tricks, and thus, my future job prospects might decrease. However, in terms of software development I believe I truly am entering the league of old men. (I’m approaching 40 and have been programming since I was a kid, so I’m ~400 years old in Internet time.) Whether or not that makes me more or less relevant, is up to the reader.
This post describes my opinion as to the best platform for new web application projects. And while “best” is nebulous, I mean it with some of the following goals in mind:
- quick to develop with, yet robust
- does not place arbitrary restrictions on application capabilities
- does not hold things back when needing to scale
- maintainable over time, by one or many programmers
- has decent community and future outlook
- supports building all kinds of cool things
Before I continue, let me be clear about something. The best platform choice (out of a selection of good platforms) is usually going to be the platform for which you and/or your team have the most experience. That fact alone trumps almost every benefit I’ll describe below in my choices and often tends to get lost in the “my platform is better than yours” discussions. Most of the good platforms can be used to build most any web system that can be imagined. This post answers the question, “If ignoring existing experience and time-to-learn, what would be the best platform?”.
I have been fortunate as a mostly independent software developer in that I’ve been able to work with a number of companies and technology platforms. When I build my own web application projects though, these are the major components that I would chose: (as of January 2015):
- Java 8+
- Sprint Boot
- Spring Framework 4+
- Spring MVC
- Spring Data/JPA
- Spring Security
- Embedded Tomcat 8
- JPA2 with Hibernate 4+
- Maven 3+
- Freemarker (if backend html/xml generation is necessary)
- Jackson (for JSON in/out on a Restful API)
- Spring WebSockets (if async is required)
- BootStrap or Foundation (or for mobile hybrid, Ionic Framework)
- AngularJS (still debating this choice because I find AngularJS very problematic)
- Gulp, Bower
- JRebel for hot reloading
- Vagrant for development environment services
- Deployment and Hosting
- Amazon Web Services, with configuration via OpsWorks or CloudFormation
- Or possibly with Docker via new EC2 Container Service
- For server provisioning, still undecided, but probably Chef or Ansible.
For anyone sharing my way of thinking, be sure to check out the jHipster project. It combines all of this and more with a yeoman generator.
On the backend, I have not made the choice to go with a strongly typed Java based platform lightly. A list of good mainstream platforms I’ve considered include:
- Python (with Flask, etc.)
The astericks indicate platforms for which I have real world experience on production systems. I am not going to list out of what I do and don’t like about each platform. There are entire books worth of forum posts and opinions written about the various merits. All of these platforms can be, and have been, used to create anything from small personal websites to enterprise class systems (even PHP).
Pros and Cons of Dynamic Languages on the Backend
Greater productivity at the beginning is why so many people like the newer platforms, such as RoR, and there is something valid to be said about that. However, when it comes to evolution over time and maintenance, dynamic languages start looking not so great.
Although controversial, I also question if productivity is greater in dynamic languages for non-beginners. My reasoning is that when doing software development, the majority of the time is not spent writing code. It’s thinking through problems, devising and testing solutions, and refactoring. A dynamic language might make the code more succinct, but in the end, I wonder if that is worth the trade-offs. An example trade-off is the very powerful automatic refactoring capabilities that are possible with a typed language like Java. While some refactoring is possible with dynamic languages and IDE capabilities are growing, the majority of refactoring when using dynamic languages often comes down to having a very good text search & replace tool with decent regular expression support.
Java has a bad (and maybe deserved) reputation for being overly verbose. Again though, I know for myself the majority of my time is not spent in writing code. Rather, it’s doing all the things around writing code. I think it’s also interesting that the C/C++ language usage is steady, if not on the rise, in many polls/indexes, and C/C++ makes Java’s verbosity look like Cliff Notes. There are (almost) always trade-offs.
Negating some benefits of the dynamic platforms
Some of the benefits of more dynamic platforms are negated when modern Java development options. For example:
- JRebel – Removes need to restart after every change. This is a huge productivity booster and I wouldn’t want to do large app Java development without it. There are alternatives to JRebel (many much less expensive), but JRebel is still the best AFAIK.
- Alternatives Languages on JVM – Although I don’t have personal experience in this, some leading developers that I respect seem to highly recommend using Scala. Other options include Jython, JRuby, Groovy, and Clojure. As long as the alternative language allows calling in to existing Java libraries, then I can see this being beneficial when there’s a benefit to using one language over another for a certain problem domain. That said, I sort-of agree with Lawrence Kesterlot’s post “Java for Everything?“.
As far as getting a backend project bootstrapped, I find Maven makes it very easy, especially when combined with Spring Boot. And projects like jHipster can bootstrap a whole stack in minutes.
This post is just a collection of random thoughts around my own baseline. I started the post back in 2013 (two years ago) and kept it as a draft because it never seemed worth publishing. I’m not sure it is worth much even now, but decided to get it out of my drafts folder. It only required a few updates to bring it up-to-date.
I find that being a more experienced modern programmer requires walking a fine line between using what works reliably, and constantly seeking out ways of doing things ever better.