Skip to content

重学前端

开篇词 | 从今天起,重新理解前端

前端发展史:从青铜到黄金时代

我自己是在 2006 年开始接触前端的。现在回想起来,那会儿前端还处于史前的“青铜时代”,甚至网页的主要交互都还是依靠切换超链接来完成的。

  1. 前端的史前记忆:“青铜时代”

那时候,谷歌刚刚基于 Ajax 发布的 Gmail 也没多久,虽然这项伟大的技术标志着 Web 1.0(静态网页)到 Web 2.0(动态网页)的迈进,但在国内依然少有人懂,如果当时谁可以对这项技术侃侃而谈,那简直就是大神的级别了。

当时我还是个学生,喜欢前端纯粹是兴趣使然。那时我混黑白棋社区,想着给黑白棋界面写插件,但自己又不懂界面相关的知识,于是开始通过各种方式学习前端。

真想学的时候才发现网络上的前端资料很是稀缺,所以我基本上都是先从图书馆借书,然后再在电脑上跑案例验证这样的方式来学习的,现在想起来,还真是一段艰难的岁月。

当然,这段经历也为我日后的前端生涯悄悄埋下了一颗种子,我逐渐开始把自己的职业规划路线放在了前端上。

这在当时是个不可思议的想法,因为那时的前端岗位不论从收入上还是在职责上,都远落后于其他岗位。但是,我基于对技术发展趋势的判断,认为前端在未来会越来越重要。

  1. 进入发展期的前端:“白银时代”

2008 年,我毕业了,也很幸运地得到了一个既能发挥我的 C++ 长处,又能兼顾前端发展规划的职位:微软北京的软件开发工程师,恰好负责的是 Windows CE 上的 IE 浏览器开发,在这里,我接触到了当时最先进的软件工程体系,并且积累了很多 UI 架构经验。

两年后,我加入了盛大做电子书,负责电子书的文本排版工作,这个工作是一个既写底层又写 JavaScript 的岗位,同时排版引擎也是浏览器的重要组成部分,也让我对浏览器的工作原理有了更深入的理解。

在盛大后期,我加入了 WebOS 项目,负责前端框架,我开始基于移动的角度思考前端交互和框架,这份工作让我离前端又近了一步。

但是很遗憾,因为种种原因,我在微软和盛大的几个项目都不算成功,除了电子书实际上市但销量不高,Windows CE 7.0 和盛大的 WebOS 都在公司内部夭折。

自己亲手构建的产品,却因为非技术原因没有服务到最终用户,对我来说,是件非常遗憾的事情。不过,这段时间,也让我更加确信前端技术的价值。

回过来看,那几年,前端技术开始了它的大踏步发展,那一段时间,可以说是前端的“白银时代”。最直观的表现之一就是前端逐步从后端分离了出来,它的代码也变得复杂了起来,还需要保存数据、处理数据、生成视图等等。

悄然之间,我发现前端已经从零散的“工序”逐步发展成为有体系和发展目标的职能,同时,在越来越大的前端团队中,工程化的思想也逐渐萌芽。我深有感触,前端已经不再是别人眼中的“小菜一碟”了。

  1. 从前端到“全端”:“黄金时代”

在这样的行业背景里,从盛大离职后,我加入了阿里巴巴做手机淘宝开发,这也是我首次从事真正的前端工作。

在手机淘宝,前端团队的各种基础设施也逐渐建立了起来,从最开始的多屏适配方案、基础库、工具链到页面搭建平台和性能体系,最后到客户端融合方案 Weex,我随着团队一起经历了业务发展、团队自身成长和行业变革。

与此同时,在我加入阿里巴巴后的这段时间里,随着移动时代的到来,前端也开启了自己的“黄金时代”,它的职责变得更加重要,有了独立的发布权限,技术也变得更加复杂。

