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

201–210 of 211 posts

Re: Towards a JavaScript Binary AST

#201

Post by hashseed »

sltkr wrote: post #172
iainmerrick wrote: post #168

This article says "Wouldn’t it be nice if we could just make the parser faster? Unfortunately, while JS parsers have improved considerably, we are long past the point of diminishing returns." I'm gobsmacked that parsing is such a major part of the JS startup time, compared to compiling and optimizing the code. Parsing isn't slow! Or at least it shouldn't be. How many MBs of Javascript is Facebook shipping? Does anyon…

I think the main issue with parsing is that you probably need to parse all JavaScript before you can start executing any of it. That might lead to a high delay before you can start running scripts. Compiling and optimizing code can be slow, too, but JIT compilers don't optimize all code that's on a page. At least at first, the code gets interpreted, and only hot code paths are JIT compiled, probably in a background t…

Chrome already caches compile result for previously visited pages to bypass the initial parsing/compiling.

Re: Towards a JavaScript Binary AST

#202

Post by nly »

c-smile wrote: post #196
limeblack wrote: post #187

Earlier quoted context omitted.

I have never been a fan of the => syntax. Although that really isn't the point. What about the syntax slows parsing?

As I said original JS syntax is pretty simple - parsing is comparable with just scanning source buffer char by char. Not too much different from HTML and CSS. Where 99% of time takes actual DOM creation. Like this XML/HTML scanner that I did while ago: https://www.codeproject.com/Articles/14076/Fast-and-Compact-... - it as fast as access to memory of HTML source. It even does not allocate any memory while parsing.

What you're describing is a recognizer, not a parser. A parser by definition produces some output other than a boolean 'yes, this is a syntactically correct HTML/JS input' (which is still more useful than what a tokenizer/scanner gives you, which is 'yes, this thing contains only HTML/JS tokens and here they are...splat')

Re: Towards a JavaScript Binary AST

#203

Post by dmitriid »

orf wrote: post #136
dmitriid wrote: post #76

Earlier quoted context omitted.

> in which we have already had most of this conversation. Interestingly enough, nowhere do you even mention these conversations in your attempts to push binary AST as hard as possible. > Consequently, should such a compilation take place, I suspect that this would considerably increase the size of the file and the parsing duration; Emphasis above is mine. However, it's presented (or was presented) by you as a fact. >…

Regardless of all your points, the fact is that WASM isn't ready for this now , and doesn't appear that it will be for some time. Combined with the fact, as mentioned above, that DOM access is significantly slower means that WASM isn't a suitable candidate. This is something you forgot to mention or take into account in your comment, for some reason. Yes this does seem to overlap a bit with wasm as you have noted, bu…

> Regardless of all your points, the fact is that WASM isn't ready for this now

As opposed to Binary AST which as available now? :)

> Combined with the fact, as mentioned above, that DOM access is significantly slower

Given that DOM access for WASM currently happens via weird interop through JavaScript (if I'm not mistaken) how is this a fact?

> "well we could get this optimization but we need to wait several years until this highy complex other spec is completely finished" doesn't seem as good.

No. My point is: "Let's for once make a thing that is properly implemented, and not do a right here right now short-sighted short-range solution"

That's basically how TC39 committee operates these days: if something is too difficult to spec/design properly, all work is stopped and half-baked solutions are thrown in "because we need something right now".

> Why not do this, and use wasm when it's available? Why can't you have both?

Because this means:

- spreading the resources too thin. There is a limited amount of people who can do this work

- doing much of the work twice

- JS VM implementors will have to support text-based parsing (for older browsers), new binary AST and WASM

Re: Towards a JavaScript Binary AST

#204

Post by orf »

dmitriid wrote: post #203
orf wrote: post #136

Earlier quoted context omitted.

Regardless of all your points, the fact is that WASM isn't ready for this now , and doesn't appear that it will be for some time. Combined with the fact, as mentioned above, that DOM access is significantly slower means that WASM isn't a suitable candidate. This is something you forgot to mention or take into account in your comment, for some reason. Yes this does seem to overlap a bit with wasm as you have noted, bu…

> Regardless of all your points, the fact is that WASM isn't ready for this now As opposed to Binary AST which as available now? :) > Combined with the fact, as mentioned above, that DOM access is significantly slower Given that DOM access for WASM currently happens via weird interop through JavaScript (if I'm not mistaken) how is this a fact? > "well we could get this optimization but we need to wait several years u…

> how is this a fact?

... because DOM access is significantly (10x) slower? That alone rules out your approach right now, regardless of the other points raised.

> Because this means: ...

When you understand how weak these arguments are you will understand the negative reaction to your comments on this issue.

You're clearly very passionate about this issue but you don't seem to be assessing the trade offs. Having something right now and iterating on it is better than waiting an indeterminate amount of time for a possible future solution involving an overlapping but otherwise unrelated specification that has not been fully implemented by anyone to a satisfactory point, and one with very complex technical issues blocking its suitability.

