Announcement

Collapse
No announcement yet.

Mozilla, Cloudflare & Others Propose BinaryAST For Faster JavaScript Load Times

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

  • Mozilla, Cloudflare & Others Propose BinaryAST For Faster JavaScript Load Times

    Phoronix: Mozilla, Cloudflare & Others Propose BinaryAST For Faster JavaScript Load Times

    Developers at Mozilla, Facebook, Cloudflare, and elsewhere have been drafting "BinaryAST" as a new over-the-wire format for JavaScript...

    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
    Every browser has java script cache. So why?
    They also cache compiled version of JS

    Comment


    • #3
      Isn't this just asking for security issues?

      Comment


      • #4
        wait, if this AST is just pre compiled bytecode - you don't actually need JS, right - isn't this just web assembly?

        Comment


        • #5
          Originally posted by boxie View Post
          wait, if this AST is just pre compiled bytecode - you don't actually need JS, right - isn't this just web assembly?
          Pretty sure this is at a different layer.

          Comment


          • #6
            I would suggest to finally turn this into a compiled binary, make it include all supported architectures (x86 + ARM), and run it that way.
            I mean, it is most of the way there anyway. Security issues are already present in fair numbers, so I fail to see the downside.

            Comment


            • #7
              Originally posted by boxie View Post
              wait, if this AST is just pre compiled bytecode - you don't actually need JS, right - isn't this just web assembly?
              I read the Cloudfare blog, they are different things, BAST and WASM:

              AFAIU, BAST is like a NIR of a JS file, you put JS file through the encoder and it spits BAST, and this BAST is what you send to the browser instead of the JS file.

              This way the browser doesn't have to run some process and know more about the lazyness of a function in the BAST form that it would know running the regular JS file through its compiler, which allows the +90% improvements in start-up times.

              WASM allows running programs from another language in the browser, when you compile targeting wasm, like ffmpeg and other programs

              Comment


              • #8
                Originally posted by miskol View Post
                Every browser has java script cache. So why?
                They also cache compiled version of JS
                Chromium has somewhat strict requirements to store js in its cache, and it only works for sites you visit often. Even with a cache that's used more aggressively, sending a pre-parsed AST to the browser makes a lot of sense. Parsing can take a significant amount of time (especially on underpowered mobile devices), and you have to run that code as well. I wonder how is this going to change developer experience. Will chromium finally get proper variable name mappings, even though source maps supported them since 2013 IIRC? Debugging compiled code can be a pain, because source maps don't map to actual variable names you need to use to do meaningful things.

                Comment


                • #9
                  They should do this in a completely transparent way. For instance, you can already (for decades!) enable site compression from the webserver. Most do that too.
                  That includes javascript. That's the stuff you see sometimes on library sites (minified en compressed) where the compressed part is done by the webserver.

                  I'd see this BinaryAST just as a webserver compression toggle for javascript files specifically. The format then probably has to change a little so that it has a header, the browser then just emits "support" for it, like it does now with gzip, and you're done. Inspecting source files still gives the users normal regular javascript code.

                  Comment


                  • #10
                    I'm kinda worried this may affect my anti-Google architecture...

                    Comment

                    Working...
                    X