Node Knockout 2010: In Response to John Resig

First, a bit of background.

When the Node Knockout competition was announced several months ago, I signed up immediately; it sounded like a helluvalotta fun and lit a fire for me to learn the ins and outs of Node as quickly as possible.  I recruited a couple of my buddies and the contest slipped off my radar and out of my mind.

Days before, though, I was reminded that it was fast approaching! Long story short, I had somehow screwed up our registration, but the gracious folks running the show set up a random-team-name account at the last minute, “Zenith-Workloom“.  We set to work right away.

I was the only participant who had experience with Node, but the guys were excited to try.  We even had a few geek friends show up when we started, just to see what we were doing and how we were going to do it.

All told, I stayed up for a 36 hour period, crushing against the GitHub, Twitter, Facebook and FourSquare APIs, fussing with relative dates, wrestling with MongoDB… really a lot of work.  We found ourselves cutting back on our features list with every passing hour, desperate to get things stable before time expired. There is quite a bit to discuss here, but I’ll save that for a blog post I plan to write later this week.

The Results

In the end, we ended up exhausted with relatively solid services and 20% of our desired feature set in the front-end.  I emphasize this because there is quite a bit of code running in Node that didn’t “bubble up” to our front-end effectively… for example, I couldn’t get GitHub check-ins to sort nicely with other events before “last call”.  This is merely a side-effect of a deadline fast-approaching.

There are some amazing entries in the Node Knockout contest… I mean, incredibly awesome.  Here are a few of my favorites:

  • Simulchart – – Real-time, embeddable data charting.
  • Drop Note – – Drop a file into your browser and share it instantly.
  • – – Real-time, addictive Scrabble game, (WOW!)
  • CloudQ – – Sandboxed Unit Test runner for GitHub projects.
  • Serrano – – Share DOM events and other information with other users simultaneously.

These guys kicked our ass.  But here’s the thing that I take away: I watched folks from these teams on IRC, struggling through issues, getting help, providing it… I mean, the community was so f’ing powerful.

Halfway through I realized I was going to learn 1000% more just looking at winning teams’ source code than I was in the contest.  I got excited, and have remained so… and I’m still proud of what my team managed to accomplish, even though we’re not realistically in the running.

Along Comes John Resig

I took issue with the following tweet by Mr. Resig:

Disappointed in the entries to the Node.js Knockout; only a handful of the entries work in non-Chrome/Safari browsers.

Wow… really?  It prompted my reply:

Was jQuery coded in 2 days? RT @jresigDisappointed in the entries to the Node.js Knockout; few work in non-Chrome/Safari browsers. #nodeko

My point was fairly straightforward:  this wasn’t for production, this was for fun.  This was to test the limits of Node.js with stunning, whimsical or powerful ideas. Take away the pressure of “selling something” and just “do something”.

After some retweeting in the node.js hashtag, this reply from Mr. Resig crossed my TweetDeck:

@clintandrewhall Teams that made working, fully-functional, cross-browser applications in 48 hours deserve to win – and get my vote.

The more I’ve thought about it, the more upset his statements have made me.

In Defense of Node Knockout Teams

The Twitter medium is the worst place to debate these kinds of points; I mean, Mr. Resig certainly has more to say that 140 characters allows.  And his interpretation of a complete application is probably different than others.  But I have to take issue with his tweets on their face…

Look, my team’s entry is cross-browser compatible… but that was by the grace of a limited feature-set.  Mr. Resig was actually a judge for our entry, and leveled a very fair, honest critique of our missing features… points of view I share.  But I’m going to protest on behalf of those other teams who only supported a limited set.

There were people attempting very complicated, near-impossible feats under a very tight timeframe… and several succeeded!  For a judge to focus on the browser when the teams had been focusing on Node just seems so argumentative.

It’s one thing if the knockout had been for a week, or maybe if server code had been locked down early with additional time for front-end.  But we’re talking 48 hours here, starting from scratch.

