重学webpack系列(一) -- 前端模块化的演变历史

本文探讨了前端模块化的演变历史,从早期的全局变量管理到AMD规范,再到ESM的出现。文章介绍了如何通过模块化解决复杂问题,如变量冲突和依赖管理,以及AMD(异步模块定义)和CommonJS规范。随着前端发展,Webpack等打包工具应运而生,解决了浏览器对现代模块化规范的支持问题,为大型项目的构建提供了便利。

前言

任何事物的产生都有他的必然性,就像是冥冥之中注定了一样,在JavaScript刀耕火种的时代,前端是被定义为切图的一项工作,页面逻辑交互全部由服务端工程师完成,前端开发几乎不受服务端开发重视,那时候也没有很好的制定前端的规范,原因归结于并没有想到现如今前端的快速发展与规模,现如今前端开发已经在web新时代占据了半壁江山,在前端演变的过程中,社区规范也在不断的完善,那在前端的发展过程中,前端模块化究竟经历了什么样的变革呢,这将是我们这一章将要探索的问题。

模块化的概念

站在现在的角度来解释模块化,我相信同学们都能够说出一二:模块是一个具有某种功能,能够解决某种问题的独立区块,模块化则是由多个模块组合,相互协调解决某类问题的一种方式

模块化是指解决一个复杂问题时自顶向下逐层把系统划分成若干模块的过程,有多种属性,分别反映其内部特性。–来自百度百科,

早期的模块化

上面说到,早期前端只是个"切图工程师",模块化的概念产生,还是源自于前后端交互的媒人 – AJAX,因为AJAX得以让前后端分离,经过数年的发展,业务系统逐渐庞大,前端逻辑变得愈加复杂,那时候模块化表现在一个文件就是一个模块,通过script标签引入多个文件就能使用,一般一个脚本文件几千行代码,其中就会导致一些问题的产生:

  • 超多全局变量产生问题。
  • 变量、函数名冲突问题。
  • 无法管理模块与模块之前的依赖关系。
  • 其他问题。

出现了上述问题怎么办,接着社区规范继续约定,每一个文件只允许暴露出一个全局对象,文件里的所有属性都必须暴露在对象里面,以达到解决重复的问题。

紧接着社区又约定了一种IIFE的方式,也就是在第二种的形势下,在外层包裹了一层自执行函数。

这一种方式所带来的好处是什么呢?

  • 因为是在自执行函数里面执行的,也就是利用闭包的特性,形成了私有的属性成员,能够很好的避免全局变量的污染。
  • 自执行函数可以传参,那也就很好的描述了模块与模块之间的依赖关系,使得模块管理变得可行。

上述三种方式为最早的社区约定的模块化方式,确实能够解决一些问题,但是同学们有没有发现,这三种方式都是通过script标签进行引入到html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值