16 ms·

Wasmer 1.0

342 points by wiqar 6y ago

anderspitman 6y ago
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) 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-of-java-applets-flash https://steveklabnik.com/writing/is-webassembly-the-return-o...
- bastawhiz 6y ago
  > 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.
  - anderspitman 6y ago
    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.
    - danShumway 6y ago
      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.
      - anderspitman 6y ago
        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.
        danShumway 6y ago
        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.
- skybrian 6y ago
  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.
  - Ajedi32 6y ago
    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.
    - anderspitman 6y ago
      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.
      - Ajedi32 6y ago
        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.
- nynx 6y ago
  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).
  - eitland 6y ago
    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.
    - devwastaken 6y ago
      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.
      - kaba0 6y ago
        Then there is no point in having a browser platform, because we are back where we started from. Then why don’t we simply run JVM apps, there are at least a handful of implementations, and it has at least a decent GUI (half joking here). But really, the JVM is where WASM may be several years later.
        devwastaken 6y ago
        VM's are not all the same, and a VM does not at all guarantee security. The JVM is not designed to run arbitrary code and/or is not as well designed to do it as Javascript or Wasm is. If it were as simple as plug JVM into browser it would be done. However it's not, because the memory and execution safety measures are better in Javascript and Wasm. Wasm should actually have better isolation than JS. If you want to know the details go read the spec and look at the implimentations.
- syrusakbary 6y ago
  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!
- hctaw 6y ago
  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.
  - amelius 6y ago
    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.
    - nynx 6y ago
      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.
      - reader_mode 6y ago
        >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.
        dagmx 6y ago
        For example, Qt already has a port to wasm
    - hctaw 6y ago
- brundolf 6y ago
  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.
  - josephg 6y ago
    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.
    - anderspitman 6y ago
      The web is a great way to distribute native programs. Click a URL to download, then run.
      - charrondev 6y ago
        I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.
        anderspitman 6y ago
        That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.
        josephg 6y ago
- phkahler 6y ago
  >> Browsers are not the right tool for sandboxing applications. Browsers have been picking up the slack where OS and desktop developers have fallen down. The OS is supposed to handle process isolation and resource access, but here we are. Tabbed browsing became a thing because GUI toolkits didn't do multiple app instances (or MDI) in a way people liked.
  - enos_feedler 6y ago
    When the browser first came out, the OS didn't even have a native TCP/IP stack! The internet was an app you installed. For a long time the core purpose of the browser was to pickup the slack/gap in the OS treating the internet as a first class thing. Now, as the internet clams down a bit, the OS handles everything natively, including the security primitives (at least on mobile) and so the purpose of the browser is sadly diminishing. It's a less useful experimental side channel to the OS.
- cortesoft 6y ago
  It seems like your argument is the opposite of the point made in the essay you linked. You say a browser is unnecessary, but the essay says that WASM won because it integrates with the rest of the browser.
  - anderspitman 6y ago
    Ha, you're actually kind of right. That article doesn't quite say what I remembered it saying. Been a while since I read it. I'd say about half the points are still applicable, but it is more pro-browser than me for sure. Too late to edit, but Steve's previous blog post probably presents my point better, though with less focus on the vs Java argument: https://steveklabnik.com/writing/webassembly-is-more-than-just-the-web https://steveklabnik.com/writing/webassembly-is-more-than-ju...
- higerordermap 6y ago
  A JIT is just more attack surface. Change my mind.
- flohofwoe 6y ago
  The idea makes a lot of sense, but it all comes down to the system-level APIs that this application-runner would provide. Should it be Web-APIs? Then you're essentially rewriting the browser, maybe minus the DOM, CSS and JS. Should it be the Windows APIs? Then you're essentially rewriting Windows above the kernel. Just POSIX? Then what about applications that need rendering and sound. Do you invent your own cross-platform APIs? It's a massive undertaking, and without the momentum that the web had and has, it'll be tough to make this application runner popular among devs and users.