一些传统软件开发和互联网服务端的方法论逐步移植到前端开发中,并形成了前端自己的工程体系,诸如持续集成、前后端分离、线上监控……

架构方面,前端架构的任务也从简单的解决兼容和风格问题,逐步过渡到提倡组件化和 UI 架构模式,最后形成了新一代的前端框架 React、Vue 和 Angular,他们也在竞争和互相学习中成长。

前端开发之痛:散点自学 + 基础不牢

正当处于“黄金时代”的前端技术在全力以赴极速前行之时,我却发现,前端开发者们的步伐似乎渐渐有些跟不上了。

因为在我职业发展的后半段,面试和培养前端工程师已经成为我的长期工作职责。在这期间,我意识到,目前的前端教育几乎是完全缺失的。

在面试应届生过程中,我会习惯性地问表现比较好的同学“你是如何学习前端的”,而我得到的答案多是“自学”“在社团学习”,却从未听到过“在学校学习过”这样的答案。

而对于工作之后的前端开发者来说,没有系统学习的问题仍然存在,常常有一些具有多年从业经验的工程师,仍然会在看到一些用法时惊呼:“还可以这样!”

在我看来,这些用法都是一些基础的不能再基础的知识点,但是他们却浑然不知。

如果深入进去了解,你会发现,表面上看他们可能是一时忘记了,或者之前没注意,但实际上是他们对于前端的知识体系和底层原理没有真正系统地理解。

在阿里工作的时候,我戏称很多同学学前端的方式是“土法学前端”,他们对于知识的理解基本都停留在点上,从来没有大范围把这些点串成线,形成自己的知识体系,因此才会出现上面说的遗漏和盲点。

这个问题在一些一直在小公司工作的前端工程师身上非常突出。

经常能看到一些案例,一些有技术追求、有热情的工程师,因为技术敏感度和主观能动性都不错,所以工作了五六年之后,逐步开始在自己的公司做一些技术管理相关的事情了。

但是,由于他们所在公司的业务并不复杂,也没有技术积累,所以他们自身的技术水平其实并不高,可以说还处于非常初级的阶段(可能面试连阿里 P6 都过不了)。

做了管理,技术没跟上,并且还错过了最佳的学习时间,这个境遇可想而知,他们在工作中大概率只能是被动地接受需求解决问题,然后也同时焦虑着自己的未来,焦虑着自己的竞争力。

关于前端工程师成长,我认为需要两个视角。一是立足标准,系统性总结和整理前端知识,建立自己的认知和方法论;二是放眼团队,从业务和工程角度思考前端团队的价值和发展需要。只有这样做,才能够持续发展,在高速发展的技术和工程浪潮中稳稳立足。

这也正是“重学前端”这个专栏的初衷,我希望提供一些视角,带你以完备、体系化的方式理解和思考前端的基础知识和工程实践。

除此之外,前端工程师也是开发工程师的一员,除了前端自身的领域知识和工程特点外,你还需要了解程序员通用的编程能力和架构能力。

所以,想要成为优秀的前端工程师,我觉得你需要通过系统地学习和总结获取知识,通过练习获取编程能力,通过工作经验来获取架构和工程能力。

当然,一个为期 3 个月的专栏无法穷尽前端庞杂的知识,讲知识点也不是我们的目标。知识点讲的再好再全,也不一定能记得住。

我们专栏的目标是帮助你建立自己的知识体系,根据你自己的理解把前端的领域知识链接起来,形成结构,这样做,不但能帮助你记忆知识,还能在其中发现自己知识的缺失,甚至可以凭借知识体系来判断知识的重要性,来决定是否要深入学习。

在这个专栏里,我将知识分成了四个模块来讲解:

JavaScript; CSS 和 HTML; 浏览器实践; 前端综合应用。

前三个模块是前端的基础知识,是个人的前端能力提升,而模块四则是前端团队发展相关的内容,有助于你和团队的整体提高。

