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

101–110 of 211 posts

Re: Towards a JavaScript Binary AST

#101

Post by rpeden »

le-mark wrote: post #37
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, m…

To me, software development seems as tribal as politics. People tend to like and agree with those in their own tribe, and tend to see criticism of their tribe's preferred ideology as an attack on their identity.

There's a lot of pressure to be part of a popular tribe, and so you see situations where even a mild criticism of, for example, the a piece of the JavaScript tribe's technology (like, say, npm or Webpack) tends to elicit vitriolic responses and counter arguments.

You can sometimes get away with this kind of criticism if you choose your words carefully and make it very clear (or at least pretend to) that you're actually a member of the tribe you're criticizing, and that your criticism is meant to be constructive. So you say something like 'I use npm, and I like it, but here's where I struggle with it and here's how I'd improve it'. But if you just write about why you dislike it, you're likely to be flamed and criticized, even if everything you wrote verifiably correct.

So I find that watching programmers argue in blogs and on HN and Reddit feels a lot like reading political arguments on Reddit, or Facebook. And maybe that's why programming tends to be faddish. Each tribe is mostly only aware of its own history; there's no real shared sense of culture, or much awareness of the rich shared history that got us to where we are today. And so you see lots of wheel reinvention, as people poorly re-solve problems that were already solved long ago by other programming tribes.

These are just my personal observations, though. I could very well be completely wrong. :)

Re: Towards a JavaScript Binary AST

#102

Post by Yoric »

malts wrote: post #96
Yoric wrote: post #94

Earlier quoted context omitted.

It faithfully models the original code. The idea is that if you want to transform `!0` to `true`, or if you want to obfuscate, etc. you can always plug an additional tool.

The 5% gains over minified code are impressive given that BinJS performs no AST manipulation. The BinJS prototype will be written in pure javascript I assume to speed its adoption?

For the moment, it's JS + Rust, because Rust is better than JS when you keep refactoring Big Hairy Data Structures. However, once the data structures stabilize we're planning to shift it entirely to JS.

Re: Towards a JavaScript Binary AST

#103

Post by sjrd »

Yoric wrote: post #98
sjrd wrote: post #93

Earlier quoted context omitted.

This is a very good point. I would also add that there are a lot of languages compiling to JavaScript that would similarly not benefit from wasm. Right now, pretty much all GC-ed languages compiling to JS (such as ClosureScript, Elm, Scala.js, BuckleScript, PureScript, etc.) are in that category. Even if/when wasm supports GC in the future, I expect that dynamically typed languages compiling to JS will still be a lon…

For context: position mapping is somewhere on our radar, but we haven't reached a stage at which it would make sense to start working on it yet. If you have ideas and/or spare cycles, of course, they are welcome :) As a side-note: I believe that we could build upon the (very early) proposed mechanism for comments to also store positions. Size-optimized BinAST files would drop both comments and positions, while debugg…

That seems awesome. I'm glad that it's on your radar.

If you can point me to the best place to suggest ideas or spend my spare cycles, I would gladly do so. At the very least, I can comment on how we serialize positions in the (tree-based) Scala.js IR, which is size-optimized.

Re: Towards a JavaScript Binary AST

#104

Post by Yoric »

_wmd wrote: post #95
mnarayan01 wrote: post #86

For those curious about how this would deal with Function.prototype.toSource, via https://github.com/syg/ecmascript-binary-ast#functionprototy... : > This method would return something like "[sourceless code]".

It seems this would break a number of libraries (can't name one, but certain I've seen it), although per the article it would be a simple affair for the browser to reify the encoded AST into a compatible representation, especially if comments are also eventually preserved (per article its on the roadmap)

It would be interesting to find any library that actually depends on that. There used to be some, but I haven't seen any in years.

If you do find one, please feel free to add a comment on the blog or one of the trackers :)

Re: Towards a JavaScript Binary AST

#106

Post by Yoric »

sjrd wrote: post #103
Yoric wrote: post #98

Earlier quoted context omitted.

For context: position mapping is somewhere on our radar, but we haven't reached a stage at which it would make sense to start working on it yet. If you have ideas and/or spare cycles, of course, they are welcome :) As a side-note: I believe that we could build upon the (very early) proposed mechanism for comments to also store positions. Size-optimized BinAST files would drop both comments and positions, while debugg…

That seems awesome. I'm glad that it's on your radar. If you can point me to the best place to suggest ideas or spend my spare cycles, I would gladly do so. At the very least, I can comment on how we serialize positions in the (tree-based) Scala.js IR, which is size-optimized.

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

Re: Towards a JavaScript Binary AST

#107

Post by markdog12 »

lj3 wrote: post #99
markdog12 wrote: post #71

Earlier quoted context omitted.

Mozilla and others had pretty strong technical objections to Native Client. Context matters (sometimes :))

Oh, I think I misunderstood you. You mean the AST is going to go the way of Native Client because Mozilla doesn't have the muscle it used to? Or do you think Google's going to sandbag it as revenge for Native Client? :)

Sorry, to clarify:

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

When I replied "Native Client", I was giving an example where Chrome came out with something the other browser vendors rejected on technical grounds.

I love this development (Binary AST) and hope it's adopted.

Re: Towards a JavaScript Binary AST

#108

Post by Yoric »

Yoric wrote: post #31
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.

I should have mentioned "1 or 2Mb of code on an average-ish computer".

Re: Towards a JavaScript Binary AST

#109

Post by lj3 »

romaniv wrote: post #56
lj3 wrote: post #44

Earlier quoted context omitted.

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 decad…

There is a serious problem when every new generations of a technology fixates on some problem of its choice and ignores all the others. The issue of binary blobs didn't go away. What changed is that a lot of developers today don't care about the open nature of the web and are perfectly fine with sacrificing it for faster load times of their JS-saturated websites. I think a much better approach to this pronblem would…

> What changed is that a lot of developers today don't care about the open nature of the web and are perfectly fine with sacrificing it for faster load times of their JS-saturated websites.

I'm one of those developers who couldn't care less about the 'open nature of the web'. I understood the necessity of it to the early, emerging internet, but times have changed. Now that we have secure sandboxes and the web is choking on its own bloat, it's time to shift back to binary blobs.

Re: Towards a JavaScript Binary AST

#110

Post by romaniv »

Yoric wrote: post #79
romaniv wrote: post #56

Earlier quoted context omitted.

There is a serious problem when every new generations of a technology fixates on some problem of its choice and ignores all the others. The issue of binary blobs didn't go away. What changed is that a lot of developers today don't care about the open nature of the web and are perfectly fine with sacrificing it for faster load times of their JS-saturated websites. I think a much better approach to this pronblem would…

So, just to clarify: this is what the JavaScript Binary AST is aiming for. We are not working on the negotiation part for the moment, because that's not part of the JS VM, but this will happen eventually.

That's good to hear. Apparently I jumped all the important parts when skimming the article. Appreciate the clarification here.
Post reply on HN