A couple of days ago, I saw a complaint post in a tech group. The poster said that before the project went live, they used a tool to minify the CSS. The next day, when a colleague opened the stylesheet, they saw a screen full of characters crammed together and immediately blew up: 'Who wrote this? Is this even human-readable?' The poster said, feeling wronged, that minification was part of the build process and they had no choice.
This situation is actually quite typical—almost every front-end team has argued about it. Today, let's discuss: after CSS minification, when colleagues can't understand it, who should really take the blame?
First, let's talk about what CSS minification does. Simply put, it removes all spaces, line breaks, and comments from the code, and shortens variable names as much as possible, with the goal of reducing file size and making web pages load faster. There's nothing wrong with that in itself—in a production environment, performance is key, and minification is standard practice. But the problem arises when many people commit the minified files directly to the code repository, even overwriting the original files. When colleagues pull the code, all they see is gibberish like 'a{b:c;d:e}'—of course they're confused.
So who should take the blame? Some say it's the minification tool's fault for being too 'brutal.' But the tool is innocent—it's just a program that executes commands. If you tell it to minify, it will minify to the extreme. If you cut your hand while using a kitchen knife, you can't blame the knife for being too sharp.
Others blame the colleagues, saying that front-end engineers who can't read minified code lack basic skills. That's a bit like standing and talking without back pain. Minified code is meant for browsers, not humans. It's like translating a novel into Morse code and sending it to a friend—if they can't understand it, can you blame them for not being good at language? Normal people read code with indentation, comments, and line breaks; minified code is completely against human nature. Forcing colleagues to struggle through minified code isn't training their skills—it's torture.
In my opinion, the real blame should go to the process and standards. In other words, the team hasn't agreed on 'what should be committed and what shouldn't.' The proper approach is to keep the source code (the human-readable CSS) in the repository, and let minification be an automatic part of the build phase. The minified files should either be output to a dist directory or bundled directly into the release artifacts—there's no need to commit them to version control. But many teams take shortcuts or don't think it through from the start, and directly commit the minified files, leading to problems.
Some might say, what if the company requires committing minified files? For example, some static hosting platforms or back-end systems directly reference files from the repository. This situation does exist, but it's not unsolvable. You can make minification a separate build step that runs before release, rather than minifying and committing right after editing code. Or use tools like pre-commit hooks to automatically handle it before committing, ensuring the repository always has an unminified version for humans to read. There are always more solutions than problems; the key is that someone on the team needs to take the lead in establishing this standard.
Another easily overlooked point is code comments. Many CSS minification tools remove comments by default, which means even if you want to leave some clues in the minified file, you can't. So, important logic that future developers need to understand must be written in the source file, and don't expect to see it after minification. This is why keeping the source file is so crucial—it's the 'true form' for team collaboration.
At the end of the day, CSS minification itself isn't a bad thing; what's bad is the lack of accompanying management habits. When colleagues can't understand it, it's not because they're incompetent or the tool is stupid—it's because there's a missing link in the workflow. It's like cooking: a good knife is a good knife, but if you insist on chopping the vegetables into mush and serving them, and guests say it doesn't look good, can you blame the knife?
So, stop arguing about this. Next time it happens, admit openly that the process wasn't defined well, and then quickly fix the standards: source files go into the repository, minification is left to the build, and no one should manually commit minified artifacts. If you'd done this from the start, there'd be no blame to assign. In short, behind technical problems often lie management issues. Don't you think?