Announcement

Collapse
No announcement yet.

Rust 1.14 Released With Experimental WebAssembly Support

Collapse
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
  • #11
    Originally posted by mmstick View Post

    Not completely, but mostly. WebAssembly is an emscripten technology and requires Javascript to import/execute it. Javascript can be used as glue code while machine code from compiled languages like Rust do all the heavy-lifting, sort of how Python is often used for on the desktop.
    Just a nit: js isn't REQUIRED but suggested (and it's expected that these early wasm implementations will use the js engine). Through opaque reference types they want to allow wasm to directly manipulate the page through web apis.
    Keep in mind that, despite its name, wasm isn't intended just to use on the web. They mention some other deployment types they'd like to accommodate like stand alone apps or platform target.

    Page not found · GitHub Pages
    http://webassembly.org/docs/gc/#opaque-reference-types

    Non-Web Embeddings - WebAssembly
    http://webassembly.org/docs/non-web/

    Comment

    • #12
      Originally posted by Luke_Wolf View Post

      HTML still needs to die in a fire and be replaced with an actual standard for web applications to run as efficiently as a native desktop application, keep in mind that it requires a minimum of 3 engines internally in order to "correctly" parse HTML, one for conformant interpretation, another for loose interpretation, and another for quirks, and then there may be additional ones for compatibility with other browsers.
      If I had a dime for each time I've heard "this technology is bad and need to die". It's almost always about technologies that have carried us for a decade or more. To name just a few we have: C, http, Java or Xorg.
      • Likes 1

      Comment

      • #13
        Originally posted by mmstick View Post

        Seems that would be simple to do if browser vendors were to work together on an ultimate standard. Basically, we would just need a new universal HTML standard with strict requirements (no special browser-specific features), and when the web browser encounters a webpage that has a tag telling the browser that it's the new standard, it chooses the correct HTML parsing engine internally.
        We have that, just put <!DOCTYPE html> and the browser knows it's seeing an HTML5 page and use its no-quirks latest parser. The excellent WHATWG specs tell browsers exactly what to do. It's still up to developers to test for features and use fallbacks or polyfills to support functionality they require; that's hard work compared with just getting it to work on current Chrome, but browser makers and developers have a spec to follow.

        The idea that closing tags to make a validating XHTML document would somehow improve web compatibility is laughable. XHTML concerned itself with the wrong problem.

        Comment

        • #14
          Originally posted by bug77 View Post
          If I had a dime for each time I've heard "this technology is bad and need to die". It's almost always about technologies that have carried us for a decade or more. To name just a few we have: C, http, Java or Xorg.
          *almost always about technologies that were choosen as the "lesser evil" even if they weren't that good to begin with.

          Comment

          • #15
            Originally posted by starshipeleven View Post
            *almost always about technologies that were choosen as the "lesser evil" even if they weren't that good to begin with.
            "Lesser evil" implies alternatives were considered and there was no better option. Hindsight is always 20/20 and I think that is especially true for software.

            I'm all for evolving code (aggressive refactoring is one of my things), but before you tear something down, you'd better make sure you have something else to put in place. Something that covers all the existing, non-deprecated use cases.

            Comment

            • #16
              Originally posted by bug77 View Post
              "Lesser evil" implies alternatives were considered and there was no better option.
              "No better option" does not mean that they are/were good and that they shouldn't die in a fire asap, only that:
              -alternatives were worse
              -there was no (credible) alternative at all

              Or, in other words, "lesser evil is still evil, just less than other options considered".

              Comment

              • #17
                Originally posted by caligula View Post

                XHTML is a problem for code generation. You can't just copy and paste strings without keeping track of the DOM. People using the lesser languages such as PHP can't be bothered to learn anything new. They want web pages to simply work like any play text file written using latin1 encoding or some other 1980s code page.
                It's especially frustrating as PHP integrates with libxml and libxsl really well, I've personally been involved in many PHP projects that did render valid XHTML, but for whatever reason the world seems perfectly content with the utter pile of trash that is WordPress.

                Comment

                • #18
                  Originally posted by Stoatally View Post

                  It's especially frustrating as PHP integrates with libxml and libxsl really well, I've personally been involved in many PHP projects that did render valid XHTML, but for whatever reason the world seems perfectly content with the utter pile of trash that is WordPress.
                  you know anything better?

                  Comment

                  Previous 1 2 template Next
                  Working...
                  X