Josh Goebel

> It does not seem like you are interested in having an objective discussion on this *I totally am.* *sighs* 😢 Sometimes I really really hate the internet's complete lack...

Do just want me to remove all the "you" and "your" and replace with "this code"? **Done.** Again no slight was implied or intended. To me "your library", "my patch",...

Meanwhile over in the SSR thread on this topic: >> I do think given these are small template inserts where the static parts are already processed at compile time the...

Ok so now I'm using the included benchmark suite (with more tests) and I switched to a likely more representative sample (a large page of HTML from Github vs Javascript...

> Faster than iteration short-circuit for fragments that don't need escaping and faster-than multi-match Regexp iteration for fragments containing a realistic percentage of real-world entities in a typical document (both...

> well, all of which pass through it very short strings, most of which contain nothing to escape or a few characters to escape. Certainly keeping that use-case fast would...

If we can reach an agreement (that highlighting actual HTML, code, or textual-ish content is the primary use) case then this PR can be simplified to a tiny, tiny PR...

I guess I should mention a few of the use cases I'm thinking of (or have personally): - Source code (highlighted output from Highlight.js or Prism.js), so really source code...

> By prose, I mean "non-html content". I'm confused by your use cases to be honest. Why do you want to encode all entities in a 1.2MB HTML document? It...

> Again from what I see right now the existing algorithm seems to only be superior (vs the new one) when given content where almost every letter needs to be...