On Asm.js

While you may be right with regards to the file size (although most SSA-representations are not built for small size, there is quite some potential to reduce it, imho), you'll have to do register allocation/spilling/etc. in your VM/compiler anyway and that is easier and faster on SSA[1, and more]. The dominance frontiers algorithm is actually not that good imho, there are better options[2], especially considering that one may not want to construct an unnecessary dominance tree in an Interpreter/VM. Now, I have no experience how much overhead SSA-deconstruction inflicts when lowering to machine code.

[1] http://www.cdl.uni-saarland.de/projects/ssara/ [2] http://www.cdl.uni-saarland.de/projects/ssaconstr/

Yes, I'm associated with that group.

What would it take to get a standards board to approve a common VM for browsers?

I don't see this ever happening. They would in effect be eliminating themselves. They would have to find new jobs or even careers.

Once the VM is standardized, what about HTML/JS/CSS. Well who the hell wants to use those slow moving legacy technologies?

So the standardization now becomes for python, for C#, for scala and lisp ETC.(and their associated UI frameworks). Not controlled by the W3C at all - thus their extinction.

It's more than this though. The W3C has an agenda and it is not to advance technology, it is to slow it down. They want everything moving so slowly that standards can be followed across the board. They want JS/CSS/HTML to be the end all not just in the browser, but everywhere. I think that this should be pretty clear if you follow their trail going back 10-15 years.

It is like a socialist government in a way. The promise is to keep everything stable and let everyone be on equal footing (equal here because the technology moves so slowly that nobody can be left behind by it.) They have to kill and silence many revolutionists who want freedom along the way to do so but consider themselves justified in doing so. Meanwhile, in a neighboring free government with limited govt, people flourish. They have more ups and downs true, and mistakes are made along the way, but after 10 years the free country is wealthy and flourishing, while the socialist one is stagnant and poor.

Think of the mere opportunity of innovation that would exist if a language creator could sit down and create a new language and UI framework universally for browsers in a well established and supported way. This lack of freedom is stagnating innovation.

Let the people decide. Make a standardized VM and your HTML/JS/CSS stack and let the people vote with their choice of options that appear.

> No, it's not technically native code, nor is it exactly assembly or bytecode. It an IR that browsers can JIT very easily. Which is basically the same thing.

So BF is "basically" native code too, since it can be JITted very easily? In fact, it's much easier to JIT BF than asm.js, so according to your definition it is even more "native" than asm.js.

The way you are using "native" takes away all of its meaning.

> Everything is an IR. Python is an IR for the thoughts in my head. It's turtles all the way down.

It's really not.

Yes, every executable representation is a representation (though we don't usually call representations "intermediate" if they are designed to be executed directly).

But the hand-wavy idea that because two things are both representations they are "basically the same thing" is so far from true that it is the opposite of insight. The truth is that the differences between representations is one of the deepest concepts in compilers and VMs.

For example, the entire difference between asm.js and PNaCl mostly boils down to the differences between their two different representations (a modified LLVM bitcode vs. a JavaScript subset). If these two things are "basically the same" then asm.js and PNaCl are "basically the same" too.

I noticed the shift from the parent's "software" to your "content." The distinction is critical. Most web pages are content, i.e. what's worthwhile in them is their media (text, images, video, etc.), and not their code. What draws us to HN is its content, and we appreciate its minimalist aesthetic, i.e. if it it used WebGL or something it could only be made worse.

As a content delivery platform, the web is unparalleled, ridiculously good. I have paid for content (for example, NSFWCorp), and will do so again in the future.

But as a software delivery platform, the web is unproven if we are to be kind, and crap if we are to be honest. Web software is fragile, limited, and subject to the whims of the site maintainers, who may modify it without warning, or even remove it entirely (e.g. Google Reader). I have spent hundreds of dollars on native productivity software, games, etc. but I have yet to spend a dime on a website for its JavaScript.

That may change in the future, but I doubt it: any program that's a sufficiently good web app can be rewritten as a desktop app with more capabilities. Ultimately the web may be the go-to place for trivial or gimmicky software, but the most powerful apps will be peers to the browser.

You're right, its more about software, less about content (but the line between software and content is blurry anyway). But it is becoming harder and harder to actually distribute software to user's desktops or mobile devices since these platforms have either been closed from the beginning (iOS, game consoles), or are quickly starting to become closed (OSX, Windows8). You can no longer simply send a download link to your users, or have your own download website with a 3rd party payment provider. The user has to jump through a comical amount of hoops to get the app running (Do you really want to run this extremely dangerous software downloaded from the interwebs? Administration rights are needed to install this software!, etc etc etc etc... its a travesty).

Everything has to go through the centralised, closely guarded app shops. You'll have to go through silly certification processes to get your app into the app shop and if the platform owners (or some minion working in certification) feels like it, they can just remove your app without warning.

Compare this to a web app. You deploy the stuff on a web server of your choice, the user clicks on a link. Done.