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

191–200 of 212 posts

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

#191

Post by ScottFree »

tracker1 wrote: post #186
ScottFree wrote: post #72

Earlier quoted context omitted.

Companies are running webapps on embedded devices now, but I don't buy the ease of hiring excuse. Web devs demand higher salaries than embedded developers and they have more leverage in terms of where they can work (ie: they're flaky as pie crust). Embedded developers are also more likely to pass the hazing ritual known as the programming interview. Where's the upside to hiring web developers in that context?

I think it's a mixed bag... a lot of developers think they know JavaScript or understand web applications. I've found that about 90% are not very good with it in practice. Often with job titles as Mid or Sr developers. Actually understanding more about JS and the browser, and actual application development, and how it fits are good places to start. I find that the browser model actually fits a redux-like master state…

Did you mean to respond to my comment? I don't see the connection between your comment and the comment you responded to.

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

#192

Post by ScottFree »

pjmlp wrote: post #175
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.

Swing is only bad for those that never bothered how to use it properly, by reading blogs and books like Filthy Rich Clients.

You're biting hard on the 'true scotsman' fallacy. Ask the linux developers where that gets them. Is it the year of the linux desktop yet?

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

#193

Post by ScottFree »

jerp wrote: post #170

Coming form a win32 desktop background, how would I do a UI in web assembly?

Have you seen Blazor?

https://dotnet.microsoft.com/apps/aspnet/web-apps/client

https://www.youtube.com/watch?v=uW-Kk7Qpv5U

It packages the entire .NET framework into a single wasm app, so it's a little bloated, but it works.

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

#194

Post by tracker1 »

ScottFree wrote: post #191
tracker1 wrote: post #186

Earlier quoted context omitted.

I think it's a mixed bag... a lot of developers think they know JavaScript or understand web applications. I've found that about 90% are not very good with it in practice. Often with job titles as Mid or Sr developers. Actually understanding more about JS and the browser, and actual application development, and how it fits are good places to start. I find that the browser model actually fits a redux-like master state…

Did you mean to respond to my comment? I don't see the connection between your comment and the comment you responded to.

I may have hit reply in the wrong one, apologies.

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

#195

Post by ScottFree »

tracker1 wrote: post #194
ScottFree wrote: post #191

Earlier quoted context omitted.

Did you mean to respond to my comment? I don't see the connection between your comment and the comment you responded to.

I may have hit reply in the wrong one, apologies.

No worries! I was more confused than anything. :)

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

#196

Post by megous »

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…

In practice, installation in web browser would use a service worker and some hand written caching logic. Neither is declarative. In fact, declarative (https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5) variant of this functionality was deprecated because devs wanted more programatic way to "install" offline web apps.

It's still sandboxed, and limited, so what's cached this way is perhaps easy to totally remove by the browser. But that's not because of the declarativeness, but because of sandboxing.

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

#197

Post by inlined »

megous wrote: post #196
inlined wrote: post #102

Earlier quoted context omitted.

[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…

In practice, installation in web browser would use a service worker and some hand written caching logic. Neither is declarative. In fact, declarative ( https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5 ) variant of this functionality was deprecated because devs wanted more programatic way to "install" offline web apps. It's still sandboxed, and limited, so what's cached this way is perhaps easy to totally remove…

Makes sense, but if there’s any OS integration (e.g. file type registration, desktop links, etc) then the app isn’t truly sandboxed by these means alone.

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

#198

Post by tatersolid »

pjmlp wrote: post #174
oaiey wrote: post #123

Earlier quoted context omitted.

Java... Are you kidding. The UI stack and distribution model is horrible compared to WebAssembly. The resources available for HTML/CSS cannot be compared with JavaFX, Swing or whatever the other original stack was. And the Applets sandboxing was obviously so horrible everyone killed it. WA is amazing here copying the existing and already hardened JavaScript model.

What a joke, where are the visual designers for HTML/CSS, with automatic binding generation for database backends? Layout engines with customization capabilities? Where is the hardware accelerated drawings that I can be fully sure it is hardware accelerated without doing tricks with z index and hoping for the best regarding mapping css drawings into textures?

> What a joke, where are the visual designers for HTML/CSS, with automatic binding generation for database backends?

Did you ever actually use a PowerBuilder (or similar RAD tool) application? The experience was horrible, slow, and basically a waste of titanic amounts of money.

I once saw half an accounting department quit after a switch to a RAD financials package.

There’s a reason all those 1990-2005 era vertical-market app companies got bought by PE firms and are just basically dead except for milking maintenance revenue. Building “data-model centric” apps with RAD tools optimizes for ease of the developer instead of the end user. Which is exactly backwards.

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

#199

Post by woah »

Merad wrote: post #147
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.

No, you might be thinking about something like Electron. There are WASM VM’s for many platforms and they are very simple and do not involve a web browser. Whether they have a good common ui library is of course a different question, but one that will be resolved in due course.

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

#200

Post by hnick »

Merad wrote: post #147
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.

It's abstractions all the way down!
Post reply on HN