- 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.
- It can suck when one of the main authors leaves.
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.
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).
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?