3 ms·
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
by emn13 13y ago
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.