在 JavaScript 部分中,我主要会从文法和运行时的角度去讨论 JavaScript 语言。它们是互相关联的,而语义就是文法到运行时之间的桥梁;它们分别又是完备的,任何语言特性都离不开两者,所以从语法和运行时的角度,我们都可以了解完整的 JavaScript。

CSS 和 HTML 部分,会侧重从语言和设计思想的角度来讲解,我们同样可以对两者的全貌建立一些认知。

浏览器部分,包含了浏览器工作的原理和一些重要的 API,包括 BOM、DOM、CSSOM 和其他一些内容。了解了这些知识,你才能把 JavaScript 和 HTML、CSS 连接起来,用 JavaScript 来实现功能。

前端综合应用部分,主要是我的一些工作经验,我会选择我在手淘和淘宝工作中的一些案例来辅助讲解。

前面,我说到前端是一个非常年轻的职业,但我仍然认为前端具有很多空间和机会,一些基础设施仍然简陋,前端的能力可以带来更多的业务场景,这些有待于我们去发掘。

前端社区非常活跃,新技术也在不断出现。在这样的环境下,机会和竞争并存,学习也犹如逆水行舟,不进则退,建立自己的知识体系和方法论,你才能够保持领先优势。

我希望从我的经验出发,给你一些启发和帮助,并借由这个专栏帮你建立自己的前端知识体系。同时,我也相信,在你们中间一定会产生更多能够带领前端领域取得突破的、优秀的前端工程师。


明确你的前端学习路线与方法

在“开篇词”中,我和你简单回顾了前端行业的发展,到现在为止,前端工程师已经成为研发体系中的重要岗位之一。可是,与此相对的是,我发现极少或者几乎没有大学的计算机专业愿意开设前端课程,更没有系统性的教学方案出现。大部分前端工程师的知识,其实都是来自于实践和工作中零散的学习。

这样的现状就引发了一系列的问题。

首先是前端的基础知识,常常有一些工作多年的工程师,在看到一些我认为很基础的 JavaScript 语法的时候,还会惊呼“居然可以这样”。是的,基础知识的欠缺会让你束手束脚,更限制你解决问题的思路。

其次,技术上存在短板,就会导致前端开发者的上升通道不甚顺畅。特别是一些小公司的程序员,只能靠自己摸索,这样就很容易陷入重复性劳动的陷阱,最终耽误自己的职业发展。

除此之外,前端工程师也会面临技术发展问题带来的挑战。前端社区高度活跃,前端标准也在快速更新,这样蓬勃发展对技术来说无疑是好事,但是副作用也显而易见,它使得前端工程师的学习压力变得很大。

我们就拿 JavaScript 标准来说,ES6 中引入的新特性超过了过去十年的总和,新特性带来的实践就更多了,仅仅是一个 Proxy 特性的引入,就支持了 VueJS 从 2.0 到 3.0 的内核原理完全升级。

缺少系统教育 + 技术快速革新,在这样的大环境下,前端工程师保持自学能力就显得尤其重要了。

那么,前端究竟应该怎么学呢?我想,我可以简单分享一下自己的经验。

学习路径与学习方法

首先是 0 基础入门的同学,你可以读几本经典的前端教材,比如《JavaScript 高级程序设计》《精通 CSS》等书籍,去阅读一些参考性质的网站也是不错的选项,比如MDN。

如果你至少已经有了 1 年以上的工作经验,希望在技术上有一定突破,那么,这个专栏就可以是你技术进阶的一个选项了。

在这个专栏中,我希望传达的不仅仅是具体的知识点,还有体系架构和学习方法。我希望达到三个目标:

带你摸索出适合自己的前端学习方法; 帮助你建立起前端技术的知识架构; 让你理解前端技术背后的核心思想。

在开始具体的知识讲解之前,这篇文章中,我想先来谈两个前端学习方法。

第一个方法:建立知识架构

第一个方法是建立自己的知识架构,并且在这个架构上,不断地进行优化。

