Hacker News Reader

Comment by kerkeslager | Hacker News Reader

I just don't understand why you'd want this, or any of the JS server-side nonsense. WebAssembly is designed for the web--why would you want to use it outside the browser, when there are dozens of much more mature frameworks out there that were designed to work on your machine?

It seems to me like a lot of the JS outside the browser stuff out there is motivated by JS people not wanting to learn something different. Meanwhile for those of us who have been doing dev outside the browser, all this is worse solutions to problems we've already got solutions for.

View on HN

> WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

While the primary target for WebAssembly is indeed the web there are surely plenty of applications for a cross-platform stack-based virtual machine.

> It seems to me like a lot of the JS outside the browser stuff out there is motivated by JS people not wanting to learn something different.

Well that certainly can't be the case here because WebAssembly specifically isn't JavaScript. It's a well specified, reliable platform for different languages to target for cross-platform execution. Is that really so bad? To turn it on its head, if you're going to build a cross-platform application framework, why not use WebAssembly, aside from the fact that it has "web" in the name?

Sandboxing alone is a very important reason.

Sandboxing 3rd party code inside existing applications for example. Like plugins for Photoshop-like applications or game mods. Portability is also a big plus for this kind of thing too.

Agreed. Wasm let's you just revoke network access from things that don't need it. I know you can also do that with docker but its an awful big hammer for the job.

Yeah exactly, it is kinda insane how deep open source tech stacks have gone.

We need a world where we can seamlessly synchronously (no IPC, no network) call a function from a 3rd party and be sure it doesn't make any network requests, read the disk (or any other type of I/O) or read non-assigned RAM.

If we could do that the amount of scrutiny you need for your 3rd party code goes down massively. WASM is a step to get there.

I think what you're saying is that we need a world where more things are built out of pure functions with explicit inputs. And I agree.

Wasm lets you take something that is coincidentally pure and run it in a way that ensures that it'll stay that way even for novel inputs, but you're still treating it like a black box... Just a particularly well behaved one.

Sometimes you need that because you're dealing with somebody else's code and they weren't especially interested in providing the kinds of assurances that you'd like to have. So I agree, it is a step in the right direction.

But if you want to author code that gives users such assurances, building to wasm is a rather small step. There only so much that can be done at the bytecode level. Much more can be done at a language level (Unison comes to mind, which goes so far as to eliminate the function's name as a source of works-differently-on-my-machine, though Haskell is probably a more common choice).

I think ultimately this isn't the solution.

The solution to insanely deep open source tech stacks is to use simpler stacks. This is really my whole problem with the way JS is ubiquitously developed: you simply do not need 99% of the tools the JS devs are using these days. I use very simple full-stacks: so simple that I don't need a JS package manager (I do use pip/pypy, but I'm extremely guarded about what code I'll import--usually <10 packages). I do write some code that could be imported in a library sometimes, but I also barely ever do any rewriting to deal with deprecations, and my builds never break due to a package change. My builds are often reproduceable by accident.

In the short run, I'm not less productive than people who use all of npm. In the long run, I'm far more productive.

And even if that weren't the case, developer productivity at the expense of user security was a pretty bad tradeoff anyway. I really wish fewer people were doing that.

One possible use-case is a system like Inferno[0] (the plan9-like operating system). Since, on that OS, you can "mount" CPUs from other machines over the network[1], you either need to make sure all of your machines have the same CPU architecture (including additional instruction sets lest you end up with AVX512 code trying to run on an Intel processor), or you use a non-compiled language. Inferno went with the latter and introduced Limbo[2] for that purpose, but with webasm we could use any language and still leverage all the great tooling being written for it.

  [0] https://en.wikipedia.org/wiki/Inferno_(operating_system)
  [1] Behind-the-scenes it actually mounts your filesystem onto the remote machine and sends it commands to run, rather than actually "mounting" a CPU over the network. https://9p.io/magic/man2html/1/cpu
  [2] https://en.wikipedia.org/wiki/Limbo_(programming_language)

Because people need to run their Apps on multiple targets and having one codebase for all targets helps with keeping maintenance and development costs down. Java would meet this requirement if the UX/UI story was anywhere near as good as the Web's. I'd argue that UI has been the main driver of all of this.

> WebAssembly is designed for the web--why would you want to use it outside the browser?

I'm not involved in Orca, but I can think of 2 reasons:

1. WebAssembly has really fine-grained sandboxing for untrusted code.

2. WebAssembly has good support for starting the program as parts of it are still being downloaded / compiled.

Same reason Docker was a success - packaging and distribution of apps becomes easier. That's my guess.

So are we inventing JVM again?

Yes. But with manual memory management this time.

Java inside the browser was a thing too, right?

You gave me a 90’s flashback…

Staring at a gray box waiting for something to happen.

I can only remember minecraft

For safely running an untrusted architecture- and operating-system-agnostic binary blob. If all operating systems could even run simple WASI cmdline blobs directly that would actually solve a real problem for me (of distributing a shader compiler executable for Linux, macOS, Windows across x86 and ARM, which is built from massively big 3rd party C++ libraries (so compiling on the user machine isn't really an option).

I guess https://github.com/jart/cosmopolitan might just be the WebAssembly for the command line then.

AFAIK Cosmopolitan is missing the sandboxing features of WASM runtimes which would allow to run untrusted code safely, and for x86 vs ARM it uses the universal binary approach (e.g. you'll either have the x86 or the ARM code as dead weight in the executable).

Suddenly the front-end coders become full-stack coders.

VSCode is JS outside the browser. It seems that companies such as Microsoft, Saleforce, want to leverage their existing JS tools.

VSCode is an entire web browser (Electron packaged Chromium). It even ships with "Simple Browser" built in, which is just a web view.

Perhaps a more direct example is Node's/Bun's ability to package a JS/TS project into a single binary with only the JS engine browsers use rather than the whole thing.

Reply on news.ycombinator.com