2024 前端生态发展回顾(1)，2024年最新前端大厂面试题及答案

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Web前端全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024c （备注前端）

正文

2. 3月 angular2.0 第一个预览版发布

3. 5月 http/2.0 标准正式发布，同月 iojs 与 nodejs合并。

4. 6月 ES6 和 WebAssembly 落地

5. 7月 迄今为止React生态圈影响最大的Flux实现redux发布1.0版本

6. 8月 Facebook公开了在React上应用GraphQL的relay框架的技术预览版

7. 9月 React Native for Andriod 发布

8. 11月伊始，es标准委员会宣布将历时3年研究的Object.observe从草案中移除，尽管它原本已经是stage2，几乎已经是ES7的事实标准。双十一刚一结束，阿里手淘团队发布了名为 无线电商动态化解决方案 的 Weex，也有人给了它一个更具象的名字，vue native。

9. 12月，赶在2015的尾巴，aurelia和angular2先后发布beta版。

css方面，postcss & cssnext先后高调走到台前。

观念的变化

由于近几年前端的野蛮生长以及前端应用的多元化和复杂化，整个技术形态已经跟几年前纯做页面的时代完全迥异了。主要观念的变化总结来看在于一点，现在的前端开发面向的是web app而不是web page。今天的前端开发模式跟传统的GUI软件(如C++、.NET开发的windows客户端)已经很接近了，而且由于现在前端领域为了解决日益复杂的web业务需求及体量，越来越多的借鉴了传统客户端的开发经验，导致两者变得越来越趋同。再加上前端一些独特的特性(免安装、增量安装等)，工程上的复杂度有过之而无不及。前端如今已经脱离了茹毛饮血、刀耕火种的原始社会，开始步入了工业时代。

框架 & 类库的变化

今年最火的框架/类库毫无疑问当属React了。React从2014年年中开始广泛受到开发者关注，但是真正开始在社区独领风骚还得归功于2015年初React Native的发布。React Native的发布使得js统一三端(前端、后端、移动端)开发成为可能(现在这个时间点看可能还是过于理想，但是整体方向还是对的)，这一针强心剂吸引了大量开发者的眼球。笔者对此最大的感受就是，我在社区发表一篇react的入门教程级别的软文便可获得广泛关注及转发，相应的写angular源码剖析的准干货大部分情况则是门可罗雀。

我们挑几个主流的框架来讲讲这一层的变化。

React & Redux

React基本简介可以参考这篇文章React简介，这里不再赘述。这里挑几个核心特征简单来讲：

1. virtual dom

这个可以说是F家工程师超强工程能力的最佳体现了(Relay也算一个)，从本质来看它是通过用js object来模拟了一个dom tree，然后将这层virtual dom插在react组件跟真实dom之间，配合强劲的dom diff算法实现它一直标榜的高性能。

2. jsx

同样为了配合react中的组件化开发模式，F家发明了一套新的语法jsx。乍看之下它像是html in js，这也是初接触的开发者最难以接受的，典型的违背前端推崇多年的表现与业务分离的原则啊。其实这里要换个角度来看jsx，它并不是html in js，准确来说它是一个用来构建react组件树的AST。这样来想你就能理解react中这一看似怪异的设计了。

3. immutable object

不可变对象是函数式编程中的重要概念，react的介入使得这一理念在前端社区中流行起来。从目前各种类库的实现来看，不可变对象在大型应用中拥有传统可变对象不具备的优势。尤其在这个内存不值钱的年代。从目前immutable object的良好走势来看，将来有可能被es纳入规范之中。目前可以通过facebook的immutable.js来实现。

