As each atom is placed individually in a library, Atomic Design saves a lot of time and makes for a more coherent and simplified end result.
Makefiles, or How to Avoid Reinventing the Wheel
After having taken a break from frontend Web application development, I’ve recently jumped back into the field through two projects that I am working on. It represents a great opportunity to revisit my preconceived notions and old work habits, through a codebase that already exists and that is up-to-date with the latest stylish tools to use, ready after a simple
With all of these new shiny things, these automated build pipelines become essential to ensure that the minification, linking, compilation?!, of all of these files won’t cancel out the efficiency gains given by these tools which are now a necessity for the development of modern Web applications.
I still can’t keep myself from wondering if there hasn’t been a little bit of a lack of communication between those that have recently needed these complex tools in their projects (front-end developers) and those who have already faced these same requirements in the past and have discovered a solution (not the only one, mind you) to this problem, way back in the 70s!
I’ve never yet felt the need to use these new tools, as I already know Make, and having already been confronted with new, shiny, stylish solutions around the turn of the century, only to have taken some steps backward from something that already worked well. Indeed, I often insist on manually creating these Makefiles for projects I contribute to and I don’t hesitate to spend the time necessary to manage this tool.
- The article that says it best: Time for Makefiles to Make a Comeback
- Reasons not to use auto*hell
From Contributions to Inno Hackfest