Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards a JavaScript Binary AST

yoric.github.io

Post reply on HN
Print view View original

141–150 of 211 posts

Re: Towards a JavaScript Binary AST

#141

Post by syg »

iamleppert wrote: post #137

I'd like to see some real-world performance numbers when compared with gzip. The article is a little overzealous in its claims that simply don't add up. My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique. This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's need…

The gzip point aside (which is not an apples-to-apples comparison as gzipping a big source does not diminish its parse time), I see the response of "JS devs need to stop shipping so much JS" often. My issue with this response is that multiple parties are all trying to work towards making JS apps load faster and run faster. It is easy enough to say "developers should do better", but that can be an umbrella response to any source of performance issues.

The browser and platform vendors do not have the luxury of fiat: they cannot will away the size of modern JS apps simply because they are causing slowdown. There can be engineering advocacy, to be sure, but that certainly shouldn't preclude those vendors from attempting technical solutions.

Re: Towards a JavaScript Binary AST

#142

Post by stcredzero »

nfriedly wrote: post #55

To clarify how this is not related to WebAssembly, this is for code written in JavaScript , while WASM is for code written in other languages. It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed. WASM doesn't currently have built-in garbage collection, so to use it to compress/speed up/whatever JavaScript, you would have to compile an entire JavaScript Virtual Machine in…

It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed.

The author of Smalltalk/X proposed this for Smalltalk at one of the Camp Smalltalk meetups about 17 years ago. Doing this for Javascript would also facilitate the running of other languages which use Javascript as a compiler target, providing 1st class debugging support for other languages as a side effect.

Re: Towards a JavaScript Binary AST

#143

Post by bgirard »

nfriedly wrote: post #55

To clarify how this is not related to WebAssembly, this is for code written in JavaScript , while WASM is for code written in other languages. It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed. WASM doesn't currently have built-in garbage collection, so to use it to compress/speed up/whatever JavaScript, you would have to compile an entire JavaScript Virtual Machine in…

Thank you for clarifying. Plain text source code is just not a good way to ship code. Browsers have a warm shared copy of a highly tuned VM. However to make use of it sites have to talk to it via plain text source code heavily penalizing startup.

A JS binary AST has the potential to transparently benefits all websites without any effort on their part if it's handled by a web server module, like GZIP, or a build step. This can remove redundant work that's done for billions of page load for all web sites.

Re: Towards a JavaScript Binary AST

#144

Post by alangpierce »

le-mark wrote: post #32

Here's some perspective for where this project is coming from: > So, a joint team from Mozilla and Facebook decided to get started working on a novel mechanism that we believe can dramatically improve the speed at which an application can start executing its JavaScript: the Binary AST. I really like the organization of the present article, the author really answered all the questions I had, in an orderly manner. I'll…

> seems unlikely all browsers would implement it

It's going through TC39 (the committee that decides how the JavaScript language should evolve) and recently reached stage 1 (proposals advance from stage 0 to stage 4). I believe that if it reaches stage 4, then that means that all browser vendors have agreed to implement it, so it certainly seems to be their goal.

Re: Towards a JavaScript Binary AST

#145

Post by syg »

s3th wrote: post #140

i'm very skeptical about the benefits of a binary JavaScript AST. The claim is that a binary AST would save on JS parsing costs. however, JS parse time is not just tokenization. For many large apps, the bottleneck in parsing is instead in actually validating that the JS code is well-formed and does not contain early errors. The binary AST format proposes to skip this step [0] which is equivalent to wrapping function…

Early error behavior is proposed to be deferred (i.e. made lazy), not skipped. Additionally, it is one of many things that require frontends to look at every character of the source.

I contend that the text format for JS is no way easy to implement or extend, though I can only offer my personal experience as an engine hacker.

Re: Towards a JavaScript Binary AST

#146

Post by s3th »

syg wrote: post #145
s3th wrote: post #140

