作为一名前端新人，可以说生在了一个前端繁荣发展的时代，似乎每过几天前端世界里都会有新东西冒出来，令人眼花缭乱。在往更深更广的领域探索之前，我实在觉得有必要整理下情绪，尝试找到一条能够将前端知识串起来的线。而当我开始考虑对前端的理解时，脑海里首先浮现出来的是一张再熟悉不过的页面，那就从页面说起好了。
前端每天都在和页面打交道，页面是什么，它又是怎样到达我们面前呢?
一张页面的生平
一张页面放在眼前，你看到了什么?略作思考后答：可见的元素和数据呈现、需要触发的交互或请求、不可见的逻辑处理。这么想其实也没错，转念一想，这些东西有什么共性吗?答：信息。
我以为页面是以浏览器为宿主的信息交换的出入口。乍一听可能有点不知所云，别急，且听小僧细细道来。
以浏览器为宿主没啥说的，看官老爷现在看到的这篇文章便是在浏览器中展示。而说到信息交换(重点来啦)，我们还是拿这篇文章来举栗子。
我想了个现在不做说明的办法把这篇文章丢到了我的服务器上的某个内存空间，我现在想在我的设备上看到这篇文章。“我想看”，这是一个信息，我想用这个信息和我的服务器交换这篇文章(同样也是信息)。我借助我的浏览器(实际上是这个进程占用的端口)和服务器(某个端口)进行这样通信，我们遵循协议，按层级组装信息，彼此理解，拥抱之后微笑着给出答复
于是我的浏览器得到了文章这个信息，开始来生成一张页面，而这个页面实际上就是前面所说的信息交换的出口，是将交换后得到的信息加工再呈现到我面前
看到这里我突然觉得这篇文章写得挺用心的，我想给作者点个赞，于是我注意到右上角有个星，我毫不犹豫点了一下。“我要点赞”，这是又一个信息，我点下去的时候，触发了一个事件，这个事件的逻辑代码里我再次向服务器发起了一个信息交换的请求。这个时候页面就承担了信息入口的角色，这个信息从页面上到达茫茫网络，辗转漂泊到我的服务器，告诉我我自己给自己点了个赞。于是我在数据库中添加了一条记录，并将这个信息返回。
我的js代码里接收到这个返回的信息，我想起来我是个爱慕虚荣的男子，我是不是应该把这个信息处理下，表现在页面上?于是我做了简单的逻辑处理，把页面点赞数加了1。看，页面上点赞加1了!页面又成了信息的出口，我心满意足，微笑着关闭了我的浏览器。
以信息交换为线，试图理解前端的知识体系
前端所做的努力都可以围绕着如何建设更好更高效的信息交换出入口来展开。
遛一遛前端的过去。
前端最初的目标很明确，就是将存储在服务器上的静态页面(信息)在客户端(浏览器)中以页面形式展示给用户。那个时候可能就是简单的HTML+少量的CSS和JavaScript。
服务端技术兴起以后，出现了表单作为页面上的信息交换的入口，而出口却没有明确的输出形式，服务端语言和客户端语言没有明确分工，代码混杂在一起，可读性极差(接触过前后端高耦合代码的我差点哭出声)。
加快步伐进入到Ajax时代，js调取server端api获取数据，局部刷新页面。信息交换的入口信息变得规范了(遵照Ajax的api要求)，出口处理也一致了(我们在回调函数中进行逻辑处理)，出口的体验和性能也更好了，因为不需要重新刷新页面就可以高效完成交互。
一件事情做到了，我们就会想怎样做到更好?js框架的兴起使得前端得到很大的发展，热烈欢迎我们的代表jQuery。jQuery的出现给前端开发带来了丰富的库，更简便的DOM操作，更高效友好的信息交换，时至今日依然被大量使用。
从静态页面到复杂交互到炫酷特效，然而这只是个开始，真正的繁荣还有30秒到达战场。
今天的前端
酒足饭饱思淫欲，我们已经能够实现信息交换，我们的业务越来越复杂，代码越来越多，于是我们开始考虑性能。信息交换整个过程中的性能问题是今天的前端技术的一条线。
我们还是从页面说起吧(逃不开的轮回)。
这次不拿我的文章举例了(域名还没备案，难受)，我们在浏览器里输入一个网址，但是这个网址朋友很少，只有DNS协议认识它。于是我们要按浏览器缓存-本地缓存-路由缓存-DNS服务器这条线去找到它对应的IP…
稍等稍等，这里有天大的性能问题!我输入网址以后等半天它连IP都没找到?我点一个链接他还要去绕那么远先找IP?
上有政策，下有对策。首先一点是减少DNS请求次数，理想做法是把所有内容都放到一个域底下，但是由于HTTP1.x对于一个域底下并行请求次数有限制，可能造成排队，反而降低性能，所以需要做出权衡。另一点要提到的是DNS Prefetch，这一点可以在加载页面的时候对网页中的域名进行解析缓存，从而在用户点击一个链接的时候节省下DNS解析过程，减少用户等待时间，优化用户体验。但是DNS Perfetch同样会带来问题，即会产生多余的DNS请求。
继续往下，我们知道了IP地址，我们要和目标主机建立TCP连接。TCP，没错，就是它，我们知道三次握手的必要性，但是我们不能容忍它带来的性能问题。于是…
HTTP2.0 曲线救国，改TCP牵涉到的东西太多了，我们还是换个方式来解决延迟带来的性能问题吧。
继续走，现在我把我的信息给你了，该你给我我要的信息了吧?
没问题没问题，等等…你要啥?
扶额…页面啊页面啊…
额，完整的页面还是不完整的…
……
服务端渲染还是客户端渲染 服务端渲染 优势：利于SEO，规避白屏，页面响应更快; 劣势：服务器性能消耗，前后端耦合; 客户端渲染 优势：适合SPA，表现和数据分离; 劣势：SEO，白屏，数据请求多;
你开心就好(看使用场景啦)，快给我内容吧…然后我的浏览器获取到了一个HTML，开始解析它为我生成页面。等等…这个js是啥?咦，我就看个博客怎么这里来了个支付宝的代码?这段css哪来的，我这里没这个元素呀?
模块化 前端在信息交换过程中根据信息类型、内容可以做的处理越来越多，无论是逻辑还是表现，都可以做得更复杂了，这就带来了代码的复杂。有的代码我现在不要用，你一股脑丢给我这不是浪费嘛!我能不能按需引入我要的东西呢? js/css模块化 js：从CommonJs到AMD(客户端js模块化)到CMD(服务端js模块化) 至于这些东西，我还在学，没达到可以拿来讲的地步...先留个空位...
嗯嗯，不错不错，这些都是我要的了。但是这个时间戳是啥?为了做缓存策略?
自动化 打包构建代表(webpack、fis) 本着减少页面请求的原则，我们把js、css文件按需引入打包好到一块，再压缩一下，上面一个css，下面一个js，多好看...这个图片比较小，那干脆不发请求了，转成base64吧...资源文件再加个时间戳，放到cdn，时间戳变化了再更新cdn缓存，看起来也很完美... 嗯嗯，还在学习中，也没达到可以详细拿来讲的地步...先留个空位...
好了好了，这些资源文件处理过了，踏踏实实给我生成页面吧。
组件化 DRY是每个程序员的追求，能够复用的代码才是好代码。你看看，我把页面设计成好几个组件，这些组件间可以互相通信，可以在别的地方方便引入，是不是比你以前写的一大堆一大堆的代码看起来简单多了呢?
你说的都对，但看起来这些都是组织代码和文件方面上的优化，你现在页面也渲染出来给我了，还有什么地方是前端可以做的呢?
回到信息交换的出口这个概念，我现在只是把你请求的信息呈现给你了，接下来我还要处理你的信息输入呀。我需要对你的信息输入和我要给你的信息输出做处理，你知道浏览器渲染是件很费力的事情，我需要找到一个好的方式去对信息交换做出响应。这件事情我们交给前端框架来做。
三大主流框架：Angular、React、Vue 我们以Vue为例来聊聊MVVM ... to be continued 需要好好整理下以免误人子弟
大概了解了一些了，但还不是很懂，有点迷迷糊糊?没关系，我也是。哈哈，来些好玩的东西调剂下吧。
css3动效 html5的新东西：web socket，localstorage，语义化标签，audio/video，canvas，google api，web worker es6 node全栈
嗯，上面只是我列出来要学的一些东西，其实以上所有都是我觉得我需要去学习的东西，有遗漏以后会补充进来。我所了解到的暂时就是这些，有的我在用，有的在学习中，最后聊聊我理解的前端的方向吧：
从客户端的角度来说，前端包含了pc、移动端以及物联网(物联网这块没怎么接触，老实说是面试了一家这个方向的公司才想起这东西)三个方向。
从内容角度来说，又有用户体验和交互、偏后的js/node开发、数据可视化、工具和框架开发等等方向。
前端每天都在和页面打交道，页面是什么，它又是怎样到达我们面前呢?
一张页面的生平
一张页面放在眼前，你看到了什么?略作思考后答：可见的元素和数据呈现、需要触发的交互或请求、不可见的逻辑处理。这么想其实也没错，转念一想，这些东西有什么共性吗?答：信息。
我以为页面是以浏览器为宿主的信息交换的出入口。乍一听可能有点不知所云，别急，且听小僧细细道来。
以浏览器为宿主没啥说的，看官老爷现在看到的这篇文章便是在浏览器中展示。而说到信息交换(重点来啦)，我们还是拿这篇文章来举栗子。
我想了个现在不做说明的办法把这篇文章丢到了我的服务器上的某个内存空间，我现在想在我的设备上看到这篇文章。“我想看”，这是一个信息，我想用这个信息和我的服务器交换这篇文章(同样也是信息)。我借助我的浏览器(实际上是这个进程占用的端口)和服务器(某个端口)进行这样通信，我们遵循协议，按层级组装信息，彼此理解，拥抱之后微笑着给出答复
于是我的浏览器得到了文章这个信息，开始来生成一张页面，而这个页面实际上就是前面所说的信息交换的出口，是将交换后得到的信息加工再呈现到我面前
看到这里我突然觉得这篇文章写得挺用心的，我想给作者点个赞，于是我注意到右上角有个星，我毫不犹豫点了一下。“我要点赞”，这是又一个信息，我点下去的时候，触发了一个事件，这个事件的逻辑代码里我再次向服务器发起了一个信息交换的请求。这个时候页面就承担了信息入口的角色，这个信息从页面上到达茫茫网络，辗转漂泊到我的服务器，告诉我我自己给自己点了个赞。于是我在数据库中添加了一条记录，并将这个信息返回。
我的js代码里接收到这个返回的信息，我想起来我是个爱慕虚荣的男子，我是不是应该把这个信息处理下，表现在页面上?于是我做了简单的逻辑处理，把页面点赞数加了1。看，页面上点赞加1了!页面又成了信息的出口，我心满意足，微笑着关闭了我的浏览器。
以信息交换为线，试图理解前端的知识体系
前端所做的努力都可以围绕着如何建设更好更高效的信息交换出入口来展开。
遛一遛前端的过去。
前端最初的目标很明确，就是将存储在服务器上的静态页面(信息)在客户端(浏览器)中以页面形式展示给用户。那个时候可能就是简单的HTML+少量的CSS和JavaScript。
服务端技术兴起以后，出现了表单作为页面上的信息交换的入口，而出口却没有明确的输出形式，服务端语言和客户端语言没有明确分工，代码混杂在一起，可读性极差(接触过前后端高耦合代码的我差点哭出声)。
加快步伐进入到Ajax时代，js调取server端api获取数据，局部刷新页面。信息交换的入口信息变得规范了(遵照Ajax的api要求)，出口处理也一致了(我们在回调函数中进行逻辑处理)，出口的体验和性能也更好了，因为不需要重新刷新页面就可以高效完成交互。
一件事情做到了，我们就会想怎样做到更好?js框架的兴起使得前端得到很大的发展，热烈欢迎我们的代表jQuery。jQuery的出现给前端开发带来了丰富的库，更简便的DOM操作，更高效友好的信息交换，时至今日依然被大量使用。
从静态页面到复杂交互到炫酷特效，然而这只是个开始，真正的繁荣还有30秒到达战场。
今天的前端
酒足饭饱思淫欲，我们已经能够实现信息交换，我们的业务越来越复杂，代码越来越多，于是我们开始考虑性能。信息交换整个过程中的性能问题是今天的前端技术的一条线。
我们还是从页面说起吧(逃不开的轮回)。
这次不拿我的文章举例了(域名还没备案，难受)，我们在浏览器里输入一个网址，但是这个网址朋友很少，只有DNS协议认识它。于是我们要按浏览器缓存-本地缓存-路由缓存-DNS服务器这条线去找到它对应的IP…
稍等稍等，这里有天大的性能问题!我输入网址以后等半天它连IP都没找到?我点一个链接他还要去绕那么远先找IP?
上有政策，下有对策。首先一点是减少DNS请求次数，理想做法是把所有内容都放到一个域底下，但是由于HTTP1.x对于一个域底下并行请求次数有限制，可能造成排队，反而降低性能，所以需要做出权衡。另一点要提到的是DNS Prefetch，这一点可以在加载页面的时候对网页中的域名进行解析缓存，从而在用户点击一个链接的时候节省下DNS解析过程，减少用户等待时间，优化用户体验。但是DNS Perfetch同样会带来问题，即会产生多余的DNS请求。
继续往下，我们知道了IP地址，我们要和目标主机建立TCP连接。TCP，没错，就是它，我们知道三次握手的必要性，但是我们不能容忍它带来的性能问题。于是…
HTTP2.0 曲线救国，改TCP牵涉到的东西太多了，我们还是换个方式来解决延迟带来的性能问题吧。
继续走，现在我把我的信息给你了，该你给我我要的信息了吧?
没问题没问题，等等…你要啥?
扶额…页面啊页面啊…
额，完整的页面还是不完整的…
……
服务端渲染还是客户端渲染 服务端渲染 优势：利于SEO，规避白屏，页面响应更快; 劣势：服务器性能消耗，前后端耦合; 客户端渲染 优势：适合SPA，表现和数据分离; 劣势：SEO，白屏，数据请求多;
你开心就好(看使用场景啦)，快给我内容吧…然后我的浏览器获取到了一个HTML，开始解析它为我生成页面。等等…这个js是啥?咦，我就看个博客怎么这里来了个支付宝的代码?这段css哪来的，我这里没这个元素呀?
模块化 前端在信息交换过程中根据信息类型、内容可以做的处理越来越多，无论是逻辑还是表现，都可以做得更复杂了，这就带来了代码的复杂。有的代码我现在不要用，你一股脑丢给我这不是浪费嘛!我能不能按需引入我要的东西呢? js/css模块化 js：从CommonJs到AMD(客户端js模块化)到CMD(服务端js模块化) 至于这些东西，我还在学，没达到可以拿来讲的地步...先留个空位...
嗯嗯，不错不错，这些都是我要的了。但是这个时间戳是啥?为了做缓存策略?
自动化 打包构建代表(webpack、fis) 本着减少页面请求的原则，我们把js、css文件按需引入打包好到一块，再压缩一下，上面一个css，下面一个js，多好看...这个图片比较小，那干脆不发请求了，转成base64吧...资源文件再加个时间戳，放到cdn，时间戳变化了再更新cdn缓存，看起来也很完美... 嗯嗯，还在学习中，也没达到可以详细拿来讲的地步...先留个空位...
好了好了，这些资源文件处理过了，踏踏实实给我生成页面吧。
组件化 DRY是每个程序员的追求，能够复用的代码才是好代码。你看看，我把页面设计成好几个组件，这些组件间可以互相通信，可以在别的地方方便引入，是不是比你以前写的一大堆一大堆的代码看起来简单多了呢?
你说的都对，但看起来这些都是组织代码和文件方面上的优化，你现在页面也渲染出来给我了，还有什么地方是前端可以做的呢?
回到信息交换的出口这个概念，我现在只是把你请求的信息呈现给你了，接下来我还要处理你的信息输入呀。我需要对你的信息输入和我要给你的信息输出做处理，你知道浏览器渲染是件很费力的事情，我需要找到一个好的方式去对信息交换做出响应。这件事情我们交给前端框架来做。
三大主流框架：Angular、React、Vue 我们以Vue为例来聊聊MVVM ... to be continued 需要好好整理下以免误人子弟
大概了解了一些了，但还不是很懂，有点迷迷糊糊?没关系，我也是。哈哈，来些好玩的东西调剂下吧。
css3动效 html5的新东西：web socket，localstorage，语义化标签，audio/video，canvas，google api，web worker es6 node全栈
嗯，上面只是我列出来要学的一些东西，其实以上所有都是我觉得我需要去学习的东西，有遗漏以后会补充进来。我所了解到的暂时就是这些，有的我在用，有的在学习中，最后聊聊我理解的前端的方向吧：
从客户端的角度来说，前端包含了pc、移动端以及物联网(物联网这块没怎么接触，老实说是面试了一家这个方向的公司才想起这东西)三个方向。
从内容角度来说，又有用户体验和交互、偏后的js/node开发、数据可视化、工具和框架开发等等方向。
