Comment by accatyyc | Hacker News Reader

Comment by accatyyc | Hacker News Reader

Parent Full thread

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.

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 :)

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

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.

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

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.

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.

Reply on news.ycombinator.com