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

151–160 of 211 posts

Re: Towards a JavaScript Binary AST

#151

Post by dblohm7 »

Yoric wrote: post #68
MadcapJake wrote: post #41

Earlier quoted context omitted.

How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling. To be fair, these two concepts are similar and I may be totally misunderstanding what this project is about. In th…

> How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling. I am not sure but there may be a misunderstanding on the word "binary". While the word "binary" is often used to…

Posting this in the hope that it might help some people grok what they are actually doing:

When I first discovered what Yoric and syg were doing, the first thing that I thought of was old-school Visual Basic. IIRC when you saved your source code from the VB IDE, the saved file was not text: it was a binary AST.

When you reopened the file in the VB6 IDE, the code was restored to text exactly the way that you had originally written it.

Re: Towards a JavaScript Binary AST

#152

Post by kannanvijayan »

apaprocki wrote: post #51

From an alternate "not the web" viewpoint, I am interested in this because we have a desktop application that bootstraps a lot of JS for each view inside the application. There is a non-insignificant chunk of this time spent in parsing and the existing methods that engines expose (V8 in this case) for snapshotting / caching are not ideal. Given the initial reported gains, this could significantly ratchet down the par…

Yoric is working on a "proper" implementation and I'll be assisting in the design work, and if needs be some implementation. I think the next milestone here is a working demo in Firefox with Facebook page load.

At a personal level, I feel pretty confident that BinaryJS will help your case. The theory behind the gains was pretty solid before we designed the prototype. The prototype, for me, basically proved the theory.

My personal hope is that by the time we're done squeezing all we can out of this - which includes zero-costing lazy function parsing, and on-line bytecode generation, we can cut the "prepare for execution" time by 80%.

Re: Towards a JavaScript Binary AST

#153

Post by pier25 »

Akkuma wrote: post #121
pier25 wrote: post #116

Earlier quoted context omitted.

But couldn't other languages also compile to this binary AST too?

Sure, why not? The difference is that WASM is aiming for near native performance of code, while the binary JS would still be limited to JS performance.

Yes, but it would have access to DOM, GC, etc.

Re: Towards a JavaScript Binary AST

#154

Post by nfriedly »

pier25 wrote: post #116
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…

But couldn't other languages also compile to this binary AST too?

Yes, and for anything that already compiles to JS, adding this as an additional target shouldn't be too much work.

However, for anything that doesn't already compile to JS, this is essentially the same amount of work as targeting regular JavaScript. In that case, the work might be better spent making it compile to WASM. But, that's not a hard and fast rule, it really depends on the situation. And, of course, it could always target both.

Re: Towards a JavaScript Binary AST

#155

Post by batmansmk »

dmitriid wrote: post #29
Yoric wrote: post #21

Earlier quoted context omitted.

Please don't tell me what the project is, I'm the tech lead :)

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 business to run.

The binary AST is a quick win for brownfield technology, with already a working version in an experimental Firefox build. It can be rolled quite fast. It improves right now the experience of many users on existing codebase the same way minification did. And improve the experience of current web assembly, as it is still largely dependent on the speed of JS. I'll take this feature any day.

Re: Towards a JavaScript Binary AST

#156

Post by Yoric »

dblohm7 wrote: post #151
Yoric wrote: post #68

Earlier quoted context omitted.

> How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling. I am not sure but there may be a misunderstanding on the word "binary". While the word "binary" is often used to…

Posting this in the hope that it might help some people grok what they are actually doing: When I first discovered what Yoric and syg were doing, the first thing that I thought of was old-school Visual Basic. IIRC when you saved your source code from the VB IDE, the saved file was not text: it was a binary AST. When you reopened the file in the VB6 IDE, the code was restored to text exactly the way that you had origi…

Interesting. Do you know of any technical documentation on the topic?

Re: Towards a JavaScript Binary AST

#157

Post by MadcapJake »

Yoric wrote: post #68
MadcapJake wrote: post #41

Earlier quoted context omitted.

How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling. To be fair, these two concepts are similar and I may be totally misunderstanding what this project is about. In th…

> How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling. I am not sure but there may be a misunderstanding on the word "binary". While the word "binary" is often used to…

> Here, "binary" simply means "not text", just as for instance images or zipped files are binary.

If it's not text, then what is it? I'm not sure "not text" is a good definition of the word "binary".

> A compiler typically goes from a high-level language to a lower-level language, losing data.

I don't agree, I don't think there is any loss in data, the compiled-to representation should cover everything you wanted to do (I suppose not counting tree-shaking or comment removal).

> I prefer calling this a compression mechanism, insofar as you can decompress without loss (well, minus layout and possibly comments).

Ahh, so you mean without losing the original textual representation of the source file.

> Wasm is about native code

Here you are making claims about their project that are just not the whole picture. Here's the one-line vision from their homepage[1]:

> WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.

With that description in mind, how do you see BinAST as different?

> Well, we're trying to solve a different problem :)

I think you might be misunderstanding what wasm is intended for. Here's a blurb from the wasm docs that is pertinent:

> A JavaScript API is provided which allows JavaScript to compile WebAssembly modules, perform limited reflection on compiled modules, store and retrieve compiled modules from offline storage, instantiate compiled modules with JavaScript imports, call the exported functions of instantiated modules, alias the exported memory of instantiated modules, etc.

The main difference I can gather is that you are intending BinAST to allow better reflection on compiled modules than wasm intends to support.

Here's another excerpt from their docs (and others have mentioned this elsewhere):

> Once GC is supported, WebAssembly code would be able to reference and access JavaScript, DOM, and general WebIDL-defined objects.

[1]: http://webassembly.org/

[META: Wow, I thought downvotes were for negative or offtopic comments]

Re: Towards a JavaScript Binary AST

#158

Post by MadcapJake »

MadcapJake wrote: post #157
Yoric wrote: post #68

Earlier quoted context omitted.

> How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling. I am not sure but there may be a misunderstanding on the word "binary". While the word "binary" is often used to…

> Here, "binary" simply means "not text", just as for instance images or zipped files are binary. If it's not text, then what is it? I'm not sure "not text" is a good definition of the word "binary". > A compiler typically goes from a high-level language to a lower-level language, losing data. I don't agree, I don't think there is any loss in data, the compiled-to representation should cover everything you wanted to…

Ok I am understanding the distinction now.

I ran a google search for "js to wasm" and found a ticket on the webassembly github that explained it all: https://github.com/WebAssembly/design/issues/219

Re: Towards a JavaScript Binary AST

#159

Post by Yoric »

MadcapJake wrote: post #158
MadcapJake wrote: post #157

Earlier quoted context omitted.

> Here, "binary" simply means "not text", just as for instance images or zipped files are binary. If it's not text, then what is it? I'm not sure "not text" is a good definition of the word "binary". > A compiler typically goes from a high-level language to a lower-level language, losing data. I don't agree, I don't think there is any loss in data, the compiled-to representation should cover everything you wanted to…

Ok I am understanding the distinction now. I ran a google search for "js to wasm" and found a ticket on the webassembly github that explained it all: https://github.com/WebAssembly/design/issues/219

Thanks for the link, it will certainly prove useful in the future.
Post reply on HN