Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wasmer 1.0

medium.com

Post reply on HN
Print view View original

11–20 of 168 posts

Re: Wasmer 1.0

#11

Post by amelius »

hctaw wrote: post #7
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…

You've just described the hardest parts of a web browser, while ignoring the necessity of a JIT compiler for your bytecode. To give proof by counterexample, the "simple wrapper" is a graphics stack like GTK alongside the POSIX APIs. It turns out this is insufficient for application development. Some things you're missing are text layout and accessibility. Neither are small or simple. The browser is the new OS and the…

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.

Re: Wasmer 1.0

#12

Post by nynx »

amelius wrote: post #11
hctaw wrote: post #7

Earlier quoted context omitted.

You've just described the hardest parts of a web browser, while ignoring the necessity of a JIT compiler for your bytecode. To give proof by counterexample, the "simple wrapper" is a graphics stack like GTK alongside the POSIX APIs. It turns out this is insufficient for application development. Some things you're missing are text layout and accessibility. Neither are small or simple. The browser is the new OS and the…

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.

While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. Perhaps that's not a bad thing.

Speaking of moving complexity into sandboxed code, browsers could potentially run js engines inside the wasm vm, reducing a lot of complexity there.

Re: Wasmer 1.0

#13

Post by anderspitman »

danShumway wrote: post #9
anderspitman wrote: post #4

Earlier quoted context omitted.

There are reasons each of those failed that have little to do with the core concept. And to be honest, I think Flash was killed before there was a suitable replacement to fill the gap. It took more than 10 years since it "died" to actually get rid of it, because HTML5 isn't actually up to the task. I think the fact that it survived so long proves there's a use for these types of runtimes.

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.

Re: Wasmer 1.0

#14

Post by reader_mode »

nynx wrote: post #12
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.

While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. Perhaps that's not a bad thing. Speaking of moving complexity into sandboxed code, browsers could potentially run js engines inside the wasm vm, reducing a lot of complexity there.

>While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel.

You can compile existing GUI libraries you just need to port the rendering backend and input.

Flutter, Qt, GTK, etc.

Re: Wasmer 1.0

#15

Post by brundolf »

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 be a flawed solution, but it's what we have, and it works, and I wouldn't hold my breath for a greenfield alternative supplanting it any time soon.

Re: Wasmer 1.0

#16

Post by hctaw »

amelius wrote: post #11
hctaw wrote: post #7

Earlier quoted context omitted.

You've just described the hardest parts of a web browser, while ignoring the necessity of a JIT compiler for your bytecode. To give proof by counterexample, the "simple wrapper" is a graphics stack like GTK alongside the POSIX APIs. It turns out this is insufficient for application development. Some things you're missing are text layout and accessibility. Neither are small or simple. The browser is the new OS and the…

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 what Microsoft recommends today, since no developer is going to use it and that rec will change tomorrow.

While technically, complexity is not necessary, pragmatically the sandbox offers next to nothing for users or developers without OS vendors enforcing its usage, or the sandbox being so compelling a target for developers they accept the limitations of the sandbox - which is why the only platforms with robust sandboxes are mobile and the browser.

Re: Wasmer 1.0

#17

Post by josephg »

amelius wrote: post #11
hctaw wrote: post #7

Earlier quoted context omitted.

You've just described the hardest parts of a web browser, while ignoring the necessity of a JIT compiler for your bytecode. To give proof by counterexample, the "simple wrapper" is a graphics stack like GTK alongside the POSIX APIs. It turns out this is insufficient for application development. Some things you're missing are text layout and accessibility. Neither are small or simple. The browser is the new OS and the…

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.

Text rendering and accessibility APIs both need to access the host OS’s APIs to work correctly. (Text rendering is subtly different on macos and windows, and app rendering behaviour should follow the platform.)

I think we can expose standardised APIs to applications for this stuff, but the API will probably need on the order of hundreds of methods.

Re: Wasmer 1.0

#18

Post by josephg »

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…

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.

Re: Wasmer 1.0

#19

Post by devwastaken »

eitland wrote: post #10
nynx wrote: post #5

Earlier quoted context omitted.

A significant point of wasm is runtime-independence. If a runtime implements the right apis, any wasm module that uses them should be able to run (performance aside).

Don't underestimate programmers and especially web developer when it comes to making software dependent on IE or Chrome just because they can't be bothered to do any QA ;-) Full disclosure: I am a developer, and I use and always used Firefox, for both pragmatic and ideological reasons.

Chrome impliments the necessary features for wasm and webgl. Here's a test: checkaux.github.io

Mobile firefox lacks simd, i haven't been able to get its shared memory to work on a local or deployed environment because of bugs in what it thinks is a 'secure context'

Desktop and mobile Firefox does not support OffscreenCanvas without turning on flags. It's been years since this was meant to be made. Therefore you cannot use seperate threads to render to webgl without using less performant workarounds.

Lack of proper threading means bad page performance.

There's lots more dumb bugs and features firefox said it would support and simply never did. Understand there's real reasons as to why chrome is the preferred. it works and it actually puts in the necessary features.

Post reply on HN