Live data from Hacker News

WebAssembly’s post-MVP future

hacks.mozilla.org

71–80 of 207 posts

Re: WebAssembly’s post-MVP future

#71
post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Is GC that wide of a problem that tunable parameters could not be provided to support different use cases?

Yes.

Re: WebAssembly’s post-MVP future

#72

Maybe a stupid question but why does the browser itself need to do compilation? Why can’t WebAssembly developers compile ahead of time and just serve the binary?

This is answered in the article (pretty far down, I'll admit):

>But if all we have is the link, there are two problems here that we haven’t addressed.

>The first one is… you go visit this site and it delivers some code to you. How does it know what kind of code it should deliver to you? Because if you’re running on a Mac, then you need different machine code than you do on Windows. That’s why you have different versions of programs for different operating systems.

>Then should a web site have a different version of the code for every possible device? No.

>Instead, the site has one version of the code—the source code. This is what’s delivered to the user. Then it gets translated to machine code on the user’s device.

Re: WebAssembly’s post-MVP future

#73
post #52
post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Why not implement the GCs themselves using low-level WASM code? That would enable a language-agnostic approach (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

You've already got 2 co-operating languages - JS and whatever is compiler to WASM.

Re: WebAssembly’s post-MVP future

#74

What is the state of expanding GPU programming APIs in the browser? Seems that one of the biggest factors holding back the development of media applications for photo/video editing, games is a lack of a modern graphics api and first class GPGPU support. A while ago there was momentum towards webGPU and webVulcan but these projects seemed to have quieted down. We did get Webgl 2.0 but there is still tons of room for i…

Chrome team has also announced intent to implement WebGPU on most platforms

https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

In addition to rich applications for 3D modelling, photo editing, etc. Adoption of WebXR as a distribution platform for VR/AR content could drive development. MagicLeap's Asset Builder Web Tool for example is built on top of NextJS and ThreeJS

Re: WebAssembly’s post-MVP future

#75

Maybe a stupid question but why does the browser itself need to do compilation? Why can’t WebAssembly developers compile ahead of time and just serve the binary?

Two reasons:

Portability - you would need to know what you're compiling for, in the same way you need to compile a different version of your program for your PC and your phone. You could imagine a system where some pre-compiled versions exist for certain browser/host combinations to make life faster for the majority case thought except:

Security - the primitives that WASM has available are limited and only affect stuff in the sandbox. The browser then compiles that to machine code and can know that the machine code will only affect stuff in the sandbox. This is exactly how JS works - unless there's a browser bug, JS can't write to an arbitrary place on your harddisk (for instance). If machine code was provided directly, then the browser couldn't easily verify that the machine code only did safe things (because machine code can do anything, unlike WASM).

Re: WebAssembly’s post-MVP future

#76

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

> Developers need laptops to run their development environment in. I hear a lot of developers going on and on about laptops these days but I can't figure out why. Is working out of a coffee shop the norm now or something?

We just get to work at the office on a docking station, at other company sites, on customer premises, home office and while traveling to customers.

Re: WebAssembly’s post-MVP future

#78

Earlier quoted context omitted.

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

If there's some better environment to be found in non-JS-land, why is Electron and its ilk so popular?

"better environment" - worse is better. Its explained in the comment above you about entrenched interests. Whether js and html are worse in the browser is one thing but I think you could argue strongly that they are worse on the desktop. As a user, the experience for me is pretty bad.

Re: WebAssembly’s post-MVP future

#79

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

WebASM really only makes sense in the context of embedding untrusted code, which outside of the browser is a concern that largely doesn't exist. Otherwise you are severely crippling yourself for no real gain. You're going to lag the hardware features by years if not decades, you're not going to get arch-specific optimizations as readily, and you're going to have huge startup costs. You're also stuck with sandbox rest…

That is how IBM i, IBM z, Unisys ClearPath work, how a large majority of Android and Windows apps, some iOS ones (mostly watchOS actually), Garmin devices, SIM cards, Blue Ray, Ricoh copiers, ...

If anything the industry is increasingly adopting bytecode as distribution format, kind of returning to the early 60/70's designs with microcoded CPUs just with another approach to the final execution.

Re: WebAssembly’s post-MVP future

#80

Earlier quoted context omitted.

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

If there's some better environment to be found in non-JS-land, why is Electron and its ilk so popular?

Because many don't know any better.
Post reply on HN