Hacker News Reader

Comment by microtonal | Hacker News Reader

Slower at an average of 50% looks acceptable to me for many applications.

However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction.

Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary builds). So, this seems to be interesting to (primarily) web applications. However, I try to avoid web apps, because they are typically proprietary, a moving target, the owner can randomly decide to charge me for things, or (ab)use my data, and they feel non-native.

(I do see the benefit for people who use web apps, since WebAssembly is typically faster than Javascript and opens up web app programming to more languages.)

View on HN

People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.

I don't know you are being downvoted. There are already instructions in ARM chips to help with JS floating-point conversion [1]. Yes, while the "Java chips" never got into the mass market[2], JS and it's ecosystem is eatting the world in a way Java never did and the trajectory is only increaing.

P.S. I know WASM isn't JS, but I'd still consider it in the JS ecosystem.

[1]: https://stackoverflow.com/questions/50966676/why-do-arm-chip...

[2]: I did hear about some "Java Chips" for garbage collection back in the day.

Lol. Well, I mean nothing is outside of the realm of possibility, but remember those native Java chips! Some thought those were going to be a big win. And then you had companies like Transmeta trying to do the exact opposite - interpretively optimize all the things....or something like that.

Transmeta JIT'd x86 into VLIW.

That was right before the Power Wall became an obstacle and CPUs were already burning up. Transmeta in a sense invented low power computing but then Intel said thank you very much; we'll take it from here. It wasn't that they didn't deliver. It's just that they were competing against Intel in the x86 space. A lot of the Transmeta team moved to nVidia and work on Denver but that's different and they got an architecture license from ARM to do that.

Ultimately the features involved in optimizing WebAssembly are even more variable than they are for Java, so a Jazelle approach is probably even less useful.

The web assembly application could also be compiled to a native binary, right? (something like an AOT compiled electron app)

A long time ago they were talking about Java chips. That didn’t materialize and as far as I know there are no chips that run JavaScript natively so I wouldn’t hold my breath for WebAssembly chips.

The Java chips were for, well, they were for Java. If ARM had designed Jazelle to be more general, it would have been useful for Javascript and Python and .... But they designed it for Java bytecode. The licensing was too expensive and so it didn't catch on and Jazelle got dropped from ARMv8.

> Slower at an average of 50% looks acceptable to me for many applications.

Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..

Native device platforms could do a system optimized AOT compile of WASM to Native as part of install. The distribution can be the same per platform, that doesn't stop a given platform from further optimization.

Also, the single biggest battery use for most people is the screen, the CPU time is minimal by comparison and that 50% is only for the narrow CPU time the app isn't just waiting for input, and for many apps, that's most of the time (idle).

sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows)

and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative.

in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that.

several apps run only on windows. some on mac and windows, some others on mac and linux. occasionally there is a mac or linux only application. and once in a while an application binary is available on all three.

this is not even an issue of portability. even if the application is easily portable, i still depend on the developers choice of which OS they support. and i can't blame them. unless i am going to make money off the application i am not going to bother with supporting windows or macos. and most others will continue to ignore linux because the smaller market is still not always worth the effort.

with webassembly we finally get a unified binary architecture.

if an application run on webassembly, then the OS no longer matters. as someone that prefers to use linux. webassembly is like the holy grail. because if it manages to take hold, then hopefully the days of needing windows or a mac will be gone.

that's the point.

Exactly this... I use all three as well, and tend to favor apps that run everywhere. Even if that means browser/electron apps. It's just less hassle for me. My single biggest issue is windows-isms for bash on windows.

In the end, as long as it works, I'm very happy. Also, it doesn't preclude a given platform from AOT optimization/compile for WASM code to platform native code. I think getting common runtime interfaces is currently the paramount point... being able to use sqlite, and SDL/OpenGL adapters to canvas or webgl are also big. Not to mention audio, and various input devices (gamepads etc).

There is a lot of existing code that could be readily ported/shimmed out if we can get some common interfaces working.

> sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows)

Is that really a big deal, though? From what I understand (and I could be wrong, so correct me if I am), most of the headaches involved in multi-platform development is the OS specific UI. Video games, for example, don't find porting to multiple architectures all that challenging because 1) they design for it and 2) they're not expected to adhere to OS UI guidelines.

Games are also expected to be battery pigs, so doing 60+ FPS GPU rendering instead of however native UIs are rendered helps. Everyone certainly COULD just write their apps as 2d OpenGL but laptop battery life would suffer for it.

It really depends on how complex your code is and what you're targeting. For example, the V8 JavaScript engine has a ton of ifdefs depending on OS (Windows, Mac, Linux, Fushia), bitness (32 or 64), chipset (ARM, ARM64, PPC, x64, etc.) and combinations thereof. For example, see some of the defines in https://github.com/v8/v8/blob/master/src/common/globals.h#L1... and their uses throughout the codebase.

EDIT: I forgot Android, and all the compiler specific flags. (https://github.com/v8/v8/blob/master/include/v8config.h is probably a better reference).

at this point it is mostly a problem of perception, and apparent complexity.

portability is not the problem, but you still need to learn how to package for each different system, you have to maintain at least 3 sets of build-to-package instructions and understand each ecosystem.

for example, i only develop on linux. yet, packaging for all linux distributions is still a hurdle. why can't i just compile and upload to my website?

i have never packaged for windows or mac, and the thought having to learn those alone makes me turn away in disgust. i am probably wrong, and packaging for both is way easier than i think. but that's exactly the point of the problem being based on perception and apparent complexity.

in order to package for all three systems, i need to first of all want to do that. and i find that i don't care enough to want it.

The point is obviously that web apps can be directly competitive with binaries, sans the same level of security, given they operate a lite version of the application. This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.

This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.

Yes. But my question is why would I want this? I won't own the software anymore. The web has shown over and over again to have far less privacy. The vendor could disappear, change their terms, change their fees any time. As a customer/user you become basically powerless.

And for non-cloud applications: what's the point. My distribution already compiles and provides most of the software that I need and my machine doesn't need to waste time/energy on JITing.

> The web has shown over and over again to have far less privacy

This may be inherent to the web but a native app would (given the current level of sandboxing) have more freedom to make http requests than a webapp. So there would be no win in forcing the bad actors to make native apps.

The argument about owning the software is a valid one, and I for one am not terribly excited about the continuous updates to everything which sometimes changes the UI of a tool that I use and know and cost me time out of the blue. However, I am using wallabyjs, a "native" app (plugin to vscode) and it updates itself practically every other day. I think that reality is hitting all kinds of software anyway.

As I understand it, WASM binaries have a well defined interface and can easily be sandboxed.

Perhaps there would then be a way to just download WASM binaries from the web and run them locally, with your own sandbox restrictions imposed on them.

I think the ability to sandbox these applications (even if they're not delivered over the web) might actually be the more valuable aspect of WASM.

Reply on news.ycombinator.com