6 ms·

Syntax Highlighting in a Webpage Without JavaScript

71 points by tathisit 6y ago

viseztrance 6y ago
Looks like we've gone full circle.
- gtsop 6y ago
  What do you mean? Honestly interested
  - the-dude 6y ago
    My take? In the beginning, we had to do everything server-side. Then, doing as much as possible client-side was all the rage. And now we are bringing these client-side libraries back to the server.
    - gtsop 6y ago
      Classic advancement of things. It is full circle but not back to the begining, it's a level higher. It looks like you're doing the same but you now have all the benefits of server side rendering AND front-end frameworks.
bugfix 6y ago
What is so special about this? This is the way websites have been doing syntax highlighting before people started using javascript libraries.
- amatecha 6y ago
  Right, looks like it's just preprocessing the content with a static site generator to insert markup + CSS classes around the different syntactical pieces. /shrug
- mixedCase 6y ago
  There's a increasingly larger amount of web developers who are only "trained in React/Angular/Vue" and are unable to understand how to use or the trade-offs of regular websites using just HTML+CSS with only a little or no JS (that goes for both templated or fully static sites), and a surprising number of them even thinking they are some kind of "legacy technology". At the very least, this kind of article is informative for that crowd.
  - simonw 6y ago
    I'm fascinated by this. It seems that for any developer with less than five years of industry experience there's a reasonable chance that they've almost exclusively worked in an SPA, JavaScript-for-everything environment. I have a hunch that there are a lot of web professionals out there these days who genuinely don't know how to build a web application without JavaScript - POST forms, cookies and the like.
    - earthboundkid 6y ago
      You should make a video with a rebranded Django as “Reinhardt, the Multi Page Application” and see how it goes. Just do the original Rails “blog in ten minutes” demo to show it goes beyond todo lists.
    - thrower123 6y ago
      This is why we end up with a new reinvention of make every five years. The churn rate on junior developers is probably the single biggest factor in software over the past two decades.
  - genericstorage3 6y ago
    I think it's wasted work/experience as css alone can't do everything. Then you'll end up having a project with highlighting logic in css and js. That's less than optimal
kaeruct 6y ago
I think the point of this article is the constexpr.js library, not the fact that syntax highlighting on the server-side is possible
- slow_donkey 6y ago
  How dare you question the snark