genpfault 6y ago
> Wasmer is an open-source runtime for executing WebAssembly on the Server.[1] [1]: https://docs.wasmer.io/ https://docs.wasmer.io/
- canada_dry 6y ago
  Could someone also ELI5 and give some low-hanging use-cases for this... especially in the IoT space??
  - orionblastar 6y ago
    Running the code at the server means it is less likely to be seen by the user. I used to program in ASP 3.0 with VBscript. The user sees HTML code as the script is run on the server and Html code is rendered for the user. Also the user is less likely to hack the code if it is on the server.
  - fnord123 6y ago
    A low hanging use case would be scripts for a distributed data analysis system. e.g. You type in a function and then it compiles to wasm and is sent out to run on worker nodes. Or you write code snippets for code to run in a distributed dag. This exists with e.g. shared file systems (how hpc works, how hadoop works) and Python can pickle code and send it over a socket (be aware that this is a security risk). WASM seems like a nice and direct solution for moving code to data.
    - alexhutcheson 6y ago
      SQL UDFs might be another potential use-case in the same category.
      - pjmlp 6y ago
        Oracle and Microsoft already use JVM and CLR for that.
rapidlua 6y ago
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.
- nine_k 6y ago
  A VM is not the best environment to test speed and compare it to a native environment speed. I noticed that certain operations take longer on a VM, and e.g. disk performance may differ a lot (and sometimes be faster than the host FS's!) Also, things being in the page cache can speed up the second and subsequent runs much faster.
  - rapidlua 6y ago
    True, but for a cpu bound task like this VM typically causes only a 10% slowdown. You aren’t going to see an order of magnitude faster execution on real hardware. The article makes it look like compilation is almost instantaneous. It’s not. Cached artifacts are rather hefty as well. V8 fares surprisingly well given that it’s not a specialized WebAssembly runtime. Wasmer should probably watch competitors more closely.
eyberg 6y ago
Was reading through https://www.diva-portal.org/smash/get/diva2:1451494/FULLTEXT02 https://www.diva-portal.org/smash/get/diva2:1451494/FULLTEXT... - what's the current status/eta of raw sockets? Last time I checked wasm consensus seemed to suggest they will never be supported?
- the_duke 6y ago
  Are you talking about the browser or other environments? There is a proposal [1] for adding sockets to WASI. This blog post [2] has some more background info. Outside the browsers, you can always provide extra functionality yourself though by supplying host defined functions as imports. That looses the benefit of a standard API, but is fine for custom deployments. [1] https://github.com/WebAssembly/WASI/pull/312 https://github.com/WebAssembly/WASI/pull/312 [2] https://radu-matei.com/blog/towards-sockets-networking-wasi/ https://radu-matei.com/blog/towards-sockets-networking-wasi/
  - eyberg 6y ago
    Yeh, this article kinda confirms what I've been thinking the past few years: "Implementing a server requires additional API functions exposed - specifically, sock_bind, sock_listen, and sock_accept" "And while implementing them is done similarly to what was described here so far, there is an underlying issue: there is no multi-threading support in WebAssembly" Really surprised to see so many people talking this up to running many/most server-side applications with so many fundamental features missing.
    - the_duke 6y ago
      There is of course the threads proposal [1], which works in chrome with a feature flag, but most runtimes don't support it yet. In general I have to agree that WASM needs more time. There are multiple quite crucial proposals in the pipeline (reference types, interface types, threads, tail calls and other advanced control flow, module linking, (GC), ...) which have all seen very slow progress. Overall I'm still bullish on the potential of WASM for universal deployment, but the slow pace is a bit concerning. [1] https://github.com/WebAssembly/threads https://github.com/WebAssembly/threads
CyberRabbi 6y ago
Congratulations to Peter and team!
dmitriid 6y ago
How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?
- coolreader18 6y ago
  Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC. WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully even the full stable version is backwards-compatible with snapshot-1.
  - dmitriid 6y ago
    > Because the "MVP" stage is itself production ready > some non-MVP features are almost stable > the posix-like system interface ABI, is still technically a "snapshot" So... It's not production ready.
    - kthxb 6y ago
      WebAssembly's MVP release was primarily targeted at the ... web. It is production ready in all (vital) aspects concerning execution in a browser.
      - dmitriid 6y ago
        > It is production ready in all (vital) aspects concerning execution in a browser As in (emphasis mine): "This means that there are important features we know we want and need, but are post-MVP" [1] As in: "a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;" It's good that you specified "vital" when talking about "all" aspects. Where vital is basically "let's run MVP in an isolated sandbox with little-to-no interoperability with the rest of the browser". Because the rest of the vital things like "basically everything" [3] [4] are still MIA. But yeah, I mean, the modern web was built on a language designed in 10 days, so I shouldn't complain, should I. [1] https://github.com/WebAssembly/design/blob/master/MVP.md https://github.com/WebAssembly/design/blob/master/MVP.md [2] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG... [3] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md https://github.com/WebAssembly/design/blob/master/FutureFeat... [4] https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals
philips 6y ago
This makes me think why deno[1] wouldn’t be a thing that people use to run WASM. [1] https://deno.land https://deno.land
- nine_k 6y ago
  I suppose a very different runtime would require a very different standard library, which is a key part of environments like node or deno.
_TA_12_ 6y ago
>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside). Why? I don't get that or maybe miss some crucial parts or maybe it's just a too enthusiastic statement. I understand the security issues of running external code. Those security issues can be reduced with a sandboxed environment like a WA runtime. On the server side the vast majority of the industry is running their own code. There are already many options like lambda-functions, hosted container environments, hosted VMs or of course running your own. So why take this extra step? Running plain binaries of your code is easier, faster and more reliable. Building, distributing and running a Go service is actually one of the easiest parts in the whole development and operations chain. Same is true for Rust or .NET Core. Even with Java where you need a runtime I don't see how a WA runtime solves a problem at all when running your own code. I see great potential where you need to run untrusted code. Customer plugins for some edge server. But that is really a niche in terms of overall market.
- vijaybritto 6y ago
  I see the main advantage in this as running a polyglot application as if its native. For example if you are making a Rust application, you can have a plugin architecture where the plugins run inside a wasm compiled python interpreter. I dont know if doing this directly and cross platform is as easy without wasmer
  - pjmlp 6y ago
    Just like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.
    - vijaybritto 6y ago
      Absolutely. But I think wasmer is a lightweight VM compared to those.
    - sagichmal 6y ago
      Wasm is structurally similar to those things, yes, but is so much faster that it is actually categorically different.
