Skip to content

Comment on Emscripten and asm.js: C++'s role in the modern web

Comments

Compiling to Javascript is nothing short of a mental illness. The perversions that the terrible design of the web has driven people to are simply breathtaking...

That's a silly position to take. It works quite well in practice, and is completely competitive with a "designed" VM bytecode.

It works well in practice depending entirely upon your goals - and depending entirely on your never ever comparing it to ANY other possible solution to the problem.

Well, we've got PNaCl to compare too, which is trying to accomplish similar things.

As an outsider, it sure doesn't seem to be getting as much traction as asm.js or have compelling advantages, though.

I think developers have a tendency to underestimate how important it is to integrate well with your environment, start up quickly, and have a good deployment story. asm.js nails these things.

Compiling to asm.js isn't the same thing as compiling to JS. asm.js is just a funny-serialized bytecode. Someday they can trade it out for a sane serialization and hardly anything will blink.

Worst case, I expect individual compilers will develop their own bytecode serialization format that generates asm.js on the client. There are various reasons to do it already (compression, debug vs release readability/minification concerns, etc) and future revisions of asm.js (like v2, which introduces Java/C#-oriented heap structures) will make it worthwhile.

Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.

Actually, it makes a lot of sense to me, and you can take advantage of C++'s more efficient abstraction models.

Maintaining a massive cross-OS cross-processor code-base is nothing short of mental illness.

Nobody would compile to JavaScript if there was an analogous platform on the Web. There isn't one.

You are entirely correct on both counts. The fact that we have been driven to madness by the horrible design of the web does not, in any way, mean that it's not still madness to do it.

The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is. They want application functionality which is as easy to access as typing an easy to remember name in an address bar. The means of achieving this goal taken by developers have been convoluted in the extreme. Each step has its own 'reasonable argument' defending the decision made, but it still adds up to madness.

The fact that we have been driven to madness by the horrible design of the web does not

I wouldn't characterize it as such. The reality is, we are pretty effin lucky the Web turned out the way it did. It does it what it does very well. I mean we have an open platform that every major tech company is on-board with, that isn't controlled, wholly, by any single one of them, a platform that works on almost every capable device out there. Those same companies cannot agree on anything else and are openly hostile to each other in every other space, except this one. It could have been worse. And future versions of JavaScript are looking pretty good too!

I'd prefer that HTML/CSS was better designed for building web-applications (right now it's a Frankenstein that doesn't know whether it wants to be a UI toolkit or markup for text). I'd prefer a language like Dart or Python to power web-pages, instead of JavaScript. But oh well.

The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is.

And that's part of the reason why JavaScript sticks around. Users don't care, and you can get far with JavaScript.

Apparently this is called "open". Black is white, god is bad, truth is a lie, web is open.

A language where `this` means everything is mental illness.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.