13 ms·

WasmBoxC: Simple, Fast, and VM-Less Sandboxing

224 points by syrusakbary 6y ago

lostmsu 6y ago
This is a really cool concept. I'd love a mature supported technology, that could replace .NET's AppDomain.
- pjmlp 6y ago
  WebAssembly is anything but mature, and given that .NET also supports C++ from the get go, I would be curious to have a security analysis in how much "secure" WebAssembly actually is. Thankfully researchers have finally started assessing it, with the first wave of papers reaching USENIX 2020.
  - azakai 6y ago
    That feels a little unfair. WebAssembly has been shipping in the majority of production browsers for over three years now. That's one of the most security-sensitive attack targets that exists. Those browsers would not have done so if it weren't reasonably safe. Of course there are vulnerabilities that are discovered, just like in every part of the web platform. Nothing is perfect. But a huge amount of attention has been put on wasm's security and the major implementations are very robust. It's true that wasm is reaching into other areas besides the web, which does raise new questions (like in that recent USENIX 2020 paper). Perhaps it's fair to say wasm is immature as a replacement for a native executable, or other new ideas that are coming out. But it's very mature as a sandboxing solution for pure computational code, and it's used successfully on the web all the time.
    - pjmlp 6y ago
      It not unfair when plenty of WebAssembly supporters try to sell it as the ultimate bytecode, without any flaws from all the ones that came into existence since the 60's. Also it is still catching up to features that those bytecodes already have during the last 20 years. Those browsers are only shipping MVP 1.0, unless you want to equate Web with Chrome. Only now are hackers and security researchers actually caring about WebAssembly security, hence the first wave of security papers on USENIX 2020. I expect those that drove WebAssembly in detriment of what we already had to be eventually surprised. For what I care, I will just take advantage of it to get back my plugins.
- merb 6y ago
  biggest problem is that .net/dotnet core can not be easily wasm aot compiled. currently you compile the runtime to wasm and use the dll with the wasm runtime. this is the approach that blazor wasm uses and it is aweful.
  - pjmlp 6y ago
    <win-dev-rant-mode> Mostly because Microsoft currently doesn't not know what they want, check the feedback regarding the missing roadmap for CoreRT/.NET Native. With Reunion, MAUI, Blazor (WebAssembly and mobile), WPF team transfer, they seem to have got back into another reboot the eco-system phase. </win-dev-rant-mode> Now given that, with Unity's .NET flavour can be compiled via IL2CPP => WebAssembly, or with Mono AOT as in Uno.
  - ckok 6y ago
    I tried this. Aot compiling with the .net runtime just isn't very practical. I know mono does this, with some guided info for reflection based classes. But the way the structure is setup, is that string pulls in globalization. And enumeration. And comparable and equality which both work by reflection to pick the right default implementation. Reflection is expected to work, which pulls in all methods and their dependencies. By the time you have a working executable for hello world, you're a few MB ahead. The class library just isn't setup for this kind of use.
    - GordonS 6y ago
      I was thinking about this just the other day, when Microsoft announced the latest dotnet 5 preview, and yet again have postponed AOT - Microsoft have been teasing dotnet devs with the promise of production-ready AOT for something like a decade. Frankly, I wish they'd put up or shut up - either prioritise it and make it happen, or just admit defeat and say it's not going to happen.
      - pjmlp 6y ago
        Production ready AOT for .NET exists since Singularity, which MIDL and Bartok compilers were the basis of .NET WinRT on Windows 8/8.x. Then some of the Midori tech eventually made its way into .NET Native, which from my point of view UWP + .NET Native is what .NET should have been all about back in 2001. Apparently after the timid attempt with XAML Islands and MSIX, they seem to be getting the house in order and driving the platform into a way to pretend that Windows 8 and 8.1 never happened, but it seems to be lacking a lot of coordination and long term planning. Windows 10X apparently is also not getting Win32 sandbox any longer, this assuming it ever gets released. Still in the middle of the chaos, it still feels much better than if I had to deal with Android on daily basis, one IO best practices is next years legacy.
