4 ms·

To be honest I (as an author of the Sciter [1]) do not expect too much gain from that. Sciter contains source code to bytecode compiler. Those bytecodes can be

To be honest I (as an author of the Sciter [1]) do not expect too much gain from that. Sciter contains source code to bytecode compiler. Those bytecodes can be stored to files and loaded bypassing compilation phase. There is not too much gain as JS alike grammar is pretty simple. In principle original ECMA-262 grammar was so simple that you can parse it without need of AST - direct parser with one symbol lookahead that produces bytecodes is quite adequate. JavaScript use cases require fast compilation anyway. As for source files as for eval() and alike cases like onclick="..." in markup. [1] https://sciter.com https://sciter.com And JS parsers used to be damn fast indeed, until introduction of arrow functions. Their syntax is what requires AST.

timdorr 9y ago
How do you do one-symbol-lookahead with things like function hoisting? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function#Function_declaration_hoisting https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- c-smile 9y ago
  Not clear how hoisting is related to parsing really ... Compiler builds table of variables (registers map) of the function to generate proper bytecodes to access registers. At this point hoisting has some effect. But it has nothing with parse/AST phase.
limeblack 9y ago
I have never been a fan of the => syntax. Although that really isn't the point. What about the syntax slows parsing?
- c-smile 9y ago
  As I said original JS syntax is pretty simple - parsing is comparable with just scanning source buffer char by char. Not too much different from HTML and CSS. Where 99% of time takes actual DOM creation. Like this XML/HTML scanner that I did while ago: https://www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer https://www.codeproject.com/Articles/14076/Fast-and-Compact-... - it as fast as access to memory of HTML source. It even does not allocate any memory while parsing.
  - nly 9y ago
    What you're describing is a recognizer, not a parser. A parser by definition produces some output other than a boolean 'yes, this is a syntactically correct HTML/JS input' (which is still more useful than what a tokenizer/scanner gives you, which is 'yes, this thing contains only HTML/JS tokens and here they are...splat')

timdorr 9y ago

How do you do one-symbol-lookahead with things like function hoisting? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function#Function_declaration_hoisting https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

c-smile 9y ago
Not clear how hoisting is related to parsing really ... Compiler builds table of variables (registers map) of the function to generate proper bytecodes to access registers. At this point hoisting has some effect. But it has nothing with parse/AST phase.

limeblack 9y ago

I have never been a fan of the => syntax. Although that really isn't the point. What about the syntax slows parsing?

c-smile 9y ago
As I said original JS syntax is pretty simple - parsing is comparable with just scanning source buffer char by char. Not too much different from HTML and CSS. Where 99% of time takes actual DOM creation. Like this XML/HTML scanner that I did while ago: https://www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer https://www.codeproject.com/Articles/14076/Fast-and-Compact-... - it as fast as access to memory of HTML source. It even does not allocate any memory while parsing.
- nly 9y ago
  What you're describing is a recognizer, not a parser. A parser by definition produces some output other than a boolean 'yes, this is a syntactically correct HTML/JS input' (which is still more useful than what a tokenizer/scanner gives you, which is 'yes, this thing contains only HTML/JS tokens and here they are...splat')