Prism vs Highlight.js: Why choose one over the other?

[joshgoebel]

Related: #3619 #3621 #3623

In trying to figure out the direction of the project moving forward, where we go, how we should or shouldn't integrate with other parsers (at the 1st party level), it'd be helpful to know WHY people prefer Highlight.js to Prism - or how they think about the differences. No detail is too large or too small. Or if you evaluated other highlighting solutions (than just these two), those thoughts would be welcome here also - provided you have a few points of comparison.

The parsing engines are of course very different. But I've never really thought about which is "better" in an absolute sense... I've just always assumed that a mono-culture is bad - and that it's good we have two great choices for highlighting on the client-side - and that people obviously have reasons for preferring one over the other.

Suddenly I'm much more curious about the WHY, and what those reasons are. Anyone care to share?

Lets keep this civil and respectful... it's ok to share perceived negatives, buts lets about things like "Highlight.js sucks because" or vise versa, etc...

[joshgoebel]

I'll start:

• Highlight.js often has more readable grammar definitions (for non regex wizards) - this is one of the reasons that drew me to it.
• Prism seems to have more community interest/contributors.
• Highlight.js is currently largely closed to 1st party grammars (too few maintainers).
• Prism seems more open, though I'm not sure how often new grammars are added.

[joshgoebel]

@RunDevelopment How would you feel about some sort of cross-posting of this?

[idleberg]

Prism seems to have more community interest/contributors.

This is pure speculation, but I have the feeling that Prism's popularity is tied closely to that of its author.

Highlight.js often has more readable grammar definitions (for non regex wizards)

As a contributor to both projects, I wanted to share my opinion on this. For obvious reasons, I prefer reading (and writing!) grammar definitions as used by Highlight.js. I would love to see some numbers, on how much optimized RegEx patterns contribute to the performance of Prism. If there's a significant gain, it makes sense, but developer experience is an important factor as well. Personally, I've been using retrie to optimize my contributions to Prism. In my opinion, that's a clear task for a computer and it kind of surprises me that contributions are higher Prism, because optimized Regex patterns are requested by the maintainers and not part of an automatic process. I've noticed for myself, that I'm slower at updating my Prism grammar rules because of this extra step.

[RunDevelopment]

How would you feel about some sort of cross-posting of this?

I just did :)

It might be good to more clearly signpost this as a survey where we are collection feedback from the community.

[RunDevelopment]

because optimized Regex patterns are requested by the maintainers and not part of an automatic process

Sorry, that's my fault.

I did request manually optimized keyword lists in the past, and that was honestly stupid. They were not only hard to read, write, and maintain, they were also slower than many "unoptimized" regexes. Turns out, browsers optimize character runs, so breaking up words too much can make regexes slower. Optimizing regexes based on tries sounds good in theory, but unfortunately rarely helps in practice. The old saying "premature optimization is the root of all evil" rang true once again. So I've changed course for a few years now and focus on readable regexes instead. Most of my usual nits and critiques when reviewing regexes were even automated by making a linter.

I know this isn't a Q&A, but I still wanted to respond to it, because it was directly my fault.

[JoshyPHP]

For me, the number one reason to use Highlight.js over anything else is the automatic language detection. I maintain a PHP library that's mostly used in forum software such as phpBB and Flarum. In my experience, most users don't fill in name of the programming language when posting code blocks. Without auto-detection or some kind of default, language-agnostic rules, there wouldn't be any highlighting.

[MBoegers]

I came to hightlight.js because I use Aciidoc-revealjs to create my slide decks and the has the best support for hightlight.js. I never worked with prism and only contributed some new keywords to hightlight, but I am think I am better with the "simple" approach taken by hightlight ;-)

[SalvatoreNoschese]

Hi, im here because use highlight.js in my blog with line numbers and copy button, but cannot found a way to make also a download button.
So, search for this and found prism (with download button, and seems to work as expected).
Search prism and ... I'm here in this git.

So, Is there any way to make similar for highlight.js? 😅

[isaacwein]

dose Prism have all these themes?

[matheusmoreira]

I think a major weakness of both syntax highlighters is they're based on regular expressions. Most if not all of the languages they highlight are not regular languages. They run into issues with things such as nesting.

A syntax highlighter having proper context-free parsers would be a major reason to prefer one over all others. An earley parser with grammar data for all supported languages, for example.

[kyle-belle]

I am testing out react-syntax-highlighter which offers both highlight.js and prism and for my use case highlight.js is much faster. I am basically trying to have editable code with live syntax highlighting like how its done on discord.

Prisma has better jsx/tsx support but its not worth it for the difference in speed.

highlight.js does seem to support jsx/tsx a fair amount but a small thing that messes it up is something like this

import { Comp_ } from "@component";
import { cn } from "../../Utils/cn";
import { useDarkMode } from "usehooks-ts";

const Comp = <T,/*<- this trailing comma as well as this comment*/>({className, ...props}: Comp_.Props<T>) => {
    return (
        <Comp_ {...props} classname={cn("w-full", className)} />
    );
}
 
export {DatePicker};