前端入门之路- 校招VIP

转载声明：文章来源https://zhuanlan.zhihu.com/p/346145904

正式接触前端应该是在2017年7月份，到现在差不多已经有两年的时间。我很庆幸，在入门的过程中我是处在一个技术资源还算有保障的环境中，遇到什么问题，都可以从身边的前辈身上找到答案。但是回想起来，仍觉得入门之路颇为坎坷。很多人刚接触前端时普遍存在的问题主要包含不理解前端的基本概念，不知道有多少技术栈，不明白各种技术栈出现的原因，以及他们之间的相互关系，在什么情况下该使用哪个。更具体地来说，是不知道问题出在哪里，也不知道该怎么描述自己遇到的问题。

我认为产生以上问题的原因主要来自于三个方面。第一，前端包含太多让人眼花缭乱、不知该从哪里下手的技术方案，对于同一种效果或功能的实现，可以有多种不同的技术搭配方案，这个现象导致学习的过程非常不稳定。第二，大多数学校都没有开设前端相关的课程，给前端入门也带了一定的困难。第三，很多学习前端的人缺少真正的实战经验，只能通过文档和视频自学，因此一直在边缘徘徊。

在这篇文章中，我试着回想并梳理一下从入门到现在自己会遇到或者思考过的一些问题，以及我现在对于这些问题的答案。简单来讲，就是一个关于前端知识的问答。

前端和后端的区别是什么？

我直到大学毕业的时候对这个问题都没有概念。16年8月份去老师的公司实习，接手了一个项目，主要工作是按照产品的需求修改前端的部分内容和功能。所以我面临的第一个问题就是搞清楚前端和后端的区别是什么，百度一下，再看几篇博客，感觉已经理解了前后端的差别。但是理解是一回事，前后端代码放在一起，让你找出来哪一部分是前端，哪一部分是后端又是另一回事。所以我花了几天的时间才搞清楚前端和后端代码的区别。

现在，我想用一个案例来描述前后端的区别。就以我们每天都会去的食堂作为模板。在食堂这个体系下，打菜的窗口和阿姨就是前端，厨房里做菜的厨师就是后端。如果把食堂里一半窗口的打菜工作人员换成年轻漂亮的小姑娘，男生们肯定都喜欢去这些窗口打菜。但是，需要明白的一点是，这些窗口的菜并不一定好吃，菜好不好吃是由每个窗口后面的厨房（假定每个窗口都有一个单独的厨房供应饭菜）决定的。所以，前端是用户能够直接看到和感知到的东西，但是用户体验好不好却要分为两个方面，一是打菜的小姑娘好不好看（前端展示的内容和效果好不好），二是厨师做的菜好不好吃（后端服务器的综合能力，可能包括数据处理、并发能力、数据真实性等若干）。

哪里可以学前端？

不管是已经下定决心要从事前端行业的人还是在犹豫期不知道该学什么想要尝试一下前端的人，都需要找到合适的学习方法和学习平台。学习平台有很多，网上一搜，一大把，W3C School（尽管我平时不太习惯看这个）、菜鸟教程、慕课视频、各种博客等。

平台有很多，但是需要注意的一点是，所有平台的教程都只能教会给我们最基本的语法和用法，并不能帮我们指明学习方向或解决具体的问题，所以我觉得这些平台的内容只适合用于入门初期快速浏览一遍。更好的方式可能是在有了一定的基础之后为自己设定一个个目标，并不断达成这些目标。比如实现一个或一组简单的网页展示、动态效果及跳转逻辑，或者参加到项目实战中去。

Html 中那些标签都是怎么写出来的？

网页中的标签都是一个一个手打出来的吗？这是我对前端的第一印象。但是网页头部往往有很多有长又难记的内容，这些内容需要把他们记住吗？还是说每次只需要从已经写好的网页上复制粘贴过来就可以了？后来，慢慢写的多了，就知道除了头部那一堆东西之外，其他的东西确实都是一行一行打出来的，但是也存在一些很方便的工具可以让我们码html 的时候更快一些，比如说利用Emmet，我们可以通过一个感叹号 + tab 就打出以下的代码

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>Document</title>
</head>
<body>
  
</body>
</html>

开发工具用什么？

最初用的是webstorm，后来使用了sublime text，现在用的vscode。多种工具各有利弊，但是都有很多便利的插件和漂亮的主题，比如说上面提到的Emmet 还有Snippets 等，善用插件可以帮我们提升很大的编码效率。最后用哪个可能全凭个人喜好。

