Earlier quoted context omitted.
And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?
Yes, a million times better.
And this is why we can't have nice things.
Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
171–180 of 212 posts
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#172Relevant: benchmarking WebAssembly using libsodium: https://00f.net/2019/04/09/benchmarking-webassembly-using-li...
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#173Earlier quoted context omitted.
Except you can run wasm on an iPhone. I like Java but it's not like they didn't try Java applets. They really screwed the security model. I guess in that sense what the parent is asking for is actually not nearly as feasible as using the current web security model.
> 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 would hurt wasm, certainly. It was an arbitrary decision but that's the reality of the world we live in.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#174Earlier 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.
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?
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#175Earlier 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.
Swing is only bad for those that never bothered how to use it properly, by reading blogs and books like Filthy Rich Clients.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#176Earlier 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.
Except you can run wasm on an iPhone. I like Java but it's not like they didn't try Java applets. They really screwed the security model. I guess in that sense what the parent is asking for is actually not nearly as feasible as using the current web security model.
You can also run Java on the iPhone.
GluonVM, RoboVM and CodenameOne are three AOT compilers for Java targeting iOS.
Also OpenJDK has reactivated the project to provide an AOT compiler for iOS via SubstractVM.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#177Earlier 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.
IntelliJ? But I agree: HTML/CSS/JS is far easier (eg: threading) and generally results in a more polished experience.
IntelliJ: It's not horrible, but it isn't really good/pretty either.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#178Earlier 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?
If Apple decided they didn't want to support web assembly tomorrow, do you think that would kill the iPhone or WASM? That's a good question, and it's certainly not one I'd want to bet on as Apple. When they managed to kill off Flash and Java applets, they were getting rid of the two awkward technologies that almost everyone in web development disliked. There were useful replacements coming down the line with HTML5, E…
This is the question of the day wrt WebAssembly: Will Apple continue to support wasm in Safari?
Does wasm strategically impact the dominance of the App Store?
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#179Earlier quoted context omitted.
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.
Flash was also the single largest exploit hole and cause of system crashing bugs at the time.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#180Earlier 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?
If Apple decided they didn't want to support web assembly tomorrow, do you think that would kill the iPhone or WASM? That's a good question, and it's certainly not one I'd want to bet on as Apple. When they managed to kill off Flash and Java applets, they were getting rid of the two awkward technologies that almost everyone in web development disliked. There were useful replacements coming down the line with HTML5, E…
At the time, Java and Flash were the main points of security exploits in practice, and flash was the single biggest cause of system crashes on Mac.