Really, though, the strong motivating consideration is that while backend code scales horizontally (i.e. you can throw money at an app and get more concurrency), the user only has one computer, so you have to optimize frontend code for performance. If we could just pay money to make users' computers faster I guarantee we wouldn't be worrying about browser JITs. :)
In fact, it is still a good story about computing dystopia. But it's no longer fiction.
Linux, the BSDs, the various commercial UNIX systems, OS X, and Windows all make very heavy use of C, and also C++ in some cases.
Apache, nginx, lighttpd, and many other web servers are written in C or C++.
The same goes for the major database systems commonly used today.
The main interpreters for languages like PHP, Python, Perl, and Ruby are written in C. Even if you're using a Java implementation of those languages, or some other language that targets the JVM, the runtime you're using is most likely written using C and C++.
So I find it kind of silly to hear Ruby and PHP advocates say how it's "dangerous" to use C or C++ for server-side development. Their preferred stacks are already essentially all C and C++! The amount of C and C++ code powering their applications dwarfs the amount of Ruby or PHP code they might have written.
The OP had a slide dedicated to platform-dependent components of building a 3D game engine (memory management, threading, game loop, audio, etc.). While much of the action happened "off camera", is the conclusion essentially that [emscripten -> [ asm.js + webGL] etc.] makes this process simpler (if still tricky to debug)?
But the most amazing thing is that they basically just compile their existing engine that has years of development to the browser using emscripten and it works. Thats a bit of a death blow to the new (and still very limited) JS 3D Engines, but of course their ease of use is a big benefit and they still make sense for smaller/web integrated projects.
These days, I'd much prefer seeing C fill such a perf-specific role. I can't stand C++, and I've read through some massive, and what most people would call "well written" code bases in C++. Every one is its own world of WTFs with abuse of templates and operator overloading and weird RAII and scoping strategies. I can never read code in C++ and really understand what's going on until I've made a cursory pass, identified everything that semantically changes the meaning of the code and internalized that. That's incredibly frustrating considering readability is paramount in really any project, but especially when the code base is tens of thousands of lines. And given that I've never seen a real world example where these features have actually provided any benefit other than terseness, I can't understand why anyone would ever use them.
Outside of the IOCCC, I haven't had trouble reading C except things that abuse the preprocessor, and that's frowned upon. So why not C?
The Pascal community was most vocal in the 1980s and 1990s, but has since dwindled in size. Today, it's often the Ruby community that's most vocal, and they are often very loud, indeed.
Curiously, we don't really see this attitude from the Python community nearly as much as one would expect. I'm not completely sure why this is, but it may be due to many Python developers having extensive knowledge of C and the various languages influenced syntactically by C (C++, Java, C#, Objective-C, and so forth). Due to their breadth of knowledge, different syntaxes just aren't an issue worth getting upset about.
Some of those people are the ones who are responsible for (unjustifiably, in my opinion) giving the C-style syntax a bad reputation by expressing their dislike for it.
And, yes, the Pascal, Ruby and Python communities, among many others, do exist. They do have very different traits and attitudes. You're free to pretend that they don't exist, but the reality is that they do.
I think my favorite least-known thing about writing simple tools for Windows during my time as a sys admin was HTAs. You had full jscript COM access with a web page presentation that's packaged into something that you can run without opening a browser explicitly. It was awesome building full web applications that could do pretty much any administrative task on Windows.
Well they are all three terribly designed languages, but JS is way faster and probably more secure: It's battle tested in environments where the assumption is that the attacker controls the code being executed, which is normally not the case on the server side. On the other hand, JS does not have anything like perl's tainted strings, which are a great security feature IMO.
edit: that said, I wouldn't be surprised if there was an OpenGL stack available for ps4, especially if they want to attract indie-devs.
Can we take baby steps, and get really rich, hardware-accelerated UIs (maybe canvas based), WebSockets, a nice debugging experience (source maps), etc... before we're trying to play Crysis 3 in the browser.
Au contraire, http://www.theverge.com/2013/3/30/4165204/microsoft-bringing...
*I totally nerded out when I found out by the way.
Longterm in also makes sense to think of games loading on demand while you play vs downloading everything to disk and install it somewhere. It also solves alot of the piracy problems of the industry.
Today there are Game Engines like Unity3D that already offer Native Client deployment and have their own browser plugin for IE or anything unsupported. Add to that a HTML5 deployment option through Emscripten & ASM.js and the games will basically run anywhere, just in edge cases requiring a plugin.