目前主流(比如 GitHub)的做法是在后端高亮,输出带样式类的 HTML;其他也有在前端通过 JS 语法高亮库进行处理的。 后端渲染语法高亮的优势是: 不会“闪”一下,渲染效果更平滑 统一处理,多端场景下升级方便 当然,也有缺点: 消耗服务器资源,请求的整体响应时间变长 处理稍微复杂,如果某种语言没有后端高亮库,就只 ..

代码语法高亮放前端还是后端?

目前主流(比如 GitHub)的做法是在后端高亮,输出带样式类的 HTML;其他也有在前端通过 JS 语法高亮库进行处理的。

后端渲染语法高亮的优势是:

当然,也有缺点:

我比较倾向于后端渲染,能一次做完的事情就不要分布出去了,那样有点浪费资源。

大家觉得哪种方案好?

单选 公开 永不结束 25 票
前端渲染
40% 10 票
后端渲染
60% 15 票

  • 语法高亮
    2 引用 • 32 回帖
  • 后端
    32 引用 • 122 回帖 • 1 关注
  • 前端

    前端技术一般分为前端设计和前端开发,前端设计可以理解为网站的视觉设计,前端开发则是网站的前台代码实现,包括 HTML、CSS 以及 JavaScript 等。

    188 引用 • 1294 回帖
1 操作
88250 在 2019-08-27 20:15:36 更新了该帖
27 回帖
请输入回帖内容...
  • dengwentong 1

    @88250 @Vanessa
    居然说到,前端和后端,自然 D & V 。
    个人倾向后端。
    作为自身,后端操作比较友好;作为看客,前端有基本的语法高亮应该看起来也会友好吧。😄

  • betou

    倾向于后端,有需求直接改就完了,如果是个 APP,出问题还要重新打包上架。

  • betou 1

    对现代硬件来说,那一丢丢资源不算是资源吧,当前情况应该是代码发展速度跟不上硬件的发展速度

  • InkDP

    后端,作为刚开发玩皮肤的人来说 后端会让前端很舒服

  • ferried

    看后端提供的服务类型吧?如果后端都是数据交换数据处理那么 渲染 放在前端合适,如果后端有一部分前端渲染引擎的话,那就放后端。

    1 回复
  • YLongo

    个人倾向放后端,代码高亮是通用的逻辑,可以一次开发,多处使用

  • Vanessa

    做为前端,总担心辣么多的处理后端会吃不消。

  • jeffjade

    看应用场景;放在前端,倘若处理得当,可以不显现“闪”一下;一般处理的话,那一闪而过的瞬间,应该也不太影响使用体验。

    对很多静态网站生成器而言,不需要后台的话,则也无需内置,用户可按需载入高亮库,这也是如今个人博客处理办法;如 Ghost:https://quickapp.lovejade.cn/how-to-elegantly-handle-quickapp-request/

    对于当下流行使用 MVVM 框架来搭建的单页应用(SPA),首屏渲染、SEO 的解决之道,可以有很多法子,可不采取服务端渲染这种相对更复杂方法,那么高亮这种自然也还是前端自己处理(发布前预渲染,这种也算是在前端了吧)。

    1 回复
  • 88250

    场景是 HTML 渲染,比如帖子里有代码块时需要高亮。

    发这个帖的原因是最近正在做社区 Markdown 渲染改造,以前用的是 markdown-it+ highlight.js(两个项目都是 JavaScript 的),目前正在改造为 Lute + Chroma(两个项目都是 golang 的)。因为我这边还有其他项目也有这个需求,所以和大家讨论一下看看,是否还有什么我没有考虑到的情况,集思广益 🙏

  • 88250

    嗯,还是看应用场景。

    Go 实现的一个静态站点生成系统 Hugo 用的也是 Chroma,这也算是“预渲染”操作吧 😅

    2 回复
  • Sunnnner

    前端吧- -后端主要还是负责数据,因为我就是负责数据的别的还没到达那种地步,另外如果放在后端,服务器一定要 hold 住,不然崩了怎么办

  • yixiangblog

    直接 highlight.js 呗。用国内 cdn,印象中不会闪,用起来也方便,也可以不用管后端是啥语言写的。if it ain't broken, don't fix it.

  • ferried

    V 说怕你吃不消,那就前端渲染?

    1 回复
  • jeffjade

    嗯嗯,是的。

  • 88250

    没事,我吃得消 doge

    @Vanessa

  • krbtgt

    后端想为前端分担压力,前端担心后端吃不消。

    我怀疑你们俩在撒狗粮,并且我有证据😂

  • zonghua

    当然是前端啦,减少我后端工作量,上班多摸鱼

    1 回复
  • csfwff

    huaji 当然是后端啦,减少我前端工作量,上班多摸鱼

    1 回复
  • zonghua

    工作成果我收了哈

  • 2501224066

    前端只会调接口,给他搞不放心

  • jenphyjohn 1

    这狗粮我先干了!后端统一处理易于维护,但是增加服务端渲染时间,看如何取舍了。个人倾向前端处理,能提高一丁点儿的体验效果也是好的,前提是有方法能解决闪一下的问题。

  • zwxbest 1

    前端啊,渲染这种功能放前端,可以减轻服务器压力,同时前端调试也比较方便。

  • Blackman99 1

    如果可以的话不必限制在一端,两种方式都提供,使用者可以根据具体应用场景进行选择

  • Green 1

    对与这种,不影响使用的优化项 在前端处理也算是一种边缘计算,这个的优点大家也都清楚。

    如果放到后端处理,
    对于少量用户来说 貌似也没有什么不可以〜
    但是稍稍多一点儿,就要用更多的 money(服务器)来换取用户体验来,简直不要太划算。

    但是这个时候,出与前端的求生欲: 我还是要说,支持后端渲染 +1 trollface

  • PeterChu 1

    我的想法是,这种问题应该不是简单一元一次方程,而应该是多元的,也就是说决定最终取舍的影响因素应该有多个,不同的影响因素大小下会产生不同的最终结果。所以,就这个问题可能需要考虑有几个,一个是服务器的能力,一个是访问量,一个是时间。🤔

  • jeffjade

    这类帖子,社区的投票功能蛮有使用的必要,:)。

    1 回复
  • 88250

    嗯嗯。

    @participants 大家来投票吧!

请输入回帖内容 ...