First and foremost, the ability to automate your workflow is incredibly valuable. It brings order to the chaotic amount of tasks that need to be run throughout development.
Let's imagine that you recently developed a big application, but instead of being able to allow the necessary time to put together a proper build system, you were pressured into completing it within an incredibly short time frame.
Here's an example of this: in the past few days, your boss has been gathering feedback from users who claim that slow load times and performance issues are preventing them from getting their work done and damaging their user experience. It has become so frustrating that they have even threatened to move to another competing service if the performance doesn't improve soon.
Due to the short deadline, the sacrifices that were made during development have actually caused problems for your users and the maintenance needed to resolve those problems has now become a large burden on you and your team.
Naturally, your boss is rather upset and demands that you figure out a way to correct these issues and deliver a more performant service. Not only that, your boss also expects you to have a sustainable solution so you can provide this across all of your team's future projects as well. It's quite a burden, especially at such short notice. This is a perfect example of where Gulp can really save the day.
To deliver better load times in your application, you would need to compress your overall file sizes, optimize your images, and eliminate any unnecessary HTTP requests.
You could implement a step in your workflow to handle each of these manually, but the problem is that workflows often flow forward and backward. No one is infallible, and we all make mistakes. A big part of our job is to correct our mistakes and fix bugs, which requires us to take a step back to resolve any issues we run into during development.
If we were to plan out a step in our workflow to handle these items manually, it would become a huge burden that would most likely take up much of our time. The only practical way to handle optimizations like these is to automate them as an ongoing workflow step. Whether we are just starting, finishing up, or returning to our code to fix bugs, our optimizations will be handled for us.
While things like these should usually be part of your initial project setup, even as an afterthought, Gulp makes resolving these issues incredibly easy. Also, it will set you up with a solid base that you can include in future projects.
There are many additional tasks that we can add to our list of automations. These include tasks such as CSS preprocessing, running an HTML server, and automatically refreshing your browser window upon any changes to your code. We will be covering all of those and more in the upcoming chapters.
At the heart of Gulp is something called streams, and this is what sets it apart from other JavaScript build systems. Streams were originally introduced in Unix as a way to pipe together small, single-purpose applications to perform complex, flexible operations. Additionally, streams were created to operate on data without the need to buffer the entire file, leading to quicker processing compared to other task runners. Piping these small applications together is what is referred to as a pipechain. This is one of the core components of how we will organize and structure our tasks in Gulp.
Like Unix, Node.js has its own built-in stream module. This stream module is what Gulp uses to operate on your data and perform tasks. This allows developers to create small Gulp plugins or Node modules that perform single operations and then pipe them together with others to perform an entire chain of actions on your data. This gives you full control over how your data is processed by allowing you to customize your pipechain and specify how and in what order your data will be modified.
Another reason why many developers find Gulp to be a more natural alternative to other JavaScript build systems is because the build file you create is written in code, not config. This may be a matter of personal preference, but I know that this was a fundamental reason why I chose to use Gulp over other build systems.
As I mentioned before, by learning more about Gulp, you are also learning the basics of Node.js, simply because you're writing code for a Node.js application. With a build system that uses a config file, you're missing out on the value of learning the core code syntax of the platform you are using.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
South Africa
Thailand
Ukraine
Switzerland
Slovakia
Luxembourg
Hungary
Romania
Denmark
Ireland
Estonia
Belgium
Italy
Finland
Cyprus
Lithuania
Latvia
Malta
Netherlands
Portugal
Slovenia
Sweden
Argentina
Colombia
Ecuador
Indonesia
Mexico
New Zealand
Norway
South Korea
Taiwan
Turkey
Czechia
Austria
Greece
Isle of Man
Bulgaria
Japan
Philippines
Poland
Singapore
Egypt
Chile
Malaysia
