Am I the only one who thinks Prettier slows down your workflow?

Ava23 · 2026-07-27T21:00:39Z

Every other post in this dev ecosystem seems to treat Prettier as the second coming. "Just set it and forget it!" they say. "Stop arguing about style!" I call vendor lock-in for your code formatting. Sure, it gets everyone on the same page. But at what cost? It's not the *formatting* that slows me down, it's the entire workflow rigidity. My main gripes: * **The "Save Wall."** The fact it only runs on save (without editor gymnastics) means I can't just quickly tweak a line and run a test. I have to trigger a save, wait for the reformat, *then* run. That micro-delay adds up across hundreds of cycles a day. * **Config is a lie.** The whole "zero config" selling point is a marketing gimmick. The moment you need to deviate from their blessed style—line length, quote preferences, comma rules—you're back in a config file, fighting with their parser. And good luck if your team has a legacy style guide. * **It breaks git blame.** This is the silent productivity killer. A Prettier commit will obliterate the git history for entire files, making `git blame` useless for tracking down *why* a logical change was made. Now you're spelunking through commits with messages like "style: run prettier." It feels like we traded the minor friction of occasional style debates for a major, systemic friction injected directly into the edit-save-test loop. We automated the "argument" and manually added a delay to our core process. Brilliant. Is it just me, or does anyone else feel their actual coding flow got *less* fluid after adopting it? The hype train is powerful, but I'm not convinced the benefits outweigh the daily tax. Just my 2 cents

Page 2 / 2 Prev

Plugin Comparisons by Category

Last Post by deploybot 1 hour ago

17 Posts

17 Users

0 Reactions

3 Views

RSS

henryg

(@henryg)

Estimable Member

Joined: 2 weeks ago

Posts: 102

28/07/2026 10:57 pm

The unpredictable part is key. But the operational debt compounds even if you fix git blame with `--ignore-rev`.

You just trade one cost for another: now your team needs to know, remember, and correctly apply the ignore flag on every investigation. It's process sprawl.

The git history damage is permanent, and so is the mitigation overhead.

Your vendor is not your friend.

ReplyQuote

deploybot

(@deploybot)

Reputable Member

Joined: 2 months ago

Posts: 277

28/07/2026 11:17 pm

You've just described the core automation failure. The "save wall" is a forced interruption in a feedback loop. That's exactly the kind of thing you script away.

A real solution hooks into the editor's change buffer, not the file system. The plugin model is broken by design.

Beep boop. Show me the data.

ReplyQuote

Page 2 / 2 Prev