我们先来讲讲什么叫做知识架构?我们可以把它理解为知识的“目录”或者索引,它能够帮助我们把零散的知识组织起来,也能够帮助我们发现一些知识上的盲区。

当然,知识的架构是有优劣之分的,最重要的就是逻辑性和完备性。

我们来思考一个问题,如果我们要给 JavaScript 知识做一个顶层目录,该怎么做呢?

如果我们把一些特别流行的术语和问题,拼凑起来,可能会变成这样:

类型转换; this 指针; 闭包; 作用域链; 原型链;

这其实不是我们想要的结果,因为这些知识点之间,没有任何逻辑关系。它们既不是并列关系,又不是递进关系,合在一起,也就没有任何意义。这样的知识架构,无法帮助我们去发现问题和理解问题。

如果让我来做,我会这样划分:

文法 语义 运行时

为什么这样分呢,因为对于任何计算机语言来说,必定是“用规定的文法,去表达特定语义,最终操作运行时的”一个过程。

文法: 词法,语法 语义 运行时: 类型,执行过程

我来解释一下这个划分。

文法可以分成词法和语法,这来自编译原理的划分,同样是完备的。语义则跟语法具有一一对应关系,这里暂时不区分。

对于运行时部分,这个划分保持了完备性,我们都知道:程序 = 算法 + 数据结构,那么,对运行时来说,类型就是数据结构,执行过程就是算法。

当我们再往下细分的时候,就会看到熟悉的概念了,词法中有各种直接量、关键字、运算符,语法和语义则是表达式、语句、函数、对象、模块,类型则包含了对象、数字、字符串等……

这样逐层向下细分,知识框架就初见端倪了。在顶层和大结构上,我们通过逻辑来保持完备性。如果继续往下,就需要一些技巧了,我们可以寻找一些线索。

比如在 JavaScript 标准中,有完整的文法定义,它是具有完备性的,所以我们可以根据它来完成,我们还可以根据语法去建立语义的知识架构。实际上,因为 JavaScript 有一份统一的标准,所以相对来说不太困难。

如果是浏览器中的 API,那就困难了,它们分布在 w3c 的各种标准当中,非常难找。但是我们要想找到一些具有完备性的线索,也不是没有办法。我喜欢的一个办法,就是用实际的代码去找:for in 遍历 window 的属性,再去找它的内容。

我想,学习的过程,实际上就是知识架构不断进化的过程,通过知识架构的自然延伸,我们可以更轻松地记忆一些原本难以记住的点,还可以发现被忽视的知识盲点。

建立知识架构,同样有利于面试,没人能够记住所有的知识,当不可避免地谈到一个记不住的知识,如果你能快速定位到它在知识架构中的位置,把一些相关的点讲出来,我想,这也能捞回不少分。(关于前端具体的知识架构,我会在 02 篇文章中详细讲解。)

第二个方法:追本溯源

第二个方法,我把它称作追本溯源。

有一些知识,背后有一个很大的体系,例如,我们对比一下 CSS 里面的两个属性:opacity, display

虽然都是“属性”,但是它们背后的知识量完全不同,opacity 是个非常单纯的数值,表达的意思也很清楚,而 display 的每一个取值背后都是一个不同的布局体系。我们要讲清楚 display,就必须关注正常流(Normal Flow)、关注弹性布局系统以及 grid 这些内容。

还有一些知识,涉及的概念本身经历了各种变迁,变得非常复杂和有争议性,比如 MVC,从 1979 年至今,概念变化非常大,MVC 的定义几乎已经成了一段公案,我曾经截取了 MVC 原始论文、MVP 原始论文、微软 MSDN、Apple 开发者文档,这些内容里面,MVC 画的图、箭头和解释都完全不同。

这种时候,就是我们做一些考古工作的时候了。追本溯源,其实就是关注技术提出的背景,关注原始的论文或者文章,关注作者说的话。

