with an AST you can visualise code in ways other than text, and also reformat code like in go-fmt.
Towards a JavaScript Binary AST
11–20 of 211 posts
Re: Towards a JavaScript Binary AST
#12> By design, however, wasm is limited to native code, so it doesn’t work with JavaScript out of the box. By design of the first MVP iteration. http://webassembly.org/roadmap/ and http://webassembly.org/docs/future-features/ GC (which is the main major feature required for JavaScript) is in progress , https://github.com/WebAssembly/design/issues/1079 So, your article is FUD in it's purest undistilled form.
Yes, dmitriid, I believe it's clear by now that you don't like this project.
As I mentioned in another conversation, if you feel you can contribute to Wasm and make it solve the problems we are solving here, this is great, by all means, please do so.
In the meantime, we are going to continue trying to solve some of the performance problems of the web using the techniques discussed in the blog entry because we are convinced that they are going to work better.
Re: Towards a JavaScript Binary AST
#13So, 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…
parsed (+compressed), not compiled.
Parsing is unavoidable, regardless if the code is interpreted or compiled. This proposal seems to further compress the AST somehow.
Basically the idea is to already preprocess the text source, so that the client can skip two steps on execution: lexical analysis and the parsing of the text source resulting in the AST. The post explains why the authors believe that this is a good idea.
Re: Towards a JavaScript Binary AST
#14So, 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…
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?
Re: Towards a JavaScript Binary AST
#15So, 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…
Well, it's more "compressed JavaScript" than "compiled JavaScript".
Something we badly need, I greatly appreciate the effort!
Re: Towards a JavaScript Binary AST
#16This is a really interesting project from a browser technology point of view. It makes me wonder how much code you'd need to be deploying to for this to be useful in a production environment. Admittedly I don't make particularly big applications but I've yet to see parsing the JS code as a problem, even when there's 20MB of libraries included.
Re: Towards a JavaScript Binary AST
#17> By design, however, wasm is limited to native code, so it doesn’t work with JavaScript out of the box. By design of the first MVP iteration. http://webassembly.org/roadmap/ and http://webassembly.org/docs/future-features/ GC (which is the main major feature required for JavaScript) is in progress , https://github.com/WebAssembly/design/issues/1079 So, your article is FUD in it's purest undistilled form.
Yes, dmitriid, I believe it's clear by now that you don't like this project. As I mentioned in another conversation, if you feel you can contribute to Wasm and make it solve the problems we are solving here, this is great, by all means, please do so. In the meantime, we are going to continue trying to solve some of the performance problems of the web using the techniques discussed in the blog entry because we are con…
I find zero arguments in your comment except ad hominem attacks.
Re: Towards a JavaScript Binary AST
#18> By design, however, wasm is limited to native code, so it doesn’t work with JavaScript out of the box. By design of the first MVP iteration. http://webassembly.org/roadmap/ and http://webassembly.org/docs/future-features/ GC (which is the main major feature required for JavaScript) is in progress , https://github.com/WebAssembly/design/issues/1079 So, your article is FUD in it's purest undistilled form.
> 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
Re: Towards a JavaScript Binary AST
#19> By design, however, wasm is limited to native code, so it doesn’t work with JavaScript out of the box. By design of the first MVP iteration. http://webassembly.org/roadmap/ and http://webassembly.org/docs/future-features/ GC (which is the main major feature required for JavaScript) is in progress , https://github.com/WebAssembly/design/issues/1079 So, your article is FUD in it's purest undistilled form.
I haven't tracked WASM closely, so this is an honest question. Are you saying this comment is false? > I am not aware of any project that achieves compilation of JavaScript to wasm I.e., Javascript to WASM is on the roadmap and something we can use in the next few years? Or am I misunderstanding the situation?
I'm saying that the whole idea of this project is built on top of false assumptions, and any counterarguments are dismissed.
Re: Towards a JavaScript Binary AST
#20with 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.