Letter to John Carmack
The following is an email I sent to John Carmack of Id Software after I had watched his Quakecon 2012 Keynote Speech
Edit: John Carmack's response is reproduced below
Hi John,
I watched the live stream of your keynote speech yesterday, and – as every year – I enjoyed it very much. I applaud your openness; it's always refreshing to hear some insights from the gaming industry that is otherwise very secretive. Thank you!
However, I believe your views on JavaScript and WebGL are short sighted.
Nobody pretends that the next AAA-title will be written in JavaScript. The community understands that it's magnitudes slower than native code, but the thing is: it just doesn't matter.
Many, many types of games don't need the absolute best and fastest environment to offer interesting gameplay and graphics. Take a look at X-Type on your iPad or iPhone for instance.
You yourself talked about how frustrating it is that you need 200 lines of code just to set up your screen for rendering on Windows, whereas in the olden days you could just push pixels to the screen with 3 lines of code.
We're there again: take 3 lines of JavaScript and you're drawing an image to a canvas element. Take 20 more lines and you have a rendering loop and a sprite that moves with the arrow keys. And all you need is a text editor and your favorite Browser. That is what JavaScript is all about.
When you're new to programming and still figuring out whether you like it, you don't want to read thick books. You want to see results. Fast. You want pictures dancing on the screen.
JavaScript is the language you should teach your son.
I backed the Oculus Rift Kickstarter yesterday and I fully expect to see significant development for it going on with WebGL. It doesn't matter that JS is "slow" when you're just trying stuff; ease of development is far more important.
Coupled with the openness of the Web, I wouldn't be surprised if much, if not most, of the research for applications of the Rift comes out of the JavaScript community.
Right-Click -> View Source is what made the web so successful and it's awesome that we now have this for 3D graphics as well.
Don't hate JavaScript. It's our generation's Apple II.
Regards, Dominic
John Carmack's Response
I didn’t really intend to come off as that critical of javascript. For aggressive tasks in a resource constrained environment, it should clearly be viewed as the wrong tool, but those two caveats don’t apply to the vast majority of programming work. I think less code should be written in C/C++ than actually is – the safety problems of pointers/array overruns and explicit memory management are much worse than the performance benefits for most applications.
I did do a little bit of simple JS programming specifically to help decide what programming language my son should learn first, and I’m not sure that it wouldn’t have been the correct choice.
I do have a bit of a wry esthetic objection to the layers on layers on layers on layers world of web development, but I recognize it as a foreign culture (from my point of view) with significant and powerful capabilities. Native code developers shouldn’t be defensive about true accusations of security and stability limitations, and JS developers shouldn’t be defensive about true accusations of inefficiency.
People should avoid statements like this comment from above:
V8's JIT and typed array buffers make JS nearly as fast as C
These arguments only work when you are comparing native code kernels that limit themselves to the characteristics of the interpreted / dynamic language you are comparing it against.
If you compared a task with enough meat on it to really exercise an optimizing programmer – say, the transcoding pipeline in Rage that decompresses pages of HD photo data and recompresses to DXT format, an implementation in javascript is going to be drastically slower. I would be very surprised if it could come in within a factor of two, and I would sort of expect it to be an order of magnitude slower. I would be willing to bet money on the factor-of-two-slower statement if anyone rabidly objects to it.
Something else to consider: the “computers are always getting faster” argument has run out of steam with scalar processors. I still hold out hope for additional significant scalar improvements, but the pessimistic view would be that current C/C++ code is faster than Javascript will ever get. EVER. It still doesn’t matter for the vast majority of applications, but it is worth a little bit of pondering.
John Carmack