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!
Thanks for the preliminary response. I am very tempted to do all of this "hacker" stuff to my Chromebook but I'm worried that's a slippery slope. As is I have no local files, no battery worries, so it's essentially a maintenance free machine. Once I start doing local work I'm going to want more and more until it's basically just a netbook. I think it's maybe good for me to have a machine where I can't constantly be tinkering.
If you did this, would there be a significant lag from i/o? I assume sticking a Class 10 SD card in it and booting archARM would be pretty quick, but still slower than the SSD that ships with the machine.
Haven't tried on this machine specifically, but never noticed much lag as a result of running from USB on others. There is a USB3 port on the back if you're concerned about performance (just remember this is a $250 ARM laptop, not a MacBook Pro).
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. :)
Hi Jeremy. Dmitry's argument you mention, for instance, is questionable and not very popular. I think I can't point to what you're going against (vs "old style" coding), maybe some examples in the post could help.
On CS: you are already using a compile step that dynamically changes code, how more complex can it get? I have thousands of lines of CS in production and it never caused any more problems than JS. If you think of CoffeeScript as a tool to write Javascript, not a separate language, things go much smoother (you want to debug the javascript output, not the cs source).
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.
There are lots of people who feel it (CoffeeScript) does indeed solve more problems then it creates.
If it actually does create more problems then it solves then a lot of people are just plain making a mistake by using it :) which I don't think is the case.
Plenty of programmers I know had a similar knee jerk reaction to the idea of CoffeeScript and have since decided it is a worth-while trade off.
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."
Project newcomers or JavaScript newcomers? Because if you are optimizing for the latter under the pretense of optimizing for the former, you are building code that experienced people won't want to interact with.
FWIW, I'm with you on wanting to write readable, usable code. But my Python code does take advantage of functional aspects and meta programming at time, because I can write far fewer lines of code, which means fewer bugs and less time spent mentally parsing code later.
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.
Agreed, also on the count that writing idiomatic code is, in my opinion, much more beneficial than having to refer to a third party style-guide to grok a non-idiomatic flavour of it.
The obvious benefit is that knowledge can then be applied to any other project using the language idiomatically, and not as if it were 30 years old. Conversely, code to the third party style guide, and struggle to understand the many things that don't adhere to it.
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.
If debugger integration is a must-have feature for you, then fair enough. I'd make the opposite choice myself which is why the previous statement surprised me.
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/