6 ms·

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However,

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as a UI widget library but as a document rendering and styling framework. Webassembly/Webgl standardization enables the creation high performance replacements for HTML/CSS/dom. We might end up with applications that are still mostly written in javascript but that call into new webassembly/webgl ui frameworks for rendering instead of into the html/css/dom layer.

slothtrop 9y ago
Well writing in languages for native code is still just as popular, and we're moving in such a direction to allow for the same application to be available both on the web and on your machine. The pure-Javascript approach to offering the same is to package a browser with a web-app and disguise this as a standalone application, which is ass-backwards.
lixquid 9y ago
I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth. WebAssembly is the first steps to truly breaking that chokehold, and truly seeing how popular JavaScript the language really is.
- BenoitEssiambre 9y ago
  Right, however javascript will still be the only full featured language having its runtime and libraries included with the browser. That means that for other languages, only the ones with fairly light runtimes and libraries could be suitable for inclusion in most web apps. This will limit the choices for non javascript general development. It may be possible to do a webassembly/webgl rendering engine to replace html/css using a limited set of dependencies.
  - akiselev 9y ago
    Most news sources already load between 2 and 10 megabytes of Javascript, which is a significant fraction of, say, Python's runtime and many, many people browse those pages on mobile devices and connections without a problem. In Python's case, a large amount of the runtime size is taken up by all of the platform specific implementations of the standard library and they wouldn't work in the sandbox anyway. Is there anything preventing Python.org from hosting the runtime environment on their CDN that everyone caches locally? Are there security issues from cross domain modules? Worst case, I don't think it would be hard to extend the LocalStorage API to cache modules between domains (perhaps with signed runtimes and a fallback).
- z3t4 9y ago
  JavaScript is easy to debug and test, its relative safe, and closures makes it easy to write async programs. Compared to C or C++ you'll have a huge productivity boost with a very small performance penalty. It's also easy to learn compared to other languages. It also doesn't have a standard library which makes it easy to integrate into any platform. For example in Windows OS and other Microsoft products you've been able to use JavaScript as a scripting language for a very long time. So JavaScript is not a language that has only been available in browsers. There are actually people out there that prefer JavaScript and write in it voluntarily.
  - lixquid 9y ago
    Personally, I'd say Lua and its family of small, easy languages more easily fills those roles. Not that I doubt some people do voluntarily enjoy JavaScript, but because of the sheer volume of StackOverflow questions, blog posts, micro-techologies, and other assorted attention bestowed upon the language it can be easy to make the logical jump that JavaScript the language is far more popular (in the satisfaction sense) than is actually so.