devwastaken 6y ago
Any time these come up i don't find a comprehensive analysis on security. The best, supposedly most secure libraries in the world get significant vulnerabilities.
- tpetry 6y ago
  This is not make any software magically secure. It‘s only purpose is to _sandbox_ a library to prevent it doing anything malicious. As wasm cant do any more than computing you simply contain the library, it cant anymore open any files, make network calls, etc.
  - mehrdadn 6y ago
    > As wasm cant do any more than computing you simply contain the library, it cant anymore open any files, make network calls, etc. I wish the world was that simple.
  - wahern 6y ago
    > As wasm cant do any more than computing you simply contain the library, it cant anymore open any files, make network calls, etc. That presumes the WASM implementation is bug free, which is not a great presumption, especially for the more sophisticated implementations with JIT engines, and even more so for those adding multi-threading, GC, etc.
  - pjmlp 6y ago
    It doesn't prevent Heartbleed like kind of attacks. Also doesn't prevent internal memory corruption attacks that expose unintended behaviors from the public module interface.
- kevingadd 6y ago
  See this paper for some recent research on the subject: http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs... You can probably use wasm to build a very comprehensive secure sandbox but right now it's actually somewhat of a regression when you care about making an application secure. Your OS is safe, at least, as long as you don't let the app make any syscalls.
pjmlp 6y ago
Well, "Everything Old is New Again: Binary Security of WebAssembly" - USENIX 2020 https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...
- azakai 6y ago
  That's a good article! Some notes on it: https://twitter.com/kripken/status/1284576787624648705 https://twitter.com/kripken/status/1284576787624648705 Perhaps wasm isn't (yet) a good replacement for native binaries for the reasons they mention. In particular such an application usually has access to files and timing etc., and you're (currently) missing some safety techniques native binaries use, which is a risky combination. But as mentioned in the post here, if you're sandboxing a specific library that does pure computation (say, a codec or a compression library) then using wasm you can make sure it cannot escape the sandbox and that it has no timing or other OS capabilities. Those are powerful guarantees!
  - pjmlp 6y ago
    Pure computation is subject to UB and memory corruption due to lacks of bounds checking inside linear memory blocks, leading to outputs that cannot be trusted, even though they are sandboxed.
    - azakai 6y ago
      Definitely, yes, and you do need to be careful about those outputs. Still, the sandboxing guarantee here is very useful! This isn't theoretical, Firefox does this approach in production (using RLBox, which is mentioned in the post), https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
      - pjmlp 6y ago
        Thanks for the link, I missed that post.
