131–140 of 211 posts
The linked article somehow avoids ever stating the meaning of the acronym, and I had to Google it myself, so I imagine some other people might not know: AST stands for "abstract syntax tree". https://en.wikipedia.org/wiki/Abstract_syntax_tree
One of my main concerns with this proposal, is the increasing complexity of what was once a very accessible web platform. You have this ever increasing tooling knowledge you need to develop, and with something like this it would certainly increase as "fast JS" would require you to know what a compiler is. Sure, a good counterpoint is that it may be incremental knowledge you can pick up, but I still think a no-work ma…
Interesting idea, which could be built on top of the Binary AST. I would personally prefer it being handled transparently by the middleware or the cdn, which would neatly separate the responsibilities between the browser, the cache+compressor and the http server. Anyway, one of the reasons this project is only about a file format is so that we can have this kind of conversation about what the browsers and other tools…
Earlier quoted context omitted.
According to a comment by Yoric, they're seeing a 5% improvement in size over minified+gzip. https://news.ycombinator.com/item?id=15046750
I would be more excited by the possible reduction in parse time since the grammar should be less ambiguous.
Earlier quoted context omitted.
This is important, as there seems to be a lot of misunderstanding in this thread. What's proposed is structural compression of JS with JS-specific bits to speed things up even more. What's proposed is not compiled JS, in that the original JS is not meaningfully transformed at all. There is a very explicit design goal to retain the original syntactic structure. OTOH WebAssembly is like a new low-level ISA accessible f…
This is a very good point. I would also add that there are a lot of languages compiling to JavaScript that would similarly not benefit from wasm. Right now, pretty much all GC-ed languages compiling to JS (such as ClosureScript, Elm, Scala.js, BuckleScript, PureScript, etc.) are in that category. Even if/when wasm supports GC in the future, I expect that dynamically typed languages compiling to JS will still be a lon…
I do recognize that this is a side point, but I think it's worth mentioning.
Earlier quoted context omitted.
You're not the only one to observe that computing tends to be fad-driven. I enjoy Alan Kay's take on it: In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understa…
I wish I've heard/seen some of the Alan Kay talks/articles earlier in my career. The more I work in IT, the more I see the wisdom in how he sees the industry. (And I don't just mean these pop culture comments.)
The downside is that exposure to both of those led me to write some software in both Smalltalk and Common Lisp...which is a downside because having worked with those makes some currently popular tools seem like dirty hacks.
Although I use things and enjoy things like React, and Webpack, and npm and I'm very happy with the things I'm able to create with them, when I stop and think about it, the tooling and building/debugging workflow feels pretty disjointed to what was available in Smalltalk and CL environments 30 years ago.
I understand why those tools didn't win over the hearts and minds of developers at the time. They were expensive and not that easily accessible to the average developer. I just wish that as an industry, we'd at least have taken the time to understand what they did well and incorporate more of those lessons into our modern tools.
Earlier quoted context omitted.
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. >…
Combined with the fact, as mentioned above, that DOM access is significantly slower means that WASM isn't a suitable candidate. This is something you forgot to mention or take into account in your comment, for some reason.
Yes this does seem to overlap a bit with wasm as you have noted, but saying "well we could get this optimization but we need to wait several years until this highy complex other spec is completely finished" doesn't seem as good.
Why not do this, and use wasm when it's available? Why can't you have both?
My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique.
This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's needed by their application, not on trying to optimize their fat JavaScript bundles. It's so lazy engineering.
I'd like to see some real-world performance numbers when compared with gzip. The article is a little overzealous in its claims that simply don't add up. My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique. This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's need…
I'd like to see some real-world performance numbers when compared with gzip. The article is a little overzealous in its claims that simply don't add up. My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique. This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's need…
> My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique.
In terms of raw file size and according to early benchmarks (which may, of course, be proved wrong as we progress), Binary AST + gzip affords us a compression that is a little bit better than minification + gzip. By opposition to minification, Binary AST does not obfuscate the code.
The real gain is in terms of parsing speed, in which we get considerable speedups. I do not want to advertise detailed numbers yet because people might believe them, and we are so early in the development process that they are bound to change dozens of time.
> This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's needed by their application, not on trying to optimize their fat JavaScript bundles. It's so lazy engineering.
Well, you are comparing optimizing the language vs. optimizing the code written in that language. These two approaches are and always will be complementary.
Also, there’s immense value in text formats over binary formats in general, especially for open, extendable web standards. Text formats are more easily extendable as the language evolves because they typically have some amount of redundancy built in. The W3C outlines the value here (https://www.w3.org/People/Bos/DesignGuide/implementability.h...). JS text format in general also means engines/interpreters/browsers are simpler to implement and therefore that JS code has better longevity.
Finally, although WebAssembly is a different beast and a different language, it provides an escape hatch for large apps (e.g. Facebook) to go to extreme lengths in the name of speed. We don’t need complicate JavaScript with such a powerful mechanism already tuned to perfectly complement it.
[0]: https://github.com/syg/ecmascript-binary-ast/#-2-early-error...