nbzso 6y ago
This is great. Now make authoring tool like flash/director and we are in 21 century for real.:)
robbywashere_ 6y ago
'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution of this runtime. I can only imagine the sheer number of man hours poured in to javascript to offer the functionality it has today while balancing with security and sandboxing. Nodejs is a different story; Take a look at Deno and its origin. Web-assembly is sandbox-able run anywhere, ubiquitous runtime which isn't owned specifically by a corporate overlord, and is also which has/or is set to have the evolutionary pressure javascript has. This is huge! Way to go Wasmer :)
- CyberRabbi 6y ago
  You don’t need webassembly to run JavaScript on the server side. You don’t need webassembly to run C++ on the server side. You don’t need webassembly to run Rust on the server side. Etc. Node was necessary because you need node (or compatible) to run JavaScript on the server side.
  - epse 6y ago
    But it helps when running untrusted code, or code that has to be separated (like what you would use containers for)
  - singularity2001 6y ago
    You DO need webassembly to run C++ on the server AND client(browser) side. (unless you want to use some hacky c++ to js transpiler)
    - CyberRabbi 6y ago
      Can you provide an example of a situation where it would make sense for both client and server to use the same build? Typically client and server play different roles and require different builds anyway.
deleted 6y ago
[deleted]
idiotta 6y ago
congrats you are talented programmer but this is the definiton of unnecessary!
littlestymaar 6y ago
> Wasm also provides a lean execution environment enabling Wasmer containers to run in places where Docker containers are too heavy to work. Can someone explain why you'd want to use a wasm runtime in that context instead of just using seccomp for that ?
tinus_hn 6y ago
> Wasm also provides a lean execution environment enabling Wasmer containers to run in places where Docker containers are too heavy to work. Is WebAssembly really faster or lighter than virtualization? Or is this about the virtual os you run in Docker?
acje 6y ago
I like web-assembly for the same reason I like Rust, actor-model and compile time checked state machines. It makes it more plausible that we can build robust services in the future. And it even feels like Computer Engineering when I'm working with these concepts. To me the web-assembly runtime is the next iteration of isolated applications, after containers which came after VMs, and I'm sure HN could come up with a bigger picture, but this is OK for my purpose. And I know nothing about browsers, GUI and front-end stuff, but Web-assembly is never the less very interesting for me, and I consider it the biggest thing since Docker.

