Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Honestly the JavaScript it generates isn't very nice to read. I'd rather use a language like TypeScript which tries to generate idiomatic JavaScript.


I'd rather it'd go the other way: please generate hopelessly unreadable but optimal javascript. However, include the original source as comments in some debug mode.

In my experience with coffeescript, the idea that the source is really readable is only somewhat true. Sure, you can read what's going on. But fancier features aren't always trivially translated; and even where a translation is trivial the small differences in syntax mean that in a large enough codebase it can take some time to find the corresponding source line.

Furthermore, because the code is supposedly "easy to read" that means it must be fairly close to javascript native, and that means (for instance) either a heavy abstraction (JSIL) that's probably slow, or exposing lots of unfortunate javascript quirks (coffeescript) such as 0 vs. null vs. undefined vs. false and/or => vs. ->. Basically, to reason about coffeescript you often enough need to understand in detail how it's translated to javascript; at that point you've lost any productivity gains you were hoping for but are still paying the costs in terms of poor tooling and browser integration.

If you're using javascript like assembly, treat it like that: please don't waste my time being sorta-almost-but-not-quite readable. Just make fast, robust, no-leaky-abstraction javascript, please.


The generated code used to be a lot prettier and more idiomatic, but JavaScript is such a pain in the ass that it's really not possible to do - too many behavioral differences, performance issues, etc. Basically all the readability problems are caused by compromises that ensure adequate runtime performance in V8 and SpiderMonkey.

Were I to start from scratch I'd probably drop the goal of producing readable JS entirely.


Typescript is surely the way to go for writing. But what about stuff that is already written? Many of the samples are code ported from C#/.NET.


With sourcemaps, this is unimportant. For example, Closure Compiler, Dart, and GWT support source maps which let you see and debug the original source inside the browsers that support sourcemaps, even if the underlying representation is heavily optimized and minified JS.


XNA/MonoGame are not yet ported to TypeScript (and I guess never will). Also the idea is to avoid having to look at JS at all (for obviou reasons) by using a language that is generally better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: