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

本贴最后更新于 1946 天前,其中的信息可能已经时移世易

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

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

  • 不会“闪”一下,渲染效果更平滑
  • 统一处理,多端场景下升级方便

当然,也有缺点:

  • 消耗服务器资源,请求的整体响应时间变长
  • 处理稍微复杂,如果某种语言没有后端高亮库,就只能通过其他的高亮进程处理

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

大家觉得哪种方案好?

单选 公开 永不结束 28 票
前端渲染
35% 10 票
后端渲染
64% 18 票

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

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

    247 引用 • 1348 回帖
1 操作
88250 在 2019-08-27 20:15:36 更新了该帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • dengwentong 1

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

  • betou

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

  • betou 1

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

  • InkDP

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

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

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

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

  • 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.

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

    1 回复
  • jeffjade

    嗯嗯,是的。

  • 88250

    没事,我吃得消 doge

    @Vanessa

  • krbtgt

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

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

  • zonghua

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

    1 回复
  • csfwff 1

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

    1 回复
  • zonghua

    工作成果我收了哈

  • 2501224066

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

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

  • zwxbest 1

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

  • Blackman99 1

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

  • K 1

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

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

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

  • PeterChu 1

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

  • jeffjade

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

    1 回复
  • 88250

    嗯嗯。

    @participants 大家来投票吧!

请输入回帖内容 ...

推荐标签 标签

  • Node.js

    Node.js 是一个基于 Chrome JavaScript 运行时建立的平台, 用于方便地搭建响应速度快、易于扩展的网络应用。Node.js 使用事件驱动, 非阻塞 I/O 模型而得以轻量和高效。

    139 引用 • 269 回帖 • 31 关注
  • IBM

    IBM(国际商业机器公司)或万国商业机器公司,简称 IBM(International Business Machines Corporation),总公司在纽约州阿蒙克市。1911 年托马斯·沃森创立于美国,是全球最大的信息技术和业务解决方案公司,拥有全球雇员 30 多万人,业务遍及 160 多个国家和地区。

    17 引用 • 53 回帖 • 140 关注
  • 工具

    子曰:“工欲善其事,必先利其器。”

    288 引用 • 734 回帖 • 1 关注
  • 一些有用的避坑指南。

    69 引用 • 93 回帖 • 1 关注
  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖 • 1 关注
  • NetBeans

    NetBeans 是一个始于 1997 年的 Xelfi 计划,本身是捷克布拉格查理大学的数学及物理学院的学生计划。此计划延伸而成立了一家公司进而发展这个商用版本的 NetBeans IDE,直到 1999 年 Sun 买下此公司。Sun 于次年(2000 年)六月将 NetBeans IDE 开源,直到现在 NetBeans 的社群依然持续增长。

    78 引用 • 102 回帖 • 684 关注
  • SOHO

    为成为自由职业者在家办公而努力吧!

    7 引用 • 55 回帖 • 5 关注
  • 新人

    让我们欢迎这对新人。哦,不好意思说错了,让我们欢迎这位新人!
    新手上路,请谨慎驾驶!

    52 引用 • 228 回帖
  • 小薇

    小薇是一个用 Java 写的 QQ 聊天机器人 Web 服务,可以用于社群互动。

    由于 Smart QQ 从 2019 年 1 月 1 日起停止服务,所以该项目也已经停止维护了!

    34 引用 • 467 回帖 • 747 关注
  • Electron

    Electron 基于 Chromium 和 Node.js,让你可以使用 HTML、CSS 和 JavaScript 构建应用。它是一个由 GitHub 及众多贡献者组成的活跃社区共同维护的开源项目,兼容 Mac、Windows 和 Linux,它构建的应用可在这三个操作系统上面运行。

    15 引用 • 136 回帖
  • Bootstrap

    Bootstrap 是 Twitter 推出的一个用于前端开发的开源工具包。它由 Twitter 的设计师 Mark Otto 和 Jacob Thornton 合作开发,是一个 CSS / HTML 框架。

    18 引用 • 33 回帖 • 668 关注
  • C

    C 语言是一门通用计算机编程语言,应用广泛。C 语言的设计目标是提供一种能以简易的方式编译、处理低级存储器、产生少量的机器码以及不需要任何运行环境支持便能运行的编程语言。

    85 引用 • 165 回帖 • 5 关注
  • Solidity

    Solidity 是一种智能合约高级语言,运行在 [以太坊] 虚拟机(EVM)之上。它的语法接近于 JavaScript,是一种面向对象的语言。

    3 引用 • 18 回帖 • 402 关注
  • CongSec

    本标签主要用于分享网络空间安全专业的学习笔记

    1 引用 • 1 回帖 • 16 关注
  • 自由行
    5 关注
  • GitLab

    GitLab 是利用 Ruby 一个开源的版本管理系统,实现一个自托管的 Git 项目仓库,可通过 Web 界面操作公开或私有项目。

    46 引用 • 72 回帖
  • 单点登录

    单点登录(Single Sign On)是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

    9 引用 • 25 回帖
  • Caddy

    Caddy 是一款默认自动启用 HTTPS 的 HTTP/2 Web 服务器。

    12 引用 • 54 回帖 • 160 关注
  • Love2D

    Love2D 是一个开源的, 跨平台的 2D 游戏引擎。使用纯 Lua 脚本来进行游戏开发。目前支持的平台有 Windows, Mac OS X, Linux, Android 和 iOS。

    14 引用 • 53 回帖 • 538 关注
  • SpaceVim

    SpaceVim 是一个社区驱动的模块化 vim/neovim 配置集合,以模块的方式组织管理插件以
    及相关配置,为不同的语言开发量身定制了相关的开发模块,该模块提供代码自动补全,
    语法检查、格式化、调试、REPL 等特性。用户仅需载入相关语言的模块即可得到一个开箱
    即用的 Vim-IDE。

    3 引用 • 31 回帖 • 104 关注
  • Log4j

    Log4j 是 Apache 开源的一款使用广泛的 Java 日志组件。

    20 引用 • 18 回帖 • 30 关注
  • OpenShift

    红帽提供的 PaaS 云,支持多种编程语言,为开发人员提供了更为灵活的框架、存储选择。

    14 引用 • 20 回帖 • 632 关注
  • 脑图

    脑图又叫思维导图,是表达发散性思维的有效图形思维工具 ,它简单却又很有效,是一种实用性的思维工具。

    30 引用 • 96 回帖 • 1 关注
  • Gitea

    Gitea 是一个开源社区驱动的轻量级代码托管解决方案,后端采用 Go 编写,采用 MIT 许可证。

    4 引用 • 16 回帖
  • Netty

    Netty 是一个基于 NIO 的客户端-服务器编程框架,使用 Netty 可以让你快速、简单地开发出一个可维护、高性能的网络应用,例如实现了某种协议的客户、服务端应用。

    49 引用 • 33 回帖 • 25 关注
  • ReactiveX

    ReactiveX 是一个专注于异步编程与控制可观察数据(或者事件)流的 API。它组合了观察者模式,迭代器模式和函数式编程的优秀思想。

    1 引用 • 2 回帖 • 162 关注
  • Vue.js

    Vue.js(读音 /vju ː/,类似于 view)是一个构建数据驱动的 Web 界面库。Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。

    265 引用 • 666 回帖