tflinton 9y ago
Even web assembly needs to call back to javascript API's to perform webgl interactions. Emscripten provides an easy to use SDL library that makes it a bit less painful. Should be noted that due to security layers there's quite a few webgl, networking and system calls that are not available. In addition good luck getting any threads working, you can fake that out by simply calling them in a setTimeout. In addition its very low level; and if you toss in libraries you'll find your binaries being VERY large.
tdb7893 9y ago
I think javascript is so popular because it's the only language for browsers. I think if you got better alternatives in the browser then javascript would lose much of it's popularity. It's not going to die overnight but my guess is that it's popularity will decline
snarfy 9y ago
> I'm not sure people will want to move away from it for most development. x = 1 + '2' //12 x = 1 - '2' //-1 Oh yes, yes we do.
- jswny 9y ago
  I mean, I agree with you but that's not even that bad of an example. I would expect many languages to do something similar. Something like this might be a better example: "\t\r\n" == 0 → true "\t\r\n 16 \t\r\n" == 16 → true "\t\r\n 16 \t\r\n" == "16" → false
  - kardianos 9y ago
    No, I don't think most languages do something similar.
  - smitherfield 9y ago
    > I would expect many languages to do something similar. Of the common dynamic languages I can think of, the only ones that do something similar are Perl/Perl6 and PHP, and even they are still saner than JS. $ $((1+\2)) bash: 1+\2: syntax error: operand expected (error token is "\2") $ $((1-\2)) bash: 1-\2: syntax error: operand expected (error token is "\2") $ ruby -e"1+'2'" -e:1:in `+': String can't be coerced into Integer (TypeError) from -e:1:in `<main>' $ ruby -e"1-'2'" -e:1:in `-': String can't be coerced into Integer (TypeError) from -e:1:in `<main>' $ python3 -c"1+'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' $ python3 -c"1-'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'int' and 'str' >>> exit() $ python2 -c"1+'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' $ python2 -c"1-'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'int' and 'str' $ perl -e'print 1+"2"."\n"' 3 $ perl -e'print 1-"2"."\n"' -1 $ perl6 -e"say 1+'2'" 3 $ perl6 -e"say 1-'2'" -1 $ php -r'echo 1+"2","\n";' 3 $ php -r'echo 1-"2","\n";' -1 $ racket -e '(+ 1 "2")' +: contract violation expected: number? given: "2" argument position: 2nd other arguments...: 1 $ racket -e '(- 1 "2")' -: contract violation expected: number? given: "2" argument position: 2nd other arguments...: 1 $ sbcl This is SBCL 1.3.18, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (+ 1 "2") debugger invoked on a TYPE-ERROR in thread #<THREAD "main thread" RUNNING {1001F0EC33}>: The value "2" is not of type NUMBER when binding SB-KERNEL::Y Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:TWO-ARG-+ 1 "2") [external] 0] 0 * (- 1 "2") debugger invoked on a TYPE-ERROR in thread #<THREAD "main thread" RUNNING {1001F0EC33}>: The value "2" is not of type NUMBER when binding SB-KERNEL::Y Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:TWO-ARG-- 1 "2") [external] 0] 0 * (exit) $ erl Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Eshell V8.3 (abort with ^G) 1> 1+"2". ** exception error: an error occurred when evaluating an arithmetic expression in operator +/2 called as 1 + "2" 2> 1-"2". ** exception error: an error occurred when evaluating an arithmetic expression in operator -/2 called as 1 - "2" 3> halt(). $ elixir -e '1+"2"' ** (ArithmeticError) bad argument in arithmetic expression :erlang.+(1, "2") (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6 (elixir) lib/code.ex:170: Code.eval_string/3 $ elixir -e '1-"2"' ** (ArithmeticError) bad argument in arithmetic expression :erlang.-(1, "2") (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6 (elixir) lib/code.ex:170: Code.eval_string/3
flavio81 9y ago
Javascript is fine, but as you already know, everybody wants to use his/her language of choice. And, more importantly, everybody should be able to choose the right language for the specific task. What could happen, with WebAssembly, is the opposite: A wane in Javascript's popularity.
- stcredzero 9y ago
  What could happen, with WebAssembly, is the opposite: A wane in Javascript's popularity. If the right moves happen, possible. If the wrong moves happen, it will be the second coming of plugins. Languages based on WebAssembly have to be 1st class citizens in the browser infrastructure, otherwise it will be a repeat. This means that debugging has to be transparent. Access to the DOM has to be ultimately the same.
  - flavio81 9y ago
    "If the wrong moves happen, it will be the second coming of plugins. " Oh my god, you sent me a flashback to the evil days of the Plugin-Based-Internet... .. the days of Flash versus Shockwave versus ActiveX versus Java Applet!!
