21–30 of 211 posts
Earlier quoted context omitted.
Well, it's more "compressed JavaScript" than "compiled JavaScript".
It's not. It's a binary representation of JS. Basically directly competing with WebAssembly. What happens a year from now when WebAssembl gets support for GC and modules?
with an AST you can visualise code in ways other than text, and also reformat code like in go-fmt.
Indeed. That's not one of the main goals of the project, but I hope that standardizing the AST will help a lot with JS tooling, including code visualisation.
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…
Compiled C is not going to go away any sooner than interpreted Javascript - but a widening of the options available is great as it allows us to focus on developing things quickly and correctly, rather than making decisions based on which particular annoyance you're happy to put up with.
Earlier quoted context omitted.
> So, your article is FUD in it's purest undistilled form. The article is just reiterating an argument that Mozilla and Facebook made. If you’re saying Mozilla and Facebook are spreading Fear Uncertainty and Doubt with their proposal for a binary JS AST, then you may do so, but please realize that they probably had good reasons to start such a project. EDIT: Even though I disagree with the parent, it is making some g…
"If big boys do it, it must be right" is a feeble argument
Does anyone know the actual spec for this binary AST can be found? In particular I'm curious about the format of each node type.
If you wish to follow the development of the reference implementation, you can find it here: https://github.com/Yoric/binjs-ref/ . It's very early and the format will change often as we
1/ fix bugs;
2/ remove debugging info;
3/ start working seriously on compression;
4/ optimize.
Earlier quoted context omitted.
Indeed. That's not one of the main goals of the project, but I hope that standardizing the AST will help a lot with JS tooling, including code visualisation.
I want to see a code editor that represent common programming language concepts such as classes, functions (OO) in a graphical way and displays the rest in text.
This 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…
Behold one of the implementational details that emerged out of this language that was indeed "designed in 2 weeks":
...
...
...
...
...
...
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 JavaScript.
These include:
+-----------------------------------------------------+
| text/javascript | text/ecmascript |
| text/javascript1.0 | text/javascript1.1 |
| text/javascript1.2 | text/javascript1.3 |
| text/javascript1.4 | text/javascript1.5 |
| text/jscript | text/livescript |
| text/x-javascript | text/x-ecmascript |
| application/x-javascript | application/x-ecmascript |
| application/javascript | application/ecmascript |
+-----------------------------------------------------+
> JavaScript versions
> There have been several formal versions of JavaScript.
> 1.0: Netscape 2
> 1.1: Netscape 3 and Explorer 3 (the latter has bad JavaScript support, regardless of its version)
> 1.2: Early Version 4 browsers
> 1.3: Later Version 4 browsers and Version 5 browsers
> 1.4: Not used in browsers, only on Netscape servers
> 1.5: Current version.
> 2.0: Currently under development by Brendan Eich and others.
The link above points to a bit of interesting general discussion about versioning, and isn't as dense as the RFC.
Earlier quoted context omitted.
It's not. It's a binary representation of JS. Basically directly competing with WebAssembly. What happens a year from now when WebAssembl gets support for GC and modules?
Please don't tell me what the project is, I'm the tech lead :)
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 improvements with WebAssembly
- No one wants to ship bytecode
False
- it's hard to align browsers on bytecode
See WebAssembly
- you can't change bytecode once it's shipped
You can, eventually. Same argument can be applied to binary AST
- WebAssembly not supported by tools
Neither is binary AST. Meanwhile one of the goals of WebAssembly is tool support, readability etc.
There were other claims just as easily falsified, and yet dismissed out of hand.
So. What are you going to do with JS AST when WebAssembly gets support for JS?
Earlier quoted context omitted.
"If big boys do it, it must be right" is a feeble argument
You're obviously passionate about this; I'd personally be interested in seeing some more concrete points detailing exactly why this is bad.
I'd like to see why it is good, given efforts with WebAsembly