Last October, myself and Conrad Irwin spent 48 hours (give or take a couple of starbucks runs) in my apartment for Rails Rumble 2012. The result was Rescue.js! In case you missed it, we created a Javascript error catcher: by integrating a snippet of Javascript, a website owner could see and get insights into all the Javascript errors that were affecting the site’s users.
We were very excited about it for a few reasons:
- We were able to build something genuinely useful, that we really wanted to exist, in less than 48 hours
- A simple but effective product design allowed us to get a great view of the client-side errors of a site’s real-world users
- We (just!) managed to pull off support for JS source maps in the backtraces, (albeit in limited form, and only in the nick of time).
After spending 2 evenings and 2 full days hacking, we were done. We promptly submitted our result and went out to celebrate. While we were out, someone submitted Rescue.js to Hacker News and the response was positive, with over 150 upvotes. People seemed excited by what we were doing. We got even more excited!
A week or so later, the judges let us know that they also liked our work. They ranked rescue.js in the final top 10: we placed 6th out of the 500 teams that entered Rails Rumble 2012. I can’t remember if we went out again to celebrate, but we definitely exchanged a high-five.
That was October 2012.
This is July 2013
Immediately after the judge’s results, we got to work; we added a couple of small features that we didn’t have time for in the original hackathon; we let a hundred or so people try out the alpha. We dogfooded the service a little more ourselves. If someone reached out to us directly and asked to try it, we aimed to always respond and let them know it was an alpha, but that they were welcome to sign up and give it a try.
But we knew that the initial 48 hours of hacking only let us prove a concept – the service would never scale for real-world production use without more work. It would be irresponsible of us to let more than a few people use it with their production sites until we had shored up the back-end properly. That is not fun work. It requires more focus than we were able to dedicate to it.
Our progress, initially so surging, stalled.
This is where we still find ourselves today: we’ve been unfair to the ~4,000 people who expressed an interest in using rescue.js on their own sites. We haven’t acted on that interest, we never truly seized it and ran with it. Our day jobs, our other interests, our other hacks: those have all taken priority over building out rescue.js into a publicly available bullet-proof service.
Life got in the way.
While it’s frustrating when promising projects announce their death (or more commonly, their “sunsetting”), it’s even more frustrating if a project dies a slow death. When no one is willing to admit that it’s lost its initial momentum, that it has very little chance of meaningful success, everyone is left wondering what’s going on behind the scenes. One of the reasons we created rescue.js in the first place was because there were a few Javascript error catchers, all seemingly unmaintained with unresponsive owners, despite their websites looking completely authentic.
Usually these projects die months or years later, as their owners finally get sick of paying for the hosting. What’s less common in this situation is to read any explanation as to why a project is defunct. It’s my hope that anyone reading this post who owns such a project will feel empowered to admit it to themselves and confess to their prospective users if their project is dead behind the scenes.
Today we’re admitting that Rescue.js will not become a mainstream service. We’ve disabled the ability to leave your email address, we’ve added a message describing that the service will never be production-ready, and we won’t be pretending that we’re going to work on it any day now.
RIP Rescue.js, we barely knew you… You were great fun to hack on that weekend in 2012.
Here’s to Rails Rumble 2013.
Follow @LeeMallabone to hear about my future posts, (they’re typically about front-end development tools, tips, and cutting-edge hacks).
fonicmonkey 