4 ms·
Faster Script Loading with BinaryAST?
- bradtn 7y agoAre the posted timings comparing unminified JS to binary AST?
- olliej 7y agoBinaryAST keeps getting proposed, yet hasn't actually demonstrated real improvements. The first real problem is this adds yet another parser to JS engines, which means more attack surface, and more duplicated effort as it becomes necessary to re-implement new language features in both parsers. That also means you have potential to have bugs where binary-ast and actual JS diverge. As far as speed goes: parsing and validating JS is already extraordinarily fast, and none of that validation work goes away with binaryast, because the validation also exists to prevent malicious code from compromising the system. Being a binary "AST" doesn't change the simple and obvious fact: it's downloaded over a network so must be treated as malicious. The cloud flare blog post also makes a number of incorrect claims: A large amount of variable and function resolution already occurs during parsing, binary AST doesn't change anything at all. The BinaryAST also doesn't do away with deferred compilation, because the reality is that developers keep shipping code with functions that aren't called (either unintentionally, or because different browsers, screen resolutions, etc require different logic). Deferred parsing also doesn't cost much as the validation requirements are more or less all handled in the initial parse (even delayed compilation needs to verify syntactic correctness to avoid executing JS if there's invalid code embedded in a nest function) It also only compares timings of the Mozilla JS engine but IIRC out of JSC, V8, and SM, SM has the slowest parser.