marcelvr

I don't agree that JavaScript being good enough for one person makes it good enough for everyone.

I don't agree that limitations should be placed on abstractions; I have no clue what's happening at the CPU level when a line of JavaScript or MSIL or bla bla executes. I don't need to know what's happening at all the layers of abstraction beneath the one I'm working on, and that helps me be productive.

There might be a pragmatic argument against using compile-to-JS languages _right now_, but with things like Google Chrome's Source Maps, this is a problem that is being solved if it hasn't been already.

"... but when it is JavaScript that will be run by the browser then JavaScript is what you should be writing."

So by that logic, one shouldn't be writing C# that targets the CLR either, but should rather be coding in MSIL directly. Mmm, no thanks!

Thanks for the comment. Before reading it, I admit to being lured into thinking the code in TFA was there to clean up after Backbone. Sneaky bit of writing...

Octopus is Paul's yacht: http://en.wikipedia.org/wiki/Octopus_(yacht)

The artwork in Braid is amazing. I like how the article shows Braid's graphical roots and how it has evolved from there. Great insight into the process.

David Hellman (the graphic designer behind Braid) has more Art of Braid articles on his blog at http://www.davidhellman.net/blog/category/art-of-braid/

> Forms are tabular data -- headers on side, data on the other.

For very simple form designs, sure. But that idea breaks down when you have a more sophisticated form and need to consider horizontal "flow" between fields.

Tables are hammers, but not all forms are nails.