mdriley 6y ago
> Wasm sandboxing is even safe to run in the same process as other code (at least modulo Spectre-type vulnerabilities)... If you want strong security with this big a modulus you may have been looking for RSA. (ugh, sorry) Spectre V1 (speculative bounds check bypass / type confusion) is basically game over for intra-process memory isolation without introducing expensive or complicated mitigations: speculation barriers at every branch, or a more optimized pass like Speculative Load Hardening (https://llvm.org/docs/SpeculativeLoadHardening.html https://llvm.org/docs/SpeculativeLoadHardening.html) that can bring the overhead _down_ to 20-50%. From what I've seen, the best understanding right now is that the process is the smallest defensible unit of isolation. That's not to say that using WASM as an intermediate compilation target won't eliminate some threats! The runtime can definitely help to improve memory safety, for example. But if you care about confidentiality of the data in your process, any code that is untrusted enough to require sandboxing should also be run out-of-process, e.g. across an IPC boundary.
- monadic2 6y ago
  I’m open to a slow but secure processor. Certainly for my personal computing.
  - pjmlp 6y ago
    I feel the same about bounds checking in programming languages, apparently not everyone does.
    - KMag 6y ago
      I vaguely remember a story about a hardware manufacturer (Burroughs? Symbolics?) that had a processor with instructions that could bounds-check array accesses with zero latency overhead. It was a great feature for Algol/Lisp, but some customers asked for an option in their Fortran compiler to disable the bounds check. The sales engineer replied that the bounds checks were zero-cost, but the customers replied that the bounds checks broke their progrems... their programs had silent (or at least unnoticed) array bounds bugs, and the customers preferred to keep those bugs, thank you very much! I wish I had kept the link. I've tired a couple times to find the story. Does this ring any bells for anyone?
syrusakbary 6y ago
Alon did a really great job with the article, hats off. I think WasmBoxC might be useful to try to benchmark how fast we can get Wasm to run server-side. We also hope to eventually beat native execution in server-side specific Wasm runtimes (such as Wasmer using the LLVM compiler and Profile Guided Optimizations) once the runtime ecosystem matures a bit. Keep up the good work!
jasonzemos 6y ago
> The OS-based implementation uses the “signal handler trick” that wasm VMs use. This technique reserves lots of memory around the valid range and relies on CPU hardware to give us a signal if an access is out of bounds (for more background see section 3.1.4 in Tan, 2017). On Linux you can also make use of userfaultfd(2) rather than handling SIGSEGV.
legulere 6y ago
> By compiling to wasm we sandbox the code, preventing it from accessing anything on the outside. Operating systems are in a sad state, as virtual address spaces already offer exactly that in hardware at full speed. It's only through the operating system APIs that processes gain the ability to affect anything outside of the process. Current operating systems weren't made with untrusted code in mind, but have so much inertia that new operating systems repairing old misfeatures can never succeed. All code is already written based on the bad Operating System APIs like for writing files. This project just handwaves the actual problem away: > the sandboxed code can’t do anything but pure computation, unless you give it a function to call to do things like read from a file, tell the time, etc.
- sanxiyn 6y ago
  CloudABI is an attempt to solve this the right way: http://cloudabi.org/ http://cloudabi.org/
- darksaints 6y ago
  100% agreement. With a kernel design like SeL4 there is no need for crazy sandboxing environments. It prevents you from accessing external resources by default. And it is probably as close as we can feasibly get to an operating system that is impossible to maliciously root.
- titzer 6y ago
  > as virtual address spaces already offer exactly that in hardware at full speed Operating system processors are pretty heavyweight, and there are lots of situations where smaller granularity protection domains are useful. I'd also quibble with "at full speed." There is a metric shitton of complexity to implement virtual memory, with multi-level TLBs, an extremely careful dance with the operating system currently, IPIs for TLB shootdown, etc. The dynamic cost of the TLB is something that is measurable, and of course, completely depends on your application behavior, kernel, availability of huge pages, etc. The reality is that we don't really have a control group for hardware without virtual memory because the only such chips are for small embedded (niche) systems, and everything else runs on kernels designed to offer virtual memory to software expecting virtual memory.
mtgx 6y ago
Would this have been more secure in Rust?
sriku 6y ago
Sounds similar to Fastly's "Lucet" - https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime https://www.fastly.com/blog/announcing-lucet-fastly-native-w...
pansa2 6y ago
So, compiling via WasmBoxC gives a 14% - 42% performance overhead compared to native compilation. Is there also a significant overhead in terms of binary size?
- kevingadd 6y ago
  wasm binaries are typically size-competitive with native x86 once you compress them (i.e. foo.so.zip vs foo.wasm.zip), but the jitcode you get out of them is usually much bigger. In my testing the size overhead for stuff like the ICU unicode library was maybe 20-40% on-disk, depending on compiler settings. It's gonna depend on your workload. Note that even if the actual generated jitcode is computationally efficient, it might be larger and as a result waste more space in the instruction cache, which would hinder performance.
brianolson 6y ago
Gary Bernhardt was prophetic https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- esperent 6y ago
  Wasm is amazing, but it's not intended to replace JavaScript. If you just want to add a form to a website, animate a drop-down menu, or the like, JS (or TS) will probably always be preferable to writing in another language and compiling to wasm. The web platform moves fast and maybe in a couple of years I'll eat these words. But nothing I've seen so far points towards the demise of JS.
  - pjmlp 6y ago
    A form like these? https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTracking=e97265b8-ec7f-4652-b052-d26b8875166d%7Ce09e2ec9-4b23-4528-8d66-448a523b7e64 https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTrack... https://gallery.flutter.dev/#/ https://gallery.flutter.dev/#/ https://platform.uno/code-samples/ https://platform.uno/code-samples/
  - ronjouch 6y ago
    Gary's talk is not exactly about the "demise of JS". Watch the talk, it's a great one :)
- kevingadd 6y ago
  WASM will never replace JavaScript. Something else might, and it might have support for compiling to WASM, but we'll see.
Chris2048 6y ago
so, if you compiled a language shell, or interpreter this way; you would end up with a sand-boxed shell/interpreter?
- ncmncm 6y ago
  One that couldn't do anything. The essence of the method is providing to the sandbox specific, safe means to interact with the surrounding process.