SahAssar 6y ago
...By running the same JS on the server or in a build step.
- anitil 6y ago
  Damn, I was hoping to discover some dark css magic that can be used to contruct some sort of parser
  - eliseumds 6y ago
    Indeed, indeed :(
  - k_sze 6y ago
    Same. :(
- zelphirkalt 6y ago
  Although at that point one could also make use of the excellent pygments library from Python, to truly have no JS, if that was the point. It is used from inside many other languages' tools as well.
eyelidlessness 6y ago
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!
madeofpalk 6y ago
Right. You just do it on the server. Okay?
jvik 6y ago
I thought our octa core 3 GHz mobile processors would be able to handle a little bit of javascript once in a while.
franciscop 6y ago
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/ https://documentation.page/ I'm using `markdown-it` with `prismjs` to generate the code snippets (see example on e.g. https://react-test.dev/ 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(...
xXx_uwu_xXx 6y ago
Why the prog element? Something wrong with <code>?
francislavoie 6y ago
In Go we have https://github.com/alecthomas/chroma 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 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.
random3 6y ago
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.
kelnos 6y ago
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.
- tantalor 6y ago
  Offloading rendering to CSS is still making the client do some work. Excessive CSS can bloat the page, hurting latency. If you take this approach to the extreme, you should render to png on the server for display, and provide plain text for accessibility only.
- genericstorage3 6y ago
  Css will work until a certain point. What do you do when css can't handle? Give up, do some super hacky unmaintainable css mess, or suck it up and use js...
  - setr 6y ago
    The trouble generally is that JS is used despite the content being static, or independent of client behavior/usage. That is, JS can be used to do everything but it is not optimal, or even near optimal (or even remotely close to) for many use cases. In terms of runtime or simplicity. But because it is capable and available, it has encroached into every niche (of html/css) until like any invasive species, it consumes and shreds through all available resources, collapses the whole ecosystem, and all complex creatures give way to a fresh start with new fairly rudimentary biology (wasm) trying to evolve towards and find a new stability point — hopefully one that does not invite a similar destructive species, but we’ll see how it goes
    - genericstorage3 6y ago
pcr910303 6y ago
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!
sedachv 6y ago
I like https://github.com/kingcons/colorize https://github.com/kingcons/colorize for Common Lisp.
u801e 6y ago
vim comes with a 2html vim script file that generates an HTML page that only uses HTML and CSS for syntax highlighting.
pornel 6y ago
Server-side I use https://lib.rs/syntect 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>.
mrozbarry 6y ago
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.

71 points by tathisit 6y ago

viseztrance 6y ago

Looks like we've gone full circle.

gtsop 6y ago
What do you mean? Honestly interested
- the-dude 6y ago
  My take? In the beginning, we had to do everything server-side. Then, doing as much as possible client-side was all the rage. And now we are bringing these client-side libraries back to the server.
  - gtsop 6y ago
    Classic advancement of things. It is full circle but not back to the begining, it's a level higher. It looks like you're doing the same but you now have all the benefits of server side rendering AND front-end frameworks.

bugfix 6y ago

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

amatecha 6y ago
Right, looks like it's just preprocessing the content with a static site generator to insert markup + CSS classes around the different syntactical pieces. /shrug
mixedCase 6y ago
There's a increasingly larger amount of web developers who are only "trained in React/Angular/Vue" and are unable to understand how to use or the trade-offs of regular websites using just HTML+CSS with only a little or no JS (that goes for both templated or fully static sites), and a surprising number of them even thinking they are some kind of "legacy technology". At the very least, this kind of article is informative for that crowd.
- simonw 6y ago
  I'm fascinated by this. It seems that for any developer with less than five years of industry experience there's a reasonable chance that they've almost exclusively worked in an SPA, JavaScript-for-everything environment. I have a hunch that there are a lot of web professionals out there these days who genuinely don't know how to build a web application without JavaScript - POST forms, cookies and the like.
  - earthboundkid 6y ago
    You should make a video with a rebranded Django as “Reinhardt, the Multi Page Application” and see how it goes. Just do the original Rails “blog in ten minutes” demo to show it goes beyond todo lists.
  - thrower123 6y ago
    This is why we end up with a new reinvention of make every five years. The churn rate on junior developers is probably the single biggest factor in software over the past two decades.
- genericstorage3 6y ago
  I think it's wasted work/experience as css alone can't do everything. Then you'll end up having a project with highlighting logic in css and js. That's less than optimal

kaeruct 6y ago

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

slow_donkey 6y ago
How dare you question the snark

SahAssar 6y ago

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

anitil 6y ago
Damn, I was hoping to discover some dark css magic that can be used to contruct some sort of parser
- eliseumds 6y ago
  Indeed, indeed :(
- k_sze 6y ago
  Same. :(
zelphirkalt 6y ago
Although at that point one could also make use of the excellent pygments library from Python, to truly have no JS, if that was the point. It is used from inside many other languages' tools as well.

eyelidlessness 6y ago

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!

madeofpalk 6y ago

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

jvik 6y ago

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

franciscop 6y ago

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/ https://documentation.page/ I'm using `markdown-it` with `prismjs` to generate the code snippets (see example on e.g. https://react-test.dev/ 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(...

xXx_uwu_xXx 6y ago

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

francislavoie 6y ago

In Go we have https://github.com/alecthomas/chroma 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 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.

random3 6y ago

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.

kelnos 6y ago

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.

tantalor 6y ago
Offloading rendering to CSS is still making the client do some work. Excessive CSS can bloat the page, hurting latency. If you take this approach to the extreme, you should render to png on the server for display, and provide plain text for accessibility only.
genericstorage3 6y ago
Css will work until a certain point. What do you do when css can't handle? Give up, do some super hacky unmaintainable css mess, or suck it up and use js...
- setr 6y ago
  The trouble generally is that JS is used despite the content being static, or independent of client behavior/usage. That is, JS can be used to do everything but it is not optimal, or even near optimal (or even remotely close to) for many use cases. In terms of runtime or simplicity. But because it is capable and available, it has encroached into every niche (of html/css) until like any invasive species, it consumes and shreds through all available resources, collapses the whole ecosystem, and all complex creatures give way to a fresh start with new fairly rudimentary biology (wasm) trying to evolve towards and find a new stability point — hopefully one that does not invite a similar destructive species, but we’ll see how it goes
  - genericstorage3 6y ago

pcr910303 6y ago

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!

sedachv 6y ago

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

u801e 6y ago

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

pornel 6y ago

Server-side I use https://lib.rs/syntect 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>.

mrozbarry 6y ago

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.