Redux则是目前react配套的Flux模式的各种实现(其实现在两者的关系越来越模糊了)中最火的一个，在此基础上它引入了函数式编程、单一数据源、不可变数据、中间件等概念。一定程度来讲，redux是今年react生态甚至整个前端生态中影响最大的一个框架，它给整个前端技术栈引入了很多新成员，尽管这些概念可能在其他领域已经有了广泛的应用。虽然它们是否会在大规模的应用实践中被广大开发者认可还需要再检验，但至少给我们带来了一些新的思路。其中的单一数据源、不可变数据、中间件等思路目前来看还是非常有价值的，尤其是单一数据源跟不可变数据，很有可能在将来成为大型应用架构中的标配(目前来看至少在应用中构建Store层在当前的前端架构中是势在必行的)。单一数据源就好比在前端构建了一个集中式数据库，所有的数据存取操作对象都是它，不单如此它里面还实现了触发器，当有insert/update操作时它会对相应组件作rerender动作，这个在各组件之间有数据同步需求的场景下就非常有用了。

至于我对函数式编程的看法，后面单独阐述。

在我看来，react的优势并不在组件化，组件化的实现方案多种多样。react的优势在于virtual dom及一个几乎构成闭环的强大生态，这归功于F家工程师强大的工程能力跟架构能力。virtual dom将应用表现层从浏览器这个基于dom的上下文中抽离出来，通过原生js对象模型的方式使得react具备在任何环境支撑上层表现的能力。上层的渲染引擎可以是canvas、native、服务端甚至是桌面端，只要相应的端提供基于react组件的渲染能力，即可达到一套代码、或者只要很少的改动就能移植到任一终端环境的效果，这个就非常夸张了。react从0.14版本之后便将react-dom抽出来变成一个独立的库，可见react的野心并不局限于浏览器，相反从这点来看，react反而是受到了dom的掣肘。

Angular2 & Vue.js

ng2跟ng1相比是一个完全革命性版本而不是升级版，它是一个为了迎合未来的标准及理念来设计的全新框架，而这些新的理念又无法通过改进ng1.x的方式来实施，所以angular团队做了这么一个看似激进的决策，可以理解成重构已经无法满足需求只能重写了。ng2也采用纯组件化的开发思路，任何单元对于它来说都是组件。同时，ng2里面也引入了一些全新的概念(对于前端而言)来提升框架的性能及设计，例如基于worker的数据检测机制能大幅度提升渲染性能(对应实现是zone.js)，基于响应式编程的新的编程模型能更大的改善编码体验(对应实现RxJS)。赶在2015年的尾巴，ng2正式发布beta版，对于angular的这次自我革命是否能成功，还有待后续检验。另外原angular团队中出来的一个成员开发了一个类ng2的框架aurelia，有相当的开发者认为它更配称为ng2，值得关注。

由于阿里在背后的技术实践及支持，Vue.js今年也开始得到越来越多的关注。vue相对于angular1.x的优势在于轻量、易用、更优异的性能及面向组件化的设计，目前发展态势也非常好，是移动端开发的一个重要技术选型之一。

标准 & 语言的变化

现在回顾起来，2015年真的是很有意义的一年：这一年是Web的25岁生日，也是js的20岁生日。同时又是ES6标准落地的一年。ES6是迄今为止ECMAScript标准最大的变革(如果不算上胎死腹中的ES4的话)，带来了一系列令开发者兴奋的新特性。从目前es的进化速度来看，es后面应该会变成一个个的feature发布而不是像以前那样大版本号的方式，所以现在官方也在推荐 ES+年份 这种叫法而不是 ES +版本。

ES2015(ES6) & ES2016(ES7) & TypeScript

6月中ES2015规范正式发布，从ES2015带来的这些革命性的新语法来看，JS从此具备了用于开发大型应用的语言的基本要素：原生的mudule支持、原生的class关键字、更简洁的api及语法糖，更稳定的数据类型。而这些new features中，有几个我认为是会影响整个前端发展进程的：

1. Module & Module Loader