342 points by wiqar 6y ago

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) 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-of-java-applets-flash https://steveklabnik.com/writing/is-webassembly-the-return-o...

bastawhiz 6y ago
> 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.
- anderspitman 6y ago
  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.
  - danShumway 6y ago
    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.
    - anderspitman 6y ago
      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.
      - danShumway 6y ago
        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.
skybrian 6y ago
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.
- Ajedi32 6y ago
  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.
  - anderspitman 6y ago
    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.
    - Ajedi32 6y ago
      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.
nynx 6y ago
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).
- eitland 6y ago
  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.
  - devwastaken 6y ago
    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.
    - kaba0 6y ago
      Then there is no point in having a browser platform, because we are back where we started from. Then why don’t we simply run JVM apps, there are at least a handful of implementations, and it has at least a decent GUI (half joking here). But really, the JVM is where WASM may be several years later.
      - devwastaken 6y ago
        VM's are not all the same, and a VM does not at all guarantee security. The JVM is not designed to run arbitrary code and/or is not as well designed to do it as Javascript or Wasm is. If it were as simple as plug JVM into browser it would be done. However it's not, because the memory and execution safety measures are better in Javascript and Wasm. Wasm should actually have better isolation than JS. If you want to know the details go read the spec and look at the implimentations.
syrusakbary 6y ago
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!
hctaw 6y ago
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.
- amelius 6y ago
  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.
  - nynx 6y ago
    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.
    - reader_mode 6y ago
      >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.
      - dagmx 6y ago
        For example, Qt already has a port to wasm
  - hctaw 6y ago
brundolf 6y ago
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.
- josephg 6y ago
  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.
  - anderspitman 6y ago
    The web is a great way to distribute native programs. Click a URL to download, then run.
    - charrondev 6y ago
      I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.
      - anderspitman 6y ago
        That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.
        josephg 6y ago
phkahler 6y ago
>> Browsers are not the right tool for sandboxing applications. Browsers have been picking up the slack where OS and desktop developers have fallen down. The OS is supposed to handle process isolation and resource access, but here we are. Tabbed browsing became a thing because GUI toolkits didn't do multiple app instances (or MDI) in a way people liked.
- enos_feedler 6y ago
  When the browser first came out, the OS didn't even have a native TCP/IP stack! The internet was an app you installed. For a long time the core purpose of the browser was to pickup the slack/gap in the OS treating the internet as a first class thing. Now, as the internet clams down a bit, the OS handles everything natively, including the security primitives (at least on mobile) and so the purpose of the browser is sadly diminishing. It's a less useful experimental side channel to the OS.
cortesoft 6y ago
It seems like your argument is the opposite of the point made in the essay you linked. You say a browser is unnecessary, but the essay says that WASM won because it integrates with the rest of the browser.
- anderspitman 6y ago
  Ha, you're actually kind of right. That article doesn't quite say what I remembered it saying. Been a while since I read it. I'd say about half the points are still applicable, but it is more pro-browser than me for sure. Too late to edit, but Steve's previous blog post probably presents my point better, though with less focus on the vs Java argument: https://steveklabnik.com/writing/webassembly-is-more-than-just-the-web https://steveklabnik.com/writing/webassembly-is-more-than-ju...
higerordermap 6y ago
A JIT is just more attack surface. Change my mind.
flohofwoe 6y ago
The idea makes a lot of sense, but it all comes down to the system-level APIs that this application-runner would provide. Should it be Web-APIs? Then you're essentially rewriting the browser, maybe minus the DOM, CSS and JS. Should it be the Windows APIs? Then you're essentially rewriting Windows above the kernel. Just POSIX? Then what about applications that need rendering and sound. Do you invent your own cross-platform APIs? It's a massive undertaking, and without the momentum that the web had and has, it'll be tough to make this application runner popular among devs and users.

genpfault 6y ago

> Wasmer is an open-source runtime for executing WebAssembly on the Server.[1] [1]: https://docs.wasmer.io/ https://docs.wasmer.io/