Sure, it would be nice to use WASM for this, but it is in no way needed at all. Given the status of WASM and the technical issues present with using it in this way it is odd to champion it to such a degree.

It seems your entire arguments boil down to "WASM may be OK to use at some point in the future, stop working on this and wait!". I, and I'm assuming others, don't see this as a very convincing point.

If I may, I'd offer some advice: stop taking this issue to heart. Time will tell if you're right, and making borderline insulting comments to the technical lead of the project in an attempt to push your position doesn't help anyone.

The world is heating up and species are dying, there are much better causes to take to heart.

Re: Towards a JavaScript Binary AST

#205

Post by chr1 »

Yoric wrote: post #199
limeblack wrote: post #188

Could the AST be made an extension of the language similar to how it works in Mathematica?

What do you mean? How does it work in Mathematica?

Mathematica has several representations for the code the main one is the inputForm, the thing that users type in, and there is a fullForm which is the full ast, and there is a way to manipulate it to create new functions on the fly (or really any other objects, like graphic or sound, since everything in Mathematica is represented in a uniform way)

For instance if in input form you have {1 + 1, 2 *3 }, in fullForm this becomes List[Plus[1,1], Times[2, 3]], which is the readable version of lisp and internally represented the same way [List [Plus 1 1] [Times 2 3]].

The fullForm is accessible from the language, and can be manipulated using standard language feature, kind of like eval but better.

It would be really cool to have something like this in javascript, but unfortunately looks like javascript tools tend to create nonuniform ast, that is hard to traverse and manipulate

Re: Towards a JavaScript Binary AST

#206

Post by slackingoff2017 »

pjmlp wrote: post #118
Yoric wrote: post #92

Earlier quoted context omitted.

Didn't they use to have a IL interpreter, back in the days? Or was it already a compiler-maskerading-as-an-interpreter?

No, .NET never had an interpreter phase like the JVM. Which actually can be configured to always JIT as well. The majority of JVMs have a non-standard flag that allows to configure how the interpreter, JIT or if supported AOT compiler work together.

This is interesting to know, thanks.

Re: Towards a JavaScript Binary AST

#207

Post by [deleted] »

batmansmk wrote: post #155
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…

Webassembly is pretty much a greenfield approach: you need to learn C, redo your whole codebase and still write JS code to load your wasm, interact with DOM and browser APIs, and leverage existing good enough JS libraries. This is the state of things as of 2017. It took 4 years to reach that point. If you want to bet everything on the state of wasm in 2-3 years from now, please be my guest. Meanwhile, I have a busine…

[deleted]

Re: Towards a JavaScript Binary AST

#208

Post by Yoric »

lomnakkus wrote: post #183
Yoric wrote: post #106

Earlier quoted context omitted.

The tracker on which you're posting is a good place, thanks a lot :)

Off-topic: I'm sorry to go a little squishy, but I thought I should say that I appreciate the work both of you do very much... though sjrd's work is a little bit more "direct-impact-for-me" at the moment, I must admit. :p Of course, as you just both said, your work is kind of complementary... which is always nice. :) Anyway, thanks for the long-term thinking to the both of you.

thanks :)

Re: Towards a JavaScript Binary AST

#209

Post by Yoric »

hashseed wrote: post #201
sltkr wrote: post #172

Earlier quoted context omitted.

I think the main issue with parsing is that you probably need to parse all JavaScript before you can start executing any of it. That might lead to a high delay before you can start running scripts. Compiling and optimizing code can be slow, too, but JIT compilers don't optimize all code that's on a page. At least at first, the code gets interpreted, and only hot code paths are JIT compiled, probably in a background t…

Chrome already caches compile result for previously visited pages to bypass the initial parsing/compiling.

So does Firefox, btw.

This is addressed here: https://yoric.github.io/post/binary-ast-newsletter-1/#improv...

Re: Towards a JavaScript Binary AST

#210

Post by Yoric »

chr1 wrote: post #205
Yoric wrote: post #199

Earlier quoted context omitted.

What do you mean? How does it work in Mathematica?

Mathematica has several representations for the code the main one is the inputForm, the thing that users type in, and there is a fullForm which is the full ast, and there is a way to manipulate it to create new functions on the fly (or really any other objects, like graphic or sound, since everything in Mathematica is represented in a uniform way) For instance if in input form you have {1 + 1, 2 *3 }, in fullForm thi…

For the moment, we're not trying to make the AST visible to the language although this would definitely be interesting.

The "recommended" manner to manipulate the AST these days is to use e.g. Babel/Babylon or Esprima. I realize that it's not as integrated as what you have in mind, of course, but who knows, maybe a further proposal one of these days?

Post reply on HN