Slow parsing speed is due to several things: - encoding issues; - ambiguous stuff (for instance, `/` can be the start of a comment, the start of a regexp or a

Slow parsing speed is due to several things: - encoding issues; - ambiguous stuff (for instance, `/` can be the start of a comment, the start of a regexp or a division, `()` or `{}` can have several meanings, etc.); - odd behavior (variables can be used before they are declared, double-declaring variables is sometimes valid but not always, etc.); - plenty of information that is necessary for execution is only available after you need it (sometimes much later, e.g. determining free variables, determining whether `eval` can affect local variables, etc). Also, this syntax makes it impossible to perform concurrent parsing (at least not without extremely costly non-concurrent pre-parsing) and makes it basically impossible to perform lazy parsing (at least not without this same extremely costly pre-parsing). If I understand correctly, your suggestion would have been to: 1. provide a "better" developer-facing text syntax; 2. if necessary, move to binary parsing. Your suggestion makes sense but I believe that it underestimates seriously the ability to: a. come up with an alternative, easier to parse, text syntax; b. make sure that your text syntax has the same semantics as the original syntax; c. get everybody to agree on that text syntax; d. maintain this text syntax through successive versions of JavaScript, without losing its desirable properties; e. have every browser maintain two text parsers. Also, note that b. most likely means standardizing upon an AST, which is roughly half of the difficulty of the current proposal. Finally, unless I am missing something, your suggestion does not improve concurrent or lazy parsing. One of the core benchmarks behind the current proposal is that lazy parsing can be made extremely faster than non-lazy parsing, as soon as you the expensive pre-parsing phase has been abolished. Does this answer your questions?