Let's assume in this context, build tools like Apache Ant, Android Gradle and other language platforms having their own build tools.
What are build tools and why we need them?
Is it possible to work without them?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (5)
In programming, there are layers.
The layers on the bottom are the most basic layers possible.
The layers at the top are things you can easily touch and play with. Things that are easy to move and understand.
When you use a build tool, it will take what you made and break it down into the smallest possible pieces for your computer or browser to run.
It is possible to work without them, but at great cost since it takes a long time to do these processes manually. This is why these tools exist.
When you're looking at your code. It's the top-most layer. It's easy to read and to play around with, but it's in a format your browser or computer may not understand by itself.
So, the build tool breaks it down into native languages like JavaScript and HTML for your browser, or deeper languages that can interact with your computer's operating system.
Building software is like baking. Sure you can bake a cake from scratch, or you could pick up a box mix from the store and have a cake in half the time.
The build tools are the box mix: it puts together basic parts of the recipe and has them ready to go for you. Combine this mix with the rest of the recipe (like eggs or in our case, your code) and you have a finished product.
So yes, you can work without them but it will cost you lots of time. Also, when you bake a lot of cakes, you likely want them to be consistent. Same for apps. The box mix comes in handy here because it guarantees that part of the recipe will always be the same.
When developing a project, there are many things that need to be, files to be processed, archives to be packaged, etc. It is fairly straightforward to just put all these tasks into a shell script, which will do exactly what you want it to do.
But as your project grows in size, you'll find that you need to add more and more steps to your shell script. Each step is taking longer and longer (because there are more source files to process), and there are more steps, and soon your build process, written as a simple shell script, is no longer so simple or fast as it once was.
But you notice that there are certain tasks that don't depend on one another, and you can run them in parallel,which saves you time. In addition, there are a lot of tasks that don't need to be run every time, because nothing has changed and you know the output will be the same,so you can skip the next time you run your script.
All these build tools, Gradle, Maven, Gulp, Webpack, or anything else, all exist to solve those problems for you. They typically provide a flexible framework for creating tasks and plugins, and a declarative way to set up which tasks to run and in which order to run them. A good, mature build tool like Gradle will also track which files have or have not changed since the last run, to avoid repeating work (it can even cache outputs built on different servers, really tricky stuff needed for truly massive projects). Some tools, like Webpack, will even process the files very differently depending on whether you are building for development or production, to speed up iterative development time.
Maybe instead of native, I should have used the word 'abstract'. Build tools break down languages like JSX and Typescript into abstracted primitive versions that a browser can easily interpret.
Just about every language needs an interpreter of some kind. JS is interpreted by the browser. In my layering example, the browser interprets CSS, JS, and HTML. They're native in the browser space.