Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

221–230 of 251 posts

Re: Pay attention to WebAssembly

#221

Post by Chris2048 »

usrbinbash wrote: post #200
Chris2048 wrote: post #189

Earlier quoted context omitted.

I understand that compilation is not an issue, but WDYM by the other stuff? Even python is a bit of a PITA to package and run where interpreters already exist, not all distros are the same - The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. JS, in virtue of being properly sandboxed, seems to be in a position to prevent coupling outside expected interfaces, and…

> Even python is a bit of a PITA to package and run where interpreters already exist That's mostly a result of everything and everyone having a different opinion where python modules should live in the filesystem, and the default behavior of a lot of package managing software to replace python installations between versions instead of shoving them into different packages and be done with it. > The advantage of a VM o…

there are also differences between lib/interpreter versions (str differences, use of Byte arrays) and stuff like Unicode/crypto support, the c-lib used (e.g. musl).

The "provided that" is exactly what I'm sceptical of - if the language is general use, not everyone will play ball unless the language/language-derivative is for the explicit purpose of maintaining this compatibility, and this is somewhat enforced. Python packaging would also be great if it shipped with an unambiguous and bulletproof/portable solution, but it didn't, and then the wheel was (partially) reinvented several times.

This is before we even consider bad-actors purposefully attacking (python packages are also susceptible to this I believe).

Re: Pay attention to WebAssembly

#222

Post by usrbinbash »

des1nderlase wrote: post #220
usrbinbash wrote: post #203

Earlier quoted context omitted.

> WebAssembly itself is independent of the web or the browser. Sure it is, but let me, a backend developer, ask a question: Why would I want to use WASM for anything running on my server, when I can just write it in Golang, and get actually native performance (not "near-native"), plus real GC, on top of an already thriving ecosystem of libraries and tools? And lets replace Golang with Rust, C, C++, or Java, or even w…

If you are building multi-tenant backend for i.e. SaaS app and you want to provide better isolation between your tenants (than relying on hardening, security/pen testing of your own code, or want to allow user/3rd party code to execute on your BE)

How exactly does WASM provide that better than, say, docker?

Re: Pay attention to WebAssembly

#223

Post by detaro »

usrbinbash wrote: post #204
detaro wrote: post #187

Earlier quoted context omitted.

Previously: "We want to deploy apps as isolated units we can have variable amounts of instances of, so we make VM images and deploy them to AWS/our VMWare cluster/...". Now: "..., so we make Docker containers and deploy them to AWS/our Kubernetes cluster/...". Hence, Docker replaced virtual machines in a way .

It replaced them from something VMs were unsuited for to begin with (running isolated environments which don't need sepearately emulated hardware).

they weren't really "unsuited", just more than necessary. Hence why they replaced them quite thoroughly. (And places like AWS spent effort on making them low-overhead, e.g. the microVMs that run your lambda functions)

Re: Pay attention to WebAssembly

#224

Post by dragonwriter »

kaba0 wrote: post #175
dragonwriter wrote: post #67

Earlier quoted context omitted.

> To continue the Java bytecode prior comment, at one point, java was in all browsers of the time No, it wasn't. > (i.e. Applets). Applets required (1) installing Java on the system, and (2) installing a plugin for Java in the browser. The capacity to run them was not built in natively to any major browser. > However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. It pr…

> But not C/C++ (or, now, Rust/Go), in which a lot of common code on which native-targeted code in other languages rely is written. It does actually. Graal can run LLVM bytecode. Also, if you mean some specific C library used by everything, the Java ecosystem is absolutely huge and has the benefit of being almost completely written in Java with very little native code.

[re: what compiled to Java when applets lost vs what compiled to WASM today]

> > But not C/C++ (or, now, Rust/Go), in which a lot of common code on which native-targeted code in other languages rely is written

> It does actually.

It didn't when applets lost.

> Graal can run LLVM bytecode

GraalVM came around a long time after applets failed, so it isn't really relevant to assessing what capability applets had when they failed vs. what WASM has now.

Re: Pay attention to WebAssembly

#225

Post by yencabulator »

maga wrote: post #64
chrismorgan wrote: post #57

Earlier quoted context omitted.

Yeah, that repository is measuring performance of a WASM/Node.js hybrid, and not straight WASM. Interoperability costs can certainly dominate in such cases, where straight WASM can bypass much of the cost. Such a hybrid is what you want to measure often, but certainly not always, and a large part of what this article is talking about is the potential of pure WASM unshackled by Node.js.

And how is the data going to reach the "unshackled" WASM in the browser, for example? I'm not aware of any way for the web page to interact with WASM other than through the JS land with the said overhead. The article explicitly mentions usage inside the web page and presents WASM as a performant alternative.

Consider a browser where the DOM is implemented in Rust and exposed to Javascript via some form of FFI.

The same DOM API could be exposed directly to WASM via WASI-like calls, without going through Javascript.

Re: Pay attention to WebAssembly

#226

Post by codeflo »

hutzlibu wrote: post #213
codeflo wrote: post #161

Earlier quoted context omitted.

I don’t know. Nothing prevents indies from selling games directly to consumers right now — it’s not like it’s hard to integrate a payment processor to your website and an auto-updater to your software. WebAssembly only replaces the auto-updater part. The actual value that Steam adds is discovery and trust.

"WebAssembly only replaces the auto-updater part. " No, it replaces the need to install something on your computer. For trying out an unknown game, I rather have a sandboxed web application, than having to install something. And most who think more in terms of convenience, will prefer the non install solution, too. Installing new software is a big hurdle to many non technical people. I witnessed many children tears,…

Are you writing from theory, or from personal experience with game app stores? Because IMO, this is mostly a solved problem in practice with Steam, Epic Store, Windows Store etc. That’s partly why those platforms are so popular.

Re: Pay attention to WebAssembly

#227

Post by jvanderbot »

the_duke wrote: post #145
playcache wrote: post #142

Earlier quoted context omitted.

One thing I am missing here. Docker, as much as it has the shortcomings you list, has an entire fleet of posix libraries, utils and tools at its availability. This has meant 99% of applications could wholesale lift their application and deploy it within a container. When I look at WASM/WASI there is no networking API, no storage API, crypto, etc etc. I can see its value for offloading parts of a web application that…

Yeah, progress on WASI has been painfully slow. I think a big reason is that it was pushed by Mozilla, but they laid off all the related employees, and now no-one is really allocating resources to push it forward. Plus it's still blocked by related proposal like interface types.

What's preventing the compilation of dependencies to WASM? Couldn't I (at extreme) run an alpine linux container distro inside WASM? At that point we're full circle, but it should be possible, right?

Re: Pay attention to WebAssembly

#228

Post by jvanderbot »

the_duke wrote: post #139
jvanderbot wrote: post #137

Earlier quoted context omitted.

So, honest question. if we're compiling our code to run on servers, why are we compiling it to run on a bytecode interpreter rather than native? My single use for docker is to containerize / isolate, not to run across architectures. I get the in-browser optimized / compiled code. That makes sense.

Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance) A few benefits why it is even useful in a server context: You can distribute a sing…

Very informative, thank you.
Post reply on HN