gnaritas 9y ago
> However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. You'd be wrong, many people would love to move away from to something better. There are many better languages than JS and we'd like to not be limited to one shitty quirky hastily designed language in the browser.
mmjaa 9y ago
It doesn't all have to be javascript, HTML and DOM, you know. That's why this is an important step. Wanna use TurboPascal to write apps, and target the entire known universe of Web browsers? Go right ahead. You can do that now. Of course, I'm being extreme, but .. you know .. there are other great ways to exploit WebAssembly as a target, and save yourself a huge amount of cultmind headache by avoiding all of the so-called "higher" layers of the stack, completely. For example, I'm quite happy writing the most cross-platform'est code, in like, ever, using Lua. And targeting WebAssembly in this circumstance is a no-brainer.
ThePhysicist 9y ago
For me the main potential of asm.js/WebAssembly does not lie in the fact that it is faster, but in that it provides us with a way to run native C/C++ code inside the browser without adapting it (much), and doing this at a speed which is not (much) worse than the speed of the original code. This in turn makes functionality that was traditionally very hard to get in a browser/JS environment suddenly very easy to get: - Cryptographic libraries (e.g. libcrypto) - Libraries for numerical data manipulation and analysis - Compression libraries - Video codecs - ... This ability will lead to a paradigm shift (IMHO), because instead of having to reproduce all this functionality in JS (which would be crazy) you can just cross-compile it and use it right away. Also, with WebAssembly, browser vendors can simply focus on providing good and secure interfaces to a limited amount of low-level functions (IO, graphics) while letting the user define the high-level usage of these interfaces. If this works out well I can even imagine this technology spilling over to other domains, because what it provides is essentially a secure, portable, low-level sandbox with a very good performance and a huge installation base.
- arethuza 9y ago
  I thought the problem with client side crypto wasn't so much performance but the fact that it can't really be trusted?
  - dullgiulio 9y ago
    That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back. If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
    - ThePhysicist 9y ago
      There might be situations when you want client-side crypto not for sending data over the network, but to securely encrypt a document that you want to send / use in a different context. Using an emscripten-compiled crypto library would allow you to do this in your browser without sending any of the data over the wire.
kllrnohj 9y ago
I honestly find it a bit crazy that we have webasm before viable multitasking in JavaScript. webworkers being multi-process not multi-threading, and also extremely slow, limited, and needlessly RAM intensive. Multi-process could have worked if they would have at least had fast messaging (~1ms communication overhead is absurd), some form of shared data (at least let me share immutable ArrayBuffers! it's immutable! that's safe!), and some form of move operation instead of copy to allow for cheap handoffs of data structures. That'd still all be safe, no risk of memory corruption, etc... But no, let's port assembly to the browser instead! Then you get that extra bit out of that one already-overloaded core instead of tapping in to the potentially 15+ other cores on the device! I'd put forth that that's a far bigger issue to web app performance than HTML/CSS/DOM is. It is for the very heavy web app I've worked on, anyway. WebAsm's most intriguing aspect as a result is that it has plans to actually add threading along with things like SharedArrayBuffer. That would make locally-intensive & offline webapps vastly more viable.

slothtrop 9y ago

Well writing in languages for native code is still just as popular, and we're moving in such a direction to allow for the same application to be available both on the web and on your machine. The pure-Javascript approach to offering the same is to package a browser with a web-app and disguise this as a standalone application, which is ass-backwards.

lixquid 9y ago

I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth. WebAssembly is the first steps to truly breaking that chokehold, and truly seeing how popular JavaScript the language really is.

BenoitEssiambre 9y ago
Right, however javascript will still be the only full featured language having its runtime and libraries included with the browser. That means that for other languages, only the ones with fairly light runtimes and libraries could be suitable for inclusion in most web apps. This will limit the choices for non javascript general development. It may be possible to do a webassembly/webgl rendering engine to replace html/css using a limited set of dependencies.
- akiselev 9y ago
  Most news sources already load between 2 and 10 megabytes of Javascript, which is a significant fraction of, say, Python's runtime and many, many people browse those pages on mobile devices and connections without a problem. In Python's case, a large amount of the runtime size is taken up by all of the platform specific implementations of the standard library and they wouldn't work in the sandbox anyway. Is there anything preventing Python.org from hosting the runtime environment on their CDN that everyone caches locally? Are there security issues from cross domain modules? Worst case, I don't think it would be hard to extend the LocalStorage API to cache modules between domains (perhaps with signed runtimes and a fallback).
z3t4 9y ago
JavaScript is easy to debug and test, its relative safe, and closures makes it easy to write async programs. Compared to C or C++ you'll have a huge productivity boost with a very small performance penalty. It's also easy to learn compared to other languages. It also doesn't have a standard library which makes it easy to integrate into any platform. For example in Windows OS and other Microsoft products you've been able to use JavaScript as a scripting language for a very long time. So JavaScript is not a language that has only been available in browsers. There are actually people out there that prefer JavaScript and write in it voluntarily.
- lixquid 9y ago
  Personally, I'd say Lua and its family of small, easy languages more easily fills those roles. Not that I doubt some people do voluntarily enjoy JavaScript, but because of the sheer volume of StackOverflow questions, blog posts, micro-techologies, and other assorted attention bestowed upon the language it can be easy to make the logical jump that JavaScript the language is far more popular (in the satisfaction sense) than is actually so.

