你们觉得作为一个前端，想去了解浏览器整个的渲染过程和执行过程而去学 C++有必要吗？

不是学了 C++就能看懂的吧。

理解了就可以转行做浏览器开发了...

讲道理，不用专门学 C++，你大概也能看懂。

当然你至少要有 C 的基础。。

真搞懂了这些还当什么前端...

有这种想法注定你学不会 c+

相信我这绝对是一条歪路

艺多不压身，不管学不学的成，你的技能树一定比一般前端广。

闲的.

难点应该不在 c++上,就像学习 linux kernel,难点不在 c 语言上一样.

看 google 的文档就可以了，然后非常熟练的使用 chrome 内置的工具多去分析页面就差不多了，比如 devtools, chrome://tracing, chrome://net-internals 等。

游戏开发者表示 无非就是如何高效的利用 opengl 的 API 组织数据。
浏览器相对于游戏就是外部的 context 不同而已，所以你要学的不是 C plus plus ，是 opengl 的渲染机制。什么是 VBO, 什么是 draw call 。

理解了这些再来看，才会事半功倍。

另外， V8 只是一个 js 解释器，如果想学编译的知识，去找一个更简单的语言或者 js 的早期版本是更好的选择，因为那会儿语言没这么复杂，也没这么臃肿，更容易让你了解到本质。

前端代码是运行在浏览器上的，了解它的原理能有助于写出性能更优的代码。 就题主说的“必要性”而言，这没有必要。 而艺多不压身，学多点东西无害

前端现在虽然挺火爆东西挺多，也只是看似挺多而已，只是不同工具办那几件事，可玩性太低了，
计算机本身的东西还是要搞的，语言不是问题， Javascript 这么简单的语法都啥都能折腾，问题是面向的平台和 api

不是必须，但是有助于你的技术提升~

透彻理解了以后就可以不当前端了 :-)

C++太了，三年都不得能了解浏览器整个的渲染过程

解析器（ HTML 、 CSS 、 Javascript ）、各个平台 context 的 drawXXX 回调、 OpenGL 贴图与渲染、 3D 坐标变换（计算机图形学）等。主要就这些东西，最原始的想象就是：你拿着笔，在固定的坐标，写什么字（颜色、大小等属性），画什么画。

题主你牛!!!

我觉得作为一个程序员 学 C++有必要

我觉的很有必要，要不然不是合格的前端

@jukka 现在的浏览器都是用 OpenGL 渲染的吗？

去了解是必需的，但是学 c++到什么程度不好说

up 主应该不会要学好 c++挣饭吃吧

有的, 很有必要. Webkit 的代码帮我在写 FORK 渲染器的时候帮了很大的忙.

罗升阳写过一系列浏览器源码解析博客 你可以看一下
确实难点不在 cpp 而是 GL 和 GPU 的理解

推断一下，“你们觉得作为一个前端，想去了解浏览器有必要吗？”

作为一个前端，没必要。
做为一个程序员，有时间的话看看 CPP 、浏览器实现还是很有意思的。

有很多东西学来对于工作可能没什么用，但是只要知道就很开心了。

我觉得没啥必要

c++点到为止即可，不然要投入大量精力，楼主更需要广泛涉猎 OpenGl 浏览器架构的。

浏览器的渲染过程跟 C++有什么关系?
浏览器又不是只能用 C++来写

前端程序员的美术基础是不是必须的呢？

就像 TCP 通信协议是每一个后端必须了解的一样，任何和 GUI 图形处理有关的应用都应该去了解一下 openGL 就算不立刻在项目里使用，也会得到较大的受益，不要因为 opengl 的学习曲线比较陡峭，看一次找不到头绪就放弃，据我所知大多数学习 opengl 入门都有一段较长的路 :)

我是做 java web 的，出于需要，看 tomcat 源码，然后看 react 模式，然后继续看 epoll,poll,select 。最近又对更底层感兴趣，开始看《编码》里面如何实现加法器，计算机是如何从 01 电路中产生想法进行构造的，我觉得只要感兴趣就去看咯。而且，你会发现这些在将来都会有作用。

这大概就跟学编译原理差不多吧

没啥不好的，就是个性价比问题，如果你有余力还有兴趣还是个 Geek 可以看呀，但要是想速成的话这个方法可能就不合适了吧。

@jukka Web 前端的核心部分，还真跟 OpenGL 关系不大。
OpenGL 是一个 GPU 3D 绘图的 API ，而前端渲染主要涉及的是 2D 矢量绘图，如果你只是搞游戏的话，对矢量绘图可能不是很了解。
简单来说， GPU 不适合 2D 矢量绘图。

