Twitter | Search | |
@rem
Do you think syntax highlighting (in blog posts, examples, etc) be in >(poll)< I've always err on the side of client as it's a progressive upgrade, not particularly costly on the client, and reduces markup downstream.
Reply Retweet Like More
Jake Archibald Apr 2
Replying to @rem
Client side: ➡️ Serve HTML. ➡️ Serve CSS. ➡️ Serve JS. ➡️ Execute JS. Server side: ➡️ Serve HTML (a tiny tiny bit more). ➡️ Serve CSS. The latter wins every time. Why make every user run code on every load when it has the same output?
Reply Retweet Like
@rem Apr 2
Replying to @jaffathecake
It's that "tiny tiny" bit more that I want to put under the microscope. But aye, I agree fully with you (and others giving their justification for server side). No one as yet has given a good reason to render client side (I can think of one, but it's not been suggested yet)
Reply Retweet Like
Phil Hawksworth Apr 2
Replying to @rem @jaffathecake
Interesting though, that the result of your poll leans so much towards doing this client-side. I'm assuming ( 👈 danger!) that's because it feels simpler and easier for developers to do it that way.
Reply Retweet Like
@rem Apr 2
So this is where I think the client side argument isn't being mentioned. SSR of syntax highlighting has always been a bit of a faff. I know a lot/most/all(?) SSG support highlighters these days, but look at highlight.js "get" instructions, all leans client side.
Reply Retweet Like
Phil Hawksworth Apr 2
Replying to @rem @jaffathecake and 3 others
I totally agree. Developer convenience has trumped other considerations. Which is something to be wary of. I'm using to do this as it brings support for using 's which I already really love.
Reply Retweet Like
Phil Nash Apr 2
SSR comes out the box with . No faff, no problem.
Reply Retweet Like
@rem Apr 2
If I had a £ for every time someone told me it just works, I'd be a rich man. It's the edge cases that failed, that cause us the next time to reach for the largest hammer for the job.
Reply Retweet Like
Charlie Don't Surf Apr 1
Replying to @rem
Server side. Quicker to render to client, no flash of unstyled code, robust.
Reply Retweet Like
@rem Apr 2
Replying to @sonniesedge
To nitpick, arguably there's a flash of unstlyed content either way. With server rendered, colours are loaded in the client. In client, text is swapped and coloured in the client. Visual content should remain exactly where it always was and always visible —
Reply Retweet Like
@rem Apr 2
Replying to @sonniesedge
The counter argument, obviously, faster and less to render in the client when the html is prepared in exactly the right format/structure for the styles to be applied.
Reply Retweet Like
Amelia Bellamy-Royds Apr 1
Replying to @rem @anatudor
I've been meaning to write up a proposal for native HTML syntax highlighting, if only because it would make it easier for people to be able to always see code in their favourite colour scheme!
Reply Retweet Like
@rem Apr 1
Replying to @AmeliasBrain @anatudor
There is language support (as little as that means) in the html spec around the PRE tag. It's odd, but it recommends using the class attribute
Reply Retweet Like
Amelia Bellamy-Royds Apr 1
Replying to @rem @anatudor
I'd say it's more of acknowledging reality as opposed to really recommending it: "There's no formal way to do it … you can use a class if you need to." So yes, the first part of my proposal would be a standard attribute to indicate the code language.
Reply Retweet Like
patrick h. lauke Apr 2
and then constantly need to keep that attribute values set up-to-date based on new languages emerging? hmmm...
Reply Retweet Like
Šime Vidas Apr 2
Just reuse the `lang` attribute and standardize language tags for programming languages
Reply Retweet Like
Phil Hawksworth Apr 1
Replying to @rem @eleven_ty
I do it server side at build time. Because anything I can do ahead of time, I do ahead of time. It doesn't add markup for me as it is done by my SSG () during the build. One less thing to have as a client-side js dependency and on the render path.
Reply Retweet Like
Matt Gaunt Apr 1
Same here. Especially if you want to support several languages.
Reply Retweet Like
flaki Apr 1
I…I don't get it, why doesn't it add markup? It adds server-side generated markup (extra DOM elements), but that's still more markup (HTML) down the wire, isn't it..?
Reply Retweet Like
Eleventy Apr 1
I believe they mean that it doesn't add any markup requirements to the content. The extra markup is added by the build
Reply Retweet Like
Matt Gaunt Apr 1
yeah this is what I was referring to. I use the GitHub flavor markdown to include language info and then at build time it's syntax highlighted (i.e. extra markup) and that is served up with some extra styles.
Reply Retweet Like
flaki Apr 1
Fair point (was just confused b/c 's OP mentions "markup" in a different setting).
Reply Retweet Like
Matt Gaunt Apr 1
Rem's argument for client side is totally valid, but it requires a download of the syntax highlighting lib. It's a trade-off (as is always the way).
Reply Retweet Like