canada_dry 6y ago
Could someone also ELI5 and give some low-hanging use-cases for this... especially in the IoT space??
- orionblastar 6y ago
  Running the code at the server means it is less likely to be seen by the user. I used to program in ASP 3.0 with VBscript. The user sees HTML code as the script is run on the server and Html code is rendered for the user. Also the user is less likely to hack the code if it is on the server.
- fnord123 6y ago
  A low hanging use case would be scripts for a distributed data analysis system. e.g. You type in a function and then it compiles to wasm and is sent out to run on worker nodes. Or you write code snippets for code to run in a distributed dag. This exists with e.g. shared file systems (how hpc works, how hadoop works) and Python can pickle code and send it over a socket (be aware that this is a security risk). WASM seems like a nice and direct solution for moving code to data.
  - alexhutcheson 6y ago
    SQL UDFs might be another potential use-case in the same category.
    - pjmlp 6y ago
      Oracle and Microsoft already use JVM and CLR for that.

rapidlua 6y ago

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.

nine_k 6y ago
A VM is not the best environment to test speed and compare it to a native environment speed. I noticed that certain operations take longer on a VM, and e.g. disk performance may differ a lot (and sometimes be faster than the host FS's!) Also, things being in the page cache can speed up the second and subsequent runs much faster.
- rapidlua 6y ago
  True, but for a cpu bound task like this VM typically causes only a 10% slowdown. You aren’t going to see an order of magnitude faster execution on real hardware. The article makes it look like compilation is almost instantaneous. It’s not. Cached artifacts are rather hefty as well. V8 fares surprisingly well given that it’s not a specialized WebAssembly runtime. Wasmer should probably watch competitors more closely.

eyberg 6y ago

Was reading through https://www.diva-portal.org/smash/get/diva2:1451494/FULLTEXT02 https://www.diva-portal.org/smash/get/diva2:1451494/FULLTEXT... - what's the current status/eta of raw sockets? Last time I checked wasm consensus seemed to suggest they will never be supported?

the_duke 6y ago
Are you talking about the browser or other environments? There is a proposal [1] for adding sockets to WASI. This blog post [2] has some more background info. Outside the browsers, you can always provide extra functionality yourself though by supplying host defined functions as imports. That looses the benefit of a standard API, but is fine for custom deployments. [1] https://github.com/WebAssembly/WASI/pull/312 https://github.com/WebAssembly/WASI/pull/312 [2] https://radu-matei.com/blog/towards-sockets-networking-wasi/ https://radu-matei.com/blog/towards-sockets-networking-wasi/
- eyberg 6y ago
  Yeh, this article kinda confirms what I've been thinking the past few years: "Implementing a server requires additional API functions exposed - specifically, sock_bind, sock_listen, and sock_accept" "And while implementing them is done similarly to what was described here so far, there is an underlying issue: there is no multi-threading support in WebAssembly" Really surprised to see so many people talking this up to running many/most server-side applications with so many fundamental features missing.
  - the_duke 6y ago
    There is of course the threads proposal [1], which works in chrome with a feature flag, but most runtimes don't support it yet. In general I have to agree that WASM needs more time. There are multiple quite crucial proposals in the pipeline (reference types, interface types, threads, tail calls and other advanced control flow, module linking, (GC), ...) which have all seen very slow progress. Overall I'm still bullish on the potential of WASM for universal deployment, but the slow pace is a bit concerning. [1] https://github.com/WebAssembly/threads https://github.com/WebAssembly/threads

CyberRabbi 6y ago

Congratulations to Peter and team!

dmitriid 6y ago

How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?

coolreader18 6y ago
Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC. WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully even the full stable version is backwards-compatible with snapshot-1.
- dmitriid 6y ago
  > Because the "MVP" stage is itself production ready > some non-MVP features are almost stable > the posix-like system interface ABI, is still technically a "snapshot" So... It's not production ready.
  - kthxb 6y ago
    WebAssembly's MVP release was primarily targeted at the ... web. It is production ready in all (vital) aspects concerning execution in a browser.
    - dmitriid 6y ago
      > It is production ready in all (vital) aspects concerning execution in a browser As in (emphasis mine): "This means that there are important features we know we want and need, but are post-MVP" [1] As in: "a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;" It's good that you specified "vital" when talking about "all" aspects. Where vital is basically "let's run MVP in an isolated sandbox with little-to-no interoperability with the rest of the browser". Because the rest of the vital things like "basically everything" [3] [4] are still MIA. But yeah, I mean, the modern web was built on a language designed in 10 days, so I shouldn't complain, should I. [1] https://github.com/WebAssembly/design/blob/master/MVP.md https://github.com/WebAssembly/design/blob/master/MVP.md [2] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG... [3] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md https://github.com/WebAssembly/design/blob/master/FutureFeat... [4] https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals

philips 6y ago

This makes me think why deno[1] wouldn’t be a thing that people use to run WASM. [1] https://deno.land https://deno.land

nine_k 6y ago
I suppose a very different runtime would require a very different standard library, which is a key part of environments like node or deno.

_TA_12_ 6y ago

>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside). Why? I don't get that or maybe miss some crucial parts or maybe it's just a too enthusiastic statement. I understand the security issues of running external code. Those security issues can be reduced with a sandboxed environment like a WA runtime. On the server side the vast majority of the industry is running their own code. There are already many options like lambda-functions, hosted container environments, hosted VMs or of course running your own. So why take this extra step? Running plain binaries of your code is easier, faster and more reliable. Building, distributing and running a Go service is actually one of the easiest parts in the whole development and operations chain. Same is true for Rust or .NET Core. Even with Java where you need a runtime I don't see how a WA runtime solves a problem at all when running your own code. I see great potential where you need to run untrusted code. Customer plugins for some edge server. But that is really a niche in terms of overall market.