为什么网页可以有很多后缀？

在不同技术栈的项目中可能会看到各种各样的网页后缀，.html，.jade，.vue 巴拉巴拉。不管是什么后缀，有一点是非常明确的，即浏览器最终只能识别并正确翻译html 后缀的网页。所以各种后缀的网页实际上是不同的框架或技术栈，为了提升html 的编码效率或扩展性所做的在html 之上的一步封装，最终发布的时候还是要被转换成html 文件。看到不同后缀的网页名字的时候只需要去网上查这个框架的语法等基本信息，就可以很快地理解并使用。但是新手还是建议从原生html 写起。

那些网页的css 都是自己写的吗？Bootstrap 是什么？

在看到css 中大段大段的代码的时候，脑海中的第一个想法就是这些内容都是开发者自己写出来的吗，还是从不知道什么地方复制过来的？是的，就是自己写的。在正常的开发流程过程中，设计人员会为前端提供网页的设计稿，设计稿上会标注出每一个元素的宽高、颜色、边缘弧度等，根据这些信息就可以利用代码一比一还原网页，只是这个还原过程需要花一定的时间去培养，需要尝试着写，去看人家的代码和反复地练习才行。

但是，随之而来的一个问题就是：很多情况下，我们可能会用到相似的css 样式，尤其是在管理系统中，比如说一个按钮、一个选择框或者一个表格，我们不想直接用很丑的原生展现，又想要一套比较好看、容易被大多数人接受的固定模板，该怎么办呢？以bootstrap 为例的框架正是以上问题的解决方案，其他的还有weui、ant design、element-ui、vutify 等，我习惯称之为UI 框架。管理系统的快速离不开这些UI 框架，但是如果像是公司官网之类定制化程度比较高的内容可能主要还是靠手写。

JQuery 是什么，该怎么用？

网页的最初目的是用于图文排版，展示内容。到后来会慢慢加入一些交互，比如用户点击一个按钮，可能会发生图片的旋转或者信息的变化等。这些功能都要通过利用js 操作dom（其实就是网页中的标签）来实现，先获取dom，然后改变dom 的内容或者css 样式等。一个很经典的用法如下：

var para = document.getElementsByTagName("p");//返回的是数组

 para[0].setAttribute("title", "a list of goods");

因此，早期的js 代码里充斥着像这种获取dom 和操作dom 的代码。但是由于早期的浏览器厂商之间的竞争和dom 技术的发展，不同浏览器对于不同代码的兼容性不是特别好，一个很典型的例子就是为dom 添加监听事件：

function addEvent(elm, evType, fn, useCapture) {
  if (elm.addEventListener) {
    elm.addEventListener(evType, fn, useCapture);//DOM2.0
    return true;
  }
  else if (elm.attachEvent) {
    var r = elm.attachEvent(‘on‘ + evType, fn);//IE5+
    return r;
  }
  else {
   elm['on' + evType] = fn;//DOM 0
  }
}

因此，通过js 来操作dom 的方式需要写很多条件判断的代码且容易出错。为了解决这个问题，jquery 应运而生。它在js 的基础之上做了一层封装，屏蔽了底层不同浏览器的差异，让我们操作dom 的过程更加简单，正确性更高。因此在很多年里，jquery 都大受欢迎，这是在那个时代大家针对前端的复杂性所研究出的最好的解决方案。

前端框架是什么？

这个问题我花了很长的时间才搞明白。如今，在我印象中的前端框架主要包含js 框架和css 框架，css 框架就是上面所说的ui 框架，它们给我们提供的是一套标准的ui 解决方案。Js 框架就非常多了，像上面提到的jquery 就是统领了前端江湖好多年的一大霸主，尽管它现在已经有些跟不上时代了。

如今的前端三杰Angular、Vue、React 是最受欢迎的三大js 框架（实际上也包含了html），他让我们的编码过程更加简单，写出来的东西可扩展性更好，降低了团队合作的成本。三大框架的流行使得很多人一开始就直接跳过原生的js 开发，直接面对这些优化过的东西。我认为这对于新手来说并不是最好的选择，还是推荐从原生的html、js、css 写起。

