Technology Evaluations
Intro
I built a stupid app this weekend. In doing so, I tried out a bunch of technologies that have been around for a while, but are new to me.
They are:
- Coffeescript
- jQuery deferred
- The twitter API
- JSONP
Here’s my review of each.
Coffeescript
I don’t really like coffescript. I will never be a fan of languages that are whitespace sensitive. But I still use them. I’m willing to overlook the straight-jacket of whitespace sensitivity as long as the laugage is good enough. Now that I think about it, both haml and sass (also used this weekend) are whitespace sensitive, and also compile to a base language before being transmitted. Their benefits are worth it, but they’re not on trial today.
Context
I like the initial idea of the @ operator in Coffeescript. It’s a shorthand for “this.” And you’d better remember that. It can’t be used like you would use it in ruby. I was stuck for longer than I’d like to admit wondering why my assignment to an instance variable wasn’t working in one of my callbacks. Culrpit: @ did not reference my class, but the context that I was currently in. From a javascript perspective, that behavior is obvious. From the object-oriented, ruby-like context that Coffeescript was trying to pretend I’m working in, it was baffling. I had to fall back to the that = this idiom in order to get my callbacks to close over the object I really wanted to operate on.
Documentation
The documentation is pretty abysmal too. You’re lucky if you get more than a couple of examples. The tutorial doesn’t even show how to make multi-line functions! Nor does it demonstrate how to use an in-line function for a function parameter that is not the final parameter. The whitespace-sensitivity can make it a bit confusing.
Only from knowing javascript did I know that I would have to call a co-member function with @ or this. Somehow in their discussion of classes in both the tutorial and the book, they managed to avoid calling a method from another method. I’m not asking for a python style formal grammar documentation, but there’s a lot to be desired here.
Globals
Coffeescript also makes it really hard to write library files. They’ve gone from javascript’s implicit globals to the complete opposite, which is not allowing any globals at all. This is an improvement in many ways, but means you have to fall back to raw javascript or settle with using the window global if you want to actually expose your code to something outside the current file.
I had my code set up with separate responsibilities: a library that interacts with the twitter API, and a UI frontend. These files can’t talk to each other at all without globals. It’s a shame that the architecture of Javascript has forced that behaviour, but coffeescript goes and makes it worse. I had to use the following code to create a global and then drop my class into it:
`TweetMax = {}`
class TweetMax.Twitterer
If it’s not clear, the backticks drop me down to raw javascript. Thankfully I can at least do this, but this is like having to drop down from C to assembly if C didn’t have the extern keyword.
jQuery Deferred
The majority of my interaction with jQuery Deferred objects was just to use the bindings off of ajax actions. However, I did write a few custom ones of my own. It’s a great API, and is probably a pattern that I’ll wonder how I ever lived without.
The one deficiency that I noted, is that you can’t reset the status of a deferred object. Once a deferred object is resolved, it can’t ever be re-resolved. This meant that I had to pull in a proper eventing framework instead of just re-resolving the deferred that I was supplying to the clients of the library. Not a big deal, and for many uses cases, that’s probably a deliberate feature. But for me, it was a deficiency.
Twitter API
The twitter API itself is nice. It’s available in a variety of formats, and is quite sensible about urls, parameterization, and paging.
It all falls down in the service. Throughout the weekend I was constantly plagued with 502s (Service Unavailable). At first, I thought I might be getting rate-limited, since my app does require quite a few sequential requests. After a bit of googling and head-scratching, I discovered that the API service is simply flaky and goes down all the time. 502s aren’t really an exceptional failure with the Twitter API. It means “try again in a few seconds”. When working with the twitter API, you absolutely must write code that anticipates that the servers will be constantly failing to fulfill your requests. Which is okay in theory, but leads us into the next technology…
JSONP
JSONP is a way to get around the cross-domain restriction on XHR requests. This means my clients can make requests directly to the Twitter API without having to filter through my server first. The specific implementation of the format isn’t entirely important, but how it interacts with the browser is. The browser loads the response from a JSONP request the same way it loads any other resource. Basically, to do a JSONP request, you add a script tag to the DOM, the browser fulfills a request, and a function gets called when it all works. What happens when it doesn’t work? Nothing. The only way to figure out that request failed is to set a timeout in Javascript that fires if your function doesn’t get called within an arbitrary time limit. Ouch. So that twitter API that is constantly failing? Doesn’t play very nice with JSONP. Even with the timeout, you don’t get the luxury of knowing what exactly went wrong. So I have to jump through more hoops to tell if I’ve been rate-limited, or if Twitter is just screwing up again.
Conclusion
- Coffescript: I’ll probably avoid it in the future. You know what you’re signing up for with javascript. Writing “function(” everywhere is annoying for some people, but not for me.
- jQuery Deferred: A+++++ would use again
- Twitter API: Hopefully I won’t have any bad ideas that involve the Twitter API again. Of course, my gripes with it aren’t the fundamental parts of the API, just the reliability of delivery. So if they fix that up, I’d be pleased.
- JSONP: Cool technology, but the inability to detect failures really snuck up on me and derailed this project. Now that I know about that problem, I’ll have to carefully consider what I want to use it for, in the future.
