Data will come, later. Sadly this is all too preliminary at this point.
mark foleysays:
Interesting results. JS optimisation has been a focus for browsers for many years of course, so there may be quite a bit of headroom to optimise webassembly to equal and exceed javascript performance in the long term
Mesays:
You can be fairly certain that the main motivation is to increase code obfuscation… It’s probably harder to reverse engineering a WA program than an JS, even when obfuscated. So if you are Google, trying to protect your Gmail and maps sources, will you go for WA once it is widely supported?
Hilmar Gústafssonsays:
if you are on a slow network connection, JavaScript programs will start faster.
This is not necessarily true, as WebAssembly can be compiled in batches, not to mention Mozilla have a tiered compiler in firefox which is capable of compiling and executing WebAssembly faster than it is downloaded.
WebAssembly (compiled with full optimization) is slower than JavaScript during execution.
Interesting blanket statement. I would very much like to see the data for this. Especially considering the fact that work has begun on replacing computationally-intensive nodejs packages written in JS with WebAssembly equivalents. How much of your benchmarking is affected by e.g. JS -> WASM interop? What kind of code are you comparing? Have you considered that WASM is still in MVP stages, and the different optimizations that multi-threading will bring?
You seem to state that the only use-case here is gaming, but what about other computationally expensive applications, such as image editing programs, modelling programs, and the like?
As you can see WASM+Rust version is now around 15% faster on SpiderMonkey and approximately the same speed on V8.
Andrew L Arnottsays:
Keep in mind while perf testing that it’s a recognized problem that js is faster than web assembly when interacting with the DOM/js world. Improvements are being made in this area, but for now web assembly is best when most of the code calls more web assembly, with few entry and exit points.
Matthew McMahonsays:
One thing to keep in mind when designing your tests is that the browsers haven’t optimized calls between JS, WASM and Native Code, yet. If your test is shuffling data between WASM and the DOM using native method calls, you may be measuring the context switch, and not code execution time, for example.
I would say that we have WASM because these questions were already asked and answered by it’s predecessor, Emscripten. Emscripten was a personal project by Alon Zakai, a developer at Mozilla. It got an early shot in the arm from the game community when Unity3D used it to replace their exising ActiveX control for previewing games on the web. It does this by recompiling your dot net assemplies using il2cpp, which is then compiled to WASM. The labor intensive part involves pushing a button and waiting.
All c/cpp based projects are a pain to set up. So are web projects. All complex projects can be labor intensive. My tool chain compiles Vala to C to Wasm. The step from C to Wasm is not the hard part. I use VSCode with the CMake plugin, and I type Ctrl-B t build, and then F5 to launch my application in chrome. Or I can use the console to run it my desktop – either linux or windows 10.
Wasm does not replace javascript. If you need a form to collect info and post it to a server, us conventional javascript. If I wanted to write a telephony app that runs in the browser, I’d pick Wasm. Use the right tool for the job – a great example (all the early stuff is game oriented) is Pico-8. It’s a toy 8bit graphpics game platform running on Lua. So to run on the web, they copiled Lua with Wasm, and run their Lua platform in the browser.
Steven Holmssays:
Without methodology and/or data, you’re talking out of your ass. Without being able to repeat the tests, why should anyone trust your word, especially when there are repeatable tests showing opposite results?
I’d recommend not publishing such claims until you’re ready to share details to back it up.
Was this kind of rude language necessary to express your (otherwise healthy and sensible) skepticism?
I provided preliminary conclusions, clearly labelling as such. I clearly indicate that there are contrary results and I provide several links.
It is totally fair to criticize me for not providing evidence. However, read through the comments and you will notice that several commenters provide supporting evidence that WebAssembly is not (yet) a JavaScript killer.
Fierrosays:
If you you’ve read any of Daniel’s past posts, you’d know that he always provides the code and data.
This post is explicitly labeled “preliminary.” Patience.
brucesays:
Thanks for pointing this out. The first that I heard of Daniel was when this blog was promoted on the Google News feed. On my phone, in the news app, Daniel’s credits and history don’t even show up. I assumed it was by yet another another trade journal pundit.
I have no doubt that WebAsm is already faster for JavaScript in some scenarios, particularly those that leverage certain patterns that are slow in JavaScript (someone better in JavaScript can explain what those are: although the list has in some sense gotten smaller over time as the compilers have gotten better). That you didn’t find any such examples is interesting, although of course it depends on the details on what benchmarks were used!
It also doesn’t surprise me there are benchmarks where JavaScript is faster: there has been an order of magnitude improvement in JavaScript performance over the last few years, and a couple of orders of magnitude if you go back further. An incredible amount of resources have been poured into the JavaScript JITs: the pace of development has been very fast compared to something like Java’s HotSpot.
Now WebAsm is starting from a faster baseline, since some of the optimization is already done at compile time – but the WebAsm JIT and runtime is in the very early days, and no doubt has a ways to go.
I don’t think WebAsm is positioned as a “replacement” for JavaScript, even by most of its proponents. It seems that its primary purpose is as a generic target for compilers, so you can write in any language and then compile it “for the web”. You could already do this with JavaScript, of course, but JS is far from an ideal target for this and the mismatch with many languages is large: it also distorts the design of languages that target JS in that they may compromise the user-facing language in order to cope with limitations of JS as an intermediate language. Woe unto anyone who tries to debug in the browser something written in a language that compiles to JS.
So I think the more interesting question for the proposed uses of WebAsm would be whether it makes a better target for compilation, rather than whether a program written in C and compiled to WebAsm, is faster than a hand-written JS program (I do expect WebAsm to usually be faster even here – but maybe not yet).
Dmitry Vedenkosays:
Your post is based on some fundamentally wrong assumptions.
(And not only with JS being extremely slow and memory intensive even after multimillion investments into the JS JIT compilers. As an example, you can check the performance and the memory consumption of behemoths like Gmail, Facebook and Slack.)
First of all, binary modules are not about size or the load time improvement. Moreover, until the very latest Chrome and Firefox builds loading WebAssembly modules was massively slower, then the JS code. The problem was with a single tier compilation for the WebAssembly, which had to optimize the application at once. Instead, binary modules are just a portable bytecode for the JS VM itself. This allows developers to execute the code written in the different programming languages inside the JS sandbox, thus solving the security issues with similar technologies from the past (like Flash, ActiveX etc). And despite your skepticism – there is a lot of code written for the front-end development as well as lots of developers using languages other than JS.
The key feature of the WebAssembly is the predictability of performance. It is difficult to achieve it using the languages with GC and almost impossible with dynamically typed languages. Before the JS function gets JITed into an optimized set of the machine instructions, it has to be executed thousands of times with the exactly the same types of the input arguments. When this condition fails – function execution falls back to the interpreter.
This behavior of JIT compilers makes it extremely hard to write the JS vs WebAssembly benchmarks. Usually, benchmark runs the same evaluation thousands of times and, as a result, easily gets to the fastest path. As a result, you are more or less benchmarking one compiler to another. On some platforms, notably on iOS, JS JIT works fantastic and easily beats the similar code, written in C and compiled using Clang to the WebAssembly. However, such benchmarks are not exploiting the weakest parts of the JS compiler and runtime at all and the real world result may be very well different.
In our case, we have a rapidly evolving 500k LOC application, written in C++ (as we have to support clients with the very outdated hardware) which we used to compile to the Asm.js to provide a web version for the client with modern computers. Switching to WebAssembly gave us around 2x performance improvement, depending on the target browser and OS. The very similar results are shown by the Unity3D and Unreal Engines.
To sum up – WebAssembly is best suited for the cases, where you have to process large amounts of data on the clients. Games and image editing seems to be the best fit at this moment of time. The official support of the WebAssembly by the Qt will push things forward as well.
Tim van der Leeuwsays:
I can think of one scenario where WebAsm might make sense, and reduce code size: where some other language is used to write the front-end code, and transpiled into JavaScript.
Java in particular creates large JavaScript files during transpiling (based on my experience with Google’s GWT, several years ago) and if instead of generating JavaScript the Java code can be compiled directly into WebAsm, I expect that sizeable gains can be made.
Holger Rappsays:
The killer argument for WebAssembly for me is code sharing. We have heavy geometric code in our backends in our company and there is benefit to reuse some of these in the front ends, for example pose interpolation for trajectories.
The story around c++ is weaker there, but rust offers a very easy way to compile pieces of your code to WebAssembly and reuse it in the front end. Speed is not a driving force for our work.
Does WASM have any SIMD action? simdjs was canceled. Did you try any SIMD?
Dmitri Vedenkosays:
At the moment, WebAssembly does not directly expose SIMD instructions
Nick Patelsays:
yes, it can be faster with the web assembly, which is faster than Javascript, but with using it, you may face the Epson error code 0xf1
Witeksays:
I do not believe in your statement that WebAssembly is slower than JavaScript. You can create contrived benchmarks where WASM code does a lot of accesses do DOM or JS code, and this can be slow (but recently Firefox made it MUCH faster), but if you have any sufficient piece of computationally intensive code (so any DOM/JS-WASM crossing overheads are negligible), WASM will be almost always much faster.
Programing entire website in WebAssembly with a lot of unstructured code and a lot of interaction with DOM or native JS functions, surely can be slow, but this is simply not a purpose of WASM at the moment.
David McCorriesays:
Surely WASM is not intended for replacing JS functionally generally. Rather it’s intended to open up new opportunities. Until WASM gets DOM access it will be slower than native JS for small functions, or functions requiring many calls to DOM – which spend more time in JS than WASM.
WASM makes sense for large applications that are calculation intensive.
WASM allows desktop apps to be ported to the browser (i.e. AutoCAD). Or cross platform applications to be developed using compiled languages (into WebAssembly, rather than native assembly) with GUI using web technologies (HTML DOM, CSS, JS) – using “Electron” for example (I.e. VSCode.
Webassembly is a nice platform. But in my opinion, JS is best and user-friendly
levusays:
JS is the best language. It is easy, and does the job fast. Other languages may be “slightly” faster but what kind of idiot finds fun coding in C? Its so boring, makes you do unnecessary work.
Dmitry Vedenkosays:
It’s extremely hard to maintain large code bases in the dynamically typed languages. And in some cases, JS is orders of magnitude slower.
Also, there is a lot of software written in C/C++ already, like image recognition and game engines, which can now be ported to run on Web.
True, though lots of web development teams use TypeScript now to solve the problem of managing large codebases in a dynamically typed language – they just use a statically typed superset, TS.
It compiles to JavaScript. (Ideally browsers would run TypeScript directly, since there should be optimization opportunities from the explicit type declarations.)
I like WebAssembly, though I’m skeptical that arbitrary and large C/C++ codebases will run efficiently as WebAssembly by default. There have been mixed results from testing Wasm performance.
Dmitry Vedenkosays:
We do run a 600k LOC C++ based UI application in browsers using WebAssembly, runs good enough even on modern phones.
obesays:
Where is the data that was promised..?
IMO if there is no supporting data then these claims should be deleted or contradicted with an update at the top.
As it is now – it’s misleading (though the comments are interesting).
Sadly, I have not yet good around to update and publish our experiments. It is coming. I am hard working but I have many things on my plate.
Yet I am not going to retire this blog post at this time. The bulk of the post is supported by the comments and by other references. Nobody challenges the fact that Web Assembly can be fat. Or that it may not load much faster than JavaScript. And as was reported a few times, if you need to access the web page (get out of your sandbox), it is going to be slow. And even the claims regarding high raw speeds do not appear to compare code hand-written by good JavaScript programmers with code written in some other language compiled to Web Assembly.
ryansays:
If you don’t know the difference between a statically type and dynamically typed language I cant help you.
You don’t understand how memory works you need to read a book.
The only reason why it wouldn’t run faster is because we have spent decades tuning JS to run on the browser.
obesays:
Hi Ryan,
I’m pretty sure that your reply is not addressed at me, but I’ll answer anyway:
There is no need to be rude.
I don’t think that the claim the author makes is that WebAssembly cannot be faster than JS. I think he just says that it isn’t.
What’s more interesting to me is understanding the type of scenarios in which it’s not faster. I can certainly imagine tasks that would (probably always) be slower in WebAssembly than in JS, such as communication with JS code.
I don’t think that the claim the author makes is that WebAssembly cannot be faster than JS. I think he just says that it isn’t. What’s more interesting to me is understanding the type of scenarios in which it’s not faster. I can certainly imagine tasks that would (probably always) be slower in WebAssembly than in JS, such as communication with JS code.
You are correct.
And, yes, there is no need to rude.
Could, in theory, Web Assembly be smaller and consistently faster than JavaScript. Of course! Working from JavaScript is a handicap for speed and performance. But it is not like other platforms we have are optimal. Nobody thinks that x86 or Windows are optimal. But both x86 and Windows rock because they got so much ressources.
I’d like first to point out that even the advocate of Web Assembly do not sell it as a “faster JavaScript”. I don’t see much in the way of “rewrite your web site from JavaScript to WebAssembly”.
Second of all, yes, JavaScript is a highly optimized target. This is an important factor. It was easy for Java (in applets) to be much faster than JavaScript back in 2000. Today, the gap between JavaScript and Java is much narrower (though Java will still be faster, sometimes much faster).
Though JavaScript has dynamic typing, the actual execution engine has an optimizing compiler than can infer types and optimize accordingly.
JavaScript in the browser does not need to download a runtime library. It has its own.
Could WebAssembly in 5 years be a much faster JavaScript. Sure. But JavaScript is not exactly standing still, is it?
ryansays:
Oh it was directed at you.
I like how you didn’t answer my questions.
If you understand memory management, threading and concurrency. We wouldn’t be posting.
Most JS developers are retarded and don’t know shit about computers.
There is a reason web developers make the least amount.
obesays:
Hi Ryan,
Directed at me?
Didn’t answer your questions? When have you ever asked me (or the author) anything?
That’s why .net core running web assembly is so powerful! Check out blazor!!
Blazor is truly sh*t currently. I doubt it could compete with React or Vue in the next 5 years.
Can you elabote more specifically?
Data?
Data will come, later. Sadly this is all too preliminary at this point.
Interesting results. JS optimisation has been a focus for browsers for many years of course, so there may be quite a bit of headroom to optimise webassembly to equal and exceed javascript performance in the long term
You can be fairly certain that the main motivation is to increase code obfuscation… It’s probably harder to reverse engineering a WA program than an JS, even when obfuscated. So if you are Google, trying to protect your Gmail and maps sources, will you go for WA once it is widely supported?
This is not necessarily true, as WebAssembly can be compiled in batches, not to mention Mozilla have a tiered compiler in firefox which is capable of compiling and executing WebAssembly faster than it is downloaded.
Interesting blanket statement. I would very much like to see the data for this. Especially considering the fact that work has begun on replacing computationally-intensive nodejs packages written in JS with WebAssembly equivalents. How much of your benchmarking is affected by e.g. JS -> WASM interop? What kind of code are you comparing? Have you considered that WASM is still in MVP stages, and the different optimizations that multi-threading will bring?
You seem to state that the only use-case here is gaming, but what about other computationally expensive applications, such as image editing programs, modelling programs, and the like?
I am working on getting actual data that can be reported upon. My comments are preliminary.
You seem to state that the only use-case here is gaming
There are already image editing programs in JavaScript… heck you can write VR games in JavaScript.
The angle I see for gaming is that lots of games are written in C++ or C# which makes WebAssembly compelling.
Especially considering the fact that work has begun on replacing computationally-intensive nodejs packages written in JS with WebAssembly equivalents.
Do we have examples yet where a highly optimized JavaScript implementation was beaten using WebAssembly? Something that went into production maybe?
Nick Fitzgerald reports of a WASM module beating very optimized JS: http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html
Nick Fitzgerald reports of a WASM module beating very optimized JS
The story requires qualification:
Keep in mind while perf testing that it’s a recognized problem that js is faster than web assembly when interacting with the DOM/js world. Improvements are being made in this area, but for now web assembly is best when most of the code calls more web assembly, with few entry and exit points.
One thing to keep in mind when designing your tests is that the browsers haven’t optimized calls between JS, WASM and Native Code, yet. If your test is shuffling data between WASM and the DOM using native method calls, you may be measuring the context switch, and not code execution time, for example.
See this October Mozilla Hacks article for more details.
I would say that we have WASM because these questions were already asked and answered by it’s predecessor, Emscripten. Emscripten was a personal project by Alon Zakai, a developer at Mozilla. It got an early shot in the arm from the game community when Unity3D used it to replace their exising ActiveX control for previewing games on the web. It does this by recompiling your dot net assemplies using il2cpp, which is then compiled to WASM. The labor intensive part involves pushing a button and waiting.
All c/cpp based projects are a pain to set up. So are web projects. All complex projects can be labor intensive. My tool chain compiles Vala to C to Wasm. The step from C to Wasm is not the hard part. I use VSCode with the CMake plugin, and I type Ctrl-B t build, and then F5 to launch my application in chrome. Or I can use the console to run it my desktop – either linux or windows 10.
Wasm does not replace javascript. If you need a form to collect info and post it to a server, us conventional javascript. If I wanted to write a telephony app that runs in the browser, I’d pick Wasm. Use the right tool for the job – a great example (all the early stuff is game oriented) is Pico-8. It’s a toy 8bit graphpics game platform running on Lua. So to run on the web, they copiled Lua with Wasm, and run their Lua platform in the browser.
Without methodology and/or data, you’re talking out of your ass. Without being able to repeat the tests, why should anyone trust your word, especially when there are repeatable tests showing opposite results?
I’d recommend not publishing such claims until you’re ready to share details to back it up.
you’re talking out of your ass
Was this kind of rude language necessary to express your (otherwise healthy and sensible) skepticism?
I provided preliminary conclusions, clearly labelling as such. I clearly indicate that there are contrary results and I provide several links.
It is totally fair to criticize me for not providing evidence. However, read through the comments and you will notice that several commenters provide supporting evidence that WebAssembly is not (yet) a JavaScript killer.
If you you’ve read any of Daniel’s past posts, you’d know that he always provides the code and data.
This post is explicitly labeled “preliminary.” Patience.
Thanks for pointing this out. The first that I heard of Daniel was when this blog was promoted on the Google News feed. On my phone, in the news app, Daniel’s credits and history don’t even show up. I assumed it was by yet another another trade journal pundit.
@bruce
I am not sure how my blog ever got promoted by Google News?
It was on Google Assistant (aka Google Now feed) for people with interest in WebAssembly
Surprising ! I look forward for the full results.
I have no doubt that WebAsm is already faster for JavaScript in some scenarios, particularly those that leverage certain patterns that are slow in JavaScript (someone better in JavaScript can explain what those are: although the list has in some sense gotten smaller over time as the compilers have gotten better). That you didn’t find any such examples is interesting, although of course it depends on the details on what benchmarks were used!
It also doesn’t surprise me there are benchmarks where JavaScript is faster: there has been an order of magnitude improvement in JavaScript performance over the last few years, and a couple of orders of magnitude if you go back further. An incredible amount of resources have been poured into the JavaScript JITs: the pace of development has been very fast compared to something like Java’s HotSpot.
Now WebAsm is starting from a faster baseline, since some of the optimization is already done at compile time – but the WebAsm JIT and runtime is in the very early days, and no doubt has a ways to go.
I don’t think WebAsm is positioned as a “replacement” for JavaScript, even by most of its proponents. It seems that its primary purpose is as a generic target for compilers, so you can write in any language and then compile it “for the web”. You could already do this with JavaScript, of course, but JS is far from an ideal target for this and the mismatch with many languages is large: it also distorts the design of languages that target JS in that they may compromise the user-facing language in order to cope with limitations of JS as an intermediate language. Woe unto anyone who tries to debug in the browser something written in a language that compiles to JS.
So I think the more interesting question for the proposed uses of WebAsm would be whether it makes a better target for compilation, rather than whether a program written in C and compiled to WebAsm, is faster than a hand-written JS program (I do expect WebAsm to usually be faster even here – but maybe not yet).
Your post is based on some fundamentally wrong assumptions.
(And not only with JS being extremely slow and memory intensive even after multimillion investments into the JS JIT compilers. As an example, you can check the performance and the memory consumption of behemoths like Gmail, Facebook and Slack.)
First of all, binary modules are not about size or the load time improvement. Moreover, until the very latest Chrome and Firefox builds loading WebAssembly modules was massively slower, then the JS code. The problem was with a single tier compilation for the WebAssembly, which had to optimize the application at once. Instead, binary modules are just a portable bytecode for the JS VM itself. This allows developers to execute the code written in the different programming languages inside the JS sandbox, thus solving the security issues with similar technologies from the past (like Flash, ActiveX etc). And despite your skepticism – there is a lot of code written for the front-end development as well as lots of developers using languages other than JS.
The key feature of the WebAssembly is the predictability of performance. It is difficult to achieve it using the languages with GC and almost impossible with dynamically typed languages. Before the JS function gets JITed into an optimized set of the machine instructions, it has to be executed thousands of times with the exactly the same types of the input arguments. When this condition fails – function execution falls back to the interpreter.
This behavior of JIT compilers makes it extremely hard to write the JS vs WebAssembly benchmarks. Usually, benchmark runs the same evaluation thousands of times and, as a result, easily gets to the fastest path. As a result, you are more or less benchmarking one compiler to another. On some platforms, notably on iOS, JS JIT works fantastic and easily beats the similar code, written in C and compiled using Clang to the WebAssembly. However, such benchmarks are not exploiting the weakest parts of the JS compiler and runtime at all and the real world result may be very well different.
In our case, we have a rapidly evolving 500k LOC application, written in C++ (as we have to support clients with the very outdated hardware) which we used to compile to the Asm.js to provide a web version for the client with modern computers. Switching to WebAssembly gave us around 2x performance improvement, depending on the target browser and OS. The very similar results are shown by the Unity3D and Unreal Engines.
To sum up – WebAssembly is best suited for the cases, where you have to process large amounts of data on the clients. Games and image editing seems to be the best fit at this moment of time. The official support of the WebAssembly by the Qt will push things forward as well.
I can think of one scenario where WebAsm might make sense, and reduce code size: where some other language is used to write the front-end code, and transpiled into JavaScript.
Java in particular creates large JavaScript files during transpiling (based on my experience with Google’s GWT, several years ago) and if instead of generating JavaScript the Java code can be compiled directly into WebAsm, I expect that sizeable gains can be made.
The killer argument for WebAssembly for me is code sharing. We have heavy geometric code in our backends in our company and there is benefit to reuse some of these in the front ends, for example pose interpolation for trajectories.
The story around c++ is weaker there, but rust offers a very easy way to compile pieces of your code to WebAssembly and reuse it in the front end. Speed is not a driving force for our work.
Does WASM have any SIMD action? simdjs was canceled. Did you try any SIMD?
At the moment, WebAssembly does not directly expose SIMD instructions
yes, it can be faster with the web assembly, which is faster than Javascript, but with using it, you may face the Epson error code 0xf1
I do not believe in your statement that WebAssembly is slower than JavaScript. You can create contrived benchmarks where WASM code does a lot of accesses do DOM or JS code, and this can be slow (but recently Firefox made it MUCH faster), but if you have any sufficient piece of computationally intensive code (so any DOM/JS-WASM crossing overheads are negligible), WASM will be almost always much faster.
Programing entire website in WebAssembly with a lot of unstructured code and a lot of interaction with DOM or native JS functions, surely can be slow, but this is simply not a purpose of WASM at the moment.
Surely WASM is not intended for replacing JS functionally generally. Rather it’s intended to open up new opportunities. Until WASM gets DOM access it will be slower than native JS for small functions, or functions requiring many calls to DOM – which spend more time in JS than WASM.
WASM makes sense for large applications that are calculation intensive.
WASM allows desktop apps to be ported to the browser (i.e. AutoCAD). Or cross platform applications to be developed using compiled languages (into WebAssembly, rather than native assembly) with GUI using web technologies (HTML DOM, CSS, JS) – using “Electron” for example (I.e. VSCode.
Webassembly is a nice platform. But in my opinion, JS is best and user-friendly
JS is the best language. It is easy, and does the job fast. Other languages may be “slightly” faster but what kind of idiot finds fun coding in C? Its so boring, makes you do unnecessary work.
It’s extremely hard to maintain large code bases in the dynamically typed languages. And in some cases, JS is orders of magnitude slower.
Also, there is a lot of software written in C/C++ already, like image recognition and game engines, which can now be ported to run on Web.
True, though lots of web development teams use TypeScript now to solve the problem of managing large codebases in a dynamically typed language – they just use a statically typed superset, TS.
It compiles to JavaScript. (Ideally browsers would run TypeScript directly, since there should be optimization opportunities from the explicit type declarations.)
I like WebAssembly, though I’m skeptical that arbitrary and large C/C++ codebases will run efficiently as WebAssembly by default. There have been mixed results from testing Wasm performance.
We do run a 600k LOC C++ based UI application in browsers using WebAssembly, runs good enough even on modern phones.
Where is the data that was promised..?
IMO if there is no supporting data then these claims should be deleted or contradicted with an update at the top.
As it is now – it’s misleading (though the comments are interesting).
Sadly, I have not yet good around to update and publish our experiments. It is coming. I am hard working but I have many things on my plate.
Yet I am not going to retire this blog post at this time. The bulk of the post is supported by the comments and by other references. Nobody challenges the fact that Web Assembly can be fat. Or that it may not load much faster than JavaScript. And as was reported a few times, if you need to access the web page (get out of your sandbox), it is going to be slow. And even the claims regarding high raw speeds do not appear to compare code hand-written by good JavaScript programmers with code written in some other language compiled to Web Assembly.
If you don’t know the difference between a statically type and dynamically typed language I cant help you.
You don’t understand how memory works you need to read a book.
The only reason why it wouldn’t run faster is because we have spent decades tuning JS to run on the browser.
Hi Ryan,
I’m pretty sure that your reply is not addressed at me, but I’ll answer anyway:
There is no need to be rude.
I don’t think that the claim the author makes is that WebAssembly cannot be faster than JS. I think he just says that it isn’t.
What’s more interesting to me is understanding the type of scenarios in which it’s not faster. I can certainly imagine tasks that would (probably always) be slower in WebAssembly than in JS, such as communication with JS code.
You are correct.
And, yes, there is no need to rude.
Could, in theory, Web Assembly be smaller and consistently faster than JavaScript. Of course! Working from JavaScript is a handicap for speed and performance. But it is not like other platforms we have are optimal. Nobody thinks that x86 or Windows are optimal. But both x86 and Windows rock because they got so much ressources.
I’d like first to point out that even the advocate of Web Assembly do not sell it as a “faster JavaScript”. I don’t see much in the way of “rewrite your web site from JavaScript to WebAssembly”.
Second of all, yes, JavaScript is a highly optimized target. This is an important factor. It was easy for Java (in applets) to be much faster than JavaScript back in 2000. Today, the gap between JavaScript and Java is much narrower (though Java will still be faster, sometimes much faster).
Though JavaScript has dynamic typing, the actual execution engine has an optimizing compiler than can infer types and optimize accordingly.
JavaScript in the browser does not need to download a runtime library. It has its own.
Could WebAssembly in 5 years be a much faster JavaScript. Sure. But JavaScript is not exactly standing still, is it?
Oh it was directed at you.
I like how you didn’t answer my questions.
If you understand memory management, threading and concurrency. We wouldn’t be posting.
Most JS developers are retarded and don’t know shit about computers.
There is a reason web developers make the least amount.
Hi Ryan,
Directed at me?
Didn’t answer your questions? When have you ever asked me (or the author) anything?
Maybe go troll elsewhere…
“Most JS developers are retarded and don’t know shit about computers.”
This is a rude generalization.