4 ms·
If you want an even smaller (sans jQuery) JS highlighter that doesn't fail on edge cases, check my jQueryJSH: http://www.phoboslab.org/files/jquery-jsh/ http://
by phoboslab 14y ago
If you want an even smaller (sans jQuery) JS highlighter that doesn't fail on edge cases, check my jQueryJSH: http://www.phoboslab.org/files/jquery-jsh/ http://www.phoboslab.org/files/jquery-jsh/
github: https://github.com/phoboslab/jQuery-JSH https://github.com/phoboslab/jQuery-JSH
- jacobr 14y ago1) How do I know it doesn't fail on the same edge cases Prism might fail on? I see no tests. 2) Do you really need jQuery there? You seem to be using it only for the html method, and including 93K extra JS instead of just using innerHTML seems a bit overkill.
- Xurinos 14y ago2) Do you really need jQuery there? You seem to be using it only for the html method, and including 93K extra JS instead of just using innerHTML seems a bit overkill. It checks for the case that .innerHTML setting is not supported (I think that was for certain versions of IE) and switches to using appendChild(). I think that that small oversight is somewhat reasonable justification for using a wrapper that abstracts away the browser differences, although it can be argued that once someone understands the differences, they could just add the use cases to their code.
- saurik 14y agoI am somewhat confused why you would trust tests for edge cases sufficiently strongly so as to distrust an implementation without any; edge cases should be proved from first principals, as you can't possible test all of them.
- jarek-foksa 14y agoBut smaller does not always mean better. Benchmarks have shown that parsers based exclusively on regular expressions can be even several times slower than parsers that use scanner/tokenizer. The bigger regExps you write, the slower and more bug-prone your code will be.