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

61–70 of 207 posts

Re: WebAssembly’s post-MVP future

#61

Post by goatlover »

tachyonbeam wrote: post #35
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…

The biggest weakness of WASM IMO is that it doesn't have its own standard library. It relies on the HTML DOM. This is an awkward, overcomplicated API that tends to differ between browsers, and worst of all, changes all the time. Because of this, WASM will likely remain a second-class citizen in the browser. It will also keep suffering of the problem of code constantly breaking when the DOM changes.

Wasm apps can just target canvas if they don't want to deal with the DOM. That's what they've been doing, since DOM access has been reliant on using JS.

Re: WebAssembly’s post-MVP future

#63

Post by mr_toad »

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…

> Developers need laptops to run their development environment in.

Not strictly true. I spent a bit of time using Cloud 9 and found it to be quite a useable experience. It’s certainly very handy to be able to access a dev environment from web browser wherever you happen to be.

https://aws.amazon.com/cloud9/

Re: WebAssembly’s post-MVP future

#64

Post by ConanRus »

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 Java/Flash. I tired of a browser as an OS replacement. It is not and it shouldn't be.

Re: WebAssembly’s post-MVP future

#65

Post by AndrewDucker »

arduinomancer wrote: post #62

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?

Because they don't know what they're compiling to. The browser could be running in a wide variety of hardware.

Re: WebAssembly’s post-MVP future

#66

Post by AgentME »

username223 wrote: post #31
fabian2k wrote: post #16

Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript? My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.

> Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript? I may be out of date here, but IME neither JavaScript nor WASM is any good for actual "number crunching" (i.e. statistical or scientific code). For that, you want at least a compiler/language that uses the latest SIMD instructions and lets you choose 32- or 64-bit floats. Be…

WASM does let you choose between 32 and 64 bit floats. SIMD and threading are mentioned in the article as things that are being worked on now.

GPU access is about browser APIs rather than being something tied to WASM. We have webgl now and it seems like there's more coming hopefully (https://github.com/gpuweb/gpuweb).

>and above all is simple enough that you can figure out why the compiler isn't performing the optimizations you expect.

Reading WASM seems easier to me than reading real assembly, so double-checking a WASM compiler's output seems much easier than double-checking a native compiler's output. Of course it's on the compilers to support WASM well, but hopefully that simplicity aids them too.

Re: WebAssembly’s post-MVP future

#67

Post by mkl »

roblabla wrote: post #46
sk1pper wrote: post #39

Earlier quoted context omitted.

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…

Accessibility is a big problem.

Re: WebAssembly’s post-MVP future

#69

Post by sp332 »

arduinomancer wrote: post #62

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?

AndrewDucker I think has the main point, but it's also easier trust and sandbox a binary that you've built yourself.

Re: WebAssembly’s post-MVP future

#70

Post by edflsafoiewq »

marcosdumay wrote: post #34
goatlover wrote: post #19

Earlier quoted context omitted.

Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries). Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just yo…

> 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?
Post reply on HN