Why prefer this over something server-side, like Pygments, when you can use the latter? I don't see many advantages to the client-side approach.
Highlight.js – Syntax highlighting for the Web
61–70 of 72 posts
Re: Highlight.js – Syntax highlighting for the Web
#62This is my favorite syntax highlighting library. The best feature is that it returns a continuation of the code being highlighted which means you can highlight code that's being streamed to you line by line. I couldn't find another library that does that.
Re: Highlight.js – Syntax highlighting for the Web
#63In 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.
Re: Highlight.js – Syntax highlighting for the Web
#64In 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 langu…
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 :)
Re: Highlight.js – Syntax highlighting for the Web
#65In 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 langu…
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. ;)
Re: Highlight.js – Syntax highlighting for the Web
#66It should be mentioned that this does not support and will indeed never support line numbers due to some strange opinions of the lead developer: http://highlightjs.readthedocs.org/en/latest/line-numbers.ht...
http://prismjs.com/ is an alternative that supports line numbers.
Prism is pretty damn good. Although the name sounds like an NSA plan to intercept all the javascript libraries in the world.
Re: Highlight.js – Syntax highlighting for the Web
#67In 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 langu…
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.
Re: Highlight.js – Syntax highlighting for the Web
#68In 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 langu…
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!
Re: Highlight.js – Syntax highlighting for the Web
#69In 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 langu…
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
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.
Re: Highlight.js – Syntax highlighting for the Web
#70Why prefer this over something server-side, like Pygments, when you can use the latter? I don't see many advantages to the client-side approach.
You may have users actually writing 'code' on the client side. For those cases a client-side solution gives a better experience that requires less code (no roundtrip to server needed).