Our Future Stack, or Why we love Knockout, Coffeescript, Redis and Go.

Posted

We built the first version of Teamwork.com back in 2007 using Adobe ColdFusion. ColdFusion has been great for us, thanks to the speed of development it provided, we were able to get features implemented faster than our competitors and we truly believe it is one of the reasons why we’ve been successful.

That said, ColdFusion was never very popular with developers, possibly because it was expensive and owned by Adobe. In fact many developers who used free and open development stacks such as LAMP often held ColdFusion in disdain (there was even a time when Dan and I came close to a brawl defending ColdFusion’s honor but that’s another story). But it has served us incredibly well over the years.

However, here we are in 2014 and we feel that ColdFusion is no longer the lady she used to be; development has slowed, the community has shrunk and her market share has eroded. It seems that everybody is jumping ship to newer, more hip languages.

Some months ago we finally decided that it’s also time for us to leap overboard and to make some big decisions about our development stack for the next 5 years…

Big Decisions

We want to build the World’s best business software. We want to ensure that Teamwork.com is the best SAAS project management product in terms of user-interface, speed, robustness and usefulness. We also want to use tools that allow us to move much faster than our competitors. We want the end result to be in every sense, as beautiful as it can be.

Choosing the right development stack for our company is obviously a very important technical decision, but it’s also a critical business decision: we need to choose a stack that will allow us to find staff easily and to outperform the competition.

Some of the key considerations for our languages, tools and libraries include:

  • They must be Popular and Growing (ie. Going to be relevant/widely-used in 5 years).
    Using popular languages, tools and libraries makes finding expert new staff much easier. It also allows our staff to get stuff done quickly by finding solutions to common problems in the community. It’s also essential that there are plenty of resources and documentation on the internet to help us speed along with development.
    > Side note: Making the wrong choices can cause problems in the future. For example there was a point in time when we choose “Prototype.js” over “JQuery”. We felt Prototype.js was technically better and went with that. Captain Hindsight eventually informed us that it was the wrong choice – JQuery has eclipsed Prototype.js and we eventually ended up reverting to JQuery with a lot of extra work.

  • Fast to develop in.
    We want to outperform our competition is terms of speed of development and quality of features.

  • Easy to maintain.
    We want to choose the languages and libraries that would allow us to keep the code simple and easy to maintain by any developer, even somebody new to the team.

  • Perfect for single page web apps.
    Web-based software is moving towards single-page applications where javascript is used to switch views and datasets instantly when the user clicks a button or link. The actions are performed on the server side through API calls. We need separate languages and tools that are perfect for the client side or server side.

  • The full team can get behind it.
    Software can be developed faster if all our developers are using the same programming languages, tools and libraries because we can learn from each other and easily get help when stuck. We can also concentrate on becoming experts on this one stack.

Our New Stack

We’ve invested hundreds of hours of research, thought, debate and testing into choosing the right languages, frameworks and tools for Teamwork.com’s next five years. There are hundreds of articles debating which framework or library to use so I’m not going into the pros and cons too much here; instead I’m simply stating that, rightly or wrongly, at this moment, this is the stack that we have chosen and we think it rocks:

Client side

Knockout.js as our MV* framework

We’ve been using knockout.js for over a year now and we love it. We did investigate every other MV* Framework thanks to todomvc.com which enabled us to see good examples of each framework in action.

We decided that most frameworks had way too much boilerplate and are slow to develop in. Knockout.js is a get-stuff-done framework, fast, powerful, easy to work with and to understand.

The one missing piece fell into place when Knockout 3.2 came out and added components. With this amazing feature, we feel using knockout.js is the best way to develop and maintain single-page applications.

Kudos to Steve Sanderson for his great work.

Coffeescript instead of Javascript

When 5 of your developers keep telling you that we should be using coffeescript, you have to listen. I committed to trying it for a month. After 3 frustrating weeks I finally got used to it and by week 4 was in love. The guys are right, it saves a tonne of time and we are going to try to use it for all future work

Adam, one of our most valued engineers, wrote a great post about Coffeescript at Teamwork recently.

Gulp.js, Slush, Less.js & Node.js

I know Adam will get upset if I don’t mention that we are also using using Gulp, Slush, Less.js and Node.js. These tools allow us to compile our coffeescript into javascript and create merged, minified css files for our website. We’ve also recently started using Less.js for generating our css files.

Server Side

MySQL for storage

We’re sticking with what works here. MySQL is something we know and love and have become pretty handy with. It works great and we’re not jumping ship on this one anytime soon.

Redis for caching

We used to use Memcached as our go-to in-memory caching layer. However we’ve been blown away by the feature set of Redis. It does so much more such as allowing us to maintain simple sorted lists in memory and to easily manage these lists. Perfect for storing items like task lists.

The Go language

This is the key decision for us because most of our work is done on the server side and is hard to change later.

“Go” is a language developed at and used by Google. Some reasons we love go include:

  • Fast Development – It doesn’t have as many features as other languages and it’s not perfect, instead it pragmatically focuses on helping us Get Stuff Done.
  • Cross platform – It can be run on linux, mac and pc.
  • No voodoo – There’s no voodoo going on under the hood. We can see and access the full code base so bizarre random problems like we used to have with the Java VM are a thing of the past.
  • Fast – It’s fast. Blazingly fast. Approaching speeds of C and likely to get faster in the future.
  • Smart – Performing background jobs is trivial.
  • Highly concurrent – It scales fantastically.
  • Low Memory – It uses very little memory (ColdFusion was a dog in this department) allowing us to use the on-server memory for other things like caching.
  • Robust – It’s robust in that it’s got built-in testing and enforces good programming style.
  • Great toolkit – It comes complete with code formatting and documentation generating tools.
  • Strong & clear docs – Documentation is a huge part of making software accessible and maintainable and the team behind Go provided us with excellent Go documentation and a tool called Godoc that makes providing excellent documentation to others trivial.
  • It’s fun! – We’ve been using Go for a few internal projects now and we think it’s elegant, fun and exciting.

We’re really happy with the choices we’ve made here. This new stack is already making a great impact at Teamwork.com (we’ve rewritten much of the Teamwork API to be much faster using Go) and we’re looking forward to making Teamwork much better all round.

We have huge plans for Teamwork.com and I’m genuinely really excited about the software we will be bringing you over the next few years with this stack.


ps. Love Knockout, Coffeescript, Redis and Go? We are hiring!