i'm very skeptical about the benefits of a binary JavaScript AST. The claim is that a binary AST would save on JS parsing costs. however, JS parse time is not just tokenization. For many large apps, the bottleneck in parsing is instead in actually validating that the JS code is well-formed and does not contain early errors. The binary AST format proposes to skip this step [0] which is equivalent to wrapping function…

Early error behavior is proposed to be deferred (i.e. made lazy), not skipped. Additionally, it is one of many things that require frontends to look at every character of the source. I contend that the text format for JS is no way easy to implement or extend, though I can only offer my personal experience as an engine hacker.

If early error is deferred then it's no longer early... that's all I meant by skipped. It still is a semantic change that's unrelated to a binary AST.

Re: Towards a JavaScript Binary AST

#147

Post by Yoric »

stcredzero wrote: post #142
nfriedly wrote: post #55

To clarify how this is not related to WebAssembly, this is for code written in JavaScript , while WASM is for code written in other languages. It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed. WASM doesn't currently have built-in garbage collection, so to use it to compress/speed up/whatever JavaScript, you would have to compile an entire JavaScript Virtual Machine in…

It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed. The author of Smalltalk/X proposed this for Smalltalk at one of the Camp Smalltalk meetups about 17 years ago. Doing this for Javascript would also facilitate the running of other languages which use Javascript as a compiler target, providing 1st class debugging support for other languages as a side effect.

Do you have a link? I'd be interested in reading how they proposed to do so.

Re: Towards a JavaScript Binary AST

#148

Post by roywiggins »

Yoric wrote: post #57
dmitriid wrote: post #29

Earlier quoted context omitted.

So why do you dismiss any and all arguments against it? Repeatedly. You and your supporters consistently spread false information. - WebAssembly does not support JS hence we need binary AST WebAssembly is on track to support dynamic and GC-ed languages - WebAssembly will be slower than binary AST You've provided zero support for this statement. Meanwhile experiments with real apps (like Figma) show significant improv…

Let me clarify things one last time . You are obviously very passionate and I believe that nothing I can write will convince you, so I will not pursue this conversation with you after this post. For the same reason, my answers here are for people who have not followed the original HN thread in which we have already had most of this conversation. I also believe that the best way for you to demonstrate that another app…

I may be mistaken, but I believe Adobe had to ship an Actionscript 2 runtime forever because they completely replaced it when they introduced AS3. They needed to keep the flash player backwards compatible, so the player had to have both runtimes. While it worked, it was a kludge.

Re: Towards a JavaScript Binary AST

#149

Post by Yoric »

s3th wrote: post #140

i'm very skeptical about the benefits of a binary JavaScript AST. The claim is that a binary AST would save on JS parsing costs. however, JS parse time is not just tokenization. For many large apps, the bottleneck in parsing is instead in actually validating that the JS code is well-formed and does not contain early errors. The binary AST format proposes to skip this step [0] which is equivalent to wrapping function…

Early benchmarks seem to support the claim that we can save a lot on JS parsing costs.

We are currently working on a more advanced prototype on which we will be able to accurately measure the performance impact, so we should have more hard data soon.

Re: Towards a JavaScript Binary AST

#150

Post by syg »

s3th wrote: post #146
syg wrote: post #145

Earlier quoted context omitted.

Early error behavior is proposed to be deferred (i.e. made lazy), not skipped. Additionally, it is one of many things that require frontends to look at every character of the source. I contend that the text format for JS is no way easy to implement or extend, though I can only offer my personal experience as an engine hacker.

If early error is deferred then it's no longer early... that's all I meant by skipped. It still is a semantic change that's unrelated to a binary AST.

Indeed it's a semantic change. Are you saying you'd like that change to be proposed separately? That can't be done for the text format for the obvious compat reasons. It also has very little value on its own, as it is only one of many things that prevents actually skipping inner functions during parsing.
Post reply on HN