操作起来也非常简单:翻翻资料(一般 wiki 上就有)找找历史上的文章和人物,再顺藤摸瓜翻出来历史资料就可以了,如果翻出来的是历史人物(幸亏互联网的历史不算悠久),你也可以试着发封邮件问问。

这个过程,可以帮助我们理解一些看上去不合理的东西,有时候还可以收获一些趣闻,比如 JavaScript 之父 Brendan Eich 曾经在 Wikipedia 的讨论页上解释 JavaScript 最初想设计一个带有 prototype 的 scheme,结果受到管理层命令把它弄成像 Java 的样子(如果你再挖的深一点,甚至能找到他对某位“尖头老板”的吐槽)。

根据这么一句话,我们再去看看 scheme,看看 Java,再看看一些别的基于原型的语言,我们就可以理解为什么 JavaScript 是现在这个样子了:函数是一等公民,却提供了 new this instanceof 等特性,甚至抄来了 Java 的 getYear 这样的 Bug。

结语

今天我带你探索了前端的学习路径,并提出了两个学习方法:你要试着建立自己的知识架构,除此之外,还要学会追本溯源,找到知识的源头。

这个专栏中,我并不奢望通过短短的 40 篇专栏,事无巨细地把前端的所有知识都罗列清楚,这本身是 MDN 这样的参考手册的工作。但是,我希望通过这个专栏,把前端技术背后的设计原理和知识体系讲清楚,让你能对前端技术产生整体认知,这样才能够在未来汹涌而来的新技术中保持领先的状态。


列一份前端知识架构图

在开始列框架之前,我想先来谈谈我们的目标。实际上,我们在网上可以找到很多参考资料,比如 MDN 这样的参考手册,又比如一份语言标准,但是我们的课程既不是一本参考手册,也不是一份语言标准。参考手册希望做到便于查阅、便于理解和全面,语言标准的目标是严谨、无遗漏、无歧义。

而我们的课程有什么不同呢?我认为,作为一个课程,有两个目标:一个是把无法通过查阅解决的原理和背景讲清楚,另一个是把不方便查阅和记忆的内容整理好。

我会尽量避免像前面提到的两种文档一样逐条目罗列知识点和细节,当然,这不是在说两种文档没有价值,而是我们各有分工,参考手册和语言标准做的事情,我们没必要重复去做,即使做了也不一定能做得更好。

在这个课程里,我希望能和你一起打造一个前端知识的框架,再把知识点做个遍历,这其中,有原理和背景的部分,我去讲解知识的原理和背景。如果没有的话,我们就去讲整理和记忆这部分知识的方法,这样,即使你遇见无法一下子记住的知识,也可以很容易地查阅参考手册和标准来解决。

如果让我做一个划分,前端的知识在总体上分成基础部分和实践部分,基础部分包含了 JavaScript 语言(模块一)、CSS 和 HTML(模块二)以及浏览器的实现原理和 API(模块三),这三个模块涵盖了一个前端工程师所需要掌握的全部知识。

学完这三个部分,你再结合基本的编程能力,就可以应对基本的前端开发工作了。实践部分(模块四)重点会介绍我在工作过程中遇到的问题和解决方案,希望这块内容能够帮助你和你的前端团队找到可能的发展方向和着力点。

JavaScript

3-1

在 JavaScript 的模块中,首先我们可以把语言按照文法、语义和运行时来拆分,这符合编程语言的一般规律:用一定的词法和语法,表达一定语义,从而操作运行时。

接下来,我们又按照程序的一般规律,把运行时分为数据结构和算法部分:数据结构包含类型和实例(JavaScript 的类型系统就是它的 7 种基本类型和 7 种语言类型,实例就是它的内置对象部分)。所谓的算法,就是 JavaScript 的执行过程。

