Wasmer 1.0 • Hacker News Board

Re: Wasmer 1.0

#21

Post by Ajedi32 » Tue, Jan 05, 2021, 9:38 PM UTC

skybrian wrote: post #8

apitman wrote: post #2

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) fo…

It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does. But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete…

Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg.

For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential management, etc; the list goes on.

That isn't to say there couldn't some day be a simpler alternative to the web offering similar features; but it has some pretty stiff competition. The only thing that even comes close today are modern operating systems like iOS and Android; and none of those are open standards like the web is.

Re: Wasmer 1.0

#22

Post by anderspitman » Tue, Jan 05, 2021, 9:55 PM UTC

hctaw wrote: post #16

amelius wrote: post #11

Earlier quoted context omitted.

All the things you mention could be available as a shared library, to be run inside the sandbox along with the application. Let's keep the sandbox as simple as possible. We can build complexity inside it, and not make complexity part of it. This makes security guarantees much simpler.

The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know…

IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications, and force developers into locked-in practices.

Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground service, which requires Java/Kotlin. There's no /etc/resolv.conf for DNS resolution, so you have to use custom servers or use the Android NDK compiler (which can be a huge pain). Plus they lock down the filesystem more each year. Android 10/11 are a complete mess on this front. Fortunately they've rolled back some of the more draconian changes, but only because of developer outcry. The fact that they even wanted to do some of the things in the first place is sad.

I'm not saying this is an easy problem to solve, but it's obvious that the big boys have only made a token (if that) effort to build a good, open way of doing it.

Re: Wasmer 1.0

#23

Post by amelius » Tue, Jan 05, 2021, 9:57 PM UTC

hctaw wrote: post #16

amelius wrote: post #11

Earlier quoted context omitted.

All the things you mention could be available as a shared library, to be run inside the sandbox along with the application. Let's keep the sandbox as simple as possible. We can build complexity inside it, and not make complexity part of it. This makes security guarantees much simpler.

The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know…

People (developers) want a target (sandbox) that is as "open" as their browser. This means that by definition the slightest presence of business-motives would ruin the entire idea (your example of Ubuntu's snap and Apple's iOS and Google's Android).

Re: Wasmer 1.0

#24

Post by anderspitman » Tue, Jan 05, 2021, 9:58 PM UTC

Ajedi32 wrote: post #21

skybrian wrote: post #8

Earlier quoted context omitted.

It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does. But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete…

Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg. For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential…

Most of the things you listed apply to web documents more than web apps. I'm an advocate for separating the two. The UX for browsers is great for what they were designed to do. Running apps is not it.

Re: Wasmer 1.0

#25

Post by danShumway » Tue, Jan 05, 2021, 10:00 PM UTC

anderspitman wrote: post #13

danShumway wrote: post #9

Earlier quoted context omitted.

I've commented before on this subject, but Flash didn't survive because it took HTML5 10 years fill in the gap. Flash survived because: A) enterprises don't upgrade or move away from technologies period (we still support IE11 and old Windows Server deployments at my current company). B) Flash the authoring tool never got replaced. It's not about whether or not HTML5 is up to the task of being a Flash-equivalent runti…

Yes, my point would more accurately be made by replacing "HTML5" with "HTML5 platform/ecosystem". Your point about Wasm not automatically guaranteeing this is important. But it would be much easier to build such a tool for a simple greenfield runtime than for a modern browser.

I have reasonably high hopes for WASM as a runtime, so I'm trying to thread a line between agreeing with you and disagreeing with you.

I do think that compiling C code to WASM is easier than compiling C code to Javascript, and I do think that WASM is going to open some doors to sandboxed native applications that the web just can't handle.

But at the same time, even forgetting about the cross-platform part, I have not seen an application framework for any platform -- even closed-down, highly consistent platforms like game consoles -- that offers the same feature-set as Flash.

So WASM may make this easier, but we have platforms already today that are extremely easy to target. If you're targeting PS4/XBox, you know exactly what drivers, software, and graphics stacks are going to be installed. And a Flash replacement doesn't exist for any of those devices. So I urge some caution about assuming that the tools you want are going to be quickly built for WASM.