那么，jquery 跟vue 有什么不同呢？jquery 统治了前端那么多年，又是如何衰落下去的？这跟大家对前端的认知阶段有关。以前（jquery时代），工程师想的是如何让操作dom 的过程更便利、更有保证，但是项目中仍然充斥着获取和改变dom 的操作，代码的书写和排错要花费很大的成本。现在的模式则是如何把操作dom 这一复杂的机制彻底隐藏，比如通过双向绑定直接将js 变量的变化关联到html 上，除此之外，组件化和模块化也使得整个项目的可维护性更高，更利于大型项目的开发。

Ajax 是什么？

很早以前，页面内容的变化只能通过整个页面的刷新来完成。后来，Google 一系列产品的应用使得只需部分刷新页面即可进行信息更新的ajax 被大家广泛接受。简单来讲，ajax 就是前端与后端进行最小代价沟通的一种技术。

Npm 是什么，为什么会出现这个东西？

前端，或者说js 对于大部分人来说都不是他们接触的第一门语言，而第一门语言通常是C 或者java。想想C 或者java 的模块化管理机制，其基本理念为将负责不同功能或者不同模块的代码放在不同的文件中，通过引入的方式来进行方法的调用。在js 中，安装node（node 是一个js 的运行环境，相当于没有界面的浏览器）时所附带的npm 就是前端的模块化解决方案。通过npm 我们可以发布和安装各种各样的依赖包，不同的包会针对不同的领域提供一个普适性地解决方案，node 项目中最知名的两行代码就是：

npm install

// 然后

npm run dev

// 下面就不会了

第一行代码的作用是按照项目根目录下的package.json 文件中的依赖关系安装相关的依赖包，安装的所有依赖包都放在根目录下的node_modules 文件夹中，这个文件夹的体积通常非常大，因此在多人协作中，这个文件夹通常是要被加入到.gitignore 文件中的。即大家仅仅通过package.json 来同步项目的依赖，这个机制使得项目的管理非常简单。

除此之外，ES6 的import 和export 也是前端模块化的解决方案之一

Js 为什么会有那么多叫法？ES6、ES7、TypeScript

同html 模块的描述一样，浏览器只能识别并正确运行原生的js 代码，即ES5（全称是ECMAScript 5，是js 发展过程中某一阶段的规范）。但是原生js 有很多缺点，在项目开发过程中使用起来十分不方便，因此慢慢出现了更多的标准，这些新的标准在代码的维护性、扩展性和团队合作的便利性方便相对于原生js 有了很大的提升。

ES6、ES7、TypeScript 就是其中之若干。现在的前端项目中很少有直接用ES5 开发的，但是初学阶段还是建议使用ES5 进行学习，因为如果使用了ES6 以上的语法，如果不进行相关的配置在浏览器中无法正常运行。至于如何分辨出ES5 和E6，这个可能就要具体情况具体分析了。

Scss、Less、Stylus 等跟Css 的关系

原生的css 书写过程中颇为复杂，维护性较差，如果你已经有一些css 方面的经验，可能会遇到过下面的代码：

.outer {
  ...
}
.outer .inner1 {
  ...
}
.outer .inner2 {
  ...
}
.outer .inner2 .inner-inner1 {
  ...
}
 
.red-a {
  ...
  color: red;
}
.red-b {
  ...
  color: red;
}

如果用stylus 来写，会怎么样：

$color-red = red
 
// 嵌套
.outer
  ...
  .inner1
    ...
  .inner2
    ...
    .inner-inner1
      ...
 
// 变量
.red-a
  ...
  color $color-red
.red-b
  ...
  color $color-red

因此可以看到，像scss、less、stylus 等被称为css 预处理器的东西所要描述的内容其实跟css 是一致的，只是表现形式不同而已，预处理器通过引入变量、嵌套、继承、mixin 等机制使得css 的书写和维护更加高效。但是到最后，所有用预处理器写成的代码最终还是要被转换成css 在浏览器端运行。

Webpack 是什么，我不用他行不行？

说到这里，webpack 就该出场了。上面提到，现在前端项目开发过程中用到了大量非原生、即浏览器不能识别的框架或技术，如果在项目开发和发布的过程中一个一个地进行配置将会是一项非常复杂的工程，那么有没有一个工具来帮助我们解决这个问题，并且可以提供除此之外的其他帮助呢？有，那就是webpack。关于webpack，之前写过一篇稍微详细一些的博客，更多内容可以参考

不用webpack 行不行？我觉得不行。

要不要看书，要看哪些书？

一定要看书，项目和实战过程中永远只能给我们线条状的知识点。块状的知识点和前端知识体系的搭建必须通过看书等系统的学习过程来完成。此处也推荐几本我看过的觉得很有帮助的书。