9 ms·

Function calls from WASM to JS don't seem to have improved so much. I don't know what I want more, DOM calls from WASM, or C++ modules. A web without javascrip

• nkozyra 8y ago
  > A web without javascript would be welcome. Why? What is it that wasm or c++ provides you in making a DOM call that modern JS does not?
  • pjmlp 8y ago
    The 2nd coming of Flash?
    • knightofmars 8y ago
      You may have said this in jest and are getting down-voted for it but this isn't an impossible scenario. I think of this article in relation to what WebAssembly means. https://dzone.com/articles/java-getting-back-to-the-browser https://dzone.com/articles/java-getting-back-to-the-browser
      • pjmlp 8y ago
        I trully believe it will happen in a couple of years, unless browser vendors change course regarding WebAssembly. Ongoing POC of running Unity games, .NET, Go, Qt and many others already show it is the direction many are moving into.
        • knightofmars 8y ago
          I agree and think it's amazing. I'm looking forward to that day and when it comes. The other side is that it's also likely to open up a whole new avenue for web based security exploits.
          • pjmlp 8y ago
            One issue regarding security is that until WebAssembly gets some kind of fat pointers or tagging, modules generated by unsafe languages can be exploited by corrupting internal state, thus changing the behaviour of exported entry points. You can easily test it by creating a WebAssembly module in C with a function that overwrites an internal memory buffer, placed besides other data, which is used to parametrize behaviour of another function, for example a boolean stating that the user is authenticated.
            • Rusky 8y ago
              "Some kind of fat pointers or tagging" is exactly the sort of thing WebAssembly was created to get away from. You can use a language that provides them and targets WebAssembly, without taking away the thing that makes the platform uniquely useful.
              • pjmlp 8y ago
                Right, but how can you trust a WebAssembly library? It might have been compiled from Ada, Rust or plain C, just as an example. Telling just to use a language we trust is not an option if one is just using other people libraries. Thus bringing to the web the same security level as depending on regular native libraries, because a regular user is not going to check what a web page depends on.
                • danShumway 8y ago
                  If you're bringing in multiple separate WASM libraries, they'll run separately from each other. Don't give them access to any memory they shouldn't have access to. Note that this is considerably better than Javascript, because without going out of your way to make an iframe, separate Javascript scripts aren't isolated from each other, so you don't know if one of them is modifying a prototype or hooking around other variables in the global scope. By default, separate WASM modules don't have access to the same memory.
                  • 8y ago
        • danShumway 8y ago
          For what it's worth, I think I remember that .NET is still using reasonable web standards under the hood. It's a framework, but it's still using CSS/HTML for actual rendering. If I'm remembering correctly, I wouldn't put that in the same category as Unity and Qt.
          • pjmlp 8y ago
            Unity is also .NET, and then there is UNO as well, UWP for WebAssembly https://playground.platform.uno/ https://playground.platform.uno/
            • danShumway 8y ago
              Blazor[0] was what I was referring to, but you're right, I shouldn't treat .NET like it's only being used in that context. [0]: https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/ https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-start...
    • danShumway 8y ago
      Hopefully not. Some devs are treating WASM as an entire runtime and outputing canvas/webGL code. I think that is mostly a mistake, and I'll be very disappointed if that becomes the defacto approach for new web devs. However, the cool thing about WASM is that it's just the code part. So you can build an app that's still normal CSS/HTML, just like every web-app should be, and then you can replace all of your JS with WASM (with the current exception of a little bit of JS-to-DOM binding code which Mozilla has promised to eventually get rid of). In the world of Flash/Java you're essentially working in a completely separate platform, it just happens to be launched from a web browser. So shortcuts don't work, accessibility is awful, users can't customize the page, extensions are broken, etc, etc... With WASM, you don't have to be in that position. You can say, "I'm a web developer, I treat the web like a medium, I write responsive HTML/CSS. I just use C instead of Javascript."
      • pjmlp 8y ago
        > In the world of Flash/Java you're essentially working in a completely separate platform, it just happens to be launched from a web browser. So shortcuts don't work, accessibility is awful, users can't customize the page, extensions are broken, etc, etc... True, but until Web development catches up with the state of Flash and other native RAD GUI designers, it is a very attractive proposition. One thing I hate when doing web development is playing around with CSS and tag soup while trying to make it work the same way across all target platforms required by the customer, that in native code would be a couple of graphical calls to the visualization engine and platform widgets, which also provide layout managers. Stuff like Web Components and Houdini would make it better, but who knows when they will be widely available.
        • danShumway 8y ago
          > while trying to make it work the same way across all target platforms This goes back to what I was talking about with treating the web like a medium, not a distribution platform. Fundamentally, the web is about giving you a "controlled" way to give up control. The native paradigm is "I want control over what each individual pixel looks like", and the web paradigm is, "heck off, well-written apps don't do that." I understand why it's attractive, and why it'll continue to be attractive. And I highly agree about Houdini being an exciting development (I don't personally think that Web Components are offering much, but whatever). I'm really looking forward to being able to polyfill CSS. But that difference you're talking about is probably not ever going to go away completely, because the web is optimizing to solve different problems than most native frameworks. Not to say one approach is better than the other (Flash had some legitimate use cases), but I find that there is an actual cultural difference between how web-apps and native apps are designed and how they balance between user control and developer control. It's not just technology.
    • finchisko 8y ago
      This is one of my nightmares. But considering how much devs hate js it's inevitable. I almost see it. HTML replaced with some binary WASM bs framework.
      • wetpaws 8y ago
        Then someone will reimplement a dom and a script language in wasm. History is going in circles.
        • Felz 8y ago
          Not quite a circle. There'd be progress in that you could choose your "Javascript" and "DOM", which really opens up a lot of possibility for progress. No need to force eternal compatibility or put up with bad APIs- just pick a better version.
          • v_lisivka 8y ago
            This! You will be able to implement your own browser in the browser, with your own brand new accessibility API, i18n and l17n API's, and your own bugs, of course. We can compile Chrome or WebKit into Wasm and then use them everywhere, even in Firefox!
      • krapp 8y ago
        But you'd still need a browser that supports HTML to load the WASM and display it. Realistically, that would be not much different than current sites using JS, or Flash when that was a thing, or even Java applets. None of those deprecated or replaced HTML, and WASM won't either. At worse, it will be just another thing you can block with a script blocker.
    • cm2187 8y ago
      Minified javascript does as much to obfuscate the code than wasm if your concern is the black box model.
      • v_lisivka 8y ago
        I can reformat minified JS, then pause at a function, see it arguments, understand it purpose, rename variables, add a comment, and so on. Can I do all that in Wasm? For practical purposes of reverse engineering, minified JS is far better than Wasm. Wasm is the new Flash.
    • mr_toad 8y ago
      Hopefully without the Swiss cheese security.
  • _wmd 8y ago
    Choice The ability to use existing non-JS code The ability to write loops involving non-trivial computations without spamming a hundred million heap objects etc.
    • CyberDildonics 8y ago
      > The ability to write loops involving non-trivial computations without spamming a hundred million heap objects How does being able to call the DOM from webasm give you that? That's what webasm is for in the first place.
      • _wmd 8y ago
        > > > Why? What is it that wasm or c++ provides you in making a DOM call that modern JS does not? > > The ability to write loops involving non-trivial computations without spamming a hundred million heap objects > How does being able to call the DOM from webasm give you that? That's what webasm is for in the first place. The tell parent comment that, not me.
      • icebraining 8y ago
        I think the idea is that they can't use webasm (exclusively) to do that without also being able to call the DOM from it.
  • Spivak 8y ago
    Wasm promises a better compiler target than JS for alternative languages. It always seems odd to me that JS is so heavily defended when pretty much everything that makes up a modern JS stack are other compile-to-js languages: JSX, Elm, TypeScript, Clojurescript, Coffeescript -- hell even ES6 is for all practical purposes a compile to JS language. Changing the game into "browsers run WASM" and JS is a built-in JIT compiler for it promises to make everyone's lives much easier.
    • skybrian 8y ago
      If you're working directly with the DOM or other JavaScript APIs it's still going to be a garbage-collected, object-oriented data model. The JavaScript object model is likely to remain fundamental for cross-language within-browser interop, just like C api's are fundamental for foreign function calls in other environments. (Or Java API's in a JVM.)
      • rickycook 8y ago
        i’d imagine that at its core, all the DOM access will be just another WASM call, and WASM has no concept of objects AFAIK? it would be up to each language to represent those bindings however it likes. i don’t think the functions would even have names per se; similar to minified JS you know some magic reference number but a human readable name is not relevant all assumptions here
        • skybrian 8y ago
          If you're willing to custom-design a new API by hand, you can do it however you like. But if you want to, say, autogenerate bindings from a typescript definition file (the defacto standard for describing Javascript API's), you're probably going to end up using or adapting their function names, type names, parameter names, and so on, or you'll confuse the developers. It can be minified if both the web assembly and foreign code pass through the same minifier, but source code still has to be readable.
  • bayesian_horse 8y ago
    The big thing isn't so much the performance of WASM by itself, but rather that this performance enables the use of data models which are different from Javascript. Typescript, Coffeescript and a host of similar options have essentially the same data model. What makes other languages, like Java, Rust or Python actually useful is their way of handling data. Which is why you can't transcribe these languages to Javascript trivially. Still, the ecosystem of javascript is a lot better than the languages which compile to WASM as of right now. I guess that will change...
  • monocularvision 8y ago
    wasm makes using a statically-typed language possible in web applications. For those that have embraced JS, that may not be compelling but for those of us that prefer strong, static typing it is a positive development.
    • eridius 8y ago
      Emscripten let you do that too, compiling to asm.js. WebAssembly certainly is an improvement, but it's not like you couldn't do this at all before. And heck, even without that, there are languages that transpile directly to JavaScript.
      • monocularvision 8y ago
        Look at the comment I was responding to: I wasn’t claiming there weren’t other ways to do this. I was responding to the question as to why you might use wasm over JS. I understand it was based on previous efforts like asm.js. Also, for several languages, specifically those based on LLVM, the path to wasm is much clearer than compiling to JS.
    • sacado2 8y ago
      I'm using typescript, so I already have a statically-typed language for my web apps. What is compelling with WASM is that it lets me provide a web-browser version of my C++ libraries, for stuff which needs decent execution speed and cannot afford a GC.
  • jillesvangurp 8y ago
    Well, kind of looking forward to getting back to using languages like Java, Kotlin, C#, Swift, ObjectiveC and other languages people have been using to make UIs for quite some time in a browser. It will take some time for proper frameworks to emerge. But things are moving fast. Driving the DOM via react and other js frameworks from these languages is kind of possible. But it's probably just a stepping stone for getting something a bit more appropriate to these languages. I have high hopes for Kotlin here. With Kotlin native they are targeting native IOS and native Android. Being able drive browsers from the same code-base via WASM seems like it will be a useful feature. Also, they seem to be really serious about tool support with Kotlin; providing dom/webgl and other bindings, and having decent end to end support with IDEs and other tools. I imagine, Microsoft might have similar plans for C#. And it wouldn't surprise me if Apple was working on some Swift WASM support either.
