Like Parsoid?

Not sure, but I think their tasks are different.
I'll see how parsoid works, Thanks.

The Parser's WikiText tokenizing is pretty complex (using multiple passes on the whole text). Fully matching it in real-time isn't likely to be possible. I think we should decline this task and instead try to address specific cases that are broken (some of which may not be fixable without degrading performance unacceptably).

If I remember correctly, I meant order of parser.
And performance should be increased only. Now sometimes (maybe always) tokenizer returns back for parse the same text again because when you look at the beginning of a string you can not be sure which exactly this token is, until find the end of the token.
For example if you meet {{{{{ it can be:

{{{{{1}}}}} - parameter inside template transclusion
{{{{{ hello word - just five {

The Parser's WikiText tokenizer works different. It looks for tokens in whole a string.
For example the firstly it find parameters, then templates, etc. It should be faster and more correctly, but this is not suitable for cases where the string has not been written completely yet.

You could also have a look at my parser in https://de.wikipedia.org/wiki/Benutzer:Schnark/js/syntaxhighlight.js, for the template mess especially search for "Multiple braces". My approach there isn't perfect, but I actually never found a real live instance where it broke.

Related tickets: T289407: CodeMirror should perform syntax highlighting inside <gallery></gallery> tags, T289405: Implement syntax highlighting in editor for markup within <score> tags., T199740: Bold and big not highlighted correctly in the 2017WTE even T272602: Interlaced, single and other non-matching brackets are not highlighted, T189571: Syntax highlighting gets confused by extra lbrace and T184272: Incorrect syntax highlighting for: *#*:#