In some ways, this is exactly the mistake that HTML5 advocates made with Flash. They assumed that all they needed to do was have APIs, and Adobe would do something to save Flash. But Adobe never really seemed to care. They had some half-hearted efforts to target devices like Android, but the Air runtime was never really good at that, and it didn't take over as a cross-platform desktop target the same way that modern Electron has. It seems intuitively obvious that if a cross-platform runtime existed that everyone loved, somebody would make a good graphics stack for it that was easy to use and that didn't require programming, but I'm not 100% certain that's actually true.

Re: Wasmer 1.0

#26

Post by anderspitman » Tue, Jan 05, 2021, 10:02 PM UTC

brundolf wrote: post #15

apitman wrote: post #2

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) fo…

As others are pointing out here: the cross-platform value-add of browser based apps is the GUI layer, not the code runtime. We've had the JVM for decades, and it even has a GUI layer, it's just a much less powerful GUI layer than today's web. People have been trying to create a simple, native, platform-agnostic GUI layer for as long as GUIs have existed. Nothing but the web has ever come close to succeeding. It may b…

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).

Re: Wasmer 1.0

#27

Post by anderspitman » Tue, Jan 05, 2021, 10:03 PM UTC

josephg wrote: post #18

brundolf wrote: post #15

Earlier quoted context omitted.

As others are pointing out here: the cross-platform value-add of browser based apps is the GUI layer, not the code runtime. We've had the JVM for decades, and it even has a GUI layer, it's just a much less powerful GUI layer than today's web. People have been trying to create a simple, native, platform-agnostic GUI layer for as long as GUIs have existed. Nothing but the web has ever come close to succeeding. It may b…

The other big thing the web provides a standard way to do distribution. Unlike JVM apps, I don’t need to install Gmail to use it on my computer.

The web is a great way to distribute native programs. Click a URL to download, then run.

Re: Wasmer 1.0

#28

Post by rapidlua » Tue, Jan 05, 2021, 10:04 PM UTC

The article doesn't mention the number/class of CPUs in the system used for the benchmark. It claims that 'Singlepass' compilation of clang.wasm took 2s and 'Cranelift' took 9s.

Running the same benchmark myself in Linux on a 4CPU VirtualBox on a MacBook Pro, I see 11s and 42s respectively. For reference , V8/Node.js compiles the same file in 27s.

Compiled files were 339 MiB (Singlepass), 640 MiB (Cranelift) and 90 MiB (V8/Node.js).

Clang.wasm itself is 45 MiB.

Re: Wasmer 1.0

#29

Post by Ajedi32 » Tue, Jan 05, 2021, 10:04 PM UTC

anderspitman wrote: post #24

Ajedi32 wrote: post #21

Earlier quoted context omitted.

Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg. For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential…

Most of the things you listed apply to web documents more than web apps. I'm an advocate for separating the two. The UX for browsers is great for what they were designed to do. Running apps is not it.

They apply to both documents _and_ web apps, and the behavior is standard across both. When I hit "Back" or Ctrl+F in a web-based chat application the result is the same as when I do those actions while browsing a news article, and that's a good thing.

Re: Wasmer 1.0

#30

Post by anderspitman » Tue, Jan 05, 2021, 10:14 PM UTC

Ajedi32 wrote: post #29

anderspitman wrote: post #24

Earlier quoted context omitted.

Most of the things you listed apply to web documents more than web apps. I'm an advocate for separating the two. The UX for browsers is great for what they were designed to do. Running apps is not it.

They apply to both documents _and_ web apps, and the behavior is standard across both. When I hit "Back" or Ctrl+F in a web-based chat application the result is the same as when I do those actions while browsing a news article, and that's a good thing.

Huh? When you click the back button in your chat app, if it happens to do something intuitive it's because that behavior was hand-coded by a JS developer using the history API.

And good luck even getting to back button from your news site through all the ads, lazy-load images causing reflow, and auto-play videos that wouldn't be possible in a nicely designed minimal document viewer.

It might be harder for news site operators to fill their sites with junk if they had to explain to their users why it needs to run in an app browser with 20 privileges rather than in their default document browser.