From 4827a6d754cc0229024b2d86a9841a94740a5269 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Wed, 30 Oct 2024 18:09:24 +0000 Subject: [PATCH] Add daily email for 2024-10-28 Why "no build" is appealing --- source/_daily_emails/2024-10-28.md | 32 ++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 source/_daily_emails/2024-10-28.md diff --git a/source/_daily_emails/2024-10-28.md b/source/_daily_emails/2024-10-28.md new file mode 100644 index 00000000..7160cac9 --- /dev/null +++ b/source/_daily_emails/2024-10-28.md @@ -0,0 +1,32 @@ +--- +title: Why "no build" is appealing +date: 2024-10-28 +permalink: daily/2024/10/28/why-no-build-is-appealing +tags: + - software-development + - front-end + - css +cta: ~ +snippet: | + More projects are moving away from complicated build processes for their front-end assets and back to something simpler. +--- + +You're or a new team member are onboarded to a project to make some CSS changes. + +The project uses Sass, Less or another preprocessor. + +Not knowing this, the generated CSS files are changed instead of the Sass files. + +The changes are committed and pushed, but because they weren't added to the Sass files, they will be lost when the CSS files are re-generated in the future. + +Or, if the Sass and CSS files become too out of sync, everyone will be too worried about losing changes to use the Sass files, so they will be abandoned and not used. + +What if you change the correct files but don't know the magic command to generate the assets for that project? + +I've seen things like this happen on numerous projects and is an example of why the "no build" approach is appealing. + +Especially with enhancements to CSS, such as custom properties (variables) and nesting, a lot of the functionality from preprocessors can now be done with normal CSS. + +This means the front-end build steps can be simplified or removed entirely, reducing the technical overhead and dependency cost, and it's easier for new Developers to get started. + +Win, win!