tflinton 9y ago

Even web assembly needs to call back to javascript API's to perform webgl interactions. Emscripten provides an easy to use SDL library that makes it a bit less painful. Should be noted that due to security layers there's quite a few webgl, networking and system calls that are not available. In addition good luck getting any threads working, you can fake that out by simply calling them in a setTimeout. In addition its very low level; and if you toss in libraries you'll find your binaries being VERY large.

tdb7893 9y ago

I think javascript is so popular because it's the only language for browsers. I think if you got better alternatives in the browser then javascript would lose much of it's popularity. It's not going to die overnight but my guess is that it's popularity will decline

snarfy 9y ago

> I'm not sure people will want to move away from it for most development. x = 1 + '2' //12 x = 1 - '2' //-1 Oh yes, yes we do.

jswny 9y ago
I mean, I agree with you but that's not even that bad of an example. I would expect many languages to do something similar. Something like this might be a better example: "\t\r\n" == 0 → true "\t\r\n 16 \t\r\n" == 16 → true "\t\r\n 16 \t\r\n" == "16" → false
- kardianos 9y ago
  No, I don't think most languages do something similar.
- smitherfield 9y ago
  > I would expect many languages to do something similar. Of the common dynamic languages I can think of, the only ones that do something similar are Perl/Perl6 and PHP, and even they are still saner than JS. $ $((1+\2)) bash: 1+\2: syntax error: operand expected (error token is "\2") $ $((1-\2)) bash: 1-\2: syntax error: operand expected (error token is "\2") $ ruby -e"1+'2'" -e:1:in `+': String can't be coerced into Integer (TypeError) from -e:1:in `<main>' $ ruby -e"1-'2'" -e:1:in `-': String can't be coerced into Integer (TypeError) from -e:1:in `<main>' $ python3 -c"1+'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' $ python3 -c"1-'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'int' and 'str' >>> exit() $ python2 -c"1+'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' $ python2 -c"1-'2'" Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'int' and 'str' $ perl -e'print 1+"2"."\n"' 3 $ perl -e'print 1-"2"."\n"' -1 $ perl6 -e"say 1+'2'" 3 $ perl6 -e"say 1-'2'" -1 $ php -r'echo 1+"2","\n";' 3 $ php -r'echo 1-"2","\n";' -1 $ racket -e '(+ 1 "2")' +: contract violation expected: number? given: "2" argument position: 2nd other arguments...: 1 $ racket -e '(- 1 "2")' -: contract violation expected: number? given: "2" argument position: 2nd other arguments...: 1 $ sbcl This is SBCL 1.3.18, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (+ 1 "2") debugger invoked on a TYPE-ERROR in thread #<THREAD "main thread" RUNNING {1001F0EC33}>: The value "2" is not of type NUMBER when binding SB-KERNEL::Y Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:TWO-ARG-+ 1 "2") [external] 0] 0 * (- 1 "2") debugger invoked on a TYPE-ERROR in thread #<THREAD "main thread" RUNNING {1001F0EC33}>: The value "2" is not of type NUMBER when binding SB-KERNEL::Y Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:TWO-ARG-- 1 "2") [external] 0] 0 * (exit) $ erl Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Eshell V8.3 (abort with ^G) 1> 1+"2". ** exception error: an error occurred when evaluating an arithmetic expression in operator +/2 called as 1 + "2" 2> 1-"2". ** exception error: an error occurred when evaluating an arithmetic expression in operator -/2 called as 1 - "2" 3> halt(). $ elixir -e '1+"2"' ** (ArithmeticError) bad argument in arithmetic expression :erlang.+(1, "2") (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6 (elixir) lib/code.ex:170: Code.eval_string/3 $ elixir -e '1-"2"' ** (ArithmeticError) bad argument in arithmetic expression :erlang.-(1, "2") (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6 (elixir) lib/code.ex:170: Code.eval_string/3

