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

111–120 of 207 posts

Re: WebAssembly’s post-MVP future

#111

Post by yoklov »

chriswarbo wrote: post #83
tyingq wrote: post #56

Earlier quoted context omitted.

The CLR in .Net seems to support a very broad spectrum of languages, including functional, statically typed, dynamically typed, etc.

I've not used the CLR, but the one thing I noted in Gilad Bracha's recent post on generics ( https://gbracha.blogspot.com/2018/10/reified-generics-search... ) was his claim that the CLR makes implementing and using dynamic languages difficult: > In systems designed to support multiple programming languages, reification brings a different problem. All languages must deal with the complexity of reification; worse they…

Reification seems pretty unrelated, as Wasm doesn't have an equivalent concept.

Re: WebAssembly’s post-MVP future

#112

Post by int_19h »

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…

For the vast majority of code that runs on either desktop or mobile, the latest and greatest hardware features don't matter, and neither do arch-specific optimizations. Startup costs are trivially solved by an OS-level precompilation and caching mechanism. And we already have sandboxes for apps, even on the desktops (both macOS and Windows store apps). Besides, why can't WebAssembly have a different, less limiting sandbox outside of the web?

The real benefit is having a portable bytecode that 1) can accommodate any language out there without constraining their object and memory model, and 2) is guaranteed to be compiled to native code by an optimizing compiler when deployed. Add some basic APIs, and we could have a situation that has heretofore has been enjoyed pretty much only by x86 - the ability to compile code, and run it 30 years later as is.

Re: WebAssembly’s post-MVP future

#113

Post by int_19h »

edflsafoiewq wrote: post #70
marcosdumay wrote: post #34

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 all the better environments are not sufficiently portable.

That said, even then, I'll take Qt over Electron any day of the week.

Re: WebAssembly’s post-MVP future

#114

Post by int_19h »

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…

Between WASM and modern graphics APIs, we might be able to actually kill DOM altogether. Something like this:

http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

Re: WebAssembly’s post-MVP future

#115

Post by bloomer »

dmitrygr wrote: post #106
Game_Ender wrote: post #84

Earlier quoted context omitted.

64 bit addressed cannot come soon enough. In certain domains the entire data set you want to work with is many times the 4GB limit, and JS has no such restriction so it’s a PITA that WASM does.

It is hard to imagine a tool less suited to working with multi-gigabyte data sets than JavaScript.

Yeah I'm really confused why working with 4GB+ datasets in the browser is a current need. Why does everything end up in web browsers these days? Is it only because developers aren't familiar with anything else?

Re: WebAssembly’s post-MVP future

#116

Post by msla »

ConanRus wrote: post #64

This is all right and all, but I have one question: why the hell it needs to be inside of a browser? To do what exactly? I don't care about browsers, I care about applications. I don't want freaking Photoshop in my browser, because I want a browser to die. This should be a part of the OS, not a freaking browser. Give me a built-in runtime with sandboxing, a delivery method, and an AppStore. Give me next generation Ja…

Because it effectively solves the distribution problem in a way which includes non-technical people.

If you think your solution does that, meditate on what "non-technical" means.

Re: WebAssembly’s post-MVP future

#117

Post by zmw »

jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

You can access web APIs and access DOM in wasm today (from your comment you seem to be unware of that?). I just wrote a tiny web app in Rust with wasm-bindgen, and it’s pretty good already. With wasm-bindgen interfacing is pretty manual at the moment — you need to declare the APIs you need in Rust by hand, but an app without dependencies that modify the DOM generates a wasm file that’s only a few KB. My app pulls in quite a few libs and ended up with a ~700KB wasm build — a bit larger than satisfactory, but definitely in the tolerable range.

Re: WebAssembly’s post-MVP future

#119

Post by user111233 »

msla wrote: post #116
ConanRus wrote: post #64

This is all right and all, but I have one question: why the hell it needs to be inside of a browser? To do what exactly? I don't care about browsers, I care about applications. I don't want freaking Photoshop in my browser, because I want a browser to die. This should be a part of the OS, not a freaking browser. Give me a built-in runtime with sandboxing, a delivery method, and an AppStore. Give me next generation Ja…

Because it effectively solves the distribution problem in a way which includes non-technical people. If you think your solution does that, meditate on what "non-technical" means.

Having the URL system also makes them so much better for sharing. Imagine being able to share a link that someone could click and it would open up your shared image inside of photoshop.

Re: WebAssembly’s post-MVP future

#120

Post by fulafel »

marcosdumay wrote: post #32
kodablah wrote: post #25

Earlier quoted context omitted.

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

The difference is being able to serve some WASM script that interacts with your page without having to send and entire glibc equivalent. In practice, that means having an standard library on browsers that you can call in a standard idiom.

Dead code elimination in your compiler should be taking care of this, no?
Post reply on HN