游戏（尤其是追求画面效果的 3D 单机游戏）的 rendering 部分的最大目标之一是用最少的硬件资源得到最好的即时渲染效果，这个“好”往往是和“真实”相对应的，聚焦于灯光、贴图等方面，利用的图元是点、面等。而矢量图中，最重要的图元是 Path （有点像 PS 里面钢笔画出来的那玩意， SVG 里面也有涉及），对于填充、线型、曲率等细节的正确性要求较高，同时还存在一个文字排版的问题（这个倒是和游戏沾点边，因为 3D 里面到处都是的贴图无法直解决游戏 UI 文字渲染的问题）。

剩下的事情很简单，假如要用 GPU 渲染一个无填充矢量圆环路径，用单个四边面表示的话，那是对像素填充率的浪费，如果利用 3D 建模中的手段，大量面片拟合的话，且不论效果好不好，效率又成了问题。

@secondwtq opengl 不支持 2d 绘图？ opengl 取决于平台调用 gdi 或者 x11 进行 2d 绘图。

webgl 的 api 是 opengl es 的子集， opengl es 的 api 又是 opengl 的子集，你怎么能说没关系呢？

@jukka

cont.
据我所知，现代浏览器引擎主要的绘图工作是委托给 Cairo ， CoreGraphics ， Skia 这样的 2D 绘图引擎的。如果一般人要从零开始写这样一个绘图引擎，也应该主要使用 CPU 算法（根据我有限的 CG 知识，类似的算法也会在 GPU 底层被应用）。我上面所列举出的库，可能在实现细节中利用了 GPU 的 3D 加速，但是这部分内容和楼主的目的距离就太远了。不同的硬件，不同的 OS ，可能使用不同的渲染引擎，不同的渲染方式，我觉得这不是楼主想要的东西。

关于利用 GPU 进行 2D 渲染的问题，可以看一下这个项目 https://github.com/memononen/nanovg ，非常精致的一个库。不过在功能上好像依然没办法和 Cairo 这样高大全的项目相比。学术界也有一摞的 paper ，然而我还没有见到过大规模实际应用的详细信息。顺便， Khronos 是有矢量绘图 API 标准 OpenVG 的，但是目前的硬件实现好像并不能达到 universal 的程度（据说移动 GPU 有实现，桌面端的话， NVIDIA 在 OpenGL 上面做了一个扩展 NV_path_rendering ，并且做了一堆的广告）。

不过另一方面， Web 前端中是有 Hardware Acceleration 和 OpenGL 的概念的。这里可以和大家分享一下我的理解（主要来源于 WebKit 引擎， Apple 官方 repo ）：

* WebGL 。这个很直接，就是调用 GL 的 API 绘图，不过 WebGL 提供的 API 是 GLES 的（在 Win 里面可能被 ANGEL 转换掉了）。
* Canvas 。可以理解为 Cairo 等绘图引擎的接口直接暴露给了 JS 。灵活性高（理论上所有用其他元素能画出来的东西都能画出来，其他元素画不出来的照样画不出来），效率不大好说，但是最后还是由绘图引擎进行实际的绘图。
* Composition 。概念上类似于基于 Sprite 的 2D 游戏，就是将某些元素单独渲染到 GPU 贴图上，再渲染到页面中，目的是在动画发生时无需使用 2D 绘图引擎重绘该部分。当然有一个假定前提就是动画过程中该部分内容不会发生改变，因为根据以上所述， GPU 在绘图过程中扮演的角色是有限的，更准确的说，其能做的所有事情就是 play with the sprite ，面片的透明度、颜色、 transform ， etc. 这就是熟悉 CSS 的同学们喜闻乐见的 translate/scale/rotate3d, opacity 等属性的“硬件加速”。
不过需要注意的是这也不是必须的，因为基本都是 2D 引擎可以模拟出来的东西，编译时 FLAG 关掉，就可以 fallback 到 2D 的渲染模式。

如果有做 iOS 的同学的话，可以打个比方：浏览器中核心绘图引擎的作用类似于 CoreGraphics ， OpenGL 的作用类似于 CoreAnimation ，当然有可能 CoreAnimation 的底层就是 OpenGL 。

@wizardforcel

把范围限制在 现代 OpenGL 的 Core Profile 里面，如何 正确的实现 2D Vector 绘图？