ES2015中加入的原生模块机制支持可谓是意义最重大的feature了，且不说目前市面上五花八门的module/loader库，各种不同实现机制互不兼容也就罢了(其实这也是非常大的问题)，关键是那些模块定义/装载 语法都丑到爆炸，但是这也是无奈之举，在没有语言级别的支持下，js只能做到这一步，正所谓巧妇难为无米之炊。ES2016中的Module机制借鉴自CommonJS，同时又提供了更优雅的关键字及语法(当然也存在一些问题)。遗憾的是同样有重大价值的Module Loader在2014年底从ES2015草案中移除了，我猜测可能是对于浏览器而言Module Loader的支持遭遇了一些技术上的难点，从而暂时性的舍弃了这一feature。但是一个原生支持的模块加载器是非常有意义的，相信它不久后还是会回归到ES规范中(目前由WHATWG组织在单独维护)。

2. Class

准确来说class关键字只是一个js里构造函数的语法糖而已，跟直接function写法无本质区别。只不过有了Class的原生支持后，js的面向对象机制有了更多的可能性，比如衍生的extends关键字(虽然也只是语法糖)。

3. Promise & Reflect API

Promise的诞生其实已经有几十年了，它被纳入ES规范最大意义在于，它将市面上各种异步实现库的最佳实践都标准化了。至于Reflect API，它让js历史上第一次具备了元编程能力，这一特性足以让开发者们脑洞大开。

关于ES2016的最重磅的消息莫过于11月初es标准委员会宣布将Object.observe从ES2016草案中移除了，尽管它已经是stage2几乎已经是事实标准。官方给出的解释是，这3年的时间前端世界变化实在太大，社区已经有了一些更优秀简洁的实现了(polymer的observe-js)，而且React带来的immutable object在社区的流行使得基于可变数据的Object.observe的处境变的尴尬，O.o再继续下去的意义不大了。

除此之外，ES2016的相关草案也已经确定了一大部分其他new features。这里提两个我比较感兴趣的new feature：

1. async/await

写过C#的同学应该对这两个关键字很熟悉了，async/await是为了更优雅的异步编程做的一个关键字级别的封装，术语叫协程。ES2016中 async/await 实际是对Promise的上层封装，几乎同步的写法写异步比Promise更优雅更简单，非常值得期待。

2. decorator

字面意思是装饰器，其实等同于Java里面的注解。注解机制对于大型应用的开发的作用想必不用我过多赘述了。用过的同学都说好。

目前ES2015/ES2016都有了比较优秀的转译器支持(没错我说的是babel)，但是也不是all features supported，尝新的过程中需要注意。

至于Typescript，你可以将它理解成加入了静态类型的js的超集。不过我对于这种转译型语言一直不感冒(包括快死掉的CoffeeScript)，有兴趣同学自己去了解下吧。。

WebAssembly

WebAssembly选择了跟ES2015在同一天发布，其项目领头人是大名鼎鼎的js之父Brendan Eich。WebAssembly旨在解决js作为解释性语言的先天性能缺陷，试图通过在浏览器底层加入编译机制从而提高js性能。这个事情跟当时V8做的类似(有兴趣的同学可以去了解下JIT)，V8也因此一跃成为世界上跑的最快的js引擎。但是由于js是弱类型的动态语言，V8很快就触碰到了性能优化的天花板，因为很多场景下还是免不了recompile的过程。WebAssembly提供工具将各种语言转换成特定的字节码，浏览器直接面向字节码编译程序。其实在此之前,firefox已经搞过asm.js做类似的事情，只不过WebAssembly的方案更激进。有人认为WebAssembly可能是2016年最大的黑马，如果wa能发展起来，若干年后我们看js编写的应用会像现在看汇编语言写出的大型程序的感觉。WebAssembly项目目前由苹果、谷歌、微软、Mozila四大浏览器厂商共同推进，还是非常值得期待的(写不下去了我决定回去翻开我那本落灰的编译原理。。)。

Web Components

webcomponents规范起草于2013年，w3c标准委员会意图提供一种浏览器级别的组件化解决方案，通过浏览器的原生支持定义一种标准化的组件开发方式。webcomponents提出之际引发了整个前端圈的躁动，大家似乎在跨框架的组件化方案上看到了曙光。但是前端这圈子发展实在太特么快了，在当前这个时间点，webcomponents也遭遇到了跟Object.observe相似的尴尬处境。我们先来看看webcomponents的几个核心特性：

