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

Analyzing the Performance of WebAssembly vs. Native Code

arxiv.org

Post reply on HN
Print view View original

21–30 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#21

Post by fooker »

onion2k wrote: post #19
jacobolus wrote: post #16

Earlier quoted context omitted.

Web apps are inherently mediocre on every platform. There’s enough advantage from being accessible via URL, usable on any device, live updating, etc. to compensate that for many uses. But using web apps daily for any serious work is a huge loss in resource use, usability, polish, ... The one that makes me saddest though is that web apps seem to be getting worse over time. For example most of Google’s suite of web app…

The problem of mediocre apps is not what they're written in. Millions of people happily use apps built on web technologies every day without even realising. Similarly, millions of people use badly made native apps and hate every second. The tech is not the problem.

The tech is part of the problem.

Sure, you can get to the same result eventually. But the tools to do so are better and more intuitive for making Android or iOS apps.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#22

Post by pjmlp »

est31 wrote: post #10
yodon wrote: post #5

Earlier quoted context omitted.

> if you care about WebAssembly performance, use Firefox Unless you have customers or want them, because Firefox's market share is generally too small to base your entire business around.

In the old days there were websites using flash or silverlight and they had a screen "in order to use this you must use flash" and for some reason, people did download and install flash so that they could watch the cat videos or whatever.

The big difference is that without them they would see a broken square, with Chrome or Safari they would still see it, just a bit slower.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#23

Post by wlesieutre »

fooker wrote: post #21
onion2k wrote: post #19

Earlier quoted context omitted.

The problem of mediocre apps is not what they're written in. Millions of people happily use apps built on web technologies every day without even realising. Similarly, millions of people use badly made native apps and hate every second. The tech is not the problem.

The tech is part of the problem. Sure, you can get to the same result eventually. But the tools to do so are better and more intuitive for making Android or iOS apps.

I’ve dabbled with iOS development and Xcode doesn’t seem that braggable as a tool.

Of course the modern Javascript web stack isn’t pretty either, so I guess what I’m saying is everything sucks a bit.

I’ve seen nice results and crappy results regardless of what particular stack it’s made in. IMO the biggest difference shows up in integration with the rest of the system. If you want to hook into the Files app or Siri Shortcuts, native apps certainly have a leg up.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#24

Post by derefr »

untog wrote: post #14
forrestthewoods wrote: post #9

Earlier quoted context omitted.

> can't even show a add to home screen native banner. That sounds like a feature.

Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.

Why not just build a web app that works as a regular (mobile) web app, but has additional features when launched in the context of a PhoneGap-style app-store app? Then have the web version offer to install the "native-ish" version. That's progressive enhancement, no?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#25

Post by derefr »

jacobolus wrote: post #15
quangio wrote: post #12

The benchmark seems to use only browsers' built in VMs to run WebAssembly (more like the the efficiency of different VM JIT compilers compared to native). How about running them in standalone webassembly VM like WAVM (it does more aggressive optimization, use LLVM for JIT), Asmble (running in JVM), or Wasmer (use Cranelift like Firefox does, maybe a little bit faster than Firefox) (I just skimmed the paper, sorry if…

Speed when running in the browser is probably the main practical concern for most folks using wasm....

Some projects are looking forward to using WASM as a general replacement for their current Turing-complete query language engine (e.g. Javascript in CouchDB, Lua in Redis, etc.) WAVM is probably what such systems would embed.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#26

Post by onion2k »

fooker wrote: post #21
onion2k wrote: post #19

Earlier quoted context omitted.

The problem of mediocre apps is not what they're written in. Millions of people happily use apps built on web technologies every day without even realising. Similarly, millions of people use badly made native apps and hate every second. The tech is not the problem.

The tech is part of the problem. Sure, you can get to the same result eventually. But the tools to do so are better and more intuitive for making Android or iOS apps.

That depends. I agree that the tooling around hybrid apps is pretty bad (debugging React Native layout issues is painful), but the tooling around web apps is really good these days, and that carries over to PWAs (and Electron, Ionic, etc) to a large extent. Chrome's perf flame chart is ace, and if you use VS Code you can get decent IDE debugging going. It's fragile and it takes effort to start but it's waaaay better than it was 5 years ago.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#27

Post by shrimpx »

pier25 wrote: post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

Honest question: does webassembly do anything about speeding up the Dom API? For example low-latency text input is non-existent in any browser engine today (short of rendering text using webgl). Does wasm do anything about this?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#29

Post by s_y_n_t_a_x »

shrimpx wrote: post #27
pier25 wrote: post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

Honest question: does webassembly do anything about speeding up the Dom API? For example low-latency text input is non-existent in any browser engine today (short of rendering text using webgl). Does wasm do anything about this?

Currently there's no way to interact with the Dom API from WASM directly, you have to interop with JS functions, so if anything, it's slower than JavaScript due to the interop bottleneck.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#30

Post by endless1234 »

crabl wrote: post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

Apart from stuff that competes with their app store, like web push, of course
Post reply on HN