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

31–40 of 211 posts

Re: Towards a JavaScript Binary AST

#31

Post by Yoric »

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.

We're working towards experimenting this. For the moment, benchmarks suggest that this will be noticeable after 1 or 2Mb of code.

We'll only know for sure once we can start testing in real conditions, though.

Re: Towards a JavaScript Binary AST

#32

Post by le-mark »

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 use this format as a template for my own writing. Thanks!

Personally, I don't see the appeal for such a thing, and seems unlikely all browsers would implement it. It will be interesting to see how it works out.

Re: Towards a JavaScript Binary AST

#33

Post by pjmlp »

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…

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

Re: Towards a JavaScript Binary AST

#34

Post by slackingoff2017 »

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 best of both worlds. Easy to compile, easy to decompile, platform agnostic, compact code, and fast if it needs to be

Re: Towards a JavaScript Binary AST

#35

Post by lj3 »

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.

Re: Towards a JavaScript Binary AST

#36

Post by goatlover »

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…

It's not optimal for things like embedded, device drivers, high performance computing, etc. So I doubt everything will settle there. There will always be situations where C/Rust/Fortran are better choices.

Re: Towards a JavaScript Binary AST

#37

Post by le-mark »

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…

Software development is fad driven, I think a lot or most people would agree with this. I myself find this to be lamentable. But over the years I've asked myself, why is this the case? I mean it has been faddish for years, this isn't new in the current era.

I think there are two main drivers for fad-ism in software. One is we as developers, are required to chase the popular languages and frameworks to stay current, marketable, and employable. So there is always a sense of "what do I have to learn next, so I can switch jobs succesfully when I need to". Another driver is, developers seek to gain experience by re-doing things from the past. Example, creating new languages, or compiler for an existing language, provides inexperience developers with fantastic new experiences and knowledge. This is desirable.

So yeah, we got fads, and us old timers, or not so old timers with a historical perspective, watch our lawns, but everyone has to learn somehow. Ideally a lot of this would come from an apprenticeship/journeyman system, or a University degree of some sort. But for now it's all we have.

Re: Towards a JavaScript Binary AST

#39

Post by goatlover »

ryanong wrote: post #4

This is some amazing progress, but reading this and hearing how difficult JavaScript is as a language to design around makes me wonder how many hours have we spent optimizing a language designed in 2 weeks and living with those consequences. I wish we could version our JavaScript within a tag somehow so we could slowly deprecate code. I guess that would mean though browsers would have to support two languages that wo…

Brendan Eich was on a podcast in 2016 talking about the origins and evolution of JS. At one point he and the ECMA team wanted to make == strict equality, but then that would have required specifying the JS version, and Microsoft didn't like that, so they decided to go with === and leave == non-strict.

It's one of several cases where backward compatibility on the web trumped cleaning up the language.

Re: Towards a JavaScript Binary AST

#40

Post by goatlover »

pjmlp wrote: post #33
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…

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.
Post reply on HN