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

201–210 of 251 posts

Re: Pay attention to WebAssembly

#201

Post by the_duke »

kaba0 wrote: post #196
the_duke wrote: post #182

Earlier quoted context omitted.

I am (somewhat) familiar with the JVM. Yes, it's also a stack based VM that is relatively small, at least superficially. It's really not that simple though. Things like GC, exception handling, a whole class model with constructors and methods, ... All of that brings countless implicit requirements that are only passingly mentioned in the spec. Plus the whole host of complexity needed in practice for supporting the Ja…

> the lack of AOT until recently (in open source implementations) The gcc project had a now discontinued AOT java compiler 2 decades ago. Java is as open as it gets, with a standard, that can be changed through a community process. I feel the web is much less open with behemoths having basically infinite veto powers like google apple microsoft. > In fact, GraalVM already supports Webassembly, including WASI! So in ce…

> The gcc project had a now discontinued AOT java compiler 2 decades ago.

Was that ever really production ready?

Re: Pay attention to WebAssembly

#202

Post by the_duke »

the_duke wrote: post #133
SquibblesRedux wrote: post #83

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the W…

A little bit of an addendum: what will make or break WASM is language support.

If enough languages get official or high quality wasm targets, it has a bright future.

Sadly progress has stalled a little bit here, partially due to very slow progress on some features important for higher level languages.

But we'll see how things develop.

Re: Pay attention to WebAssembly

#203

Post by usrbinbash »

kccqzy wrote: post #41
hankman86 wrote: post #18

There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks. Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm…

WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answ…

> 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 with a more dynamic language like Python or node if its not performance-critical...the question remains.

My point is, why would I use WASM for something other than what it was originally designed for (running things in the browser), when I already have a big collection of really powerful, established, stable, well supported backend Languages?

What does WASM bring to the backend-table that the current tools cannot provide, or provide badly?

Re: Pay attention to WebAssembly

#204

Post by usrbinbash »

detaro wrote: post #187
robertlagrant wrote: post #185

> Just as Docker could not replace virtual machines entirely I keep seeing this. Docker in no way replaces virtual machines. Can someone explain?

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).

Re: Pay attention to WebAssembly

#205

Post by pjmlp »

goombacloud wrote: post #193

You lose the regular Linux process you are used to and the interaction you can have between processes: start new ones to offload a small task, pipe data, trace them with strace or debug them with gdb. I think this convenience also held back people from moving to Unikernels.

Yet they are running containers on a top of type 1 hypervisor that they can only control over Web dashboards and cluster telemetry.

Re: Pay attention to WebAssembly

#206

Post by pjmlp »

usrbinbash wrote: post #203
kccqzy wrote: post #41

Earlier quoted context omitted.

WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answ…

> 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…

Business opportunities for new startups trying to sell it as a new idea.

Re: Pay attention to WebAssembly

#207

Post by pjmlp »

the_duke wrote: post #201
kaba0 wrote: post #196

Earlier quoted context omitted.

> the lack of AOT until recently (in open source implementations) The gcc project had a now discontinued AOT java compiler 2 decades ago. Java is as open as it gets, with a standard, that can be changed through a community process. I feel the web is much less open with behemoths having basically infinite veto powers like google apple microsoft. > In fact, GraalVM already supports Webassembly, including WASI! So in ce…

> The gcc project had a now discontinued AOT java compiler 2 decades ago. Was that ever really production ready?

Yes, Red-Hat used to AOT compile Eclipse with it.

Re: Pay attention to WebAssembly

#208

Post by pjmlp »

kaba0 wrote: post #173
mdasen wrote: post #81

Earlier quoted context omitted.

I think what makes thing succeed or not can be subtle (and therefore it's easy to disagree with). Ultimately, I think WASM will succeed because it's a uniting force among communities. Rust people are behind it, Microsoft and C#/.NET are behind it, people in the Go, Python, and other communities are behind it, and the browser vendors are behind it. Java applets were things that were slow to load and didn't interface w…

I don’t think that Flash and Java “created their own little world”, but rather that they were entities not “accepted” by browsers, so they remained in a “third-party” status, but that was not their decision to make.

The irony being that now all of them have WebAssembly based runtimes available, so one gets to run two runtimes instead of one.

Re: Pay attention to WebAssembly

#209

Post by pjmlp »

the_duke wrote: post #135
hwers wrote: post #4

Another random reason webassembly is really cool is that it let's you run ML models way faster after page load than through the GPU (which can take a ton of time to load all the buffers into VRAM).

In contrast, webgpu Webassembly bindings have the potential to enable fast ML code execution everywhere. Both for browser and native use cases.

OpenGL ES 3.2 is already capable of that, but politics killed the support for compute shaders in WebGL.

Now we have to wait for WebGPU.

Re: Pay attention to WebAssembly

#210

Post by ncmncm »

fsloth wrote: post #128
evmar wrote: post #120

Earlier quoted context omitted.

Yes, sorry! I should've written GL, not GPU, but it's too late to edit it to fix. ...though there are some shaders involved.

FWIW I think GPU is fine as Webgl is the only api browser can use before Webgpu takes off.

I wonder why we don't get WebVulkan instead. Is it just because Apple Metal is insufficient to implement Vulkan on?
Post reply on HN