• jandem 8y ago
  > Function calls from WASM to JS don't seem to have improved so much. Yeah, Wasm => JS calls used to be reasonably fast because we had optimized that before. The work described here made that path much nicer, though (a more unified stack layout for JIT/Wasm frames) and also a bit faster still. JS => Wasm calls being slow was one of the big performance cliffs in SpiderMonkey and I'm really glad that's fixed now.
• flohofwoe 8y ago
  Timing for calls from WASM to JS went from 750ms to 450ms for 100 million calls, so from 7.5 nanoseconds per call to 4.5 nanoseconds per call. A 3 GHz CPU would do 3 ticks per nanoseconds, doing such a bridging call in 23 or 15 CPU ticks is quite good IMHO (I just hope I didn't blunder the math, but function call overhead from WASM to JS isn't much of an issue, it was already fast after the previous round of optimizations).
• bayesian_horse 8y ago
  At the moment I don't think there is a frontend language/framework which compiles to WASM and is actually worth using, at least from a perspective of frontend productivity. For performance or porting legacy code, WASM is already useful. I mean, yes, there are things like Blazor or similar things for Rust or Nim, but these aren't yet compelling to me.
  • steveklabnik 8y ago
    What would make it compelling? (I don’t think this is where wasm will be used as much but I’m still interested!)
    • bayesian_horse 8y ago
      Something like react or vuejs in Python, with similar performance and equally or more productive. There is something like this for Rust, I think. But Python for the Browser is not compelling unless we both have a faithful implementation of the language and data model and a productive and beautiful frontend framework. Call it a React for Python or a Django for the frontend. Similar goals apply for other languages which have an edge on Javascript in some regard.
      • steveklabnik 8y ago
        Okay yeah, I wasn't sure if you were saying "the frameworks that exist are bad" or "a framework should exist". Thanks. (And yeah, there are several of these in Rust now, but they're extremely early days, and not really ready for anything serious at all.)
      • nicoburns 8y ago
        I doubt we'll see that. Python just isn't that different to JS (so what's the point), and is in any case much slower than JS in all current implementations (so performance parity is unlikely).
        • bayesian_horse 8y ago