类型部分中,对象比其它所有类型加起来都要更为复杂,所以我们会用较长的篇幅来讲解对象,包括它的一些历史和设计思路。

执行过程我们则需要按照从大结构到小结构的角度讲解,从最顶层的程序与模块、事件循环和微任务,到函数、再到语句级的执行。我们从粗到细地了解执行过程。

实例部分,对 JavaScript 来说类似基础库,JavaScipt 的内置对象多达 150 以上,考虑到我们即使逐次讲解也必定不如 MDN 更加细致全面,所以我们会从应用和机制的角度,挑选其中几个体系来讲解。

文法中的语法和语义基本是一一对应关系,在 JavaScript 标准中有一份语法定义表,它同样不适合一一讲解,我们会从 JavaScript 语法中特别的地方,以及与日常开发比较相关的地方来重点讲解,剩下的内容和词法部分,我们会带领大家做一些数据挖掘工作,从这份表格中找到一些和我们日常开发息息相关的内容。

语义的大部分内容我们会在运行时的讲解中透出,同时它又跟语法有对应的关系,所以我们不再单独拿出来讲解。

HTML 和 CSS

3-2

在 HTML 的部分,我们会按照功能和语言来划分它的知识,HTML 的功能主要由标签来承担,所以我们首先会把标签做一些分类,并对它们分别进行讲解。

我们都知道 HTML 的标签可以分为很多种,head 里面的我们称为元信息类标签,诸如 title、meta、style、link、base 这些,它们用来描述文档的一些基本信息。还有一类是一些诸如 section、nav 的标签,它们在视觉表现上跟 div 并没有区别,但是各有各的适用场景,我们把它们称作语义类标签。另外一类是 img、video、audio 之类的替换型媒体类标签,用来引入外部内容,平常开发中你也会经常用到。再有就是表单类的,比如 input、button。

所以,基于这样的分类,我把标签分成下面几种。

文档元信息:通常是出现在 head 标签中的元素,包含了描述文档自身的一些信息;
语义相关:扩展了纯文本,表达文章结构、不同语言要素的标签;
链接:提供到文档内和文档外的链接;
替换型标签:引入声音、图片、视频等外部元素替换自身的一类标签;
表单:用于填写和提交信息的一类标签;表格:表头、表尾、单元格等表格的结构。

我们的重点会放在前四种标签上,表单和表格较少用到,而且基本以查阅型知识为主,这里就不拿出来讲解了。

除了标签之外,我们还应该把 HTML 当作一门语言来了解下,当然,标记语言跟编程语言不太一样,没有编程语言那么严谨,所以,我们会简要介绍 HTML 的语法和几个重要的语言机制:实体、命名空间。

最后我们会介绍下 HTML 的补充标准:ARIA,它是 HTML 的扩展,在可访问性领域,它有至关重要的作用。

CSS 部分,按照惯例,我们也会从语言和功能两个角度去介绍。在语言部分,我们会从大到小介绍 CSS 的各种语法结构,比如 @rule、选择器、单位等等。功能部分,我们大致可以分为布局、绘制和交互类。

在布局类我们介绍两个最常用的布局:正常流和弹性布局。绘制类我们则会分成图形相关的和文字相关的绘制。最后我们会介绍动画和其它交互。

浏览器的实现原理和 API

3-3

浏览器部分我们会先介绍下浏览器的实现原理,这是我们深入理解 API 的基础。

我们会从一般的浏览器设计出发,按照解析、构建 DOM 树、计算 CSS、渲染、合成和绘制的流程来讲解浏览器的工作原理。

在 API 部分,我们会从 W3C 零散的标准中挑选几个大块的 API 来详细讲解,主要有:事件、DOM、CSSOM 几个部分,它们分别覆盖了交互、语义和可见效果,这是我们工作中用到的主要内容。

其他的 API 怎么办呢,别着急,在最后,我会给出一份 Chrome 已经实现的 API 跟 W3C 标准的对应关系和它的生成过程,来覆盖其它部分。

