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

91–100 of 207 posts

Re: WebAssembly’s post-MVP future

#91

Post by beatgammit »

robotblake wrote: post #42
beatgammit wrote: post #29

Earlier quoted context omitted.

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

Nice.

I've been watching efforts to port Lua to WebAssembly (the official VM looks simple enough, but luajit won't be easy) because I want to have an app that shares code with the browser, and it would be awesome to play with WebAssembly as the plugin system of choice on the backend.

I'm also super excited for nebulet[1], which is a micro-kernel experiment using WebAssembly in Ring 0, which is pretty neat.

I'm really excited to see where WebAssembly can go. I know many of these projects will peter out, but it's exciting nonetheless.

[1] https://github.com/nebulet/nebulet

Re: WebAssembly’s post-MVP future

#92

Post by tabtab »

matthberg wrote: post #82

The parallels with the Destroy All Software talk "The Birth and Death of Javascript" [0] are crazy. Seeing the section where they address the possibility of Node modules and system access from WASM is like seeing a flying car advertisement in real life. [0]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: like seeing a flying car advertisement

Ditto the feeling. I don't "get" WASM from a typical in-house CRUD development. Game makers, maps, movie editors; sure they need the speed. But some say it's gonna revolutionize most browser-based application dev, but I can't get specific examples that are relevant to us. And even for those domains listed, relying on inconsistent and buggy DOM as found in browser variations is a problem it probably won't solve. DOM will still suck as a general purpose UI engine.

WASM just makes DOM bugs run faster.

Re: WebAssembly’s post-MVP future

#93

Post by wild_preference »

pjmlp wrote: post #80
edflsafoiewq wrote: post #70

Earlier quoted context omitted.

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.

Meh, the issue with Electron is performance. The actual dev environment is decent, like how trivial it is to bring your own abstractions like React. Being able to inspect element and use Chrome's debugger. Being able to use whatever text editor you want. Using a compile-to-JS language. etc.

I'm certainly not using Xcode + Cocoa + the MVC abstraction for iOS/macOS apps because it's the superior way to build software. It has its own warts, like the effort it takes to swap out MVC with some other pattern, or how it comes with no async abstractions -- you'll just be writing callback code like JS developers had to before the Promise.

It's tempting to unmask "ugh, JS developers" as a bunch of idiots, but I think you'd only be kidding yourself if you think your pet environment is some global optimum.

Re: WebAssembly’s post-MVP future

#94

Post by pcwalton »

tabtab wrote: post #92
matthberg wrote: post #82

The parallels with the Destroy All Software talk "The Birth and Death of Javascript" [0] are crazy. Seeing the section where they address the possibility of Node modules and system access from WASM is like seeing a flying car advertisement in real life. [0]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: like seeing a flying car advertisement Ditto the feeling. I don't "get" WASM from a typical in-house CRUD development. Game makers, maps, movie editors; sure they need the speed. But some say it's gonna revolutionize most browser-based application dev, but I can't get specific examples that are relevant to us. And even for those domains listed, relying on inconsistent and buggy DOM as found in browser variations…

The DOM isn't particularly "buggy", relative to, say, Win32 or Cocoa. It may or may not be a bad API, but implementations are pretty solid.

(I have to confess I've never understood the objections to the DOM. I have literally never had an instance in which I had to use the raw Win32 API that didn't turn into a miserable experience.)

Re: WebAssembly’s post-MVP future

#95

Post by tabtab »

pcwalton wrote: post #94
tabtab wrote: post #92

Earlier quoted context omitted.

Re: like seeing a flying car advertisement Ditto the feeling. I don't "get" WASM from a typical in-house CRUD development. Game makers, maps, movie editors; sure they need the speed. But some say it's gonna revolutionize most browser-based application dev, but I can't get specific examples that are relevant to us. And even for those domains listed, relying on inconsistent and buggy DOM as found in browser variations…

The DOM isn't particularly "buggy", relative to, say, Win32 or Cocoa. It may or may not be a bad API, but implementations are pretty solid. (I have to confess I've never understood the objections to the DOM. I have literally never had an instance in which I had to use the raw Win32 API that didn't turn into a miserable experience.)

With Win32 and Cocoa you pretty much have one vendor with roughly 3 or so major releases. But with browsers you have roughly 8 vendors above 1% market-share with 3 or so (notable) major releases each. Therefore, you have to target roughly 8x more variations of the UI engine.

