What are the key takeaways from this Software Engineering Daily episode?

Key insights include: **Opinionated formatting over configurable rules:** ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review.; **Prettier ignore as the escape valve:** When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified.; **Never run Prettier through ESLint:** Using the ESLint-Prettier plugin routes formatting through ESLint's rule engine, which reruns fixers up to 10 times when fixes conflict, turning a sub-second formatting operation into a multi-second delay per save. Running Prettier directly as a separate process avoids this overhead entirely and keeps the two tools' responsibilities cleanly separated.

What did James Long discuss on Software Engineering Daily?

James Long, creator of Prettier, joins Josh Goldberg on Software Engineering Daily to discuss how the opinionated JavaScript formatter emerged from code-style debates at Mozilla, why deterministic formatting removes team friction, the technical complexity of building formatters, and the financial realities of sustaining popular open source tooling. Key topics include: **Opinionated formatting over configurable rules:** ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review.; **Prettier ignore as the escape valve:** When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified..

How long is this episode of Software Engineering Daily?

This episode is 50 minutes long. SignalCast provides an AI-generated summary so you can get the key insights in about 3 minutes.

Software Engineering Daily

Prettier and Opinionated Code Formatting with James Long

March 19, 2026

50 min episode · 2 min read

James Long

Episode

50 min

Read time

2 min

Topics

Productivity, Fundraising & VC, Software Development

AI-Generated Summary

Published Mar 19, 2026

Key Takeaways

✓Opinionated formatting over configurable rules: ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review.
✓Prettier ignore as the escape valve: When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified.
✓Never run Prettier through ESLint: Using the ESLint-Prettier plugin routes formatting through ESLint's rule engine, which reruns fixers up to 10 times when fixes conflict, turning a sub-second formatting operation into a multi-second delay per save. Running Prettier directly as a separate process avoids this overhead entirely and keeps the two tools' responsibilities cleanly separated.
✓Unified AST toolchains solve the real performance problem: Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially. The traditional stack parses and regenerates code at each tool boundary, multiplying overhead — a structural inefficiency that a Rust rewrite alone would not fix.
✓Open source financial sustainability gap: Prettier has raised approximately $243,000 total across nine-plus years on OpenCollective, with no full-time maintainers and no backing company. Long frames this as the standard open source trajectory: initial creative energy drives adoption, but long-term maintenance requires compensation structures that donation models rarely provide at sufficient scale for tools used by millions of developers daily.

What It Covers

James Long, creator of Prettier, joins Josh Goldberg on Software Engineering Daily to discuss how the opinionated JavaScript formatter emerged from code-style debates at Mozilla, why deterministic formatting removes team friction, the technical complexity of building formatters, and the financial realities of sustaining popular open source tooling.

Key Questions Answered

•Opinionated formatting over configurable rules: ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review.
•Prettier ignore as the escape valve: When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified.
•Never run Prettier through ESLint: Using the ESLint-Prettier plugin routes formatting through ESLint's rule engine, which reruns fixers up to 10 times when fixes conflict, turning a sub-second formatting operation into a multi-second delay per save. Running Prettier directly as a separate process avoids this overhead entirely and keeps the two tools' responsibilities cleanly separated.
•Unified AST toolchains solve the real performance problem: Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially. The traditional stack parses and regenerates code at each tool boundary, multiplying overhead — a structural inefficiency that a Rust rewrite alone would not fix.
•Open source financial sustainability gap: Prettier has raised approximately $243,000 total across nine-plus years on OpenCollective, with no full-time maintainers and no backing company. Long frames this as the standard open source trajectory: initial creative energy drives adoption, but long-term maintenance requires compensation structures that donation models rarely provide at sufficient scale for tools used by millions of developers daily.

Notable Moment

Long revealed that the productivity benefit Prettier became most known for — writing messy code and reformatting it instantly with one keystroke — was never the original design goal. He built it to eliminate PR review arguments, and the authoring speed improvement emerged as an entirely unplanned side effect after release.

Know someone who'd find this useful?

Episode Transcript

Developer tooling shapes how software gets written day to day, but the best tools often disappear into the background once they succeed. Formatting, linting, and build systems can either create friction and endless debate or quietly remove entire classes of problems from a team's workflow. Over the past decade, the JavaScript ecosystem has wrestled with both extremes, as it scaled rapidly and accumulated complexity. Prettier emerged as a response to the surprisingly human problem of engineers spending too much time debating code style instead of building software. It offers a deterministic, opinionated formatter that helped normalize automation as part of everyday development. James Long is a design and product engineer who has worked at Mozilla and Stripe, and he's the creator of Prettier. He joins the show with Josh Goldberg to talk about the origins of Prettier, why formatting debates are so emotionally charged, the technical challenges of building formatters, the realities of maintaining popular open source tools, and how the JavaScript tooling ecosystem continues to evolve. This episode is hosted by Josh Goldberg, an independent full time open source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of The O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies and a cofounder of SquiggleComp, a conference for excellent web developer tooling. Find Josh on Blue Sky, fostidon,and.com as Joshua k Goldberg. With me today is James Long, a design and product engineer who has worked at companies such as Mozilla and Stripe, created Prettier, and created and open sourced the actual finance app. James, welcome to Software Engineering Daily. Thank you, Josh. Very happy to be here. So excited to talk to you as a user of Prettier and advocate for this is a dream come true. But before we dive into Prettier and formatting and all these fun JavaScript and TypeScript dev tools, can you tell us who are you and how did you get into coding? Sure. So I'm James. I've been coding really since well, I've been in the industry for over two decades, but, you know, I was kind of the typical cliche, like, nineties kid that was hacking on computers. Just kinda always we happen to have I think it was an Apple two in our house when I was, like, in middle school, and I just kinda instantly gravitated towards that, just kind of like a lot of nerdy kids did in that age. Right? And I remember programming in was it QBasic? There was the one that was just like you had, like, the ten, twenty, thirty, forty with the line numbers. For some reason, it wasn't one, two, three, four. I'm pretty sure. And I think the thing that really draw me to it also is that I could draw things through the screen. So I remember, like, drawing lines, and it was just, like, that green kinda terminal look was the …

Get the full transcript (10,749 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Software Engineering Daily transcripts →

You just read a 3-minute summary of a 47-minute episode.

Get Software Engineering Daily summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Books, tools, and gear mentioned in this episode

SignalCast may earn commission on purchases via these links.

Tools

PrettierBy guest
“James Long, creator of Prettier, joins Josh Goldberg on Software Engineering Daily to discuss how the opinionated JavaScript formatter emerged from code-style debates at Mozilla”
Biome
“Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially.”
OXC
“Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially.”
ESLint
“ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments.”