Grunt、Gulp区别 webpack、 requirejs区别

谁说我不能喝 提交于 2020-01-21 03:20:19

1. 书写方式

grunt 运用配置的思想来写打包脚本,一切皆配置,所以会出现比较多的配置项,诸如option,src,dest等等。而且不同的插件可能会有自己扩展字段,导致认知成本的提高,运用的时候要搞懂各种插件的配置规则。
gulp 是用代码方式来写打包脚本,并且代码采用流式的写法,只抽象出了gulp.src, gulp.pipe, gulp.dest, gulp.watch gulp.task等接口,运用相当简单。经尝试,使用gulp的代码量能比grunt少一半左右。

2. 任务划分

gulp是工具链、构建工具,可以配合各种插件做js压缩,css压缩,less编译 替代手工实现自动化工作

1.构建工具  :    可以用构建基础项目

2.自动化  :          可以通过gulp.task配置各接口自动对js,css,html代码进行压缩, 自动刷新页面( IDE好多已经可以自动刷新了 )

3.提高效率用  :  可以编译less语法,可认快速对css的编辑

webpack是文件打包工具,可以把项目的各种js文、css文件等打包合并成一个或多个文件,主要用于模块化方案,预编译模块的方案

1.打包工具   :   gulp 也可以,但是需要按项目配置属性项 ,  webpack 很集成了,简单

2.模块化识别

3.编译模块代码方案用

所以定义和用法上来说 都不是一种东西,无可比性 ,更不冲突!【当然,也有相似的功能,比如合并,区分,但各有各的优势】 

  seajs / require : 是一种在线"编译" 模块的方案,相当于在页面上加载一个 CMD/AMD 解释器。这样浏览器就认识了 define、exports、module 这些东西。也就实现了模块化。

  browserify / webpack : 是一个预编译模块的方案,相比于上面 ,这个方案更加智能。没用过browserify,这里以webpack为例。首先,它是预编译的,不需要在浏览器中加载解释器。另外,你在本地直接写JS,不管是 AMD / CMD / ES6 风格的模块化,它都能认识,并且编译成浏览器认识的JS。这样就知道,Gulp是一个工具,而webpack等等是模块化方案。Gulp也可以配置seajs、requirejs甚至webpack的插件。

 

1,gulp更注重前端开发流程

2,webpack更注重模块化开发

Gulp和Webpack的基本区别:

gulp可以进行js,html,css,img的压缩打包,是自动化构建工具,可以将多个js文件或是css压缩成一个文件,并且可以压缩为一行,以此来减少文件体积,加快请求速度和减少请求次数;并且gulp有task定义处理事务,从而构建整体流程,它是基于流的自动化构建工具。

Webpack是前端构建工具,实现了模块化开发和文件处理。他的思想就是“万物皆为模块”,它能够将各个模块进行按需加载,不会导致加载了无用或冗余的代码。所以他还有个名字叫前端模块化打包工具。

就我而言,我在实际当中会将两种都选择混合使用。虽然两个都可以进行代码的压缩合并减少代码体积,但gulp.config.js中gulp的代码更加简单易懂,需要压缩合并谁就用哪个方法,而webpack样式合并需要在node环境下下载插件才能使用。另一点,gulp 是基于流的打包工具,需要谁,引用谁,并且他的压缩简单明了,后期维护起来方便,webpack则可以将具体的模块进行划分,需要哪个模块就加载哪个模块,实现按需加载,并且排除掉冗余代码,减少代码体积。

总结起来就是,gulp是基于流的自动化构建工具,但不包括模块化的功能,如果要用到的话,就需要引入外部文件,比如require.js等;而webpack是自动化模块打包工具,本身就具有模块化,并且也具有压缩合并的功能。二者侧重点不同,我认为相互结合使用会提高代码质量和代码的优化。

gulp的核心配置文件:

webpack的核心配置文件:

1,必须要有一个入口文件,入口文件是入口起点告诉 webpack 从哪里开始,并遵循着依赖关系图表知道要打包什么。可以将您应用程序的入口起点认为是根上下文(contextual root)或 app 第一个启动文件       入口文件需要我们自己创建,并在webpack.config.js中的entry:处写上正确路径

2,出口            将所有的资源(assets)归拢在一起后,我们还需要告诉 webpack 在哪里打包我们的应用程序。webpack 的 output 属性描述了如何处理归拢在一起的代码(bundled code)。

3加载器    

webpack 的目标是,让 webpack 聚焦于项目中的所有资源(asset),而浏览器不需要关注考虑这些(这并不意味着资源(asset)都必须打包在一起)。webpack 把每个文件(.css, .html, .scss, .jpg, etc.) 都作为模块处理。而且 webpack 只理解 JavaScript。

webpack loader 会将这些文件转换为模块,而转换后的文件会被添加到依赖图表中。

在更高层面,webpack 的配置有两个目标。

  1. 识别出(identify)应该被对应的 loader 进行转换(transform)的那些文件
  2. 由于进行过文件转换,所以能够将被转换的文件添加到依赖图表(并且最终添加到 bundle 中)(use属性)

以上配置中,我们对一个单独的 module 对象定义了 rules 属性,里面包含两个必须属性:test 和 use。这可以告诉 webpack compiler 如下:

“嘿,webpack compiler,当你碰到「在 require()/import 语句中被解析为 '.js' 或 '.jsx' 的路径」时,在你把它们添加并打包之前,要先使用 babel-loader 去转换”。

W> 重要的是要记得,在 webpack 配置中定义 loader 时,要定义在 module.rules 中,而不是 rules。在定义错时 webpack 会提出严重的警告。

我们还有尚未提到的 loader,可以设定更多特定属性。

4,插件

插件是 wepback 的支柱功能。在你使用 webpack 配置时,webpack 自身也构建于同样的插件系统上!

webpack 插件是一个具有 apply 属性的 JavaScript 对象。 apply 属性会被 webpack compiler 调用,并且 compiler 对象可在整个 compilation 生命周期访问。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!