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.

More in the discussion (powered by webmentions)

  • Javascript Digest responded at reposts this. ( RT @sil: @dylans also,… My opinion has not changed very much in the intervening years :) @rem
  • Dylan Schiemann responded at @sil @rem I don't disagree, I just have different requirements in that I want Dojo to stay competitive in the coming years
  • Dylan Schiemann responded at likes this. (
  • Paul Lewis responded at @sil well my own case is that I often want to help devs to learn. That said many things are unminified in a GitHub repo.
  • Stuart Langridge responded at @aerotwist ya, plus source maps, etc. You're good at doing it because of sense of duty and decency; I like that the web pushes it on people
  • Claudio Procida responded at @sil @BrendanEich +1 for the View Source button (or Inspector alike) on mobile browsers.
  • Stuart Langridge responded at @claudiopro @BrendanEich wholly, completely agree.
  • Matt Wilcox responded at @sil I agree everyone should grok CSS first. But I haven’t written pure CSS in work life in many years. It’s impractical.
  • Stuart Langridge responded at @MattWilcox really? I use a preprocessor of I actually need it, which is the case on about half my projects.
  • Matt Wilcox responded at @sil use it all the time, it’s simply more convinient to author, and you get minification as a built in bonus.
  • Stuart Langridge responded at @MattWilcox I don't like minifying either. See the blog post :-)
  • Matt Wilcox responded at @sil stuff as simple as importing standard reset and standard typography partials helps authoring by removing that from actual styling file.
  • Matt Wilcox responded at @sil yeah I would agree if I wasn’t also outputting sass source maps. Inspector shows the proper rules regardless, and scss line numbers.
  • Matt Wilcox responded at @sil heck looking at a bare CSS file even unminified is impractical to learners when inspector tools do a better job of that these days.
  • xnoɹǝʃ uɐıɹq responded at @sil def feel the same but want better labeling. most of these projects say they are JS or worse 'standard' when truly something… else
  • Stuart Langridge responded at @brianleroux I hate it when I go looking for a module to do a thing I need and then see it's coffee and walk away
  • xnoɹǝʃ uɐıɹq responded at @sil happened to me twice today and a colleague once. its a problem.
  • Stuart Langridge responded at @brianleroux it totally is. Hence blog post :)
  • xnoɹǝʃ uɐıɹq responded at tag:twitter.... (
  • Andrew Hutchings responded at tag:twitter.... (
  • Sebastian Lenton responded at I’ll stop minifying code if you agree to stop using cursive as a fallback in your font stack 😅😉
  • Matt Andrews responded at ... I may regret initiating this flamewar.
  • Stuart Langridge responded at hmm. The font itself is cursive, sorta; handwriting. But I take your point. I should do something about that :)
  • Eric Bailey responded at This is a great article, thanks for sharing it.
  • Jude Gibbons responded at tag:twitter.... (
  • Eric Bailey responded at tag:twitter.... (
  • Javascript Digest responded at @jennschiffer agreed. I don't think my view has changed much since I wrote… years ago; moving from "you can learn fro