On: Towards a JavaScript Binary AST

[lj3]

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.

[romaniv → lj3]

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 be a compression format that's designed specifically for JavaScript. It could still be negotiable, like GZIP, so anyone wanting to see the source would be able to see it. It could also be designed in a way that allows direct parsing without (full?) decompression.

[Yoric → romaniv]

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.

[romaniv → Yoric]

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

[lj3 → romaniv]

> 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.

[tree_of_item → lj3]

How does adding more code to the browser stack prevent the web from "choking on its own bloat"? You need to take things away to reduce bloat, not add them.

[goatlover → lj3]

But there has been Java Applets, Active X, Flash, and Silverlight.

[lj3 → goatlover]

And they all had crippling security problems[1]. I only mentioned the JVM, but you're right, all of those technologies contributed to the work of secure sandboxes.

[1]: Except maybe Silverlight. From what I remember, it didn't see enough success to be a tempting target for hackers.