Things that compile to JavaScript

Lots of discussion recently about things-that-compile-to-JavaScript. And the discussion is forcefully making the point that they’re a good idea:

JS is a compile target, and that is not only a strength but a feature. Not a bug. JS community needs to embrace diversity. — @brianleroux

Brian’s right, too, and those that battle against this have a little flavour of the assembly language hackers who railed against C because compilers couldn’t produce things as tightly rolled as hand-hacking opcodes.

However, I’m not sure I like the idea all that much, and I don’t think that my reasoning boils down to “I don’t like it so you can’t have it”. Herewith, my reasoning.

There are some people who believe that a compiler will produce bad JavaScript. The JS produced by a program will be less elegant, less efficient, make less use of the language, than anything hand-written and loved and agonised over could be. This is a crock of shit. Sure, when a compiler is first built then a super-dedicated super-expert person might be able to beat it, but the gap narrows and narrows over time. I do not care, in this discussion, about forcing the last clock-cycle of efficiency out of your JavaScript by writing it by hand. However, I do care, a lot, about the JavaScript I can see being readable.

Why don’t mobile browsers have “View Source”? — @mrdoob

The Web, unusually, came with a View Source button. Hardly anyone had done that before, and hardly anyone’s done it since. Hands up if you’ve learned at least something by viewing the source of other people’s pages. OK, everyone, now put your hands down. Hands up if you learned everything from books and nothing at all from web pages? OK, no-one, don’t put your hands down because there is no-one with their hands up, because there is no-one like that. What concerns me about JavaScript being a target language, a thing which is written by compilers and minifiers and compressors, is that we break people’s ability to learn. When you’re debugging your code, when you’re debugging someone else’s site, when you’ve seen a cool trick and want to learn how it’s done, you have to do that by reading code that no human has ever seen; by reading code output by a computer program. Computers are excellent tools, but they are very bad at teaching. If you’re trying to learn from code that isn’t the code that the author actually wrote, you’re always going to be at a gargantuan disadvantage. Obviously, when the author’s debugging her own code she’s got the Real Source to hand, and a bunch of sweet tools to work with it and debug it and step through it and understand it. Those of us learning from what’s actually given to the browser have no such luxury.

Obviously, there is a balance here. People don’t minify their code because they want to hide it from prying eyes, they minify it because they want to make their site load faster and because Steve Souders has proved that it will if they do. (Well. Some people do minify their code just because they want to hide it, but I think we can all agree that those people can sod off, right?) No-one writes in CoffeeScript because they want to hide the secret .coffee magic from browsers; they do it because it’s better for them, and optimising your process to make stuff easier for random people to learn from your code is the tail wagging the dog a bit, amirite?

Well, sorta, and sort of not. Remember that View Source thing. This is a tragedy of the commons; if we make things better for ourselves right now by obfuscating code (for speed, not hiding), by removing View Source from browsers (for elegance and simplicity of UI, not restrictiveness), by reviewing applications before they’re allowed to be run (for consistency of experience, not gatekeeping)… where are the next brianleroux and mrdoob and dmr and dhh and linus and woz coming from? I don’t say this to suggest that building a language which compiles to JavaScript makes you someone who hates openness and the web, not at all. But I do ask that we bear in mind that View Source is increasingly useless if you’re not Viewing the Source that was written. There’s a shift to “I’ll provide the source if I want to, as an altruistic act” (which most people I know, and certainly everyone on that list, does), and away from the Web’s default position which is “of course the source is there for you to look at and learn from and experiment with and improve; why would it not be?” We aren’t going to throw that away unnecessarily, but I want the next generation to know that it’s important too, and that means we’ve gotta tell them why… and telling them why is hard if they think of JavaScript as a thing that only computers read.

5 thoughts on “Things that compile to JavaScript

  1. skierpage says:

    Good point. You used to be able to copy code from production websites to add functionality to your own pages, and that’s impossible now. And it’s so hard to examine and step through anonymous function-passing clojured callbacks, even if the code isn’t minified.

    However, you can still usefully view and modify the CSS and DOM of production sites in Firebug, and if you want to persist your changes you write some bookmarklet-level JavaScript. And great tools like jsFiddle, JS Bin, plunker, tinker.io, etc. let you create and share readable bits of JavaScript on top of massive impenetrable libraries. There’s more web code sharing going on than ever before, only not by viewing production web sites.

    Mozilla’s Webmakers project has to deal with this. I’m afraid it’ll end up as “Let’s go camping and make a primitive page” (that you’ll be embarrassed to show your friends) or “Use our nifty tool to make a cool page” (but good luck ever understanding how the tool works).

  2. Rodney Dawes says:

    The view source thing isn’t just a problem with JS. It’s a problem with everything now. People are compressing every possible thing to have as little whitespace as possible, and it just makes reading stuff, absolutely impossible. What I would really like, is for the “view source” functionality in Firefox, etc… to properly prettify the content for reading (aka viewing), regardless of how it is delivered. I’m quite happy to have the server send me the stuff as one very long line with very few space characters, but what I really want, is to be able to read stuff when I do click “View Source” in the bloody VM.

  3. Arpad Borsos says:

    Well apart from the obvious view-source problem you mentioned, I do have a strong opinion for things that compile to js.
    If js is considered the ‘target language’, the source language is what makes it interesting.

    There is emscripten, compiling C++ to js, the usecase is mainly to translate proven (legacy?) codebases to js.
    There is coffeescript, that aims to be a more concise language with more syntactic sugar. While i personally don’t like the syntax, the language serves a purpose.
    Now as someone who had the gruesome experience to work with GWT, writing Java compiling it to js, I just don’t see the point why anyone would want to do that. Why on earth would one write new (!!! not legacy) code in a static, highly redundant (even C++11 has the auto keyword), non-expressive language that lacks all the great features that js has, like real closures, flexible objects and functional array extras.

  4. Grazanaut says:

    @Rodney – Chrome/Webkit dev tools has had a js “beautifier” for a while now. Just look for the “{ }” button at the bottom while viewing source in the dev tools. obviously won’t help with minified method and var names, but definitely fixes the one-line/whitespace problem

  5. [...] downside of generated JavaScript Last spring Stuart Langridge posted an argument against the rise of generated JavaScript. The main point is that the practice breaks the usefulness of View [...]

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>