5 ms·

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a brows

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution of this runtime. I can only imagine the sheer number of man hours poured in to javascript to offer the functionality it has today while balancing with security and sandboxing. Nodejs is a different story; Take a look at Deno and its origin. Web-assembly is sandbox-able run anywhere, ubiquitous runtime which isn't owned specifically by a corporate overlord, and is also which has/or is set to have the evolutionary pressure javascript has. This is huge! Way to go Wasmer :)

CyberRabbi 6y ago
You don’t need webassembly to run JavaScript on the server side. You don’t need webassembly to run C++ on the server side. You don’t need webassembly to run Rust on the server side. Etc. Node was necessary because you need node (or compatible) to run JavaScript on the server side.
- epse 6y ago
  But it helps when running untrusted code, or code that has to be separated (like what you would use containers for)
- singularity2001 6y ago
  You DO need webassembly to run C++ on the server AND client(browser) side. (unless you want to use some hacky c++ to js transpiler)
  - CyberRabbi 6y ago
    Can you provide an example of a situation where it would make sense for both client and server to use the same build? Typically client and server play different roles and require different builds anyway.
    - steego 6y ago
      The point isn’t to run client code in the server and server code on the client. The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense. Embedding SQLite is a perfect example.
      - CyberRabbi 6y ago
        > The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense. That seems useful for the client side but you don’t need webassembly to do that on the server-side. E.g. https://github.com/mapbox/node-sqlite3 https://github.com/mapbox/node-sqlite3
- programmarchy 6y ago
  You’re missing the point. It’s about containerization. To quote a Docker cofounder: > If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! [1] https://twitter.com/solomonstre/status/1111004913222324225?s=21 https://twitter.com/solomonstre/status/1111004913222324225?s...
  - CyberRabbi 6y ago
    I’m not. You’re making a different argument for why webassembly is relevant than the post to which I originally responded.
higerordermap 6y ago
> offer the functionality it has today while balancing with security and sandboxing. LoL, LoL, LoL You can say this only because every other operating system sucks at sandboxing. There is no reason you have to be inefficient as browser to provide security and sandboxing. In return there is also a huge attack surface, with all the code running below, and corner cases in web standards. AFAIK any js click event can allow a website to read your clipboard. Websites can somehow prompt to add extensions to your browser etc.. I know there are legitimate reasons for this but it sandboxing is not exclusive virtue of web platform.
- alexhutcheson 6y ago
  What existing sandboxing systems are you thinking of that are more efficient? Would you be confident using them to run possibly malicious code on your system?
  - shakna 6y ago
    BSD jails? I'd be quite confident running possibly dangerous code in one of the most restricted jail configs. Processes can't interact, can't access outside their given directories, can't modify devices, etc.
  - deleted 6y ago
    [deleted]
  - higerordermap 6y ago
    >> because every other OS sucks at sandboxing And I won't be confident using browser too. Pretty sure at any given time there will be quite a few javascript/wasm attacks which can escape browser sandbox and run arbitrary code, then my files won't be safe. When I am running potentially malicious website I am creating a separate user on my linux box anyway.
justsomeuser 6y ago
I like WASM for technical reasons, but I do not think it will stand the test of time and become a major part of how programs are run. Mainly because the areas where it used have other solutions that are “good enough”. In the browser JS is good enough. On the server Docker + your typical Linux program is “good enough”. In time things like KVM will offer great sandboxing to containers. Another issue is that server side programs depend on system interfaces of Linux, which are battle tested, observable and trusted. With WASM you need to replicate that with some message passing system.

CyberRabbi 6y ago

You don’t need webassembly to run JavaScript on the server side. You don’t need webassembly to run C++ on the server side. You don’t need webassembly to run Rust on the server side. Etc. Node was necessary because you need node (or compatible) to run JavaScript on the server side.

epse 6y ago
But it helps when running untrusted code, or code that has to be separated (like what you would use containers for)
singularity2001 6y ago
You DO need webassembly to run C++ on the server AND client(browser) side. (unless you want to use some hacky c++ to js transpiler)
- CyberRabbi 6y ago
  Can you provide an example of a situation where it would make sense for both client and server to use the same build? Typically client and server play different roles and require different builds anyway.
  - steego 6y ago
    The point isn’t to run client code in the server and server code on the client. The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense. Embedding SQLite is a perfect example.
    - CyberRabbi 6y ago
      > The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense. That seems useful for the client side but you don’t need webassembly to do that on the server-side. E.g. https://github.com/mapbox/node-sqlite3 https://github.com/mapbox/node-sqlite3
programmarchy 6y ago
You’re missing the point. It’s about containerization. To quote a Docker cofounder: > If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! [1] https://twitter.com/solomonstre/status/1111004913222324225?s=21 https://twitter.com/solomonstre/status/1111004913222324225?s...
- CyberRabbi 6y ago
  I’m not. You’re making a different argument for why webassembly is relevant than the post to which I originally responded.

higerordermap 6y ago

> offer the functionality it has today while balancing with security and sandboxing. LoL, LoL, LoL You can say this only because every other operating system sucks at sandboxing. There is no reason you have to be inefficient as browser to provide security and sandboxing. In return there is also a huge attack surface, with all the code running below, and corner cases in web standards. AFAIK any js click event can allow a website to read your clipboard. Websites can somehow prompt to add extensions to your browser etc.. I know there are legitimate reasons for this but it sandboxing is not exclusive virtue of web platform.

alexhutcheson 6y ago
What existing sandboxing systems are you thinking of that are more efficient? Would you be confident using them to run possibly malicious code on your system?
- shakna 6y ago
  BSD jails? I'd be quite confident running possibly dangerous code in one of the most restricted jail configs. Processes can't interact, can't access outside their given directories, can't modify devices, etc.
- deleted 6y ago
  [deleted]
- higerordermap 6y ago
  >> because every other OS sucks at sandboxing And I won't be confident using browser too. Pretty sure at any given time there will be quite a few javascript/wasm attacks which can escape browser sandbox and run arbitrary code, then my files won't be safe. When I am running potentially malicious website I am creating a separate user on my linux box anyway.

justsomeuser 6y ago

I like WASM for technical reasons, but I do not think it will stand the test of time and become a major part of how programs are run. Mainly because the areas where it used have other solutions that are “good enough”. In the browser JS is good enough. On the server Docker + your typical Linux program is “good enough”. In time things like KVM will offer great sandboxing to containers. Another issue is that server side programs depend on system interfaces of Linux, which are battle tested, observable and trusted. With WASM you need to replicate that with some message passing system.