@jibal > Yeah, because a) JIT hasn't been invented and b) all machines have the same > instruction set.
A JIT alone doesn't remove VM bloat. It also requires a languare that is designed to be JIT compiled. Everything being garbage collected reference types is not the best idea to make things fast and memory saving. > > you have a very hard time accepting that people can have a very different > > opinion that you have, don't you? >> >> Sorry we don't agree that the web development stack with EcmaScript is the >> future. > > Pot/kettle/black. > > Who the heck is this "we"? That's not what Libman said ... he merely said he > hopes for something different. Are you now speaking for him? > It's a rather obvious fact that ECMAScript isn't going away soon, if ever. That is sad enough, but there is still hope that it can become redundant. > And WebAssembly? That's not a source language, it's not a compiler ... it's > an intermediate language and interpreter, so whoever your "we" is, it doesn't > include Libman, who wrote "Compiled is always better than interpreted, > because no code format will ever be simultaneously ideal for both human > programmers and computers". (The fact that his comment is nonsense, > especially in light of WebAssembly, notwithstanding.) I don't exactly know how WebAssemply works, but I did some research into NativeClient from Google and I am applying the knowledge from there to WebAssembly knowing that it might be wrong. But the projects had the same goal, bring native execution speed to the Web. NativeClient simply put the intermediate language of clang, that clang was using already when compiling any of its source languages, on the Web and added some safe belts around it that prohibited forbidden actions such as system calls. It circumvents the compilation to JavaScript, but still allows save execution on the Web. I am not an expert in security, but it all sounded promising. WebAssembly is as far as I know a successor project that also includes the guys from ASM.js. > And it will allow more languages to be compiled to be used in the browser. > How so? Nim compiles to JS, and that probably makes the Nim compiler simpler > than if it were compiling to WebAssembly. Not necessarily. When Nim compiles to JavaScript you have to write Nim code that is aware of the fact that it compiles to JavaScript. Meaning every object is a reference counted object and stuff like that. The WebAssembly target would allow to think more like a C/C++ developer with pointers to structs and stuff in that direction. > > That is the difference to between hiding complexity and removing complexity. > > Um, no ... see [https://xkcd.com/927](https://xkcd.com/927)/ I don't get that reference to the current context. > The point of WebAssembly is speed. It doesn't remove anything, it only adds > another component to the mix. So then how do you make things faster? By removing unnecessary crutches? I don't think JavaScript is really a suitable intermediate language to compile to. WebAssembly provides an alternative that I can compile to, that allows me to use the computer more effeciently. JavaScript for example doesn't allow me control over memory layout, not even 64 bit integers. > You might want to read > [https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.ue5jxfsvs](https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.ue5jxfsvs) > : I'll take a look at it. > "JS is safe. The ecosystem will thrive for many years. Wasm is about > performance, diversity and innovation, not fragmentation." I have my very own theory here. But I think my personal opinion here would make people offended. > > I also somehow have the impression that WebAssembly is holding back more > > than it needs to, because it doesn't want to scare the people who want and > > need EcmaScript to be important. > > I hope you realize that there's absolutely no rational basis for your > impression, that it's just something you believe because it fits your > preconceptions and preferences. I mean there was already NativeClient. I hoped it would some day be adopted by firefox, too. But it did not happen. I don't know the reasons. Instead WebAssembly needed to be made. At least now everybody is in the boat. That restart is by the way the reason for my impression.