WebGL 的问题 45L 解释的很清楚，不过是将不同类型的调用委托给不同的 API 。
并且我所讨论的是浏览器绘图工作中 dominant 的部分，我们现在日常所浏览的页面中，和 WebGL 沾上边的有几个？倒是 Composition 到处都是。

后面那条涉及到编译了。 v8 就是 c++写的，所以学 c++就能看懂源码了。

但如果你不想搞得这么复杂，可以尝试实现 c 语言的子集，或者 basic 。你可以搜索《自制 /手写编译器》来找这类教程。只是练手的话，不必非得用 c++来写，用 java 写也行，不过大多数教程都是 c 或者 c++写的，最好还是看看。

也可以用 flex 和 yacc 这种工具来快速生成（就像一些 lab 那样），但我觉得还是手写更能理解其原理。

不是应该跟着标准走吗？陷入到某种具体的实现应该是不靠谱的。

有条件尽量吧，适当了解一些原理对于性能优化总会有好处的，但是过度分析就不用了
我是做 php 后端的，我就想有时间分析一下 php 的运行原理之类的

有没有必要看个人吧，如果平时只是撸业务的，那恐怕没有太大必要，不过多了解实现并且（不可避免地）多翻标准对处理兼容性问题有一定好处。如果是做数据可视化或者做基础库 /框架的，会比较有用，因为优化的需求会比较多，而任何领域的优化都需要足够的底层知识作为基础。

至于专门学 C++ 是不是显得矫情……关键要看楼主计算机基础如何，这些东西说白了也就是大型软件项目而已，如果计算机基础不行（图形学、编译原理、计算机网络等），光看 C++ 是没有用的，还是会一头雾水，还不如先补基础。另外不能说不需要学 C++，因为这些引擎通常含有大量 C++ 技巧（自己实现的智能指针，元编程 etc.），即使你相应的基础知识很熟，要想真的读懂代码也还是要对 C++ 有足够了解。

另外渲染引擎和 Javascript 引擎是两个次元的东西，前者代码量一般是后者十倍以上，而且对应的标准长度大概是后者的…………百倍以上？前者主要是绘制的计算和 DOM 的实现，大概对于普通前端来说比较上层的那些东西是可以直接开始看的（无非就是把标准里的要求实现出来而已，对着 W3C 和 WHATWG 的标准翻即可），但是里面一些细节（比如 HTML/CSS parser ）可以先跳过，具备了足够基础后再来看也无妨。另外最底层的绘制细节一般都交给了 Cairo 之类的图形库，所以没有图形学相关知识的话也可以先当成黑盒子跳过……

Javascript 引擎的话，如果楼主有足够的编译原理基础又不想跑太偏的话，也是可以直接看的吧……（愿意跑偏一点的可以看看 Lua 的实现这种，相似之处不少，而且相对简单得多）。但是如果 lexer 啊递归下降的 parser 啊 SSA 啊 JIT 这些都不知道是啥的话，来看 V8 之类的引擎肯定会一头雾水的……最起码也得能看懂 ECMAScript 的标准里的文法吧？如果发现看不懂的话，可能还是先去学学编译原理合适些……

还有我觉得楼主似乎应该搞清楚一个浏览器的架构先……比如不要把 V8 和 Chakra 归成 “浏览器内核”？要知道在 Google 啊 M$ 啊之类的地方，做 Javascript 引擎的团队通常也是跟浏览器团队分开的，有不同的组织和 leader ，而且后者一般人多得多…… Javascript 引擎团队更多的是需要对编程语言和高级语言虚拟机有深入了解的人，浏览器团队一般收的人会多元化一些，因为浏览器是个更加庞大、涉及更多领域的项目。而且通常 Javascript 引擎不止为浏览器服务（ Node.js ， M$ 的 UWP 等），所以他们需要让这个引擎能够嵌入到非浏览器环境去，自然不能跟浏览器耦合太重。举个栗子来说，早期的 V8 团队都跑去搞 dart 了，而早期的 IE 团队在 M$ 高层不重视 IE 之后很多都跑去搞 WPF 了，大概就能体会到两者技能树的不同了吧……

@joyee 据我了解， JS 引擎主要重心是优化（至于 ES6 新特性的实现什么的就不是很清楚了），这也是现代编译器工程的重点。比如 WebKit 的 JSC 引擎就从最开始的 tree 解释器，发展到 bytecode 解释器，再到现在的 LLInt - Method JIT - DFG - FTL 架构，轮子一点没少造。

