Yoric - the Binary AST size comparisons in the blog - was the original javascript already minified?
Towards a JavaScript Binary AST
81–90 of 211 posts
Re: Towards a JavaScript Binary AST
#82This 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…
Another mechanism created to do something similar to versioning was strict mode.
Re: Towards a JavaScript Binary AST
#83Yoric - the Binary AST size comparisons in the blog - was the original javascript already minified?
On our sample, x0.95 for minified code (so that's a 5% improvement) and ~x0.3 for non-minified code.
As usual, read these numbers with a pinch of salt, they are bound to change many times before we are done.
Re: Towards a JavaScript Binary AST
#84Earlier quoted context omitted.
> 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.
Please do not disparage an entire committee because you disagree philosophically with one proposal in it.
Re: Towards a JavaScript Binary AST
#85Earlier 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.
I don't know of anyone working on it, exactly because it is so difficult. So, while it might happen eventually, I don't think that anyone can provide an ETA at this stage.
Re: Towards a JavaScript Binary AST
#86For 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]".
Re: Towards a JavaScript Binary AST
#87Yoric - the Binary AST size comparisons in the blog - was the original javascript already minified?
On our sample, x0.95 for minified code (so that's a 5% improvement) and ~x0.3 for non-minified code. As usual, read these numbers with a pinch of salt, they are bound to change many times before we are done.
Does BinJS perform AST transforms like `!0` to `true` which would be shorter in binary AST encoding? Or does it faithfully model the original code?
Re: Towards a JavaScript Binary AST
#88Earlier quoted context omitted.
Probably unlikely. Watch binary AST blaze through whatever passes for "process" at TC39 though.
Please do not disparage an entire committee because you disagree philosophically with one proposal in it.
I don't disagree with just one proposal. I disagree with multiple proposals and the committee's approach to the "process".
Re: Towards a JavaScript Binary AST
#89It's really exciting that this would mean smaller files that parse faster, but also more readable!
Re: Towards a JavaScript Binary AST
#90Can you work on webpack instead?