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

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 207 posts

Re: WebAssembly’s post-MVP future

#41

Post by kllrnohj »

skybrian wrote: post #12

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 restrictions that you've self-imposed, making it harder to do things that would have otherwise been trivial or needs to be re-invented.

You could maybe squint and claim you need a portable IR, but given there's only really 2 ISAs in widespread use (x86 & ARM) does that _really_ matter? Similarly you could claim cross-OS support, but again as there's only _really_ 2 OS's for each target (Windows/Linux for server, Android/iOS for mobile) does that _really_ matter? Critically does it matter to such a degree that you'd rather severely cripple your own app to get it instead of just compiling it 2, 3, or 4 times?

Re: WebAssembly’s post-MVP future

#42

Post by robotblake »

beatgammit wrote: post #29
skybrian wrote: post #12

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…

One awesome thing about WebAssembly is that it makes a lot of sense as an extension language. Instead of building around the JVM or .NET to get access to languages on those platforms and instead of standardizing on one embedded language (Lua, Python or JavaScript), I can use anything that supports WebAssembly and double dip with that same ecosystem working in the browser. And that list of supported languages will onl…

I work with some people who are working on Iodide [1] which is a Jupyter style notebook thing that runs entirely in the browser, they've already ported Python to WebAssembly [2][3] so you can use it as a language.

[1] https://iodide.io/ [2] https://github.com/iodide-project/pyodide [3] https://iodide.io/iodide-examples/python.html

Re: WebAssembly’s post-MVP future

#43

Post by Vinnl »

Wow. Never did I expect it to generate this much (potential) innovation back when asm.js was announed. Pretty excited to be following on, even though I personally probably won't be writing anything for WASM any time soon - though this excellent series on Mozilla Hacks probably also played a role.

Re: WebAssembly’s post-MVP future

#44

Post by tehsauce »

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 improvement and much to be gained!

Re: WebAssembly’s post-MVP future

#45

Post by tyingq »

rifung wrote: post #26
eksemplar wrote: post #14

Earlier quoted context omitted.

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…

I'm not really sure wasm is meant to compete with JS like that though? To me the main benefits of wasm are that you can * make web pages with languages besides JS * do lower level things not possible with JS (low latency real time games?) If you already know JS well and want to make a normal website I don't think you need WASM necessarily although it will enable those who don't know JS or want to use JS to make them…

Once they add GC, threads, polymorphic inline cache, and some sort of stdlib, it will be possible to have popular scripting languages run in the browser without the current problems of download size for the runtime and performance.

So, it may not be completely intentional, but WASM does have roadmap items that may end up competing with JS. WASM starts to look more like a general purpose VM over time.

Re: WebAssembly’s post-MVP future

#46

Post by roblabla »

sk1pper wrote: post #39
msoad wrote: post #20

I used to think without DOM web assembly is uselsess then I saw how Figma made their UI super fast rendering to a canvas and was convinced that hopefully WS will be the reason DOM apis go out of fashion

How does this not end up as Flash reincarnated though?

What part of flash was bad?

- the (bad) sandboxing? WASM uses the same sandboxing model as JS, and thus provides the same security guarantees?

- the requirement of an external plugin? WASM comes preinstalled in all browsers.

- the proprietary aspect? Wasm is an open standard.

- the obfuscated nature? WASM can be decompiled very easily. Besides, js served by modern websotes are already minimized and obfuscated beyond recognition.

What am I missing here? I consider Flash to be a truly great piece of technology. It allowed easy creation of multimedia contents Its flaws were in its implementation, not in what it allowed. I want wasm to succeed as a reincarnated, better flash.

Re: WebAssembly’s post-MVP future

#47

Post by nfriedly »

sk1pper wrote: post #39
msoad wrote: post #20

I used to think without DOM web assembly is uselsess then I saw how Figma made their UI super fast rendering to a canvas and was convinced that hopefully WS will be the reason DOM apis go out of fashion

How does this not end up as Flash reincarnated though?

Multiple implementations, including more than one Open Source implementation.

Re: WebAssembly’s post-MVP future

#48

Post by flohofwoe »

tehsauce wrote: post #44

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…

AFAIK the current WebGL-successor-work happens here, and there's very recent activity:

https://github.com/gpuweb

No idea how long until we can play around with it in browsers though.

Re: WebAssembly’s post-MVP future

#49

Post by zimbatm »

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.

Re: WebAssembly’s post-MVP future

#50

Post by msoad »

nine_k wrote: post #40
msoad wrote: post #20

I used to think without DOM web assembly is uselsess then I saw how Figma made their UI super fast rendering to a canvas and was convinced that hopefully WS will be the reason DOM apis go out of fashion

Displaying is the easier part. Taking input would be trickier.

Also accessibility. But those are easy to solve problems worth solving considering how much of a garbage DOM is
Post reply on HN