4 ms·

In my opinion it's irresponsible to use highlighters like these. At least when you use them like advertised. Why does no one bat an eyelid at letting the client

In my opinion it's irresponsible to use highlighters like these. At least when you use them like advertised. Why does no one bat an eyelid at letting the clients handle the highlighting? The highlighting (lexing) could (and should) be done ONCE at the server. Imagine some high traffic blogs with hundreds of millions of hits combined - all these clients downloading the highlighting libs + lexers for 50 different languages that will never be used on the blog anyway. The wasted energy here is probably even measurable. Cons when letting the clients handle syntax highlighting: - Much slower load times - Wasted energy - Can fail because of JS crashing - Noscript users won't get any highlighting (and your blog targets technical users, right? They are more likely to use no script) - Slow mobile devices will have a harder time loading the site (or depending on javascript engine - failing highlight) - (if no site optimization is made) the client will download lexers for languages not used on the blog Cons when the server do the lexing ONCE: - NOTHING Note that this rant isn't targeted at Highlight.js. It's a good highlighter - I use it myself at my blog. Except I use it on the server via a CGI script. It took me no more than 2 minutes to set up.

WA 12y ago
Except I use it on the server via a CGI script. It took me no more than 2 minutes to set up. How about you write a tutorial about this and submit it to HN? This is probably a better way to make people adapt your approach than a rant, no matter how valid your points are :)
- accatyyc 12y ago
  That's a good idea! I should make a blog post about it. And maybe be less ranty. ;)
sneak 12y ago
Computing is cheap. Setting up and maintaining that is more human seconds than doing it clientside. I dare you to calculate the amount of energy this wastes on a blog that gets a billion hits. This is a battle you cannot win and should not attempt to fight.
- accatyyc 12y ago
  Sure, the energy argument is probably the least interesting of the ones listed above. Don't ignore the rest of them!
Confusion 12y ago
In my opinion it is irresponsible to post strongly worded opinions such as these, because you forget you may not be seeing the whole picture. Cons when the server do the lexing ONCE: - NOTHING You are assuming a specific use case, where static code originally exists on the server and the highlighted version is included in a page that is viewed many times. My use case for these libraries is different: users actually write 'code' in my app, which I wish to highlight as they type it. Of course many users will write the same fragments and energy could be saved by caching the highlighting of those on the server. However, the latency of that solution (roundtrip to server needed to highlight code) and the code complexity (cache expiration is one of the two 'hard' problems in SE) are much worse than for the client-side highlighting solution.
- accatyyc 12y ago
  That's an entirely different problem I'd say, and the perfect use case for these libraries on a client! If you'd do it server side it would be like a local IDE sending the code to be lexed remotely... My rantiness (I apologize for that) targets programming blogs/static pages.

WA 12y ago

Except I use it on the server via a CGI script. It took me no more than 2 minutes to set up. How about you write a tutorial about this and submit it to HN? This is probably a better way to make people adapt your approach than a rant, no matter how valid your points are :)

accatyyc 12y ago
That's a good idea! I should make a blog post about it. And maybe be less ranty. ;)

sneak 12y ago

Computing is cheap. Setting up and maintaining that is more human seconds than doing it clientside. I dare you to calculate the amount of energy this wastes on a blog that gets a billion hits. This is a battle you cannot win and should not attempt to fight.

accatyyc 12y ago
Sure, the energy argument is probably the least interesting of the ones listed above. Don't ignore the rest of them!

Confusion 12y ago

In my opinion it is irresponsible to post strongly worded opinions such as these, because you forget you may not be seeing the whole picture. Cons when the server do the lexing ONCE: - NOTHING You are assuming a specific use case, where static code originally exists on the server and the highlighted version is included in a page that is viewed many times. My use case for these libraries is different: users actually write 'code' in my app, which I wish to highlight as they type it. Of course many users will write the same fragments and energy could be saved by caching the highlighting of those on the server. However, the latency of that solution (roundtrip to server needed to highlight code) and the code complexity (cache expiration is one of the two 'hard' problems in SE) are much worse than for the client-side highlighting solution.

accatyyc 12y ago
That's an entirely different problem I'd say, and the perfect use case for these libraries on a client! If you'd do it server side it would be like a local IDE sending the code to be lexed remotely... My rantiness (I apologize for that) targets programming blogs/static pages.