It's funny to see us remembering that things can be done on the server. The trend to render everything client-side has always been troubling to me. Such a waste of resources (but it's not your resources, so developers don't care). Sure, things that are truly dynamic or are different for every user is probably usefully done on the client. But a static page with code samples can easily be rendered on the server, with syntax highlighting, and then cached. You only need to do it once, rather than hundreds or thousands of times on every client device.

What is so special about this? This is the way websites have been doing syntax highlighting before people started using javascript libraries.

...By running the same JS on the server or in a build step.

This is not new, but it's nice to spread awareness since it seems everyone loads it in the front-end nowadays and I've noticed that it also avoids the page moving around too much.

In https://documentation.page/ I'm using `markdown-it` with `prismjs` to generate the code snippets (see example on e.g. https://react-test.dev/). It's in fact a default helper, so you don't even need hacks:

    import MarkdownIt from "markdown-it";
    import Prism from "prismjs";

    function highlight(str, lang) {
      if (!lang || !Prism.languages[lang]) return;
      return Prism.highlight(str, Prism.languages[lang], lang);
    }

    const md = new MarkdownIt({ highlight }).use(...

I think the point of this article is the constexpr.js library, not the fact that syntax highlighting on the server-side is possible

Looks like we've gone full circle.

In Go we have https://github.com/alecthomas/chroma, and I implemented the lexer that the Caddy docs use for syntax highlighting the Caddyfile (see https://caddyserver.com/docs/caddyfile/concepts for example). What's cool about this is Caddy is serving the site from markdown files rendered via Go templates, with Chroma for code blocks. So Caddy can highlight its own config.

So many HNers pointing out that it was possible since the dawn of the web... yet the point of this article is that you can just add highlighting JS and constexpr.js will automatically optimize it. JS-based highlighters have all sorts of plugins, so it makes sense to reuse the effort.

So basically the script renders the JS-needed website, execute the JS as a build step and spit out the highlighted site. Pretty cool!

There’s a code parsing intrinsic complexity cost. It can be paid in space / memory by pre-rendering on the server or it could be pushed at runtime as JS and potentially as CSS (which I understand is Turing complete) but one way or another the cost will be paid.

Right. You just do it on the server. Okay?

There are pros and cons to highlighting on the client vs the server.

If you highlight on the server:

pros: no javascript, can cache

cons: might be a way to inject scripts into everyone's browser, since the client has to trust the html from the server

--

If you write it on the client:

pros: server can't distribute injected scripts, server stores less things

cons: more javascript, every client has to do work

--

All software choices are weighing the pros and cons. Do the thing that lets you work quickly and safely.

Server-side I use https://lib.rs/syntect, which supports Sublime Text language definitions and themes.

BTW: the markup grows substantially. It's worth having a simplification step. Also the old-school <tt> element is shorter and cooler than <span>.

Well I for one wish I’d known about this (specifically constexpr.js) sooner. I like to develop sites with TS, but generally prefer to ship as little of it to the client as possible. There are a few solutions for this but most have some kind of compromise or another. It’s good to see another contender out there!

I like https://github.com/kingcons/colorize for Common Lisp.

I thought our octa core 3 GHz mobile processors would be able to handle a little bit of javascript once in a while.

vim comes with a 2html vim script file that generates an HTML page that only uses HTML and CSS for syntax highlighting.

Why the prog element? Something wrong with <code>?