31–40 of 212 posts
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?
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.)
Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…
But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box. Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-t…
Earlier quoted context omitted.
Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.
We already had "instant (no install) apps that are inherently sandboxed": Java and its net-top boxes. Why didn't it work?
I was involved with Java applets when Java was in beta and one of the most annoying things was that JDK 1.0 did not come with serialization.
I would build applets that displayed content generated on the server and serialization-deserialization code could be 2/3 of the program. Most people had a slow net back then, so the download performance was a big deal.
JDK 1.1 put serialization in right away, but Netscape had already introduced it's own incompatible serializer, and there were delays in getting JDK 1.1, plus people didn't like Java serialization -- practically there was a year or two where you couldn't use it.
Applets had enough teething pains that people quickly came to the conclusion that they weren't worth the trouble, then Flash came along which came closer to what people wanted at the time.
Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…
But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box. Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-t…
I've been running the Catalina betas, and running non-notarized apps only requires right clicking instead of double clicking. If that's too much of an obstacle for you, you probably shouldn't run the app.
Gatekeeper on macOS is a technology designed to protect careless users. It makes it slightly harder to shoot yourself in the foot. It doesn't prevent you from doing it, though.
Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…
It's businesses that demand web applications, because native deployment (in-house or for customers) is a tougher sell. A lot of it has to do with the bad security model of desktop operating systems combined with the overhead of administration.
Last but not least, web developers are the biggest pool to hire from. It all adds up to where the benefits outweigh the (significant!) drawbacks.
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?
Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…
But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box. Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-t…
Thing is, "safe" OS-sandboxes are not safe; "local" privilege escalation vulnerabilities are still pervasive. Until OS's are safe enough that I can run `sudo -u nobody untrusted_binary` and not even think about the possibility of it taking over my system, something like the WASM sandbox (perhaps extended with WASI and other optional mechanisms) will always be needed.
> an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online > [security] checks are necessary for WebAssembly’s safety > current JavaScript implementations reserve a few registers for their own use, which increases register pressure on WebAssembly
This echoes the arguments for / against java. The compiler in this context mustn’t be “fast enough to be online” - it must be fast enough to keep up and able to smart enough to know what’s important. It also benefits from watching the actual program execution. Presuming you can “warm up” the application, it might just do fine.
I vaguely think that a lot of people are considering the compilation as a one time deal. It could be a phased thing. Java’s a great example of that.
Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…
Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.