224 points by syrusakbary 6y ago

lostmsu 6y ago

This is a really cool concept. I'd love a mature supported technology, that could replace .NET's AppDomain.

pjmlp 6y ago
WebAssembly is anything but mature, and given that .NET also supports C++ from the get go, I would be curious to have a security analysis in how much "secure" WebAssembly actually is. Thankfully researchers have finally started assessing it, with the first wave of papers reaching USENIX 2020.
- azakai 6y ago
  That feels a little unfair. WebAssembly has been shipping in the majority of production browsers for over three years now. That's one of the most security-sensitive attack targets that exists. Those browsers would not have done so if it weren't reasonably safe. Of course there are vulnerabilities that are discovered, just like in every part of the web platform. Nothing is perfect. But a huge amount of attention has been put on wasm's security and the major implementations are very robust. It's true that wasm is reaching into other areas besides the web, which does raise new questions (like in that recent USENIX 2020 paper). Perhaps it's fair to say wasm is immature as a replacement for a native executable, or other new ideas that are coming out. But it's very mature as a sandboxing solution for pure computational code, and it's used successfully on the web all the time.
  - pjmlp 6y ago
    It not unfair when plenty of WebAssembly supporters try to sell it as the ultimate bytecode, without any flaws from all the ones that came into existence since the 60's. Also it is still catching up to features that those bytecodes already have during the last 20 years. Those browsers are only shipping MVP 1.0, unless you want to equate Web with Chrome. Only now are hackers and security researchers actually caring about WebAssembly security, hence the first wave of security papers on USENIX 2020. I expect those that drove WebAssembly in detriment of what we already had to be eventually surprised. For what I care, I will just take advantage of it to get back my plugins.
merb 6y ago
biggest problem is that .net/dotnet core can not be easily wasm aot compiled. currently you compile the runtime to wasm and use the dll with the wasm runtime. this is the approach that blazor wasm uses and it is aweful.
- pjmlp 6y ago
  <win-dev-rant-mode> Mostly because Microsoft currently doesn't not know what they want, check the feedback regarding the missing roadmap for CoreRT/.NET Native. With Reunion, MAUI, Blazor (WebAssembly and mobile), WPF team transfer, they seem to have got back into another reboot the eco-system phase. </win-dev-rant-mode> Now given that, with Unity's .NET flavour can be compiled via IL2CPP => WebAssembly, or with Mono AOT as in Uno.
- ckok 6y ago
  I tried this. Aot compiling with the .net runtime just isn't very practical. I know mono does this, with some guided info for reflection based classes. But the way the structure is setup, is that string pulls in globalization. And enumeration. And comparable and equality which both work by reflection to pick the right default implementation. Reflection is expected to work, which pulls in all methods and their dependencies. By the time you have a working executable for hello world, you're a few MB ahead. The class library just isn't setup for this kind of use.
  - GordonS 6y ago
    I was thinking about this just the other day, when Microsoft announced the latest dotnet 5 preview, and yet again have postponed AOT - Microsoft have been teasing dotnet devs with the promise of production-ready AOT for something like a decade. Frankly, I wish they'd put up or shut up - either prioritise it and make it happen, or just admit defeat and say it's not going to happen.
    - pjmlp 6y ago
      Production ready AOT for .NET exists since Singularity, which MIDL and Bartok compilers were the basis of .NET WinRT on Windows 8/8.x. Then some of the Midori tech eventually made its way into .NET Native, which from my point of view UWP + .NET Native is what .NET should have been all about back in 2001. Apparently after the timid attempt with XAML Islands and MSIX, they seem to be getting the house in order and driving the platform into a way to pretend that Windows 8 and 8.1 never happened, but it seems to be lacking a lot of coordination and long term planning. Windows 10X apparently is also not getting Win32 sandbox any longer, this assuming it ever gets released. Still in the middle of the chaos, it still feels much better than if I had to deal with Android on daily basis, one IO best practices is next years legacy.

devwastaken 6y ago

Any time these come up i don't find a comprehensive analysis on security. The best, supposedly most secure libraries in the world get significant vulnerabilities.

