为什么前端从简单的写html变成如今各种框架与模块，看起来如此复杂？

前言

• 本来是想记录一下npm的包管理，发现既然想要做个包管理介绍，肯定要先知道模块是什么，而谈到模块就想到，正是模块的思想让我们现在的前端看起来如此复杂，框架离不开依赖包，而依赖包管理也就是一个个逐渐封装起来的模块而已，它们看起来复杂，却带领前端走向新的时代，我们谈谈模块，谈谈我们现在所说的框架到底是什么。

模块是什么

1. 大概就是将比较庞大的东西分割成一个个部分，而我们编写js，当然是将复杂的js代码分成多个js，所以不严谨的说，就是一个js文件就是一个模块。
2. 为什么需要分割出模块？假设我们有一个方法是某种复杂的算法，这个算法在很多文件中都需要用到，如果不将这个方法写成一个模块的话，你就需要在不同文件中每次使用时编写一遍该算法，显然模块就是为了消除这种冗余的代码，将可能会重复的代码内容封装成一个模块。

模块的导出与导入

• 既然分出了模块，那模块与模块之间又是如何工作呢，必须要有东西将它们串起来，用es6的模块为例，也就是我们的导入import与导出export。

导出

1. 我们写好一个count对象，count中间有两个我们写好的简单加减方法，使用export default暴露出去。
2. 这里涉及到es6模块的两种导出方式，一种是默认导出export default，默认导出只能导出一次，当导入时就没有用花括号获取到的就是默认导出的唯一内容。
3. 另一种就是直接export导出属性，可以导出任意个，需要在声明属性的同时导出或者使用花括号导出.
4. 下面这样导出的结果等于，导出一个默认的count与一个包含所有直接导出属性的集合对象{ add, del, add2, del2 }

   //count.js
   const count = {
     add: (a, b) => {
       return a + b;
     },
     del: (a, b) => {
       return a - b;
     },
   };
   export const add = Count.add;
   export const del = Count.del;
   const add2 = count.add
   const del2 = count.del
   export const { add2, del2 };
   

导入

1. 导入时，使用import count from "./count.js"可以获取到export default默认导出的东西，也就是count。
2. 如果需要获得直接导出的属性，得需要用花括号{}。

   //test.js
   import count, { add, del } from "./count.js";
   console.log(Count.add(1, 2));//3
   console.log(add(1, 2));//3
   console.log(del(1, 2));//-1
   

依赖关系与依赖包管理

1. 上面的例子中我们可以知道，我们封装了count模块，用于做计算，而test模块需要导入count，它依赖于count，如果count这个东西不存在，那test便无法正常工作了。
2. 那假设我将count做的更强大，并非只是简单的加减法，然后将它发布为npm包供人下载，他们使用npm下载完我们的count包，导入我们的模块它们就可以使用了，这也就是依赖包管理的由来。

为什么模块让我们的前端变得复杂

1. 而现在很多流行的前端框架，比如我们编写react代码时，需要import ... from 'react'，会发现它也是封装好的模块作为依赖包。
2. 这些流行的框架其实都是js，利用js可以生成dom的原理，设计出了他们的虚拟dom，因此我们前端从简单的html变成了复杂的项目，需要下载一堆包。
3. 它们看起来是变得复杂了，但是它们的诞生让前端迈入了新的时代，能做的事情更多也更容易。好比我们从自行车换成了汽车，汽车肯定比自行车来的庞大内部结构也更加复杂，但是它的确能让我们到目的地的速度变快，现在我们使用react编写项目时，我们更在乎的是如何使用react编写出项目，而不是react是如何被编写出来的，当然我们仍然需要抱着一颗好学的心，不断尝试去了解它的原理。
4. 我们编写前端项目需要依赖于这些框架的包，而这些框架也有它们运行时需要依赖的包，技术力提升是一个踩在过去巨人肩膀上不断上升的过程，我们不停探索原理，不断去找寻巨人脚底下的更大的巨人时必然发现自己如此渺小。