不过传统上 JS 引擎确实被认为是“浏览器内核”的重头戏。我最早认识 Chrome 好像也是看到 V8 跑分比较吊，感觉在很多人眼中 Layout engine 完全被无视的样子。

楼主如果去看 Compiler 前端的东西的话，我觉得作用是有助于理解语言中一些语法设计和坑。不过我发觉现在一个现象是，一些教科书之类的东西偏向于讲解静态语言，实际遇到的许多项目则是动态语言。这个地方 VM 优化比前端的分量要重很多，我倒是没有太大兴趣，但是这也是楼主研究的空间。对于后端这部分，我感觉楼主大致了解一下的话，可以更深入地理解一些 JS 对象、属性、闭包、函数调用等方面的效率问题，当然这些和所针对的引擎有很大关系。

@secondwtq

我的意思是，要看懂 JS 引擎，起码得具备基本的编译原理知识，否则光是编译器前端就已经看不下去了，更不要提后端的优化。但是具备了基本的编译原理知识，起码可以看懂 JIT 以外的大部分东西。目前各个 Javascript 引擎都是解释器+ JIT 编译器的架构了，包括 V8 这个编译器忠实信徒都为资源有限的设备搞出了 ignition ， Chakra 做跨平台移植也是先不管 JIT ，将解释器移植起来再说。所以可以先看懂前端+解释器+GC 的部分，再去深入研究 JIT ，因为后者起码还得对汇编和计算机组成原理有足够的了解才能向下看，恐怕对于前端来说跑得更偏了……

不过和 layout engine 相比，显然 Javascript 引擎更有趣吧（更像一个 big clean problem ，虽然跟其他语言比一点都不 clean ……）， layout engine 感觉就是在跟 W3C 和后面那成山成海的 spec 搏斗，搏斗的同时还要在一个庞大无比的代码山里做性能优化，看起来就枯燥的多……

Javascript 引擎们反倒更像是普通的高级语言引擎，何况脱离浏览器的使用场景也不少了，能从其他语言的实现里借鉴的东西也很多，不少搞 Javascript 引擎的人以前都是搞 Java 啊 C# 啊的实现出身的。如果有其他高级语言实现的经验切换到 Javascript 的次元相对来说要容易一些……（除了要适应一下各种反人类反优化的语言设计……）

@secondwtq

感谢回复。:)
本人不是 web 出生，不太了解前端的机制，臆测了一些表示抱歉。

那你是不是顺带把承载浏览器的操作系统也研究一下？我觉得做什么需要什么再去学什么。胡乱学习基本没几天你就忘了。

学 C++是值得的，但我觉得没有动力不大可能看得懂 JS 引擎的代码。难点不是 C++，而是它本身的理论基础一般人不会有接触。

@bk201 我反而是觉得编译啊，图形啊， system 这些东西国内搞的公司太少，当兴趣研究的人也太少，教程也少，这是不正常的，因为任何一个对计算机有兴趣的人都不满足仅仅调用 api 。前端我不评论，我也没写过几次，后端整天写 curd 我都觉得烦。

不妨先看这两个课程: https://www.udacity.com/courses/ud884 和 https://www.udacity.com/courses/ud860

如果能知道浏览器执行过程所用到的各种库能事半功倍

后面的回复比较有意思了，作为前浏览器开发者补充一下吧：

- 现代浏览器渲染引擎里 2D 绘图的地位不如以前了，大量新的 CSS / DOM 操作都要求把工作放到 GPU 完成，所以虽然 CoreGraphics/Skia 这样的库依然是渲染引擎的核心依赖，但要理解整个渲染流程只理解绘制 (在 Blink 和 WebKit 里叫 painting) 是远远不够的，还要理解 layout 和 compositing ，三者紧密结合。
- 现代浏览器的复杂程度导致个人要对整个引擎的架构和实现有很清晰的了解都很难了，大部分人会选择专攻一个方向，比如你选择 graphics 方向就会专攻用 GPU 做 compositing ，选择 layout 方向就会研究 CSS 的种种特性 (这倒是跟前段需要了解的部分有重叠)，选择 painting 部分则会去学习 CG/Skia 这些库的使用和优化等等。一般都先成为了一个领域的专家再考虑兼顾一下和其他领域接口的细节。

- V8 这种 Javascript 引擎的内部实现其实跟浏览器以及 DOM 的关系不大，除非你要在 Javascript 语言方面有作为，否则不怎么需要了解 v8 的实现细节 (事实上大部分 Blink 的开发者和 v8 的开发者尽管在一个公司都很少有交流)。

