Earlier quoted context omitted.
Native Client
Firefox had a much higher market share than Chrome back then. Context matters.
Mozilla and others had pretty strong technical objections to Native Client. Context matters (sometimes :))
Towards a JavaScript Binary AST
71–80 of 211 posts
Re: Towards a JavaScript Binary AST
#72To 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…
Keywords: currently doesn't have GC, currently is for other languages.
Because, surprise, it's an MVP, and wok has already started to bring other languages (including JavaScript) to it.
So. The question is: one-two years from now, when there's support for wasm in javascript, where does it leave binary AST?
Re: Towards a JavaScript Binary AST
#73To 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…
Keywords: currently doesn't have GC, currently is for other languages. Because, surprise, it's an MVP, and wok has already started to bring other languages ( including JavaScript) to it. So. The question is: one-two years from now, when there's support for wasm in javascript, where does it leave binary AST?
> one-two years from now, when there's support for wasm in javascript
How likely is this to happen in the next 2 years? I thought it'd be a lot more difficult.
Re: Towards a JavaScript Binary AST
#74Lua has something very similar(bytecode vs AST) via luac for a long while now. We've used to to speed up parse times in the past and it helps a ton in that area.
I'm interested. Do you have a link?
Re: Towards a JavaScript Binary AST
#75Earlier quoted context omitted.
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.
> That is what on my ideal world ChromeOS should have been, but with Dart instead, That would have been very interesting. I liked Dart from the brief time I looked at it. The web still feels like a somewhat crippled platform to develop for.
> The web still feels like a somewhat crippled platform to develop for.
Which is why nowadays I always favour native development when given the option, in spite of having been a Web 1.0 enthusiastic developer.
Re: Towards a JavaScript Binary AST
#76Earlier quoted context omitted.
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…
Let me clarify things one last time . You are obviously very passionate and I believe that nothing I can write will convince you, so I will not pursue this conversation with you after this post. For the same reason, my answers here are for people who have not followed the original HN thread in which we have already had most of this conversation. I also believe that the best way for you to demonstrate that another app…
> in which we have already had most of this conversation.
Interestingly enough, nowhere do you even mention these conversations in your attempts to push binary AST as hard as possible.
> Consequently, should such a compilation take place, I suspect that this would considerably increase the size of the file and the parsing duration;
Emphasis above is mine. However, it's presented (or was presented) by you as a fact.
> What I claimed is that if we ended up with one-bytecode-per-browser or worse, one-bytecode-per-browser-version, the web would be much worse than it is. I stand by that claim.
We are ending up with one wasm bytecode for every browser, aren't we?
> as far as I know, browser vendors are not working together on standardizing a bytecode for the JavaScript language;
Because they are working together on standardizing bytecode for the web in general, aren't they?
> coming up with a bytecode for a language that keeps changing is really hard
So you're trying to come up with a binary AST for a language that keeps changing :-\
> keeping the language-as-bytecode and the language-as-interpreted in sync is really hard
What's the point of WebAssembly then?
> I do not think that anybody will start working on standardizing a bytecode for the JavaScript language.
Because that's not really required, is it? This is a non-goal, and never was the goal. The goal is to create an interoperable standardized bytecode (akin to JVM's bytecode or .Net's MSIL), not a "standardized bytecode for Javascript". For some reason you don't even want to mention this.
> I claimed that no browser vendor seriously contemplates exposing their internal bytecode format
They don't need to.
> Additionally, the JavaScript Binary AST is designed in such a manner that evolutions of the JavaScript language should not break existing parsers.
I shudder to think how rapidly changing languages like Scala, ClojureScript etc. can ever survive on the JVM. The horror!
> If/when that day arrives, I'll compare both approaches.
Basically you will end up with two representations of JS: a binary AST and a version that compiles to WASM. Oh joy. Wasn't this something you wanted to avoid?
Re: Towards a JavaScript Binary AST
#77Earlier quoted context omitted.
Keywords: currently doesn't have GC, currently is for other languages. Because, surprise, it's an MVP, and wok has already started to bring other languages ( including JavaScript) to it. So. The question is: one-two years from now, when there's support for wasm in javascript, where does it leave binary AST?
> one-two years from now, when there's support for wasm in javascript How likely is this to happen in the next 2 years? I thought it'd be a lot more difficult.
Probably unlikely. Watch binary AST blaze through whatever passes for "process" at TC39 though.
Re: Towards a JavaScript Binary AST
#78This 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…
> I wish we could version our JavaScript within a tag somehow Behold one of the implementational details that emerged out of this language that was indeed "designed in 2 weeks": ... ... ... ... ... ... https://tools.ietf.org/html/rfc4329 : 3. Deployed Scripting Media Types and Compatibility Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and Ja…
Yea I remember that versioning but few browsers implemented it.
Re: Towards a JavaScript Binary AST
#79Earlier 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…
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.
Re: Towards a JavaScript Binary AST
#80So, 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…
On .NET's case the IL is never interpreted, it is only a portable executable format.
It is either AOT compiled to native code via NGEN, Mono AOT, MDIL or .NET Native.
Or JITed on file load before actually executing the code.
The only .NET toolchain, from Microsoft, that actually does interpret IL it is .NET Micro Framework.
The idea of using bytecodes as portable execution formats goes back to mainframes, of which IBM AS/400's TIMI is the best known example.