JavaScript code is much more expensive, byte for byte, than an image, because of the time spent parsing and compiling it. It's possible to parse and compile wasm as fast as it comes over the network, which makes it much more like an image than JavaScript code. Game changer!
-
-
Yes, it's shipping today, but they are not interchangeable, so it still doesn't matter for most devs while binary AST could provide great benefits for everyone with little to no changes to stack. The shrug part sounds sad indeed.
-
I'm strongly in favor of binary-ast. Speak to your local browser representative (FF is already bought in, so you can move on to other browsers).
-
If only JavaScript proposals would be decided on http://uservoice.com or similar platform by entire community and not by vendors themselves...
-
It's called TC39. Plz join.
-
First, individuals can't join, only companies whose interests lie there. Second, even if I could, it would be still a group of interested parties (aka vendors), just with one more added. Still not the community as a whole.
-
When I joined I was community member #1. Now there's tons of people not from vendors. The more the merrier! The more from the community the more we can all push for features of interest to the community. binary-ast has a chance because of this factor.
-
Can you share more details? ~1 year ago I reached out to the Secretary General about attending as a community member & was informed that I HAD to be sponsored by a company. As a minor figure (to put it gently) in the community that wasn't going to happen.
End of conversation
New conversation -
-
-
Usually ASTs in compilers are highly unstable implementation details. It sounds like this will suffer one of two problems: 1) this AST is final, so now we have a fixed backend to target this IR and a separate one for other targets or...
-
2) the AST is just shipping the compiler design, which will just be a fight between all JS compilers to ship their AST, and no one will be happy
-
In JS land AST standard(s) for JS already exist and are generic enough. Same can be done for binary one between compilers.
-
The problems you're talking about could be applied to WASM format as well, and yet everyone collaborated on creating a single IR that can be translated to whatever's used internally.
-
I don't think this will be an issue for generic AST format either.
-
In particular: - the spec is already designed to evoke an AST - hiperf comes from later tiers - the JS compiler ecosystem has actively worked on some standardization - this problem wasn't a high order bit objection in TC39 when it came up (vs prioritization and "is it worth it")
-
I could be wrong about any of these assumptions, but I think the wins of binary are so large, that if we could get everyone to agree with the benefits, there'd be strong motivation to make it work. Cutting http://facebook.com parse time by 8x is no small thing.
-
Oh and I meant to say: Because of the likely debate around trying to standardize a whole new AST (both from impl and other stakeholders) the path of least resistance is to stick closely to the spec's representations at first. I think this is a good thing
- 1 more reply
New conversation -
-
-
In 12 months in beta + 12 months out, not a single player started making $ with wasm. Magic tech, no use case yet.
-
What does making $ mean?
-
$=Dollars, Money. Sorry! wasm ships in 68% of browsers, fallbacks to asmjs for the rest.. yet afaik, no company has shipped some core product with wasm.
-
Glimmer (the project I'm working on) is gonna ship wasm Q1 2018 if all goes well. It'll then be in Ember, which is in tons of products that make $. wasm->asm fallback has serious issues and is still our #1 blocker.
-
Great! I need to check your branch :)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.