But more importantly, Node Knockout entries are graded as follows, (from

Entries will be judged on a 1-5 scale across 4 dimensions:

  • Utility – Is the site offering a service you’d use again and again?
  • Design – How good does it look and feel to use?
  • Innovation – How original is the idea and execution?
  • Completeness – How “fully baked” is the site? Are there bugs or dead ends?

First, I concede that judges have every right to pet peeves, sticking points, etc… and we were told to keep the judges in mind when we were working. Still, I would hope that an entry would still be judged on its merits more so than those irritations.  And to be fair, where in the criteria above is browser compatibility even mentioned?

Perhaps “completeness” could include cross-browser compatibility… but in this context… should it?

Based on Mr. Resig’s logic from his tweet, had my team completed our feature set in our present level of compatibility, we’d have garnered a 5-star vote from him.  That’s great!  But is he saying that, of the entries I mentioned above, none deserve five star ratings simply because they don’t work in all browsers?  Is my team’s simple effort, to compile data feeds chronologically on one page, full orders of magnitude “better” than those ideas simply because our CSS happens to be cross-browser compatible?  I certainly don’t think so… my team didn’t even have JS in the front-end…

Look, I’m well-known for being a progressive-enhancement nazi, swinging the “gotta work everywhere” sword in wide archs… but I make an exception here.

This contest was about doing freakishly cool things in Node in 48 hours, not a browser.  Having participated first-hand, and seeing the absolutely amazing things that were done, I am in awe.  That’s not even to mention the inspiring, multi-continent community that was flash-created in a 48 hour period.  Even better, most teams have pledged to open source their code for all to see.

Absolutely incredible.

Yet… that someone, let alone one of the judges, would publicly minimize a team’s accomplishments by focusing on the tiniest, almost out-of-context point saddens me.

I don’t think anyone should be “disappointed” by these entries.

Go Explore and Vote

I encourage all of you reading this, if you haven’t yet, visit the Node Knockout entries page and comment and vote for your favorites.  Go and see for yourself what amazing things can be done with 48 hours, an idea and a ton of people willing to help.

5 Awesome Comments So Far

Don't be a stranger, join the discussion by leaving your own comment
  1. Ian
    August 31, 2010 at 12:48 pm #

    Stands to reason that the spirit of the event is of ingenuity and creativity, not cross browser standards. However I do know how hard it is to take those standards goggles off. After all, I still have to code for IE6.

    I miss being able to do cool shit.

  2. John Resig
    August 31, 2010 at 2:12 pm #

    The vast majority of the submitted projects only work in Chrome. A couple also worked in Safari and even fewer worked in Firefox. Even a couple more required specific builds of specific browsers (e.g. Firefox 4.0b1).

    There are two separate metrics upon which this strategy fails: Utility and Completeness.

    Since I use Firefox as my day-to-day browser (not an unreasonable assumption, considering that it has about 23% market share and is a standards-compatible browser) I find it hard to be able to rate an application highly for Utility that simply won’t work for me. I make exceptions for applications for which the demo is so compelling that I would consider opening or downloading a separate browser just to use that application (such is the case for Serrano, for example). In the end though I will have to dock an application at least 1 star for simply not allowing me to be able to use it. At this point I’m not even considering Internet Explorer 6-8 – I think we can at least assume that developers should just be shooting for standards compatible browsers in the limited amount of time given to them. Of course any team that goes above-and-beyond to make sure that their project works in older browsers (like Simulchart) should absolutely receive additional points.

    Now, for Completeness it can also be argued that any application that simply breaks in my browser is not complete – and is buggy, as per the guidelines: ‘How “fully baked” is the site? Are there bugs or dead ends?’ I docked at least one point for Completeness for projects that didn’t support Firefox (thus making it unusable for me).

    You argue that developers that do good work and have a good project but that don’t have cross-browser support (and, thus, are not useful to the general public) shouldn’t be docked points. If that’s the case then surely you would agree that developers that do good work and have good projects AND have cross-browser support should be given additional points. Their projects are ready for prime-time – which means that they went above and beyond and deserve to win the competition. Sites that I want to use today (like Simulchart) and games that I can play today (like — and share with my friends and family without repercussion deserve every star they get.

    Another way to think about it: The browser is a critical aspect of any of the entries — it is the medium through which they are meant to be viewed. Ignoring that medium would be foolhardy as it is absolutely critical that it work properly. If the contest was all about Node then there would be no Design rating. So far I’ve only come across one entry that used a non-browser as an access medium and that was the Discworld MUD (you could also access from Telnet). I connected via the OS X Telnet client and confirmed that it worked and was playable. If I was unable to connect using that client then I would’ve docked the entry another point — for the same exact reason that my inability to view the entry using Firefox causes me to view the entry in a particularly negative light.

    I completely stand by what I said: “Teams that made working, fully-functional, cross-browser applications in 48 hours deserve to win – and get my vote.”

  3. Clint
    August 31, 2010 at 2:50 pm #

    Thanks for replying and clarifying your position. It makes more sense… and I’m glad to see that you appear to have an objective approach to your ratings.

    Feel free to stand by your second statement… I don’t think I took as much issue with your second tweet as I did the first… the second simply exacerbated. Knowing how many difficulties so many people had in this contest, having your first and second, (and so far, only) tweets sound so negative struck me as off-putting.

    People did some amazing stuff. I guess where we differ the most considers your Telnet example: if the team whose project didn’t work in Firefox listed in their description that it only worked in Chrome… would you have docked points? I guess that answer is “yes”, because a browser is a browser is a browser. I simply disagree with you as to its importance in the grand scheme of things.

    All things being equal, sure, those whose projects are ready for prime time deserve great credit. I’m simply putting more stock in the “great, bold attempt.” And I still don’t think anyone should be disappointed by the intense amount of pure effort that people put into these projects and then had the guts to have their work judged en masse.

    In short, to apply a crude analogy, someone who builds a car that runs on plain water but unfortunately isn’t certified for highway travel deserves more credit, I think, than a hybrid that just gets better gas mileage? 🙂

  4. Ian
    August 31, 2010 at 2:55 pm #

    Can we go back to being a happy developer family now?

  5. John Resig
    August 31, 2010 at 3:11 pm #

    I think a more apt analogy would be that someone built a car that runs on plain water (an awesome achievement, to be sure) – but can only be driven by people that are taller than 6 feet. That’s all well and good but being shorter than 6 feet means that the car does nothing for me. I can get a tall friend (Chrome) to help drive me around but that sort of defeats the purpose.

    I think we can all agree though that old IEs need to die and that the newer browser releases (like Firefox 4.0 and IE 9) can’t get here fast enough.

Leave a Comment

Remember to play nicely folks, nobody likes a troll.