前端工程实践

3-4

最后一个模块是前端工程实践。我们在掌握了前面的基础知识之后,也就基本掌握了做一个前端工程师的底层能力。在这个模块中,我选择了性能、工具链、持续集成、搭建系统、架构与基础库这几个方向的前端工程实践案例,来与你一起分享我的经验。

性能 首先我们会谈谈性能。对任何一个前端团队而言,性能是它价值的核心指标,从早年“重构”的实践开始,前端有通过性能证明自己价值的传统。但是性能并非细节的堆砌,也不是默默做优化,所以,我会从团队的角度来跟你一起探讨性能的方法论和技术体系。

工具链 工具链下一个案例是工具链。这一部分,我将会探讨企业中工具链的建设思路。对一个高效又合作良好的前端团队来说,一致性的工具链是不可或缺的保障,作为开发阶段的入口,工具链又可以和性能、发布、持续集成等系统链接到一起,成为团队技术管理的基础。

持续集成
接下来还会给大家介绍前端的持续集成,持续集成并非一个新概念,但是过去持续集成概念和理论都主要针对软件开发,而对前端来说,持续集成是一个新的课题(当然对持续集成来说,前端也是一个新课题),比如 daily build 就完全不适用前端,前端代码必须是线上实时可用的。这一部分内容将会针对前端的持续集成提出一些建设的思路。

搭建系统
接下来的案例是搭建系统,前端工作往往多而繁杂,针对高重复性、可模块化的业务需求,传统的人工开发不再适用,搭建系统是大部分大型前端团队的选择。这一部分内容我将会介绍什么是搭建系统,以及一些常见的搭建系统类型。

架构与基础库
最后一个部分,会给大家介绍前端架构和基础库的知识。软件架构师主要解决功能复杂性的问题,服务端架构师主要解决高流量问题,而前端是页面间天然解耦,分散在用户端运行的系统,但是前端架构也有自己要解决的问题。

前端需求量大、专业人才稀缺,更因为前端本身运行在浏览器中,有大量兼容工作要做。所以前端架构的主要职责是兼容性、复用和能力扩展。这一部分文章我将会介绍前端架构工作的一些思路和切入点。

上面的这些案例来自我在领导手淘前端团队时的经验,和我在阿里巴巴工作参与晋升面试时听到的案例,这些内容几乎是每一个年轻的前端团队成长过程中都会需要的基础设施。

好了,前端的知识体系我们大致列出来了。你可能发现了,知识体系图中的每一个知识点,专栏里都有与之对应的文章,这也是我的初衷:希望借由讲解这 40 余个知识点,帮你建立起前端的知识框架。

3-5;

讲述形式

基于这份知识框架图,我们的课程主要采用两种讲述形式:一种是重点讲解的课程,一种是知识图谱型的课程。

重点讲解的课程我们会从技术的背景、原理和设计出发,把知识的内容呈现出来。这种形式适用于有体系和源流的知识,比较适合系统学习和理解,比如 JavaScript 中的对象、CSS 的排版。

知识图谱型的课程则提供一些方法,用表格或者脑图的形式来整理知识的结构。这种形式适用于零散的知识,比较适合记住大概,用到时去查阅,比如 JavaScript 的词法、HTML 中的所有标签、以及浏览器中的 API 就十分适合这样的讲解方式。

结语

今天我带你一起划分了前端的知识内容,前端的基础知识分成 JavaScript、HTML、CSS 以及浏览器四大重点模块,每个模块也分别有自己的技术重点。你可以在框架中,挑选你最需要的前端知识,按需学习。

当然,这篇文章最重要的是,我希望能帮你建立一个理解前端的全景图。这样,任何时候,你都能够体系地思考问题,分析问题。

你觉得你的划分跟我一样吗,你还有其他的想法,你觉得是否有想了解的知识不在其中,欢迎给我留言。