5 ms·

What's the point of using this for native applications ? I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away

• rtpg 8y ago
  you don't have to deal with the distribution issues related to the app store, you can easily roll out changes quickly, you can create "shareable applications" (URLs!) quite easily. You can also build hybrid apps, where you can take advantage of web tech for certain presentational stuff and still go fast for stuff in the backend
• vardump 8y ago
  20% performance or, as I like to say, 20% battery life. Anyways, there are good uses for WASM even outside browser. Plugins and when you have multiple architectures you need to deal with. Sandboxing and deterministic memory consumption is a great fit in certain applications. I'd like to use WASM on relatively small embedded devices (even as small as 64 - 256 kB RAM), to provide extendibility, for example.
  • masklinn 8y ago
    nebulet is a project to build a µkernel using wasm modules running directly in ring0.
• int_19h 8y ago
  By the same token, writing native apps in anything other than C++ is a waste of performance, sometimes much more significantly so... but we still do it. Performance just doesn't matter all that much in so many cases.
  • deleted 8y ago
    [deleted]
• cm2187 8y ago
  It’s not “a bit of convenience” when you are the business owner having to write multiple cheques instead of one, because each platform enforces its own incompatible technologies. Plus there is another big argument. Some app written in wasm is not just compatible with today’s platforms (iOS, Android, MacOS, Windows, etc), but also with tomorrow’s platforms. The lack of apps is probably what killed windows mobile and resulted in the current duopoly. If all apps become compatible with any platform as long as they implement a standard, then there is a chance for a challenger to break the duopoly.
  • ghettoimp 8y ago
    Hrmn. Isn't this cross-platform argument the same thing we heard for using Java instead of C (write once run anywhere) or, for that matter, using C instead of assembly (portable assembly language)? Don't get me wrong, this is all to the good. But does WASM have some special way to prevent the various platforms from implementing their own unique, special, and (of course) incompatible APIs?
    • cm2187 8y ago
      There might be some differences in API. But if your base runtime + UI (html5) + basic apis (http, storage, location, etc) are the same, you are left having to deal with edge cases about platform specific features. That's not really different from the browser compatibility problems web developers consistently run into now. So from an absolute purist point of view, yes, but practically it will be as cross-platform as it gets.
      • AnIdiotOnTheNet 8y ago
        > you are left having to deal with edge cases about platform specific features Which is always the case. The more you abstract the less you control, the more you need to control the less you can abstract. We've played this game before with Java.
    • TheCoelacanth 8y ago
      Java became one of the most heavily used programming languages, so it seems to me like that supports the cross-platform argument.
• krapp 8y ago
  >What's the point of using this for native applications ? The point is that javascript isn't actually a bytecode (javascript as the "bytecode for the web" is just a metphor and a necessary evil,) and compiling to javascript isn't as efficient as compiling to bytecode. Also, that webassembly provides an open (non-proprietary) general purpose compile target for multiple languages, as opposed to Flash or Java, which are proprietary and meant to target only a single language. Also, to allow for seamless transitions between applications on the web and off the web, allowing the web to serve as a primary channel for the distribution of native software.
• fetbaffe 8y ago
  In my opinion it is not the performance of JavaScript or WebAssembly that is the real problem, it has not been for the past few years, it is the performance of the entire web stack (e.g. electron) that is the problem. Combining all of the technologies in the web stack has performance hit far higher than 20%.
  • hinkley 8y ago
    One of things I find myself having to teach people over and over again about performance: It's like personal finance. At the end of the day you are not going to 'balance the checkbook' by identifying the 2 places where you are misbehaving the worst. You have to get every aspect of your spending below a % of your overall budget or you will always be in debt. Starting with the big things can be very motivational but it's not a strategy that works (or rather, it works by accident). The relevant part for this discussion is that if you fix the slowest thing, (interpreting code) then the effects of all of the other sources of slowness are magnified. Everything else gets 'slower' by comparison (if you fix the thing that takes 50% of the time, then all of the things that used to take single digit percentages jump to double digits). You'll eventually get near your goal that way but the entire process is a game of whack-a-mole, and nobody will ever support you going back for the last 2% in some section of the code, leading to death by a thousand cuts (and honestly, I've watched a lot of people interpret performance reports and most of us can't even spot problems that small.)
• jules 8y ago
  The biggest advantage is the same as using Javascript with Electron: being able to use web technologies on the desktop for easy cross-platform GUI applications. WebAssembly addresses two big downsides of that approach: speed, and having to program in Javascript.
• Dylan16807 8y ago
  If we can get to the point where we're only throwing away 20% performance on web-engine-based programs, I'll be overjoyed.