Languages, frameworks, and tools, oh my!
A lot has changed since I spent time building websites. Figuring out where to start is slightly overwhelming. Around ever corner there is a decision: less or sass? grunt or gulp? django or rails? handlebars vs mustache vs angular? Without too many restrictions it’s easy to get lost in the sea of choice. So here are my criteria for choosing the technology for this project:
- Handles front and back end
- APIs are first-class citizens
- Connects with multiple kinds of databases
- Uses a sane front-end templating system
- Able to automate deployment
Language
Most people usually pick a language before picking a framework to use. That’s not how I am going to do things. I’m currently working in my 4th programming language, so adding another one is not a big deal. At this point the biggest hurdles for me end up being tooling and conventions rather than language syntax. Of course the tooling significantly differs depending on language.
Tooling is the main reason I’m not doing any of this in Swift. It’s far too new, and doesn’t have enough established conventions separate from the iOS and OS X world. Maybe in 5 years it’ll be viable, but right now it’s not ready for this project. I also have similar thoughts about Go, so that’s also not on the list.
Based on what I know about the common web world, the most popular languages are (in no particular order): PHP, Ruby, Java, Javascript, Python, and C#. Even though I work for a large enterprise, I don’t want to spend my free time working in enterprise software land, which rules out Java and C#. I also moved on from PHP many years ago and don’t really want to go back. So that leaves me with: Ruby, Python, and Javascript.
My biggest irk with all of these is that none are strongly typed. My second biggest irk is connecting them to a debugger is difficult. To someone used to no debuggers or types, that might not sound like a big deal, but debugging is a lot easier with types and runtime introspection. Basically half of my debugging skills are simply not applicable in a loosely typed world. This is going to be all rainbows and butterflies.
Frameworks
These are all popular and (mostly) modern web languages with a plethora of tools and frameworks available to use. In these three languages there are a number of frameworks to choose from. These tend to fall into two camps: opinionated but contains everything and micro but pluggable/extendable.
Do-it-all frameworks
These are the frameworks most likely to become a monolith: Rails, Djano, and Sails.js. These all come with the kit-and-caboodle ready to go, including command line helpers. I’m a huge fan of automation, so having those commands is a big time saver.
Rails is a framework I’ve worked with off and on for several years, mostly as smaller projects. It’s currently my go-to for prototyping or as a stand-in for a real service. With Rails 5 creating an api-only site is much easier. The best part about Rails is that I am already familiar with it, even though some things have changed in Rails 4 and 5 that I need to catch up on. For some reason the asset pipeline just never stuck. Rails does hit all my bullet points, and is able to plug and play with many kinds of databases and front end languages. Rails 5 has done good work at cutting down on dependencies, but there are still a lot. The biggest draw back is that sometimes Rails is too opinionated and magical. I’d like to be a little closer to the metal this time around.
Django has been around for a while and is one of the most popular Python framework. Like Rails, it has command line generators for a number of different kinds of things, middlewear to connect to a number of different databases, and a whole lot of plugins. I’m particularly fond of the django-admin plugin that is just so much better than anything I’ve used with Rails. It took me less than 2 hours to get through the intro tutorial, including over a half hour trying to figure out why my code wasn’t working when it was the same as the tutorials. Stray whitespace and the loose types are not my friends.
Sails.js is a Javascript framework heavily based on Rails. The CLI is well developed and there are sensible defaults for the conventions. Unfortunately, there is no Sails.js introduction tutorial that walks through all of the basics on the official Sails.js site. I spent an hour trying to mimic the Django tutorial I did (which was fantastic) but ended up not getting very far. In addition to a lack of a good tutorial, when I had no items for a query, Sails returned a 404 instead of an empty collection. Needless to say I was not impressed.
Microframeworks
Each language that I’m considering has a microframework that’s more popular than all the others. Ruby has Sinatra, Python has Flask, and Node has Express.js. All of these on their own don’t really provide enough of a baseline for me to get started. I want more than a simple server that can respond to requests, and while a lot of middlewear exists, there’s still a lack of conventions to follow. I don’t want to completely reinvent the wheel. Fortunately others have run across this problem so I don’t need to build my own solution. Enter Padrino and Hapi.js.
Padrino is a Ruby framework based on Sinatra. It’s very much a plug-and-play system where you can add or not add modules as you choose. It does have a CLI for quickly creating new kinds of files, and it sticks with the common MVC paradigm for organization. After a little bit of playing, this definitely lacks the heft of Rails while providing a lot of the niceties. And here we have the first actual contender!
Hapi is one of the few popular Node.js frameworks that doesn’t depend on Express.js. It has a fairly small core with a lot of plugins. And the authenticaiton/authorization model is the best I’ve seen so far. It doesn’t provide an ORM out of the box, but integrates well with Sequelize which does have a CLI for me to work with. Even though it is Javascript, I think I can make this work.
Next up: creating the basic site skeleton in Pandrino and Hapi (yes there will be code!)