Where are we going – the back end

When trying to decide what stack to use, inevitably there will be two main differentiated technologies right off the bat – opinionated and unopinionated frameworks. Generally speaking, the difference is “do I want to be super frustrated later on, or right from the beginning?”.

Opinionated Frameworks

A good way to start when you don’t have much experience  and you don’t want to make many decisions is with an opinionated framework. They provide a much lower barrier to entry. You generally don’t have to know how to do things until you realize something is not working the way you want it to. A little “ignorance is bliss” can pay off in terms of spending time building something someone can see instead of working out tooling. The pain comes when you want to replace a piece of the opinionated framework with something else – all of the sudden you need to become a super expert and pull back all the curtains.

Which opinionated framework?

Are you making a single page application (you never refresh the page, UI elements show up and disappear smoothly) where most of the functionality is in the UI?

Are you making a multi page application with all its “back button actually works”, “wait while it refreshes” goodness?

  • Are you making a “traditional” application where you just want to get data from here and put it over there in a table?
  • Are you working on something fundamentally rooted in science or mathematics?

Unopinionated Frameworks

This is where everything goes all to hell. The definitions of “unopinionated” and “framework” both begin to break down. I’m going to use “framework” to refer to everything, even though that may be unfair, just because I don’t have a better word. Various technologies fall on different places of both the spectrum of opinions and their modularity – whether they consider themselves a library or a framework or a module or whatever. By the time you’ve read enough to feel like you’ve got a good grasp on the landscape, a new major version of FrameworkJS has been released and FrameworkJS version old is really falling out of favor.

I’m already decided on both PostgreSQL and Angular JS, I’m thinking it’d be most useful to try and sew together some unopinionated pieces. This will also provide me some insight into the strengths and weaknesses that emerge when compared to what I usually work with – Ruby on Rails. The available web frameworks are typically pretty heavily tied to a particular language.


NodeJS is *so* popular right now. It seems everyone is now convinced that the only difference between front-end developers and back-end developers what what language they use… This has given rise to a huge number of technologies to support the fad. I have to say, I love this video (don’t watch if you’re delicate and infatuated with Node). If going down the NodeJS route, I would be seriously tempted to get TypeScript set up and go that route.

  • ExpressJS – minimalist and unopinionated, a very thin wrapper over Node, just enough to make it a “web framework”. The lightweight nature is appealing, as there is very little “magic” happening, but the lack of structure and community developed best practices is a bit intimating – they take “unopinionated” seriously! The Sinatra of the JavaScript world. It’s easy to get lost while adding all the things that come in a more structured framework. It has a generator, but my personal experience is that it’s not really used as much as other frameworks.
  • Sails – ExpressJS + opinions = Sails. Session management and ORM choices etc. let the developer stop worrying about the absolute basics and get on with the other aspects of your application development. The Ruby on Rails of the JavaScript world. I haven’t used Sails, but it looks interesting enough that I’ll investigate it a bit.
  • Koa – strikes me as very similar to ExpressJS but it trades new features for stability. At this moment its in the awkward middle phase between version 1 and version 2. This means I’ll be giving it a bit of time to settle before I look into it too closely. If I were looking had at Express I’d definitely take a look at Koa to see which I felt I liked more.
  • Hapi – a bit more of an industrial Node based framework. It’s backed by WalmartLabs, so presumably has a bit of staying power, but I must say I’ve never looked at the Walmart website and said anything other than “this kind of sucks”. On the surface, it looks like it may be a better choice for teams or more REST based servers.
  • A million other ones, everyone is jumping on this bandwagon.


  • ASP.NET – My impression is that this is pretty hugely popular, particularly in the enterprise space. A long history, a stable and performant technology, and an abundance of tooling supported by big names all yield a pretty solid choice. I’ve barely written any C# and I’ve never used ASP.NET, so I don’t have much to say about it personally. It seems like a good choice if you’re in the Microsoft ecosystem, or if you’re coming from one of the various C dialects.


  • Spring – very enterprise oriented, in the same neighborhood as ASP.NET. I used it a little bit a few years back and became a little bit overwhelmed by it. The options to use XML configuration or annotations are handy if you understand them, but they’re confusing to start out with as there are generally two ways to do every task. Anything annotation driven leans very heavily on the tooling to be able to navigate and refactor appropriately, so I definitely wouldn’t want to write a Spring application without a fully featured IDE. Not my first choice for personal projects, but a definitely a strong contender for larger efforts.


  • Play Framework – could be used with Java, but definitely comes across as intended for Scala (even more so with Play 2). I think my number one biggest issue with it is the terrible Google-ability of “Play”. I tried doing a sample app when it was still quite new, and spent most of my time being enraged as I got irrelevant search results. Looking around now, information discovery seems to be much better, so I might give it another try. It generally doesn’t look like it has much buy in from big companies. Lots of people play with it (excuse the pun), but I don’t see a lot of people keeping it around. The 2.3 – 2.4 upgrade debacle seems to have cut a lot of teams loose.


  • CppCMS – I wasn’t even aware this existed until writing this. For whatever reason, C++ is not typically associated with web development. Definitely not my first choice on popularity alone, although I’m sure it punches above its weight. Based on virtually nothing at all, I’d guess it’s similar to the Play Framework – lots right about it, but little traction.


  •  Flask – I don’t often use Python, so I’m really not too well informed about the Python ecosystem. Flask appears to be active and popular, and if I were already strong in Python I would likely consider it in the same realm as Express for JavaScript and Sinatra for Node. Lightweight, low barrier to entry, freedom to shoot yourself in the foot at scale type of offering.


  • Sinatra – I’ve used Sinatra for a handful of things, always small projects though. Very lightweight, very approachable syntax, a bit shocking in the terseness. If you don’t need the ORM-ness and asset pipeline of Rails, it would make for an interesting pros and cons list deciding between the two. Definitely a solid choice for getting simple endpoints up and running.


I don’t use or like PHP, I’m not really interested in looking up too much about the available technologies, so here are some Google results:

  • Symfony – Googling around shows that it is generally peaked and is being surpassed by Laravel
  • Laravel – appears to be the new darling of the PHP web development world


This is by no means a complete list, but hopefully it’s a decent overview of some of the top offerings as they stand right now.

What to use?

So what am *I* going to use right now as I get moving with this project? I’m not sure what all the fuss is about in the NodeJS world, so I’d like to take a stab at a JavaScript framework. NOT because I think its the best technology, or has any particular advantages, but because the whole world is blowing up with NodeJS love right now and I want to be able to have informed discussions as to why. If I had any plans on scaling or longevity, I would be looking elsewhere – a technology built on a statically typed language for sure, but as this is more an exercise than a deliverable I’m looking to learn. With that in mind, I’m going to try Express and see where that gets me. Hopefully it shouldn’t be too hard to abandon if I immediately regret everything about it. Additionally, I’d like to try and use TypeScript instead of vanilla JavaScript, so I’ll take a look at how possible that is.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s