TaskRabbit is Hiring!

We’re a tight-knit team that’s passionate about building a solution that helps people by maximizing their time, talent and skills. We are actively hiring for our Engineering and Design teams. Click To Learn more


On Tooling

@ 30 Apr 2015


We have all seen the posts, the livid conversation, the crusade to rid the world of jQuery (hyperbole for effect); in an age where JavaScript frameworks are popping up like daisies, we see much discussion of whether or not to use frameworks at all. In light of this I wanted to talk about some of the reasons that we at TaskRabbit chose to use the tools we did.


  • We choose to build an in-house framework despite the availability of many great open-source frameworks. We choose to do this given the experience of our team, the optimizations we prioritized, the requirements of our application, and the understanding of the cost tradeoffs of maintainability and implementation/learning.
  • Our choice to build with such a framework has led to many discoveries.
    • We are more engaged with our JavaScript architecture, and in learning various patterns from other frameworks.
    • It can suck when one of the main authors leaves.

Another framework

The world wide web is changing, technology is improving, and we are advancing towards a more unified JavaScript standard. Yet we still seem to harp on about jQuery. We have not found the gold standard of frontend frameworks. The sheer amount of JavaScript frameworks currently in use or in development seems a little crazy.

Given this ecosystem, I wanted to discuss our decision to contribute to the bloat in creating our own in-house framework.

I am of the opinion that all libraries are tools. Such tools are appropriate in a given situation. Need to cut an apple in half? I would choose a knife instead of a hammer. As developers, our decisions may not be as apparent as that example, but they share a common thread.

At TaskRabbit we have made the decision to build a single-page(ish) app. We made this decision given our requirements, and team. We decided to optimize for speed, the key metric being the perceived time to interaction. We had some very strong engineers who had already built frameworks that were fully featured, based on what our app needed. We decided the cognitive overhead required to learn a new system such as Ember or Angular was too great at the time. When we had the opportunity to switch, we chose to implement the framework that had a similar structure to our current implementation but would enable us to move toward using something like Ember.js if that time arose.

While we employ this toolset on our main client-facing web app, we build feature prototypes in jQuery and our admin site using standard Rails architecture. Different scopes, different toolsets. We leverage jQuery’s massive feature set and simple API, to build out tests quickly. We leverage standard Rails as it is super accessible to all of our developers no matter which side of the stack they have most experience in.

Here are some things to think about in order to make decisions:

  • What browsers do I have to support?
  • When must this project be delivered?
  • Given the current team structure/knowledge/experience which tool makes the most sense?
  • What are the requirements of the project? (page load times, usability, interaction, new technologies, etc)

Learnings from going in-house

It is really interesting when you tether yourself to an in-house framework. You can deliver more bugs, mostly edge-case bugs. Your framework has not had extensive use in the way that larger open source ones do. You do not have as many eyes on your code, so you are not benefiting from the stores of community knowledge. On the other side, your framework does everything you need it to. Probably without much bloat. You are closer to the code; you inherently know what it is doing, and where to look for a bug when one arises. As such the feedback loop is super small; once an issue is found, you can address it immediately.

One of the things that I have noticed at TaskRabbit is that the conversations around JavaScript are different. They have to be. We have to talk about best practices around architecture, we have to talk about the best way to time event firing, or how to construct a router. We are forced to have a deeper knowledge of the native capabilities of JavaScript. As an engineer I think it forces a higher level of code or, at least, engagement with our code. I am not saying that we are the best engineers. I am saying we ourselves become better than we otherwise might be.

On the other hand: when the main author of your framework moves on, shit can hit the fan. Maintainability of that library’s codebase comes into question, and if pressures have already shown areas of weakness, there will be more pressure to switch. Engineers can be somewhat cavalier when it comes to the merits of their code over someone elses. A voice inside the room is heard better than one outside (depending on if one is whispering and one is screaming, I guess).


The world of JavaScript is something like what I expect the Wild Wild West was like way back when. Spattering of heros, spattering of outlaws, but still not any solid, stable guidelines or frameworks. It’s not like the world of Ruby, where Rails is pretty much the expectation (I guess you can use Sinatra). There are a bunch of really smart engineers trying to build the gold standard, but they still haven’t. We have choice, and we have a bunch of different tools. Our goal as engineers should be to solve problems in the best way possible, given the constraints of our current context and ecosystem. Im not saying we shouldn’t have discussions around the pros and cons of our toolset and how we can create better patterns and structures. But just because a tool exists doesn’t mean one should use it.

I like to ask: Given the reality I am in right now, with its complexities, requirements, limitations, and my own education and experience, what tools should I be using?


Coments Loading...