Sam Stephenson on Pow, CoffeeScript, and the Rails 3.1 Asset Pipeline | Hacker News Reader

Sam Stephenson on Pow, CoffeeScript, and the Rails 3.1 Asset Pipeline

lg.gd

66 pointsnetherland14 comments

As someone with a stake in lots of this stuff, this interview is interesting to listen to. I especially appreciated the bit about 3/4 of the way through about how doing Docco affected Pow. To quote:

"Pow started out without any documentation. I went through and added the Docco stuff later.

"I thought it was fascinating the way it actually changed the code. As I would go through and document things, I would run in to cases where they were too hard to explain. Something was too hard to explain or looked too awkward. So I'd refactor it to be more linear, more narrative -- and it matched up with the documentation, and seemed so much nicer.

"I think that's half the benefit of Docco, and the other half is that it makes it so much easier for anyone to come in to the project and understand what's going on and contribute a change."

I can attest to that, both from reading and writing code with Docco documentation.

It's also great IMHO for getting an uncluttered view of code. In many cases, no matter how well written, the documentation is not enough. And while Docco is all about documentation, it shines even then.

Sam, creator of Prototype.js: "I hope to never have to write JavaScript again."

He could have build Prototype.js in CoffeeScript. :)

unless you meam "rewrite", I guess his time machine was non functional.

Well he would have had to write CoffeeScript instead of waiting for jashkenas to build it. He should have, I'm disappointed.

I've heard this from many people who've picked up CoffeeScript, especially those who are most fluent in Ruby. Dr. Nic of Engine Yard, an early proponent of CoffeeScript, gave me this blurb for my book:

> JavaScript the runtime language is fast, dynamic, and can run in places other languages can't. But JavaScript the development language is kind of icky. That's why CoffeeScript may turn out to be one of the great innovations in web application development; since I first discovered it, I've never had to write a line of pure JavaScript.

One thing that wasn't mentioned was template bundling with sprockets. A hack/workaround was posted at https://gist.github.com/989891 but I would really like to know if there is or will be a recommended way of doing it.

The latest Sprockets beta has JST support, heavily inspired by Jammit's approach. Load either the ejs or eco gem in your app, then put a "foo.jst.ejs" or "foo.jst.eco" in your load path. Require it from JS and you'll be able to access the compiled template as JST["foo"].

awesome, thanks!

Cool! I use a version of haml-js that's been modified to work well in the browser. (https://github.com/wintondeshong/haml-js). Jammit allowed me to set the template function as Haml and it just worked, by passing the content of the jst files to the Haml() function. Is there an equivalent in sprockets?

UPDATE: As much as I like Haml, I think I'll just switch to eco, since it seems better integrated for now, and... CoffeeScript! Now all I need is haml-coffeescript / eco-haml. Well it turns out this does exist: https://github.com/9elements/haml-coffee. But I don't know how much work I'd need to do to get it working with the sprockets asset pipeline?

"We can put out code that is useful to us that raises the bar, and get people using it, and we get our bug fixes for free, and our R&D." Maybe the best case for open sourcing commercial products that I've heard.

Thanks for a great interview!

I've noticed that the link to Jeremy's twitter account is wrong on your website.

I cannot believe this got a mention https://github.com/rails/rails/compare/9333ca7...23aa7da

I do hope GitHubChan becomes a "thing"

Reply on news.ycombinator.com