- 了解内部实现有没有帮助？当然是有的，但见效慢，对于前端而言应该更多关注各个浏览器平台的布道师们的 blog 和讲座，那些才是更立竿见影的，比如 Chrome 的年度开发者会议就是主讲比如怎么用 Chrome DevTools 调试和优化 Web 应用的。如果你真的对内部实现很有兴趣再去关注 Blinkon 、 CSS Houdini 这些会议。

就跟没考上大学但又想自学量子力学一样

为啥要给自己设限呢？想学什么就学什么啊。

标记一下

作为前端你读标准就够了，实现不用太在意，跟前端差太远了

秋怡在上面出现了啊，再贴一个她的知乎回答。

https://www.zhihu.com/question/29973122/answer/46405754

不一定要学 C++， 233
https://www.zhihu.com/question/29261736/answer/45328232
不过 Servo 的 JS 引擎现在仍然是 C++写的。
Rust 的 JS 引擎倒是有几个，不过都是比较业余的。最近 Chakra 开源应该能带来一阵自己写 JS 引擎的热潮吧， 17 年应该能看到效果。

看你什么 level ，如果你是 bat 前端里面或相对 bat 前端顶级高手了，完全没问题；
比如
作为 dba 去读 mysql 源码；作为运维去读 linux kernel 源码；（很有必要）
我的体会，读个屁啊， level 没那么高，不太可能有什么造诣。

@bombless 记得有一次看 Rust 团队的人出来做 talk 提到过用 Rust 写 JS 引擎这个问题，目前的看法是没什么必要，因为 Rust 最重要的特性之一是 safety ，而给浏览器写一个 JS 引擎没有 JIT 根本不能投入生产，而要写 JIT 那基本上就是无穷无尽的 unsafe 了（本质上就是生成汇编然后塞进一个 executable memory ，如何安全的起来……）

其实有一类前端应用是真的需要了解这些的数据可视化和游戏开发，典型特征是富交互+大量动画和计算+浏览器负荷重+需要保持一定帧率才不影响用户体验。如果你的工作强迫你天天打开火焰图和各种 profiler 优化再优化，那么这些知识就比较重要了……

举个栗子，如果你不知道在 WebKit 系内核下访问 offsetParent 之类的属性会导致 relayout ，然后在类似 mousemove 里的事件里不断地去触发这些东西，量到了一定程度就可能导致丢帧卡顿。如果不知道 var 会导致内存分配，并且在 V8 里申请分配足够内存后会引发 GC 停顿，于是在 requestAnimationFrame 里不断分配大量内存用于计算，也会造成动画卡顿。或者在每帧执行的函数里引发各种导致你的函数无法被 inline 的东西，比如 eval/with ……另外虽然 JS 有 GC ，但写的不好依然会引发内存泄露，在需要处理大量数据的可视化项目里，特别是拿去做公关的大屏项目里，是很严重的……你总不能发现内存爆了，在众目睽睽之下刷新网页吧……

如果你的项目火焰图稀疏无比且面积小，那一般看浏览器实现对日常工作帮助不大，最多了解一下兼容性问题根源+熟悉一下标准？

没有。你用到的前端库的源码看完了么？没有的话，为什么要去看跟本职工作距离甚远的代码呢？从另一方面来讲，这种细致的观察，就好比生物学家去研究量子物理，太舍近求远了。

不过，如果真觉得有兴趣，那就学呗。

只是想了解直接找别人的博客看就行了，要深入去看，那已经完全脱离了前端了范围，不仅数据结构算法基础要好，要熟悉 C++，要熟悉底层图形渲染，要跟系统底层打交道，全部会了之后，你已经不是前端了，工资也高了十几个档次

渲染 HTML 和 V8 没有关系。
V8 是 js 解释引擎。

单纯的 V8 和浏览器都没有关系。你看看 node.js 。

如果想要了解浏览器，绝对不是 V8 。而是 Webkit 这样的大家伙。

了解渲染主要还是学 Opengl 可编程管线吧...
C++如果 webkit 代码没用到什么奇怪的模板技巧，大概去了解语法就可以看懂源代码了吧。
我自己只懂点 html/css ，之前用 shader 做过东西，有一次去翻一本讲解 webkit 的书，渲染那部分读起来还是挺好懂的。

有时间兴趣就学，学了只有好处没坏处

不用 C++，这是基础。。。

了解个大概就差不多了，没必要扣底层代码。

我也是前端，也在学习 C++
但目的不是为了了解浏览器
而是为了其他的，比如无人机