tpetry 6y ago
This is not make any software magically secure. It‘s only purpose is to _sandbox_ a library to prevent it doing anything malicious. As wasm cant do any more than computing you simply contain the library, it cant anymore open any files, make network calls, etc.
- mehrdadn 6y ago
  > As wasm cant do any more than computing you simply contain the library, it cant anymore open any files, make network calls, etc. I wish the world was that simple.
- wahern 6y ago
  > As wasm cant do any more than computing you simply contain the library, it cant anymore open any files, make network calls, etc. That presumes the WASM implementation is bug free, which is not a great presumption, especially for the more sophisticated implementations with JIT engines, and even more so for those adding multi-threading, GC, etc.
- pjmlp 6y ago
  It doesn't prevent Heartbleed like kind of attacks. Also doesn't prevent internal memory corruption attacks that expose unintended behaviors from the public module interface.
kevingadd 6y ago
See this paper for some recent research on the subject: http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs... You can probably use wasm to build a very comprehensive secure sandbox but right now it's actually somewhat of a regression when you care about making an application secure. Your OS is safe, at least, as long as you don't let the app make any syscalls.

pjmlp 6y ago

Well, "Everything Old is New Again: Binary Security of WebAssembly" - USENIX 2020 https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...

azakai 6y ago
That's a good article! Some notes on it: https://twitter.com/kripken/status/1284576787624648705 https://twitter.com/kripken/status/1284576787624648705 Perhaps wasm isn't (yet) a good replacement for native binaries for the reasons they mention. In particular such an application usually has access to files and timing etc., and you're (currently) missing some safety techniques native binaries use, which is a risky combination. But as mentioned in the post here, if you're sandboxing a specific library that does pure computation (say, a codec or a compression library) then using wasm you can make sure it cannot escape the sandbox and that it has no timing or other OS capabilities. Those are powerful guarantees!
- pjmlp 6y ago
  Pure computation is subject to UB and memory corruption due to lacks of bounds checking inside linear memory blocks, leading to outputs that cannot be trusted, even though they are sandboxed.
  - azakai 6y ago
    Definitely, yes, and you do need to be careful about those outputs. Still, the sandboxing guarantee here is very useful! This isn't theoretical, Firefox does this approach in production (using RLBox, which is mentioned in the post), https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
    - pjmlp 6y ago
      Thanks for the link, I missed that post.

mdriley 6y ago

