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

41–50 of 211 posts

Re: Towards a JavaScript Binary AST

#41

Post by MadcapJake »

Yoric wrote: post #8
cabaalis wrote: post #6

So, compiled Javascript then? "We meet again, at last. The circle is now complete." The more I see interpreted languages being compiled for speed purposes, and compiled languages being interpreted for ease-of-use purposes, desktop applications becoming subscription web applications (remember mainframe programs? ), and then web applications becoming desktop applications (electron) the more I realize that computing is…

Well, it's more "compressed JavaScript" than "compiled JavaScript".

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 the spirit of fairness, let me test my understanding. You are saying wasm bytecode is one step too early and a true "machine code" format would be better able to improve performance (especially startup time). I'm not following wasm development, but from comments here I am gathering that wasm is too level and you want something that works on V8. Is that what this project is about?

On a side note, it's truly a testament to human nature that the minute we get close to standardizing on something (wasm), someone's gotta step up with another approach.

Re: Towards a JavaScript Binary AST

#42

Post by markdog12 »

lj3 wrote: post #35
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…

All they have to do is convince Google. Chrome's the king of the castle right now.

Native Client

Re: Towards a JavaScript Binary AST

#43

Post by lj3 »

slackingoff2017 wrote: post #34
cabaalis wrote: post #6

So, compiled Javascript then? "We meet again, at last. The circle is now complete." The more I see interpreted languages being compiled for speed purposes, and compiled languages being interpreted for ease-of-use purposes, desktop applications becoming subscription web applications (remember mainframe programs? ), and then web applications becoming desktop applications (electron) the more I realize that computing is…

I think everything will eventually settle in the middle where Java and C# currently live. They have an "intermediate code" that they somewhat compile down to. But this is really a more compact version of the source than a binary though. You can see this easily by running a decompiler. Often times the decompiled IL is almost identical to the source. And before the JIT kicks in the IL is typically interpreted. You get…

The Design of Everyday Things is instructive here. You don't design for the middle or the average. You design for the extreme edges. If you have a programming language that can be used both by absolute beginners who just want to learn enough programming to script their excel spreadsheet AND HFT traders who need to ring out every cycle of performance they can on every core they have at their disposal, then the middle will take care of itself.

Re: Towards a JavaScript Binary AST

#44

Post by lj3 »

cabaalis wrote: post #6

So, compiled Javascript then? "We meet again, at last. The circle is now complete." The more I see interpreted languages being compiled for speed purposes, and compiled languages being interpreted for ease-of-use purposes, desktop applications becoming subscription web applications (remember mainframe programs? ), and then web applications becoming desktop applications (electron) the more I realize that computing is…

Part of this is fad driven, but part of this is also driven by other human concerns. For example, had the early web been binary (like we're pushing for now) instead of plain text it would have died in its crib. Executing binary code sent blindly from a remote server without a sandbox is a security nightmare. Now that we have robust sandboxes, remote binary execution becomes a viable option again. But, it took a decade's worth of JVM R&D to get to this point.

Re: Towards a JavaScript Binary AST

#45

Post by robertkrahn01 »

jlebrech wrote: post #23
Yoric wrote: post #20

Earlier quoted context omitted.

Indeed. That's not one of the main goals of the project, but I hope that standardizing the AST will help a lot with JS tooling, including code visualisation.

I want to see a code editor that represent common programming language concepts such as classes, functions (OO) in a graphical way and displays the rest in text.

http://imgur.com/a/c7cNx

Re: Towards a JavaScript Binary AST

#47

Post by jlebrech »

robertkrahn01 wrote: post #45
jlebrech wrote: post #23

Earlier quoted context omitted.

I want to see a code editor that represent common programming language concepts such as classes, functions (OO) in a graphical way and displays the rest in text.

http://imgur.com/a/c7cNx

bit old school, but in that direction. yes

Re: Towards a JavaScript Binary AST

#48

Post by nfriedly »

onion2k wrote: post #16

This is a really interesting project from a browser technology point of view. It makes me wonder how much code you'd need to be deploying to for this to be useful in a production environment. Admittedly I don't make particularly big applications but I've yet to see parsing the JS code as a problem, even when there's 20MB of libraries included.

On a decently fast computer, you're right. On a low-end cell phone, 20MB of libraries will take a noticeable amount of time to parse.

Re: Towards a JavaScript Binary AST

#49

Post by nfriedly »

MadcapJake wrote: post #41
Yoric wrote: post #8

Earlier quoted context omitted.

Well, it's more "compressed JavaScript" than "compiled JavaScript".

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…

To quote the original post:

> If you prefer, this Binary AST representation is a form of source compression, designed specifically for JavaScript, and optimized to improve parsing speed.

Re: Towards a JavaScript Binary AST

#50

Post by pjmlp »

goatlover wrote: post #40
pjmlp wrote: post #33

Earlier quoted context omitted.

The JIT/AOT approach was already there in Xerox PARC systems in the 70's, oh well.

Imagine if Xerox Parc happened in the early 90s and we ended up with a Smalltalk web browser environment.

That is what on my ideal world ChromeOS should have been, but with Dart instead, unfortunately the ChromeOS team had other plans in mind and made it into a Chrome juggler OS.

I was using Smalltalk on some university projects, before Sun decided to rename Oak and announce Java to the world.

The development experience was quite good.

Similarly with Native Oberon, which captured many of the Mesa/Cedar workflows.

Post reply on HN