What is Reddit's opinion of
WebAssembly?
From 3.5 billion Reddit comments
➔ WebAssembly website
By popularity on Reddit, this Service is:
67 reviews of this app found across Reddit:
> I've yet to see "Why I chose Assembler over javascript", I'd love to read that
Here you go. :D
Do you really think "everyone still prefers javascript" because it's such a great language?
Perhaps it's just because web browsers, with their de facto Javascript VMs, are everywhere - and that's where software makers want their software to run.
Perhaps the reason you're seeing all of these new / alternative languages that transpile to Javascript are because "everyone" is getting tired of how bad a language Javascript is, and "everyone" wants something better.
Perhaps similar forces (dissatisfaction with Javascript as a language and as a VM) are what's causing technologies like WebAssembly to come into existence.
I applaud the pioneering spirit of those willing to seek out new and possibly better ways to get work done - and to share their successes, and their failures. We don't need to find a holy grail. Finding something merely better (or in the case of Javascript, less terrible) is good enough.
Why wasm? Imagine vlc.js being a thing. Suddenly you wouldn't have to worry about whether your browser supported some obscure file format and it'd be able to play any file that's ever existed.
Or take a look at how far the project to port Unity to web assembly has already come
Rust uses LLVM as it's backend so it's already fully supported by Emscripten. E.g. This article shows how to write a browser-based game using Rust, Emscripten, and SDL2.
Beyond the prototype/experimental UI frameworks as shown in the OP that's as far as any language has got with WebAssembly so far, because right now it's only a Minimum Viable Product. But when DOM manipulation (and garbage collection) get added to the spec then it really will take off. (And I suspect what will happen then is that frontend web developers will suddenly find their space invaded by the Enterprise Java army... which would be a fittingly ironic retribution for putting Javascript on servers IMHO :P).
Anyway, I'm certain that once there is an official DOM manipulation spec then any serious language will have bindings to it. Can't see there being too much demand for Rust-based web developers myself, but who knows.
It depends what part of 'web development' you are talking about. There are several server side frameworks like Perfect and Vapour for doing back-end development in Swift
At the moment, there's no real way of doing client side development in Swift. Keep an eye on Webassembly though...
> So I understand that WebAssembly is based in JavaScript sort of
No, WebAssembly is a new portable, size- and load-time-efficient format suitable for compilation to the web. WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines (LISK). WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.
https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6 What is WebAssembly? The Dawn of a New Era
>> WebAssembly adds things that most JS developers would agree we don’t need in JavaScript. We may still get those things, but not because we need them for JavaScript code. We’ll get them to support compiling from other languages which use them.
>> WebAssembly gives us an alternative compile target — One specifically designed for that purpose.
>> With WebAssembly and an accompanying set of tools, programs written in languages like C/C++ can be ported to the web so they run with near-native performance. We expect that, as WebAssembly continues to evolve, you’ll also be able to use it with programming languages often used for mobile apps, like Java, Swift, and C#.
I think that's valid but shortsighted. I imagine that a shared library standard will emerge to solve the static compile issue. I think modules are the start of that. Browsers vendors will basically end up shipping the most common modules and caching others.
> Can't we have something like JVM for the (browser) masses including javascript?
That's exactly what WebAssembly is; and is being developed and will be supported by all the major browsers.
My understanding is that this isn't true. It's the other way around. See http://webassembly.org/docs/faq/
> WebAssembly minimizes costs by having a design that allows (though not requires) a browser to implement WebAssembly inside its existing JavaScript engine (thereby reusing the JavaScript engine’s existing compiler backend, ES6 module loading frontend, security sandboxing mechanisms and other supporting VM components).
and
> ## Is WebAssembly trying to replace JavaScript? > > No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web.
But we need to hurry up! I read in a blog that the next version of internet will use WebAssembly[1]. I really do not want to make a second rewrite after the update.
Probably I will help, currently I now two programming languages: HTML5 and CSS3, and I am in the process of learning TypeScript, that is like JavaScript but from Microsoft, and with better types!
Bitcode doesn't actually make target architecture irrelevant. Bitcode is LLVM IR, and LLVM IR is not architecture independent, in general. The language compiler frontend can and will end up generating different LLVM IR depending on the final target architecture. For C (and family) it's pretty much impossible to not bake-in architecture specific details into the generated LLVM IR.
The WebAssembly guys have an FAQ entry on why they don't use LLVM Bitcode for their format, and it's basically because LLVM Bitcode is non-portable.
LLVM isn't a language; it's a toolkit with a complex intermediate representation that has many more moving parts than wasm, some of which are less efficient. The name may contain "VM" but that's a misnomer; it's no more a VM than GCC is. In particular, LLVM's intermediate representation is not portable.
LLVM can (and does) work in tandem with webassembly.
As to the inefficiency - are you referring to the variable-length integer encoding issue - https://github.com/WebAssembly/design/issues/601 ? Because that sounds rather minor; it was rejected for a reason, after all.
Edit: actually, the webassembly FAQ specifically has a section titled Why not just use LLVM bitcode as a binary format?
Funny enough we now have a standard binary executable format called Web Assembly which might actually replace javascript. The upside is people could use the same backend language they use to develop the browser frontend.
Asm.js is a subset of Javascript. Any browser can run it [because it's just javascript]. Many browsers have made sure to optimize for it. Wasm is a binary format. Support for it is nascent and older browsers will not be able to support it natively.
There's some hope even for older browsers though as I think a JS-based interpreter can be made to compile wasm code. Though at that point maybe best to keep two copies on hand on the server.
P.S. I am not a web developer!
I was under the impression that asm.js was what you're describing and WASM was a new standard bytecode to represent an AST. This seems to be supported by the docs. Am I missing something?
The current approach would be to use WebWorkers for individual Wasm modules.
As /u/ElvishJerricco already noted, threads are a planned feature, high on the list
As a web developer, I urge you to reconsider. I'm building games for the web and I'm going to rely on the latest web standards because they make my life way easier (e.g. WebAssembly, which is brand new in FF 52 and will continue getting new features). If your browser isn't new enough for the things I use, you won't be able to access my content, and I'm sure plenty of other sites will do the same.
So the WebAssembly people are delusional?
>Is WebAssembly trying to replace JavaScript?
>No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations:
With WebAssembly becoming a thing I would say it would be worth it to learn c++ and and web at the same time. You can also use c++ to write nodeJS add-ons. But this is kinda jumping the gun to just learning. I would agree with ministryofsound, pick one that you like more and focus on it for the time being until you become more comfortable with it, then try to venture to new things.
We all learn differently, so ultimately do what works best for you. I started learning c# to automate task at work, and part of the automation included web automation. I discovered Selenium, which is an extension to firefox used for web automation. This got me in to starting to learn javascript, as I could in c#, write a string of javascript code that selenium injected in to the browser to be executed. I ended up leaning more towards javascript as I liked it more.
Last recommendation I would have is, think of a project or task you want to do/solve and work on it. It doesn't have to be anything fancy or complicated, but having a goal in mind will help. I have seen many people try to get in to programming and fall off fast. Most of the time it's because they just start using code academy and other tutorial sites. which are decent for introductions, but start to become stall cause your not really working on accomplishing something. For me, I was able to stick with it because I wanted to get something done to make my life at work easier, and just kept searching for answers, and able to see the results along the way.
Rust can compile to WebAssembly (not the same as JavaScript!) but:
- It's very early days yet, both for the WA spec and for compiling Rust to it. Neither are even close to being production-ready yet, but you can have a play around with it.
- There's no frameworks available (that I know of) that'll allow you to make a single page app purely in Rust. I hope someone does come up with something like that once things are a little further along, though!
I'd recommend checking out Elm if you're looking to write a single page app in a strongly-typed language - it's a lot more Haskell/F# inspired than Rust, but they share a lot of concepts.
(On an unrelated note - can people please stop downvoting honest questions? Just because the answer seems obvious to you, doesn't mean it is to everyone else!)
> which is designed with assumptions that js will compile to it
Is that true? I thought wasm and JS weren't directly compatible, for the same reasons that typescript compiles to javascript but javascript doesn't compile to typescript. I thought WASM was defined strictly so that you can make assumptions about things like types and such, which you can't do with javascript.
> and that bytecode will run in js vm.
~~No it won't? WASM doesn't run in a VM, that's the entire purpose of it - it's as close to bare metal as you can get.~~
I'm slightly off here, WASM can utilise a lot of the features of the JS VM but it isn't the same as translating the bytecode to the same bytecode JS gets trasnlated to.
If you're talking about http://webassembly.org/docs/c-and-c++/ that just mentions porting from c++, and that you can link in normal libraries like OpenGL with dlopen (which behind the scenes adds an import, and the compiled module).. then of course OpenGL calls can be routed to WebGL. You don't need to use it, the web Assembly specification does not rely on it.. only the imports and the actual stack "bytecode" (or text) of the web assembly. The actual MVP (http://webassembly.org/docs/mvp/) does not mention c/c++. I've done research too. :) .. but yeah! Thanks for the good wishes! Good luck and have fun as well :)
I'm a bit late to the conversation here, but something like this is being designed right now. It's called Web Assembly
Basically, it's a low-level language designed for use by web browsers. What this means is that we will be able to write our client-side code in whatever language we want, and then compile it down to Web Assembly. This will open up opportunities for new languages other than JavaScript to be used.
Web Assembly is currently being developed as a standard through the W3C with active participation from all major browser vendors.
You can read more about it at webassembly.org
Tagging /u/Signal_Beam in case he's interested in this answer
Apparently it will eventually have some sort of DOM API (source). There must already some way of setting up a rendering pipeline, considering the WebAssembly.org demo page is a Unity game.
I just read a bunch of info about it on http://webassembly.org/ and wikipedia, then read my way through the spec. Had to ask a few questions on the github issue tracker to clarify bits, it's not always easy to figure out how different parts of it should interact just from the spec.
The real learning experience was writing nanowasm.
Obviously you know nothing about WebAssembly or you never would have said that.
>Is WebAssembly trying to replace JavaScript?
>No! WebAssembly is designed to be a complement to, not replacement of, JavaScript.
Everything is compiled into wasm. Agree though that most standard c++ libraries will require refactoring for EOS smart contract. But from security standpoint wasm is built specifically to run compiled code sandboxed securely on modern browsers.
>EOS is not that platform. The decision to implement smart contracts in general purpose languages such C++ and Javascript exemplifies a design focus that favors performance and features over security
WASM is the binary format the C++ (or Rust, or any other language in the future) smart contracts compile into.
From http://webassembly.org/docs/security/
>The security model of WebAssembly has two important goals: (1) protect users from buggy or malicious modules, and (2) provide developers with useful primitives and mitigations for developing safe applications, within the constraints of (1).
Haven't read the rest of the article, but as far as the quoted text goes it's plainly wrong.
Btw take a look at this https://github.com/ewasm/design
There is no SIMD support in JS.
There was a proposal for it, but it was dropped.
Wasm will support SIMD, though. It's on the roadmap.
(Dart also supports SIMD, but not when compiled to JS. Works in Flutter apps, though.)
WebAssembly does have access to the WebAPI and DOM, so you should be able to use ARIA tags, populate element bodies, and such.
WebAssembly FAQ (The relevant point is at the VERY bottom)
sure, within reason and common sense. you couldn't make a website that somehow makes faster than light travel possible, for example.
https://experiments.withgoogle.com/chrome is a neat place to go for crazier web stuff. contrary to the name, pretty much all of them work in the other modern browsers these days.
also, webassembly is picking up some steam (http://webassembly.org/), which would theoretically allow you to make any program you could outside of the browser, within the browser.
I am sorry if I missed something. But isn't one of the main points of Web Assembly writing in C/C++ and compiling to WASM bytecode? I get that it doesn't completely replace JavaScript, but couldn't whole elements of a site be replaced with C++ written WASM?
That least ways is what I am getting from their website... http://webassembly.org/getting-started/developers-guide/
>I think wasm is similar to assembly
Is that opinion based on actually reading the spec? http://webassembly.org/
>if you have a c program and compile it to wasm, you compile your code to a assembly language
Incorrect. Assembly is native code (well, machine code is native code, but let's not get that nitpicky now). Web Assembly is not.
Web Assembly is this:
;; simple.wasm (module (func $i (import "imports" "i") (param i32)) (func (export "e") i32.const 42 call $i))
in binary form.
And it's designed to be highly optimizable. Whether it is compiled to native code in every case, every time, is implementation dependent. That is not defined by the spec at all.
March is when the "MVP" was finalized and many browsers shipped it in their stable release, but maximizing performance is a post-MVP concern.
MVP: http://webassembly.org/docs/mvp/
post-MVP: http://webassembly.org/docs/future-features/
Implementors can probably eke out more performance using only what's specced out for the (now-live) MVP, but future enhancements would allow them to go further.
Never heard of WASM. Went to http://webassembly.org/ and I still have no fucking idea what it is. Why do framework websites do this? They spew out generic catch words like "fast" and "safe" and nonsense but never once mention what it does.
> WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.
The fuck does this mean? Is it JS? Is it a new language?!? ?!?!?!
> is there a general plan to have IO/DOM manipulation with wasm only when it becomes ready for production level code or javascript glue will be kept as the method to invoke wasm functions?
I've read in multiple places on the internet that it's on the roadmap but when I look for it i don't see it. It seems to be folded into the garbage collection section, which worries me. Why would garbage collection be required to interact with the DOM?
Then you need a standalone disassembler. Such tools exist.
Again, obfuscated/minified JS is equally unreadable without some sort of tool to give it more reasonable formatting.
There is nothing safe guarding that in JavaScript either, you have browser or implementation specific magic there too. It's essentially just a subset of JavaScript which can execute much much faster delivered in a different way.
http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web
That was fun. Thank you for the link. First time I've heard of wasm. Now this might actually be big.
>Will WebAssembly support View Source on the Web? > >Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool.
Source: http://webassembly.org/docs/faq/
What? That is pretty neat! Am I going to see an explosion in web development soon? Open code makes it easier for filthy casuals like me to learn from other's code.
Allowing other languages to target JS may be a boon for some developers, as it makes writing them a bit more accessible (to some).
The most notable development in recent times is that of the introduction of WebAssembly (wasm). Its minimum viable product is now in Firefox and Chrome (and IE? I forget), and it has additional planned features coming. I don't know if it's yet available within extensions.
Wasm aims to be a compile target for all sorts of languages, making it attractive to non-JS developers, but one of the areas where it shines is in performance, being able to compile non-garbage collected (typically precompiled languages) such as C/C++ and Rust. This allows for near native performance.
edit: I've confirmed that wasm is fully supported in extensions.
Native client will not be part of Firefox. They should port the NaCl Chrome code they have to webassembly which is an open cross browser standard.
You can compile other languages to JavaScript, like C and C++ using Emscripten. You can even compile Python to JavaScript. Plus as you said there is http://webassembly.org/ . I think that's the future. It's silly to be forced to use one language if you want code to run in a web browser. Though for the present, I don't think you can totally ignore JavaScript if you want your code to closely interact with a web page.
There is no GC yet.
http://webassembly.org/docs/faq/#is-webassembly-only-for-cc-programmers
You can of course run an entire VM inside Wasm, but that's pretty wasteful. E.g. with Lua you add about 200 KB and with Ruby you'd add a whopping 50 MB or so.
A trimmed down JVM is around 1.5 MB and a full one is 10+. I suspect C# would be similar.
Thank you for the edit. Posting this as another top-level comment for more visibility.
That's also not too interesting because without actually using the result of x, you compile it out entirely, which doesn't give any insight into the actual performance. Adding something like printf("Final value of x=%f\n", x); after the loop keeps it from being optimized away and should give you real numbers.
Now, when I run it with -O0 I get 5-8ms. When I run it with -O2 I get similar results. Looking at the differences in the generated .wast files, the loop body is trivial enough that there's not much for the compiler to actually optimize, so the time taken is fairly similar.
I was able to get it to take 1600ms though, and that was by using the binaryen interpreter. Turns out interpreters are substatially slower than JITed code.
What are you testing it with? If you're trying it in a browser, you need to be using either Chrome Canary or Firefox Nightly to have native wasm support enabled, and then you need to set the experimental flag in settings. If you look at your dev console it should say which binaryen methods it's tried. The demo page on webassembly.org has instructions if your browser doesn't have wasm enabled.
If you're trying it from command-line, V8 requires the flag --expose-wasm to enable native support. I assume the other js engines use something similar.
AssemblyScript : compiles a strict variant of TypeScript (basically JavaScript with types) to WebAssembly
>EOSIO based blockchains execute user-generated applications and code using WebAssembly (WASM). WASM is an emerging web standard with widespread support of Google, Microsoft, Apple, and others. At the moment the most mature toolchain for building applications that compile to WASM is clang/llvm with their C/C++ compiler. For best compatibility, it is recommended that you use the EOSIO toolchain.
So yeah, that's the definitive answer. If you can find a compiler for C# to wasm you're gucci. Essentially any lang that has a compiler to wasm is fine for dev. JS should have one. idk about C#.
can someone give me an ELI5 of web assembly?
The "overview" page on http://webassembly.org says:
"WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web"
which doesnt mean a whole lot to me. Is this meant to replace javascript?
Yes. WebAssembly will be enabled in NodeJS, the LISK's JavaScript engine, soon. With WebAssembly you can compile C/C++/Rust (many more to come) into portable WebAssembly modules and integrate with JavaScript. Traditionally, using C/C++ libraries (e.x cryptography libraries) in JavaScript code requires you to code NodeJS extensions. You must know C/C++, and NodeJS internally. C/C++ is not portable. Packaging and shipping such libraries are not easy. Compiling C/C++/Rust/D code into WebAssembly modules and call it in JavaScript is much easier and more productive.
Also, WebAssembly can bring new features that JavaScript does not support natively to JavaScript engine: thread, SIMD ... That is not possible (or require a lot of work) with current technologies
Citation needed. Because apparently you know something the actual definition of WebAssembly doesn't.
WebAssembly is not Javascript. WebAssembly is designed, specifically, to not be Javascript. It's a completely separate stack machine with it's own not Javascript binary bytecode format.
The Wasm MVP went live in all modern browsers in March. You still need JS to talk to the outside world. Since it's being kept platform-agnostic, don't expect to ever see this change.
> if only there was a way to communicate with the browser APIs that didn't involve writing tons of wrappers
> Probably not gonna happen any time soon.
I agree, it's not on their list of post-MVP features:
http://webassembly.org/docs/future-features/
Although, I do think this is an area where the community can fill in the gaps.
WebAssembly, hopefully.
Basically instead of everything like Elm and Purescript having to compile down to JavaScript, everything will compile down to webasm, and we can move on from the poorly designed language that is JavaScript.
>Ah... the difference is that tools like Adblock Plus can either edit the JS insitu or block those external requests by inspecting the JS text. With WASM that would not be possible.
No, Adblock works by installing a listener into the webRequest API of the browser (you can read that up on developer.mozilla.org). ADB will then get information in any stage of a HTTP request made by a website and can decide on how to proceed, it can redirect, block or just log the request.
There is no reason this would not work on webassembly either, foremostly because it'll likely use a JS shim for the web request.
>WebAssembly.instantiateStreaming
afaict this function streams a webassembly binary, which in theory could be used to stream an add but again, ABP can just block the request through the webRequest API (and chrome equivalents)
>Also: http://webassembly.org/docs/dynamic-linking/
This looks like it only works on already loaded and local WASM modules.
>The spec is still in flux and who knows, maybe the W3C and those involved (Brendan Eich) will come to their sense and make some changes. They failed to do so for DRM. So until then, I personally am very displeased with the direction things are going.
Maybe it helps that you have no idea how ABP intercepts requests? It doesn't edit JS insitu or inspects JS, it just loops any HTTP request through a filter via a browser API. This works, atm, regardless on how this request was made.
> there is no difference here. A same domain script can also simply make secondary calls.
Ah... the difference is that tools like Adblock Plus can either edit the JS insitu or block those external requests by inspecting the JS text. With WASM that would not be possible.
> No because atm WebAssembly cannot make network calls on it's own
WebAssembly.instantiateStreaming - the stream could easily be an add
Also, call_indirect can be made to do it presently
Also: http://webassembly.org/docs/dynamic-linking/
They are also working on a ABI for making WebAPI calls that works similarly to WebAssembly.instantiateStreaming
> it requires a JS shim to do that
That's the JavaScript API and yes you are correct that does indeed go through the browser. The other API's don't.
The spec is still in flux and who knows, maybe the W3C and those involved (Brendan Eich) will come to their sense and make some changes. They failed to do so for DRM. So until then, I personally am very displeased with the direction things are going.
Keep going. You're only adding more reddit fodder for me.
EDIT: For the braindead
>Is WebAssembly trying to replace JavaScript?
>No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations
You conveniently left out the "implement" word there. They want to IMPLEMENT the mvp with roughly the same functionality as ASM.js, primarily aimed at c/c++.. please go here (http://webassembly.org/docs/mvp). That page lists the modules, instructions, binary format, etc.
Edit: would you like me to also explain what mvp means while I'm at it? Or are you good now?
Edit Edit: Sorry, but just tired of having to explain when I shouldn't need to. #oldmanproblems
It relies on WebAssembly support, which is only enabled by default in fairly recent browsers. If it doesn't work, try getting the WebAssembly tank game demo at http://webassembly.org/demo/ to work first.
The editor is simplistic but gets the job done. I've created all the database content so far with it. Previously it only ran on Linux, which was a big barrier, but now anyone can start modeling their favorite transitions and contributing them, to make the map better. :)
For more info about the project, see https://github.com/Eelis/GrappleMap/
Yes, I think it's intended to be purely a compilation target, not something you would actually write yourself.
Basically, you could write C++, Java, Python, or even JavaScript still, run it through a wasm compiler, and get high-performance code that runs in a browser.
It's intended to be just that, high-performance code. It'll allow for things like fast applications and games. Here is a Unity game running natively in your browser (if you have an up-to-date browser like Chrome)
Right now this Python VM is just on the future plans. I can only link you to the list of tools they aim to support.
http://webassembly.org/docs/tooling/
I expect there is no code yet, I couldn't find it on their github, but there are so many people involved it's possible it just hasn't found its way to the repo yet.
This is where the browser and WebAssembly could eventually end up. There are already a fair number of demos showing this technique.
Here are a couple demos:
To my knowledge there are no full commercial web assembly games ye as the spec is still very new. But think about it. Not you could have Proprietary games running in the open source sandbox of your browser!
edit: formatting
> LLVM IR isn't as golden as you think - see http://webassembly.org/docs/faq/ "Why not just use LLVM bitcode as a binary format?" for more details.
LLVM is of course more elaborate and evolving instruction set.
But my question wasn't "why didn't they use LLVM" so this FAQ doesn't answer my question: why is WebAssembly so much slower.
I'm not asking about fringe features like "fast-math" or proprietary vector instructions, but basic algorithms implemented on top of baseline instructions available across all modern CPUs.
> Again, nobody else you're comparing to has the code->abstraction->recompile->run model because the ones you are comparing to are actually not designed with the portability abilities you describe. Also I think it's still actually at the code->abstaction->abstraction->recompile->run stage until emscripten has a truly native pipeline. Just because it has the name "assembly" in it doesn't mean it's low level to the end machine it actually runs on :).
AFAIK Emscripten is not part of any production WebAssembly pipeline shipped in browsers today. This was only necessary for bridging WASM to ASM.js before WASM support was available.
Adding abstraction levels can be harmful to performance, but not by default, it has to be demonstrated why that'd be the case. Especially not when the abstractions are so similar, and mostly about mapping one "add" instruction to another "add" instruction, so this alone can't explain the slow-down IMHO.
LLVM IR isn't as golden as you think - see http://webassembly.org/docs/faq/ "Why not just use LLVM bitcode as a binary format?" for more details. As it mentions PNACL tries to avoid some of the problems but the solutions aren't perfect which is why WebAssembly ended up being an LLVM target. The rest of that documentation also does a good job at explaining design decisions and resulting limitations as well.
> WebAssembly doesn't make use of any existing parsing, specializing, optimizing JIT logic, as that's specific to JavaScript.
Specializing it coexists with, parsing it does not share, JIT it should share a significant portion in the future when JIT is added to WA. Remember JS engines these days are multi-level multi-step, it isn't just parse->JIT and the components inbetween can be made shared.
>The only thing it can re-use is the infrastructure around the machine code emitters, so this implies those emitters are half the performance of any other emitters seen throughout the industry. So why is that the case?
Again, nobody else you're comparing to has the code->abstraction->recompile->run model because the ones you are comparing to are actually not designed with the portability abilities you describe. Also I think it's still actually at the code->abstaction->abstraction->recompile->run stage until emscripten has a truly native pipeline. Just because it has the name "assembly" in it doesn't mean it's low level to the end machine it actually runs on :).
Most people who'll use it in the foreseeable future will probably just use Wasm modules for heavy computations and continue to write the application itself (well, the entry point and the UI) in JS/TS/Dart/etc.
Hopefully we will see better web based MMORPGs in the future. The major browser vendors are currently implementing webassembly. Unity is starting to support the standard as well. This could be a revolution in browser based F2P games.
http://webassembly.org/demo/ (choose asm.js to play.. so it is cheating.. but still)
I don't know for sure, but I don't think the call stack is entangled in the linear memory area. For example, the section on local variables suggests that local variables are kept separate from the linear memory space, so certain kinds of pointer tricks would not work. I suppose a compiler for a language like C could use the linear area to pass parameters by emulating a call stack, thus preserving the ability to overwrite the wrong data. But I think the actual control stack is managed separately, so you can't for example overwrite the return address of your stack frame.
So at least some exploits won't work.
From the homepage
> WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines.
It doesn't have to run on top of javascript virtual machines, but it's most likely going to be sharing a lot of the same things, at least until javascript goes out of fashion. Which is why I said sorta.
> working on web assembly to get rid of [js]
From the FAQ on http://webassembly.org/:
>### Is WebAssembly trying to replace JavaScript?
>No! WebAssembly is designed to be a complement to, not replacement of, JavaScript.
Could you? Of course, you can write a browser to interpret web pages however you want. Indeed, there is a plugin to allow embedding Java applications in web pages, but it is now falling out of favour, and browsers are dropping support.
That's not because Javascript is a perfect language and there can be no better alternative, but because Javascript has become the standard. And it's important to have standards for the web, because if everybody's browsers implement a different set of languages (or implement the same thing with different semantics) then developers would have to reimplement their application in several languages to ensure support for all of them.
Besides, as much as I hate JS, I don't think replacing it with another language is a good solution because all languages have their flaws. Instead, I think it would be better to have a common bytecode that any language can use as a compile target. And this is being worked on.