Wasmer 1.0
medium.com
Wasmer 1.0
1–10 of 168 posts
Re: Wasmer 1.0
#2Browsers 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) for requesting/providing filesystem, networking, graphics, etc resources (if you think this sounds like java, see [0]).
And I think there's room for diversity here. I can imagine a world where it's normal to have 3-4 different app runners installed on your system. Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app.
[0]: https://steveklabnik.com/writing/is-webassembly-the-return-o...
Re: Wasmer 1.0
#3Browsers 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…
> Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app.
We had this. ActiveX, Flash, Director, Air, Silverlight, Java. It was a mess, and I think you'd be hard pressed to find very many folks who found it desirable.
Re: Wasmer 1.0
#4Browsers 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…
> Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app. We had this. ActiveX, Flash, Director, Air, Silverlight, Java. It was a mess, and I think you'd be hard pressed to find very many folks who found it desirable.
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.
Re: Wasmer 1.0
#5Browsers 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…
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).
Re: Wasmer 1.0
#6Browsers 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…
Completely agree with that.
I think Wasm has the potential to become the lingua franca for software. It allows containerization in a much lighter way than virtualization (KVM), but also in a platform-agnostic way.
We have a very interesting future ahead of us!
Re: Wasmer 1.0
#7Browsers 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 they're big and complicated like OSes by necessity, not accident.
Re: Wasmer 1.0
#8Browsers 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 implementations exist. (Such as in browsers and operating systems.) And they need to keep moving as the culture changes; you want to support the latest emojis, right? Well maybe you don't, but your users will.
Furthermore, these implementations are at least partially specific to particular programming languages. If you want something portable, you might build on the Skia graphics library but that won't give you a way to build an app on its own.
Re: Wasmer 1.0
#9Earlier quoted context omitted.
> Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app. We had this. ActiveX, Flash, Director, Air, Silverlight, Java. It was a mess, and I think you'd be hard pressed to find very many folks who found it desirable.
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 runtime, nobody built a replacement for Macromedia/Adobe Flash targeting any runtime anywhere. To this day, there is not a vector animation tool on par with Flash for any platform, and that has nothing to do with the capabilities of the web.
People blame HTML5 when what really happened was Adobe abandoned their authoring tools and nobody built an alternative because we expected the W3C or somebody to do it for us. But a programming language will never be a replacement for a full-featured content creation tool and IDE.
Even WASM is not going to replace Flash unless some company or group somewhere actually sits down and writes a native program that can target it and that is actually competitive with what Flash the authoring tool offered devs. I have not seen serious effort in that direction, so if you're hoping WASM just magically makes these problems go away, I'm a little less optimistic about that. WASM is just going to be another runtime target -- a good one, but not a replacement for an IDE.
Re: Wasmer 1.0
#10Browsers 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…
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.