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

Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

usenix.org

Post reply on HN
Print view View original

141–150 of 212 posts

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#141

Post by bastawhiz »

AnIdiotOnTheNet wrote: post #109
bastawhiz wrote: post #83

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installa…

Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again.

The difference is that the runtime lives in the browser, based on an open standard. Operating systems come with browsers. The success of WASM is that my mom doesn't need to know how to install Java (and maybe accidentally a Yahoo toolbar) to run an app to look at her DICOM images.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#142

Post by AnIdiotOnTheNet »

ScottFree wrote: post #137
AnIdiotOnTheNet wrote: post #132

Earlier quoted context omitted.

You're going to have a hard time convincing me that the browser as a runtime is a better solution than a runtime actually designed for running applications.

The problem lays in the UI. Most of what a modern application does is provide a decent UI to interact with data on a remote server. Swing was a terrible UI library. I never saw a java applet that wasn't ugly and clunky.

And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#143

Post by AnIdiotOnTheNet »

HALtheWise wrote: post #135
AnIdiotOnTheNet wrote: post #131

Earlier quoted context omitted.

> Except you can run wasm on an iPhone. An arbitrary decision made by the manufacturer. If Apple decided they didn't want to support web assembly tomorrow, do you think that would kill the iPhone or WASM?

It depends on when, and how much adoption it has. If the iPhone stopped supporting HTML, it would kill the iPhone, and your guess is as good as mine about how wide of adoption wasm needs before it hits that threshold.

I'm not so sure. Flash was ubiquitous until the iPhone decided not to support it.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#144

Post by DonHopkins »

josalhor wrote: post #53
jakobegger wrote: post #25

Can someone explain a concrete use case for web assembly? Are there projects out there using web assembly in production? What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?

Unity 3D targets Web Assembly now for the web, which makes much more sense than JavaScript, even if asm

Yes, Unity3D's WebAssembly back end is a very widely used, non-trivial, practical, and successful example.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#145

Post by ScottFree »

AnIdiotOnTheNet wrote: post #142
ScottFree wrote: post #137

Earlier quoted context omitted.

The problem lays in the UI. Most of what a modern application does is provide a decent UI to interact with data on a remote server. Swing was a terrible UI library. I never saw a java applet that wasn't ugly and clunky.

And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?

Yes. Presentation matters.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#146

Post by FpUser »

bigato wrote: post #117
FpUser wrote: post #94

Earlier quoted context omitted.

"yes, this is way forward." - I don't think so

Well the alternative is exchanging data, not code. Actually this was the initial idea on the web, hyperlinked data. Look where that brought us. Maybe we could devise a better model with a client (code) that is simple enough and universal enough, and the server providing/receiving only data and not code? That is, instead of me running the publisher's code on my terminal, i run my code on the publisher's data, exchangi…

I think the way forward is to stop worry too much. Like you really gonna be worrying running "flight simulator". I think it is a FUD designed mostly to support big and cloudy providers. Those are the real entities one should worry about. They spy 24x7 .

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#147

Post by Merad »

bastawhiz wrote: post #83

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installa…

> So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS.

But we've accomplished that by effectively turning web browsers into VM's that have a complexity on par with a full operating system. I have a sneaking suspicion that we're going to end up deciding that was a huge mistake.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#148

Post by FpUser »

inlined wrote: post #102
megous wrote: post #27

Earlier quoted context omitted.

Webassembly is not magic. You still have to download and possibly cache code and assests. Call it install or not. I think win is having free software or at least opensource apps that are trusted by distributors and easy to analyze/modify, and actually own (meaning have on your harddrive and fully control). And we already have that win.

[Former developer on the Windows Component and Applications team, renamed Developer Experience team] There's a big difference between an imperative (e.g. arbitrary code) and declarative installation process. Imperative installation is most common on Windows due to the initial decisions made by the registry designers + the Windows Installer originating from Office and starting with imperative. Declarative installs are…

Why? I've had that clean painless install on Windows like forever. My installs are always a single executable that copies itself to a proper place, gets any data if needed from company website and when uninstalled leaves no trace on a system. Never touched registry. There is nothing here that calls for "starting from scratch"

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#149

Post by AnIdiotOnTheNet »

bastawhiz wrote: post #141
AnIdiotOnTheNet wrote: post #109

Earlier quoted context omitted.

Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again.

The difference is that the runtime lives in the browser, based on an open standard. Operating systems come with browsers. The success of WASM is that my mom doesn't need to know how to install Java (and maybe accidentally a Yahoo toolbar) to run an app to look at her DICOM images.

> The difference is that the runtime lives in the browser, based on an open standard.

Java is an open standard (I think, I didn't fact check this thuroughly) OpenJDK is the reference implementation of that standard. You can try to claim that in reality Oracle has a lot of control, but I'd come right back and say that Google basically controls the browser.

> The success of WASM is that my mom doesn't need to know how to install Java

If OSs had bundled a Java runtime she wouldn't need to install Java either.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#150

Post by FpUser »

kowdermeister wrote: post #59
FpUser wrote: post #45

Earlier quoted context omitted.

Yeah, right. Compilers do not deal with the difference in presence / absence and different implementations of various features on different platforms, be it native OS or Browser OS.

Is that so? Worst case I can imagine is to have the same compiler emit app-firefox.wasm and app-chrome.wasm binaries from the same codebase, but I think this is highly unlikely. But there probably always will be a safe flag that generates everywhere running binaries.

And by then you will have discovered that your software can not do this and that after being relegated to a lowest common denominator state.
Post reply on HN