Hacker News Reader

Comment by dherman | Hacker News Reader

Nobody is going to agree to standardize the internals of their JS implementation. Competition for JS performance remains high, engines change their implementations all the time. Engine implementors do not want to, and should not, expose their implementation internals.

Instead, what people really want is a standard semantics they can target that isn't tied to any one vendor's implementation details. That's the crux of a VM, and that's what asm.js is providing.

View on HN

Sorry, I did not explain my position accurately. When I said that JS VMs are not standardized, I was not arguing that they should be (that is in fact a terrible idea), I was responding to the poster above who said that since we (a) already have a JS standard and (b) browsers have JS VMs, that we already pretty much have what I was arguing for.

I also agree that standard semantics is what people really want. Asm.js seems like an interesting project but one of the issues that (I like to think) the VM approach would solve is that the semantics could be more low-level. Why do I think that that is a good idea? Well ideally, one would not have to wait for different browsers to implement say websockets, but the websocket functionality could be simply implemented by the website as a library which would use (presumably secure) lower level primitives of the VM to achieve the websocket functionality. (If that sounds vaguely familiar to the microkernel idea, it's not just you :-) ).

What you're asking for is drastically harder to achieve from a security perspective. If we didn't care about security, we could just standard the Linux syscalls or something and call it a day. :) But what we're doing here is providing the low-level computational model but still only providing attenuated access to system facilities like the network through standardized web API's.

I would not say 'drastically'. I guess arguments from the monolithic vs microkernel discussion can be recycled. Basically, security is one of the main arguments for the latter [1] and a lot of OSs that require high security are in fact microkernels. But yeah, implementing the Linux API in the browser does in fact sound like a rather sub-par idea but I was not arguing for that.

[1] http://en.wikipedia.org/wiki/Microkernel#Security

In any other context, would you argue with the guy who has to actually /do/ something, about how hard it will be?

Oh this programming thing looks easy. all you're doing is typing words into the computer. What's the big deal?

I did not say that it would be simple, it would be pretty hard actually. The question is, whether it is worthwhile for people to be investing so much time to make something do something it was not intended to do (I'm not talking just about asm.js but about all the other languages and tools that target JS as well. I feel like these don't really add anything new to the table). And the question is also not whether it is hard or not but whether it is hard compared to similar projects. For example, I'm not convinced that it would be any harder than building a new browser (again I realize that this is super hard, but I'm speaking comparatively).

As to arguing, I prefer the word 'debating'. Also I was under the impression that that is what comments were for. Correct me if I'm wrong.

You have to define what you mean by "intent" for that to make any sense. Here is Dave Herman, one of the authors of javascript, telling you here is asm.js. you can use compilers to compile to it. Is that not intendy enough for you?

> Asm.js seems like an interesting project but one of the issues that (I like to think) the VM approach would solve is that the semantics could be more low-level.

Can you elaborate? asm.js semantics are already low-level, in fact as I said in another comment, they are lower than some VMs (e.g. PNaCl).

Which part of asm.js do you find to be too high-level?

Reply on news.ycombinator.com