I love trying to automate whatever I can. It might be considered a problem, but also it brings me a lot of personal satisfaction, and automation in the right place can pay huge dividends. For example, I wrote scripts at work to guide and automate production programming of electronic controllers. This not only cut the per-unit cycle time to 1/3 of human-entry time for an experienced operator, but also allowed me to set up a production programming computer for the goal of moving programming orders out of Engineering and to the shop floor, cutting our costs even further. Since the scripts automate most of the work and prompt the user for interactions, while verifying if the production environment is correct, it drastically reduces the training time and experience required.
Terminology and knowing what can do what is my first issue, so I found a post on Stack Exchange discussing the differences between Gulp, Grunt, Webpack, and Browserify, and what they’re used for. This was a great diving-in point, and gave me much more to look into.
Next, I read about the history of runners and bundlers, and the article I found did a good job of summarizing things. It was interesting to read about Make being released as far back as 1977, and transitioning from configuration-heavy Grunt, to code-focused Gulp, Gulp’s synergy with Browserify, and now with configurable core and plugin approach with Webpack. FuseBox also sounds very interesting!
While reading up about task runners and bundlers, I accidentally stumbled across a blog talking about serving WebP images to users. There are open issues both on my portfolio and AGWSU, so this was a nice surprise to find!
For further information on comparison between these runners and bundlers and more practical examples, I found an article that provided great examples of pros and cons of each, and general conclusions. While I didn’t see a date on the article, it looks like comments started from 4 years ago, so maybe things have changed a bit since then. One thing that was mentioned was that…
There’s a growing trend, especially among the React community, to use Webpack instead of Gulp.
It sounds like Webpack is complex to initially configure, and Gulp adds overhead, so there are trade-offs to both.
Getting into the actual execution, the specifics kind of got away from me. I made an effort to follow along and try to understand what was happening and why, but I think there is just more foundational information I need before I will fully understand what is happening. Thankfully, the author made the example repo for this comparison process available on GitHub, so I’ve starred it for future reference.
Near the end, the author makes the case that Gulp has three core issues:
- Dependence on plugin authors
- Frustrating to debug
- Disjointed documentation
When libraries get updated, the corresponding Gulp version of the library also needs to be updated, which does not always happen. Similarly, using Gulp adds a layer of abstraction over using the library natively. With this in mind, the conclusion of the offer was that using webpack and NPM scripts directly provided the best experience. Reading a few more posts, it seems that other developers agree.
I really hadn’t expected, coming into this, that learning about Gulp might ultimately have me switching away from it in favor for something else. That’s what is exciting about the web, though - it’s very much a living thing, constantly changing and evolving. Coming from engineering, where there is room to adopt new skills but little to no pressure to change from “how it’s been done” for the past 30 years, the risk and excitement of having to constantly keep up with the curve is exhilarating. Learning is a motivator for me, and this is a field where there will most likely never be a shortage of things to learn.
Looking more into Webpack, I next read a blog post that, right off the bat, gave a quote illustrating what I had already written above:
Webpack offers enough power out of the box that you typically don’t need Grunt or Gulp at all. Yep, sorry, that shiny new skill you just mastered is already nearly useless. Uh…yay? Sigh. Welcome to life on the front-end. But hey, that’s the price of progress.
To my surprise, I discovered that
create-react-app actually is already using Webpack! The more I had been reading, the more I was wondering if something was already running under the hood. I will need to get in there and poke around to see what all is actually happening when I run my commands.
I am sure that I will eventually want to learn enough about everything to be dangerous, but as I mentioned in my latest blog post, correctly prioritizing learning the correct things first is critical, as time is my most valuable resource. Sometimes, you have to spend some time to “read and update your map” and make sure you’re headed in the right direction early, which is exactly what today has felt like.
- Learn about task runners and bundlers
- 2 hours and 40 minutes