Shameless plug time: I built Rekapi, which is a context-agnostic keyframe animation library. That means it works with DOM, Canvas, or whatever you need: http://rekapi.com/
Article author here. I can try a newer Vim when I have some time and update the post, this was just the first thing I got working. Thanks for the heads up.
Article author here. Anecdotally the battery life takes a bit of a hit, but I've been running it pretty hard to get everything installed. I haven't done any tests. I have a suspicion that Chrome limits its CPU usage, and the chroot does not. That said, the battery life isn't completely shot in the chroot.
I got my Chromebook on Monday, so I haven't updated it after initial boot. I'm not sure about the updating issues, but you can always go into non-Developer Mode and update from there. If that causes problems for the chroot, it's really easy to back up the chroot (it's just a directory) and reinstall it with Crouton: https://github.com/dnschneid/crouton#you-want-to-make-a-boot...
So in other words, I can't answer any of those questions yet, sorry!
Debugging compiled code is absolutely unpleasant. Fortunately, I only have to do it rarely. From what I can tell, debugging JavaScript that was compiled from CoffeeScript is a standard practice, and I simply don't want to pursue that. It's interesting how you describe CoffeeScript as a tool rather than a language, but in my opinion it is still a very leaky abstraction.
As I mentioned, I look forward to revisiting it when a standard toolset has matured.
I meant that I optimize for project newcomers, preferably ones who are comfortable in the finer points of JavaScript.
It's not that I don't take advantage of JavaScript's strengths. I get the sense that people interpreted my article as a glorification of the Google Style Guide, that it should be followed precisely. I suppose I should have worded it better. My personal style is heavily inspired by Google's, but I freely deviate where I feel it is practical. For instance, I use closures and functional approaches when I feel it will make for faster/more readable code. It's mainly the annotations and and line limit that I follow religiously.
I'll get into CoffeeScript when I feel that it solves more problems than it creates (it's very important for me to be able to debug raw source code in a language). My goal as a programmer is to reduce complexity, and I think it will take about 10 years for CoffeeScript to let me do that.
EDIT: Forget to mention, there's nothing in particular that caused me to write this. I just realized that, more and more, my style goes against what a lot of people do. I figured I'd document it for anyone interested in it. :)
It's a matter of practicality. JavaScript can do some really cool things, but if it makes the code harder to read/follow/maintain, it's not very useful. From what I've seen, a lot of the JavaScript techniques that have gained popularity over that last couple years make code less grokkable for a project newcomer.
My goal is to write code that anyone can understand. I get much more enjoyment out of that than writing JavaScript "the JavaScript way."
Because I want make UIs and apps with open web standards, and JavaScript is the only practical language. CoffeeScript and other macro languages are cool, but currently there is no way to debug and step through the source.
I can't wait for the day that CoffeeScript has a robust debugger.
To be clear, I don't follow the Google Style Guide exactly, at least not for my open source projects. It's more of a jumping-off point that I then tweak to my liking. As I said in the article, it's not worth going into every detail of my style preferences (like spacing and naming), as I find that stuff pretty trivial.
If a style guide is making code less readable, I would argue that the style guide needs to be amended.
It also supports exporting JavaScript keyframes to CSS3 @keyframes, as demonstrated with Stylie: http://jeremyckahn.github.com/stylie/