> Wasm sandboxing is even safe to run in the same process as other code (at least modulo Spectre-type vulnerabilities)... If you want strong security with this big a modulus you may have been looking for RSA. (ugh, sorry) Spectre V1 (speculative bounds check bypass / type confusion) is basically game over for intra-process memory isolation without introducing expensive or complicated mitigations: speculation barriers at every branch, or a more optimized pass like Speculative Load Hardening (https://llvm.org/docs/SpeculativeLoadHardening.html https://llvm.org/docs/SpeculativeLoadHardening.html) that can bring the overhead _down_ to 20-50%. From what I've seen, the best understanding right now is that the process is the smallest defensible unit of isolation. That's not to say that using WASM as an intermediate compilation target won't eliminate some threats! The runtime can definitely help to improve memory safety, for example. But if you care about confidentiality of the data in your process, any code that is untrusted enough to require sandboxing should also be run out-of-process, e.g. across an IPC boundary.

monadic2 6y ago
I’m open to a slow but secure processor. Certainly for my personal computing.
- pjmlp 6y ago
  I feel the same about bounds checking in programming languages, apparently not everyone does.
  - KMag 6y ago
    I vaguely remember a story about a hardware manufacturer (Burroughs? Symbolics?) that had a processor with instructions that could bounds-check array accesses with zero latency overhead. It was a great feature for Algol/Lisp, but some customers asked for an option in their Fortran compiler to disable the bounds check. The sales engineer replied that the bounds checks were zero-cost, but the customers replied that the bounds checks broke their progrems... their programs had silent (or at least unnoticed) array bounds bugs, and the customers preferred to keep those bugs, thank you very much! I wish I had kept the link. I've tired a couple times to find the story. Does this ring any bells for anyone?

syrusakbary 6y ago

Alon did a really great job with the article, hats off. I think WasmBoxC might be useful to try to benchmark how fast we can get Wasm to run server-side. We also hope to eventually beat native execution in server-side specific Wasm runtimes (such as Wasmer using the LLVM compiler and Profile Guided Optimizations) once the runtime ecosystem matures a bit. Keep up the good work!

jasonzemos 6y ago

> The OS-based implementation uses the “signal handler trick” that wasm VMs use. This technique reserves lots of memory around the valid range and relies on CPU hardware to give us a signal if an access is out of bounds (for more background see section 3.1.4 in Tan, 2017). On Linux you can also make use of userfaultfd(2) rather than handling SIGSEGV.

legulere 6y ago

> By compiling to wasm we sandbox the code, preventing it from accessing anything on the outside. Operating systems are in a sad state, as virtual address spaces already offer exactly that in hardware at full speed. It's only through the operating system APIs that processes gain the ability to affect anything outside of the process. Current operating systems weren't made with untrusted code in mind, but have so much inertia that new operating systems repairing old misfeatures can never succeed. All code is already written based on the bad Operating System APIs like for writing files. This project just handwaves the actual problem away: > the sandboxed code can’t do anything but pure computation, unless you give it a function to call to do things like read from a file, tell the time, etc.

sanxiyn 6y ago
CloudABI is an attempt to solve this the right way: http://cloudabi.org/ http://cloudabi.org/
darksaints 6y ago
100% agreement. With a kernel design like SeL4 there is no need for crazy sandboxing environments. It prevents you from accessing external resources by default. And it is probably as close as we can feasibly get to an operating system that is impossible to maliciously root.
titzer 6y ago
> as virtual address spaces already offer exactly that in hardware at full speed Operating system processors are pretty heavyweight, and there are lots of situations where smaller granularity protection domains are useful. I'd also quibble with "at full speed." There is a metric shitton of complexity to implement virtual memory, with multi-level TLBs, an extremely careful dance with the operating system currently, IPIs for TLB shootdown, etc. The dynamic cost of the TLB is something that is measurable, and of course, completely depends on your application behavior, kernel, availability of huge pages, etc. The reality is that we don't really have a control group for hardware without virtual memory because the only such chips are for small embedded (niche) systems, and everything else runs on kernels designed to offer virtual memory to software expecting virtual memory.

mtgx 6y ago

Would this have been more secure in Rust?

sriku 6y ago

Sounds similar to Fastly's "Lucet" - https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime https://www.fastly.com/blog/announcing-lucet-fastly-native-w...

pansa2 6y ago

So, compiling via WasmBoxC gives a 14% - 42% performance overhead compared to native compilation. Is there also a significant overhead in terms of binary size?

kevingadd 6y ago
wasm binaries are typically size-competitive with native x86 once you compress them (i.e. foo.so.zip vs foo.wasm.zip), but the jitcode you get out of them is usually much bigger. In my testing the size overhead for stuff like the ICU unicode library was maybe 20-40% on-disk, depending on compiler settings. It's gonna depend on your workload. Note that even if the actual generated jitcode is computationally efficient, it might be larger and as a result waste more space in the instruction cache, which would hinder performance.

brianolson 6y ago

Gary Bernhardt was prophetic https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

esperent 6y ago
Wasm is amazing, but it's not intended to replace JavaScript. If you just want to add a form to a website, animate a drop-down menu, or the like, JS (or TS) will probably always be preferable to writing in another language and compiling to wasm. The web platform moves fast and maybe in a couple of years I'll eat these words. But nothing I've seen so far points towards the demise of JS.
- pjmlp 6y ago
  A form like these? https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTracking=e97265b8-ec7f-4652-b052-d26b8875166d%7Ce09e2ec9-4b23-4528-8d66-448a523b7e64 https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTrack... https://gallery.flutter.dev/#/ https://gallery.flutter.dev/#/ https://platform.uno/code-samples/ https://platform.uno/code-samples/
- ronjouch 6y ago
  Gary's talk is not exactly about the "demise of JS". Watch the talk, it's a great one :)
kevingadd 6y ago
WASM will never replace JavaScript. Something else might, and it might have support for compiling to WASM, but we'll see.

Chris2048 6y ago

so, if you compiled a language shell, or interpreter this way; you would end up with a sand-boxed shell/interpreter?

ncmncm 6y ago
One that couldn't do anything. The essence of the method is providing to the sandbox specific, safe means to interact with the surrounding process.