Announcement

Collapse
No announcement yet.

Wasmer 1.0 Beta Released For Running WebAssembly Code Anywhere

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wasmer 1.0 Beta Released For Running WebAssembly Code Anywhere

    Phoronix: Wasmer 1.0 Beta Released For Running WebAssembly Code Anywhere

    Wasmer is one of the leading software solutions aiming to bring WebAssembly (WASM) to the desktop rather than largely isolated to the web browser as is the case now. Wasmer aims to allow WASM programs anywhere and on any client while quickly closing in on its 1.0 release...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Is it just a virtual cpu for desktops or it includes support for DOM and ability to render html code as well ?

    Comment


    • #3
      Originally posted by dev_null View Post
      Is it just a virtual cpu for desktops or it includes support for DOM and ability to render html code as well ?
      Yep, it appears it is just the former, and is not able to render any form of graphics.

      Comment


      • #4
        Originally posted by dev_null View Post
        Is it just a virtual cpu for desktops or it includes support for DOM and ability to render html code as well ?
        Regular WASM in browser also can not access directly DOM, you need some javascript glue (yeah this is really stupid, we could have finally an option to create a website without javascript).

        Comment


        • #5
          Originally posted by dragonn View Post

          Regular WASM in browser also can not access directly DOM, you need some javascript glue (yeah this is really stupid, we could have finally an option to create a website without javascript).
          WebAssembly is a work in progress. Like Rust, it was released as a "minimum set of features that won't require API-breaking to extend" and they're still working to incrementally design and implement the rest of it.

          See the roadmap for a quick overview on their progress. DOM interaction requires GC integration that they're still designing.

          Comment


          • #6
            Originally posted by ssokolow View Post

            WebAssembly is a work in progress. Like Rust, it was released as a "minimum set of features that won't require API-breaking to extend" and they're still working to incrementally design and implement the rest of it.

            See the roadmap for a quick overview on their progress. DOM interaction requires GC integration that they're still designing.
            Thanks, good to know! Waiting for they day when we start getting non-javascript frontend frameworks

            Comment


            • #7
              Originally posted by dragonn View Post

              Regular WASM in browser also can not access directly DOM, you need some javascript glue (yeah this is really stupid, we could have finally an option to create a website without javascript).
              Agreed. And bindings always suck. This is why I generally stick to C or C++ for pretty much everything. With our Emscripten ports, in some cases where we cannot use the built in "normal computer emulation layer", we do things like this:

              Code:
              EM_ASM({
                  var canvas = document.getElementById("canvas");
                  canvas.width = $0;
                  canvas.height = $1;
              }, newWidth, newHeight);
              In some ways, I wish I could do similar for other annoying languages when we have to connect to consumer platforms like Android/Java, iOS/Swift. But it is still time consuming and error prone however.

              Interestingly this is an example of an issue which Rust cannot really solve. Once Rust gets mature enough to support this kind of "fake inline-asm" stuff, it will all need to be in unsafe{} tags because memory cannot be tracked across language boundaries. The JavaScript garbage collector could easily strip the memory away from underneath Rust. Just like it does in C++ smart pointers.

              Our solution is to avoid storing references to GC memory (notice I was doing a getElementById each time I call it?) Obviously this would have performance issues in a number of situations.

              (I actually implemented the initial proof of concept inline-asm for Emscripten many years ago when writing our internal Unity clone (Unity were still dicking around with their web plugin) and we needed a more flexible engine), Before, to access the "native" JavaScript, the process was much worse).
              Last edited by kpedersen; 05 December 2020, 07:39 AM.

              Comment


              • #8
                Originally posted by dirlewanger88

                Disregarded. Garbage language.
                You make mistake, Rust don't have a Garbage collector Unlike JavaScript ...

                Comment


                • #9
                  Originally posted by dirlewanger88

                  If Rust got garbage collection, it'd collect itself.
                  Rust don't have garbage collection because he does not spread garbage. Then it's not necessary.

                  Comment


                  • #10
                    Originally posted by dirlewanger88

                    The Rust community is 100% garbage.

                    Garbage in, garbage out.
                    And you are the messiah who brings the truth ?
                    ... You are not very convincing, but funny

                    Comment

                    Working...
                    X