flavio81 9y ago

Javascript is fine, but as you already know, everybody wants to use his/her language of choice. And, more importantly, everybody should be able to choose the right language for the specific task. What could happen, with WebAssembly, is the opposite: A wane in Javascript's popularity.

stcredzero 9y ago
What could happen, with WebAssembly, is the opposite: A wane in Javascript's popularity. If the right moves happen, possible. If the wrong moves happen, it will be the second coming of plugins. Languages based on WebAssembly have to be 1st class citizens in the browser infrastructure, otherwise it will be a repeat. This means that debugging has to be transparent. Access to the DOM has to be ultimately the same.
- flavio81 9y ago
  "If the wrong moves happen, it will be the second coming of plugins. " Oh my god, you sent me a flashback to the evil days of the Plugin-Based-Internet... .. the days of Flash versus Shockwave versus ActiveX versus Java Applet!!

gnaritas 9y ago

> However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. You'd be wrong, many people would love to move away from to something better. There are many better languages than JS and we'd like to not be limited to one shitty quirky hastily designed language in the browser.

mmjaa 9y ago

It doesn't all have to be javascript, HTML and DOM, you know. That's why this is an important step. Wanna use TurboPascal to write apps, and target the entire known universe of Web browsers? Go right ahead. You can do that now. Of course, I'm being extreme, but .. you know .. there are other great ways to exploit WebAssembly as a target, and save yourself a huge amount of cultmind headache by avoiding all of the so-called "higher" layers of the stack, completely. For example, I'm quite happy writing the most cross-platform'est code, in like, ever, using Lua. And targeting WebAssembly in this circumstance is a no-brainer.

ThePhysicist 9y ago

For me the main potential of asm.js/WebAssembly does not lie in the fact that it is faster, but in that it provides us with a way to run native C/C++ code inside the browser without adapting it (much), and doing this at a speed which is not (much) worse than the speed of the original code. This in turn makes functionality that was traditionally very hard to get in a browser/JS environment suddenly very easy to get: - Cryptographic libraries (e.g. libcrypto) - Libraries for numerical data manipulation and analysis - Compression libraries - Video codecs - ... This ability will lead to a paradigm shift (IMHO), because instead of having to reproduce all this functionality in JS (which would be crazy) you can just cross-compile it and use it right away. Also, with WebAssembly, browser vendors can simply focus on providing good and secure interfaces to a limited amount of low-level functions (IO, graphics) while letting the user define the high-level usage of these interfaces. If this works out well I can even imagine this technology spilling over to other domains, because what it provides is essentially a secure, portable, low-level sandbox with a very good performance and a huge installation base.

arethuza 9y ago
I thought the problem with client side crypto wasn't so much performance but the fact that it can't really be trusted?
- dullgiulio 9y ago
  That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back. If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
  - ThePhysicist 9y ago
    There might be situations when you want client-side crypto not for sending data over the network, but to securely encrypt a document that you want to send / use in a different context. Using an emscripten-compiled crypto library would allow you to do this in your browser without sending any of the data over the wire.

kllrnohj 9y ago

I honestly find it a bit crazy that we have webasm before viable multitasking in JavaScript. webworkers being multi-process not multi-threading, and also extremely slow, limited, and needlessly RAM intensive. Multi-process could have worked if they would have at least had fast messaging (~1ms communication overhead is absurd), some form of shared data (at least let me share immutable ArrayBuffers! it's immutable! that's safe!), and some form of move operation instead of copy to allow for cheap handoffs of data structures. That'd still all be safe, no risk of memory corruption, etc... But no, let's port assembly to the browser instead! Then you get that extra bit out of that one already-overloaded core instead of tapping in to the potentially 15+ other cores on the device! I'd put forth that that's a far bigger issue to web app performance than HTML/CSS/DOM is. It is for the very heavy web app I've worked on, anyway. WebAsm's most intriguing aspect as a result is that it has plans to actually add threading along with things like SharedArrayBuffer. That would make locally-intensive & offline webapps vastly more viable.