#Why use webpack vs gulp or grunt install
Gulp isn’t the only culprit either Jake, Broccoli, Brunch and Mimosa all require plugins to install as well, which means when using any of these task runners, you’re essentially just installing 1 more dependency (the task runner) than if you had no task runner, and just used each of the projects own binaries.Īll this talk of plugins leads me nicely to my next point… Relying on plugins
Gulp’s version only clocks in at 7 lines of code, but still requires 2 dependencies ( gulp itself, and gulp - jshint) and I still need to run gulp jshint (which is only 1 keypress less than jshint **. Well, if we were to have a Gruntfile that simply ran jshint, it would look a little something like this: “What does a configuration look like?”, you might ask. You can install plugins, like grunt-contrib-jshint which let you use your favourite tools to work with your code. Grunt uses configuration files and plugins to help you, through the centralised “Gruntfile” which declares your settings, and as veteran users of Grunt will attest to, the configuration is far from terse. BloatĪll of these task runners (or build systems if you want to call them that) try to abstract some kind of task paradigm away into their own siloed incantations. Let me cover some of the reasons why I think these tools are bad choices. Reading between the lines, we can see tools like Gulp attempting to solve the problems of Grunt, and Broccoli attempting to solve the problems of Gulp - covering up the inadequecies of the previous tool while also surfacing their own. I’ve used Gulp and Grunt in several projects (mostly closed-source projects, but some open-source, such as Tempus).įor me, especially more recently, I feel like many of these tools are solving the problem badly. They must be doing something right, right? Build systems seem to be the tool du jour of the JavaScript community. Grunt receives a whopping 30,000 downloads most days, and Gulp has a respectable 15,000 daily downloads. The heavyweights of this world are Grunt and Gulp, although many, many others exist too. If you’re building a modern JavaScript application or website, there’s a good chance you’ve seen the JavaScript Build Tool Landscape. Here, for example, is a sample task that makes use of three of these four functions: gulp.Why we should stop using Grunt & Gulp Keith Cirkel JavaScript Cyber ShepherdĭevOps Why we should stop using Grunt & Gulp I will be using Gulp as a task runner because it is very developer friendly, easy to learn, and readily understandable. Once the task runner is configured, all you need to do is invoke a single command in a terminal. The purpose of a task runner is to automate all of these tasks so that you can benefit from an enhanced development environment while focusing on writing your app. This amounts to a significant number of tasks that have nothing to do with writing the logic of the web app itself.
#Why use webpack vs gulp or grunt code
It’s also quite common to use language preprocessors such as SASS and JSX that compile to native JS and CSS, as well as JS transpilers such as Babel, to benefit from ES6 code while maintaining ES5 compatibility.
0 kommentar(er)
