Hacker News Reader

Comment by hexo | Hacker News Reader

I really do prefer open stuff so I have zero plans on turning wasm on in my browser. How does open web benefit from wasm, pretty please? Because open web is top priority, not enabling astonishingly complicated, compiled and locked down "apps". Did I miss something?

View on HN

How is wasm less open than minimised JavaScript? It's effectively just a binary format for asm.js.

Maybe you mean "openess" in an "in-browser inspectable" sense, ie. "open web" as in "Gopher & Gemini", but if you mean "open" as in "open-source" then there actually some folks doing really interesting things in this space:

https://spritely.institute/news/hoot-wireworld-live-in-brows...

I don't think you are missing anything, it's just that most people care more about easily building things than "openness".

Do you also not run javascript code of websites that has been run through a transpiler with tree-shaking and minification? Because WASM is about as locked down as that.

Since unfortunately the proliferation of use of WASM on the open web seems inevitable (to me), perhaps some community effort into tooling to automatically inspect and disrupt WASM apps to make your browser behave is worthwhile. Random ideas: web canvas OCR scrapers, dumping longer strings from wasm memory to render a useful page, etc. I'm thinking of the regular debug tools but on steroids and geared around subverting the user-hostile stuff we're about to see.

I'm less interested in WASM in-browser than I am for WASM-powered services in edge computing (Cloudflare workers, Wasmer Edge, etc). Without WASM, you're always going to suffer cold start issues due to containers or other runtime initialization costs. This is likely the reason why Cloudflare Workers are so much cheaper than Lambda, however it's limited to workers/wasm.

I honestly don't really get how wasm solves this issue. How is it better for this than natively compiled binaries or java bytecode?

Binaries require a container or VM sandboxing in order to run. Java bytecode, afaik, has a slow cold start issue and still requires some additional sandboxing afaik. WASM can cold start fast because the runtime API is natively restrictive to local resources and requires explicit permissions to do otherwise. It would seem that WASM actually makes for a better binary format for edge computing.

> the runtime API is natively restrictive to local resources

What does it even mean?

You can't just go calling fopen with all the permissions of the thread/process.

What does it have to do with fast startups then?

Since the WASM runtime doesn't have to worry about resource access violations or memory corruption, it doesn't need a VM or container. This means WASM can start faster without needing any additional security wrappers. I'm doing my best to simplify, but I'd recommend reading about Workerd or Wasmer to learn more about WASM host services.

With all due respect, this doesn’t make any sense. A VM in the JVM sense is an almost identical runtime - why would one start faster than the other? The only difference might be between the speed of the interpreters, as WASM is a bit lower-level than JVM byte code.

Containers have absolutely nothing to do with the topic, and I’m afraid if you mix them up with the former kind of “VM”s your point is moot.

I know little about JVM, but I've gathered that WASM cold starts are far quicker because WASM can be incrementally compiled* as bytes are streamed into edge services. Cold start time is king when almost every user is using a different edge location. * https://stackoverflow.com/a/58134568

Java class files are very small, and also support streamed loading.

This was a very enlightening thread. My takeaway is: It actually is a similar approach to the jvm, but cold starts faster, whether because of differing design and implementation choices explicitly made to achieve this, or just because it ended up working out that way.

But in either case, "a bytecode for a JIT-compiling runtime that cold starts very quickly", does indeed sound very useful for edge computing. Thanks!

Thanks for the mention to Wasmer.

I'll put here a link in case is useful for future readers: https://wasmer.io/

How is the current JS blob served by e.g. facebook right now with a().b=c any more readable than a binary blob?

About 1000 times more

Please take a look at Facebook’s loaded js files.

Ultimately, you probably won't have an option - just as one can't disable JavaScript today and still view most of the web. If the vast majority of people leave WASM enabled, companies will build things using it. It seems likely that WASM will displace JavaScript over the next 20 years as engineers decide they'd like to use non-JS languages to build their client-side code. It will take time since there's a huge amount of JS that's already out there, but new projects will become less and less likely to choose JS. Some still will. Many people like JS. However, I think a majority of new front-end projects 10 years from now won't be JS.

You're not missing anything. WASM's primary purpose is to push unblockable, canvas-drawn ads.

Reply on news.ycombinator.com