Look how hard Wine's job is to be sufficiently compatible.

I believe we need to either simplify the front-end standards (pushing as much as possible to the server), or fork browsers into specialities: games, media, CRUD, documents, etc. What we have now sucks bigly. Try something different, please!

Re: WebAssembly’s post-MVP future

#96

Post by pcwalton »

zimbatm wrote: 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.

Well, not implementing GC isn't really a viable option long-term. You have to have some bridge between Web Assembly and objects defined in WebIDL, and, for better or for worse (I think: for better), GC'd objects with WebIDL interfaces are the COM objects of the Web.

If DOM objects can hold on to Web Assembly objects--as for example happens in the case of event listeners implemented in wasm--and Web Assembly objects can hold on to DOM objects, then the only sensible solution to memory management is a GC that can trace both kinds of objects. All other solutions eventually lead to uncontrollable memory leaks (see IE6).

Re: WebAssembly’s post-MVP future

#97

Post by pcwalton »

tabtab wrote: post #95
pcwalton wrote: post #94

Earlier quoted context omitted.

The DOM isn't particularly "buggy", relative to, say, Win32 or Cocoa. It may or may not be a bad API, but implementations are pretty solid. (I have to confess I've never understood the objections to the DOM. I have literally never had an instance in which I had to use the raw Win32 API that didn't turn into a miserable experience.)

With Win32 and Cocoa you pretty much have one vendor with roughly 3 or so major releases. But with browsers you have roughly 8 vendors above 1% market-share with 3 or so (notable) major releases each. Therefore, you have to target roughly 8x more variations of the UI engine. Look how hard Wine's job is to be sufficiently compatible. I believe we need to either simplify the front-end standards (pushing as much as poss…

Interoperability, and the standards process, is how we get specs that are sensible. Whenever I have to program using Win32, Cocoa, etc. I inevitably spend a ton of time reverse engineering how the proprietary APIs work. For DOM APIs, things generally work how they are supposed to work, because they were actually designed in the first place (well, the more recent APIs were).

Wine isn't comparable, because the Web APIs are designed by an open vendor-neutral standards committee and have multiple interoperable open-source implementations.

Your proposals break Web compatibility and so are non-starters. Coming up with fixes for problems in the DOM and CSS is the easy part. Figuring out how to deploy them is what's difficult.

Re: WebAssembly’s post-MVP future

#98

Post by tannhaeuser »

kllrnohj wrote: post #41
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 rest…

In addition, WASM lacks bindings to the browser environment (or any API for that matter), as its original pitch was improving performance-critical code paths in browser apps; but like you said, it won't be able to reach native ARM ISA speeds nevertheless. At most, in a couple years, it could hope to do what JavaScript has been doing for over a decade. But the browser rendering model and WebGL will just be the same. And then you still have an upstream battle and hope Apple and Google will open their mobile platform APIs to WASM apps, and agree to a common standard which I don't see happening. I can't understand for the life of me what people are projecting into WASM. A new bytecode format for code delivered over the network doesn't solve any problem we're having that isn't solved much better using a native platform API/ABI.

Re: WebAssembly’s post-MVP future

#99

Post by raphlinus »

kllrnohj wrote: post #41
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 rest…

I agree that WASM is only really interested for embedding untrusted code, but am not sure that the browser is the only place where you need that. A good example is Cloudflare's workers, which they talked about at the last SF Rust Meetup.

Once you get a _good_ solution to embedding untrusted code, you might find it turns out to be pretty useful.

Re: WebAssembly’s post-MVP future

#100

Post by kllrnohj »

raphlinus wrote: post #99
kllrnohj wrote: post #41

Earlier quoted context omitted.

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…

I agree that WASM is only really interested for embedding untrusted code, but am not sure that the browser is the only place where you need that. A good example is Cloudflare's workers, which they talked about at the last SF Rust Meetup. Once you get a _good_ solution to embedding untrusted code, you might find it turns out to be pretty useful.

Do you really need embedded code for things like Cloudflare's workers, though? It doesn't seem like it does, seems like each worker can just be its own process using normal process isolation mechanisms. Switching to embedded untrusted code for things like that would actually make a lot of stuff a lot harder - scheduling, resource monitoring, etc... would all need to be re-invented from scratch. Is it really useful to re-invent the kernel in userspace to use a bunch of embedded webasm contexts instead of just a bunch of processes?
Post reply on HN