1. Shadow DOM

2. Custom Element

3. Template Element

4. HTML Imports

其中1、4现在都能很容易的通过自动化的工程手段解决了(shadow dom对应的是scoped css)，而自定义标签这种事情不论是React还是Angular这类组件框架都能轻松解决，那么我用你webcomponents的理由呢？

另外webcomponents将目标对准的是HTML体系下的组件化，这一点跟React比就相对狭隘了(但是这并不表明React把战线拉的那么长就不会有问题)。

不过原生支持的跨框架的组件还是有存在的意义的，比如基础组件库，只是在当前来看web components发展还是有点营养不良。期待2016年能有实质上的突破吧。

架构的变化

2015年出现的新的技术及思路，影响最大的就是技术选型及架构了。我们可以从下面几点来看看它对前端架构上都有哪些影响。

组件化

React的风靡使得组件化的开发模式越来越被广大开发者关注。首先要肯定的是，组件化是一个非常值得去做的事情，它在工程上会大大提升项目的可维护性及拓展性，同时会带来一些代码可复用的附加效果。但这里要强调的一点是，组件化的指导策略一定是分治(分而治之)而不是复用，分治的目的是为了使得组件之间解耦跟正交，从而提高可维护性及多人协同开发效率。如果以复用为指导原则那么组件最后一定会发展到一个配置繁杂代码臃肿的状态。如果以组件的形态划分，可以分为两个类型：基础控件和业务组件。基础控件不应包含业务逻辑不然达不到拿来即用的效果，因此它也会表现出可复用的价值，但是根本还是为了提高业务组件的可维护性。至于业务组件，可复用的价值就很低了。

1. 组件化指的是什么

组件化这个词，在UI这一层通常指“标签化”，也就是把大块的业务界面，拆分成若干小块，然后进行组装。

_狭义的组件化一般是指标签化，也就是以自定义标签（自定义属性）为核心的机制。_这也是我们通常认识的组件。

_广义的组件化包括对数据逻辑层业务梳理，形成不同层级的能力封装。_它不一定是一个自定义语义标签：它可以是一个包含逻辑(js)、样式(css)、模版(html)的功能完备的结构单元，也就是我们常“口口相传”的模块(从术语准确性的角度来看模块这个描述并不合适，应该称之为组件)；它也可以是一个单纯的js，比如http组件这种纯逻辑单元。严格从概念上来讲，css跟html是不具备单独/组合成一个组件的，它们不具备描述逻辑的能力(非图灵完备)。从这个层面来看，全组件化是没有任何问题及疑义的。

2. 是否需要全组件化

我们通常说的组件指的是狭义上的组件，而且往往我们理解的全组件化也是建立在狭义的组件基础上的，

代表框架是React。React＋Flux体系下，它提倡尽可能将页面作细粒度的组件拆分，组件的数据全部由父级组件通过props传递而来。这本身是一件非常有价值的事情，能有效的确保应用状态的稳定及可预测性，但是应用一旦复杂庞大起来，组件树变得“枝繁叶茂”导致叶子节点层级过深，当出现数据问题时，我们必须一层层的回溯来定位bug。而且组件树过于庞大也会增加组件之间的通讯负担。从狭义的组件来看，我对全组件化是存怀疑态度的，工程上的成本太高是最大的问题，而且大部分开发者很难拿捏合适的组件粒度，容易出现过细／过粗的拆分。很多场景其实并不适合实现成狭义上的组件，它以零散的模板的方式存在更合适。

总结

技术学到手后，就要开始准备面试了，找工作的时候一定要好好准备简历，毕竟简历是找工作的敲门砖，还有就是要多做面试题，复习巩固。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024c （备注前端）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

复习巩固。

[外链图片转存中…(img-5ND5GOmA-1713627071811)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024c （备注前端）
[外链图片转存中…(img-MBJATskG-1713627071812)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！