vijaybritto 6y ago
I see the main advantage in this as running a polyglot application as if its native. For example if you are making a Rust application, you can have a plugin architecture where the plugins run inside a wasm compiled python interpreter. I dont know if doing this directly and cross platform is as easy without wasmer
- pjmlp 6y ago
  Just like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.
  - vijaybritto 6y ago
    Absolutely. But I think wasmer is a lightweight VM compared to those.
  - sagichmal 6y ago
    Wasm is structurally similar to those things, yes, but is so much faster that it is actually categorically different.

nbzso 6y ago

This is great. Now make authoring tool like flash/director and we are in 21 century for real.:)

robbywashere_ 6y ago

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution of this runtime. I can only imagine the sheer number of man hours poured in to javascript to offer the functionality it has today while balancing with security and sandboxing. Nodejs is a different story; Take a look at Deno and its origin. Web-assembly is sandbox-able run anywhere, ubiquitous runtime which isn't owned specifically by a corporate overlord, and is also which has/or is set to have the evolutionary pressure javascript has. This is huge! Way to go Wasmer :)

CyberRabbi 6y ago
You don’t need webassembly to run JavaScript on the server side. You don’t need webassembly to run C++ on the server side. You don’t need webassembly to run Rust on the server side. Etc. Node was necessary because you need node (or compatible) to run JavaScript on the server side.
- epse 6y ago
  But it helps when running untrusted code, or code that has to be separated (like what you would use containers for)
- singularity2001 6y ago
  You DO need webassembly to run C++ on the server AND client(browser) side. (unless you want to use some hacky c++ to js transpiler)
  - CyberRabbi 6y ago
    Can you provide an example of a situation where it would make sense for both client and server to use the same build? Typically client and server play different roles and require different builds anyway.

deleted 6y ago

[deleted]

idiotta 6y ago

congrats you are talented programmer but this is the definiton of unnecessary!

littlestymaar 6y ago

> Wasm also provides a lean execution environment enabling Wasmer containers to run in places where Docker containers are too heavy to work. Can someone explain why you'd want to use a wasm runtime in that context instead of just using seccomp for that ?

tinus_hn 6y ago

> Wasm also provides a lean execution environment enabling Wasmer containers to run in places where Docker containers are too heavy to work. Is WebAssembly really faster or lighter than virtualization? Or is this about the virtual os you run in Docker?

acje 6y ago

I like web-assembly for the same reason I like Rust, actor-model and compile time checked state machines. It makes it more plausible that we can build robust services in the future. And it even feels like Computer Engineering when I'm working with these concepts. To me the web-assembly runtime is the next iteration of isolated applications, after containers which came after VMs, and I'm sure HN could come up with a bigger picture, but this is OK for my purpose. And I know nothing about browsers, GUI and front-end stuff, but Web-assembly is never the less very interesting for me, and I consider it the biggest thing since Docker.