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

[KellyClowers]

>Inspecting source files still gives the users normal regular javascript code.

that would be key IMO

There are a lot of issues with the web as a platform, but at least we can see behind the curtain for a large chunk of it. It would suck to lose that.

[cl333r]

I'm angry but I don't know what to protest against.

[ssokolow]

>Inspecting source files still gives the users normal regular javascript code.

that would be key IMO

There are a lot of issues with the web as a platform, but at least we can see behind the curtain for a large chunk of it. It would suck to lose that.

Yeah. Converting back is easy (the minifiers used to produce the ugly-but-compact walls of text you're already inspecting today basically just convert to an AST and then back). It's having it built into the browser that's important.

[AsuMagic]

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

AST is not really bytecode in the sense of V8's/SpiderMonkey's bytecode. The AST, or abstract syntax tree, is one common step of compilation that involves transforming the source into a tree of expressions.
As a vague and fabricated example, you could imagine do_something(a, 5); to be compiled into an AST node that is FunctionCall (name="do_something") with two children nodes Identifier (name = "a") and NumeralLiteral (value=5).
Caching this allows to skip the parsing stage which can be fairly expensive depending on the language.
It should not be particularly hard to "decompile" back to human readable source code. That of course still depends on whether people decide to mangle names etc.

The AST is generally then compiled down to a VM bytecode, which is implementation-specific for JS. VM bytecode is relatively similar to machine code in a way. WebAssembly is indeed one of those.

IMO the best solution would be to compile down JavaScript to WebAssembly and deal with it. This would solve a lot of the hassle and allow to concentrate efforts to wasm. That being said, I don't know much about web development or about how it works under the hood.

[Mystro256]

AST is not really bytecode in the sense of V8's/SpiderMonkey's bytecode. The AST, or abstract syntax tree, is one common step of compilation that involves transforming the source into a tree of expressions.
As a vague and fabricated example, you could imagine do_something(a, 5); to be compiled into an AST node that is FunctionCall (name="do_something") with two children nodes Identifier (name = "a") and NumeralLiteral (value=5).
Caching this allows to skip the parsing stage which can be fairly expensive depending on the language.
It should not be particularly hard to "decompile" back to human readable source code. That of course still depends on whether people decide to mangle names etc.

The AST is generally then compiled down to a VM bytecode, which is implementation-specific for JS. VM bytecode is relatively similar to machine code in a way. WebAssembly is indeed one of those.

IMO the best solution would be to compile down JavaScript to WebAssembly and deal with it. This would solve a lot of the hassle and allow to concentrate efforts to wasm. That being said, I don't know much about web development or about how it works under the hood.

Very true, AST is not a bytecode and can be decompiled easier, while WASM effectively is a bytecode.

With that said, I think the major draw back of compiling all JS to wasm is exactly the issue AST is trying to avoid; you can't decompile it easily. Makes it harder to debug from the web developer's and browser developer's perspective.

[microcode]

Every browser has java script cache. So why?
They also cache compiled version of JS

Read the article, they address that, and they have data.

[microcode]

Isn't this just asking for security issues?

It's a tree data structure, with extents for collections. Traversing a datastructure like this is very low risk.

[SystemCrasher]

Next they would propose getting rid of JS. because it slow, error prone and both features are hard to fix? Not to mention HTML is highly redundant thing that is slow to parse as well. Isn't it cool to first put hell a lot of redundancy and then heroically try to get rid of it, while trying to do something about fact it pretty much inconvenient for computers to parse? The overall result is that web is nearly most sluggish UI one can get.

[bug77]

This just makes me nostalgic about Dartium. Running Dart directly in the browser, without translating it to JS was fast.

[oiaohm]

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.

That does not fly. x86 and arm cpus do get new instructions. and at times cpu bugs turn up.

Of course what would you do for people using powerpc workstations? MIPS cpu feature phones(yes these have webbrowers) and there was a MIPS CPU desktop running debian released in 2016.

CPU issues turns up with javascript and BinaryAST the processing engine in browser can be fixed so when person updates browser it fixed.

Lets say we had binaries like you are suggesting on every website cpu fault turns up every site would need to be fixed, Browser would have to try to perform disassembly the binary to work out if it is problem or not and this may make mistakes adding extra security issues. So there is no question your idea would make security way worse. We have enough security issues in browsers without in fact spreading this problem across every website wanting scripting and making the process of dealing with these security problems worse.

Javascript is not great but is no where near the worst that can be done. Platform particular binaries is in fact way worse of a security problem.

Remember a lot of computer virus infections could have been blocked if people had kept their software upto date.