Prettier and Opinionated Code Formatting with James Long

0:00Developer 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.

0:42James 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 tool set for JavaScript and TypeScript.

1:23He is also the author of the O 'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on Blue Sky, Fostadon, and.com as Joshua K. Goldberg.

1:52with me today is james long a design and product engineer who has worked at companies such as mozilla and stripe created prettier and created an open source 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 I've been in the industry for over two decades.

2:23But you know, I was kind of the typical cliche, like 90s kid that was hacking on computers, just kind of always we happen to have, I think it was an Apple II in our house when I was like in middle school. And I just kind of 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 q basic there was the one that was just like you had like the 10 20 30 40 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 drew me to it also is that i could draw things to the screen so i remember like drawing lines and it was just like that green kind of terminal look was the only color that it had but you could like draw lines and draw shapes and it was really cool is you could actually play notes too like it had it had a command like play a flat so you could draw little lines and have these things animated and like it would play music and so it just like instantly drew me to it and then later in high school 3d games was like something that just like really attracted me to it just blew my mind that you could do that with a computer and you know it took me a couple years to figure out how that even worked but i bought some books around like the direct 3d programming and things like that so i studied it in college and then i got a job and just has always just it's just always kind of been that thing that has satisfied a creative itch for me.

3:33We're going to talk more about that creative itch as we continue. How did you get from sort of 3D programming and notes and such into working on web development or even web development tooling? So it was easier to get a job for sure. I went to a small school in Chattanooga, Tennessee. And so there was like a local web development shop and there weren't any game development shops around that. It was also I felt like even though I had tinkered around with game dev programming. It's just like a harder industry to get into. That was most people were using like C or C++ back then. And I wasn't as strong in that.

4:05So the web was a little bit more, it was just more accessible. And the web was interesting too, because it was also a visual thing. So it was a good blend of practicality. But like the front end part of it was still satisfied that creative itch a little bit where I could still do visual things, still work with designers and still come up with like visual things. But the games industry is like such a different industry. And the first couple of years I was doing the web stuff with my eye on game development. But the more I was able to like get in touch with people and learn about that industry, it just became clear that it was just such a grueling industry, super low level, super low pay, like just seemed very grueling and just not really fun.

4:42So I kind of knew that it would become kind of just like a, the game stuff would be just kind of a side project to me and the pay would be coming from like web development stuff. There's something fun about web development, how you can kind of just get a page locally, throw some JavaScript, some CSS on there and instantly see the changes as you edit them, right? Yeah. And also just the ability to just share it with a friend instantly because the game development stuff, a lot of the studios and the engines have, were getting really good to where you could have hot reloading and do a lot of like visual stuff.

5:10You could be in something where you could select elements and like move them around and then like patch like script elements to them, but you can't share it. Like Of course, eventually once WebGL and all that got good enough, then you kind of can do that too. But yes, the web had a very instant gratification for creativity. Let's talk about the web. You have been working in web dev tooling for a while. The most notable project folks associate you with is Prettier. First of all, what on earth is Prettier? Why do we need something like this? Prettier is a JavaScript formatter. It takes your code and then you give it basically one parameter.

5:44It's got a couple other options, but mostly the philosophy of it was like to be very opinionated, to not take options. You just give it one parameter, which is the print width. So you say, I want there to be 80 characters or 100 characters. I want all of my code to fit within this size. And then it formats it based off of that size. And it's a deterministic formatter. So whatever the input is, no matter how many spaces, new lines, however, whoever was super opinionated about how they wrote the code, you'll get the exact same format out. And the reason why you need this is just, well, the original reason was mainly to just get rid of these kind of like fights and little nits between teams, right?

6:21Or like even specific team members that were really opinionated about it. And it just would, I hated the PR review. So I was working back at Mozilla before I created Prettier and I just felt like such a waste of time to be having these PR reviews go back and forth about formatting nits. And it was like a weirdly emotional thing that just to me just did not matter at all. Like it means zero difference on the users that you were using. So it was like this thing that tended to fall into some of our like OCD or perfectionism traits that like maybe a lot of people just couldn't help but care about the formatting.

6:54And this is a tool that is automating away this so that you can kind of like relieve that care about it and have a perfectly consistent code base across all of your teams. And it's just something that you can accept. Now, that's the thing that was surprising to me is that we very quickly saw how it relieved some of the pain and annoyance of actually writing code. So now when you have this format or embedded into your editor as your writing code, you can write code like in a very stupid way. You can write it all on one line and then just press one keystroke and it just formats it in the production ready format that you could commit.

7:28And that was a surprisingly effective thing that actually I actually was not building it for and actually was like something that was unexpected. Well, Prettier came around in around 2017, right? Yes, I think at the end of 2017 was when it started. It actually launched January 2018, if I am remembering that right. Well, at that time, we already had tools like ESLint and TSLint, now just ESLint and TypeScript ESLint that can format code. And there are stylistic and formatting rules in linters like ESLint. Why would I want something like Prettier, a second additional tool when I can just use ESLint?

8:02I think there's two reasons. One is that, so we did that at Mozilla. We use eslint. And I think it would try to automatically fix your code based off of those things. However, if you looked at our eslint config, I swear it was like it was like 100 rules. And these weren't even including the actual semantic rules. These were just the formatting rules. And so like it didn't solve the team dynamics of the you wanted to have control over the formatting. I forget exactly why we would still have the problem of PR nits. And actually, I think that leads me to my second point. I do remember why it was because there was those even though you could even though ESLint had multiple, multiple, I think over a hundred, I don't know exactly how many rules based off of the formatting.

8:45It still didn't cover everything, right? So there's, there's our things about how you, in JavaScript that are very dynamic or that are very hard to express as a Lint rule, such as if you call a function, give it three or four arguments. And then the last argument is a function. You know how JavaScript, we tend to do the first three arguments that are numbers all on the same line as the call to the function. But then the anonymous inline function that we're passing to it, we will break that on the opening bracket and then write that inline indented, right? And you just can't express that with ESLint's rule-based system.

9:19You need a much more expressive dynamic, like a holistic formatter that can reason about where that function is, is what's the parent of that function. And so I think those are the two things. Like one is that it allowed different people in different teams to have too much control over the formatting, because they could like customize all of these hundreds of rules and it just didn't cover enough. I remember trying to roll out prettier on a team back when I was at Microsoft and an actual common piece of pushback we got was, I like the idea of faster code authoring. However, I put so much intent and meaning behind the formatting choices, such as when you have a class or enum with many properties, putting the equals all aligned.

9:59I don't like how prettier removes my build to do that. What would you say to someone giving you that pushback when you're trying to advocate for Prettier? At this point right now, I don't really hear that much anymore. I think that argument has kind of been proven false to where most people use it now and the benefits of it are worth it. And I think that was like an attachment to the code that you wrote that that argument just wasn't correct, right? Like there was not meaning there. Like once you kind of start using it, you see that you're still able to understand the code just as much. It was harder to make the argument in 2018, 2019 when people were pushing back this a little bit more at the beginning.

10:34And I think what we would try to tell people is kind of what I just said, but in a more gentle way, like, it's like, hey, you should just try this. You should give it five minutes. You should give it a little bit of time. See if there actually is meaning in that. You will find that in a lot of places that you thought there was meaning that you can actually just understand the code relatively the same. If there is something that's like an embedded, like matrix that you really do want aligned really well, then we have the ability to ignore, like you can say prettier ignore in a comment above that expression and prettier will not format it so there are rare cases where you can care about it but like to say that you need to care about 100 or even like even you need to care about you know 20 to 30 of your code that the formatting matters that much i think is just like not an argument that we were ever convinced by and we would just try to tell people that and if they didn't agree then they didn't have to use prettier but i think eventually they saw like the social proof as more and more people started using it and they would try it out and kind of see that.

11:31I think you might need to care about like 1%, 0.1 % of your code. Like there's few places that you really are having something really specifically formatted, but that's what we would try to say. It's interesting also that this came out relatively recently in the JavaScript lifetime. You know, this was not a thing in the 90s, not a thing in the early 2000s, and it took until closer to 2020 than 2010. What do you think took so long for the community to create and then adopt something like Pridio? So this is a good time to also talk about Christopher Chateau, who I actually consider a co-creator of Prettier.

12:02I think like he and I both individually say that we created Prettier and I have no problem with that. I technically created like the first implementation. He came in very quickly and I think we can talk more about the history of this later. But I say this because he has a great post on his blog that I think is called the Birth of Prettier. And I forget his exact blog. I think hopefully we can link to it. Or if you just search Chris Fruchido, birth of prettier than that post will come up. He has a good explanation about like, there were several formatters that were attempted. And also ESLint, I think was like probably a lot of people use ESLint with the formatting rules.

12:39And a lot of people just thought that was good enough. So that was one thing that people just didn't really see why you needed a holistic formatter, like a whole different tool. A lot of people didn't see that. There were some other efforts that tried it. And I think the thing that they got wrong is that they would try to follow the philosophy of some other formatters like GoFormat. And the difference between GoFormat and Prettier is that GoFormat is, it's very, I'm trying to think about the right word. It's even more opinionated than Prettier basically. Like it doesn't support some of the sophisticated breaking patterns that Prettier does.

13:13So it's like, it will always format like a struct or things, and it will always break it across the line. It doesn't have a concept of like a print width, right? And the thing about the print width that was interesting about Prettier is that it sounds like, like, why wouldn't you just hard code like a print width or something like that? But it's interesting about this because with Prettier, you need the ability to, in JavaScript specifically, compared to Go, because you do a lot of nesting of inline JavaScript functions, and there's all these just really weird patterns, you cannot have a deterministic, or not a deterministic, you can't have like a simplistic approach to formatting kind of like the go format does which is like hey if you have a struct we're going to spread it across all of the lines because what if you pass like in javascript if you have like the inline function case well sometimes we format it differently if it's at the top level or if you pass it as an argument to a function in go format it just didn't support that kind of thing at all like it would whether it was a function argument or top level it was broken up the exact same and i think some of the other javascript formatters had taken that kind of approach.

14:16And it just didn't work because it just failed way too quickly on all kinds of real world patterns that looked too ugly. And so for this project to succeed, it needed to pass, even though I say I don't care about the formatting, we all do care a little bit, right? Like it can't look horrendous. And so it needed to meet a bar that I don't think other formatters had quite hit yet. And so I think it just happened to be kind of the right timing where people were kind of geared up for this, but they hadn't quite experienced the tool that did it well enough yet. And I did for whatever reason. I don't know if I like got lucky or I think I'm decent at marketing too.

14:52I might've just gotten lucky with my marketing. And it just part of these kinds of things are always luck, right? That like, I just might've happened to be at the right time at the right place. And I remember specifically my tweet that went viral that kind of kicked everything off. And sometimes you just kind of get lucky like that. When you think about it too, at the time, that was right about when promises were getting ratified, async await was getting ratified, rolling out to browsers, the JavaScript of 2015, 16, 17 had a lot more callback hells and pyramids of doom than the code we write today, and especially compared to other languages.

15:22That's a great point, actually. That is very much true. Today's episode of Software Engineering Daily is brought to you by Unblocked. Your coding agents have access to your code base. Maybe you've even connected other tools via MCPs. But access doesn't mean context. Agents can't reason across MCPs. They don't know your architectural decisions, your team's patterns, or why the API was shaped the way it is. So agents look in the wrong place and deliver bad outputs. Then you spend time correcting, turn after turn. Unblocked is the context layer your agents are missing. It synthesizes your PRs, docs, slack, and tickets into organizational context that agents actually understand.

16:03So they make better plans, write higher quality code, use fewer tokens, and require fewer correction loops. If you are running Claude Code, Cursor, or any agentic workflow, Unblocked is worth a look. Get a free 3-week trial at getunblocked.com.se daily. In mobile application security, good enough is a risk. GuardSquare uses advanced, multi-layered code hardening techniques and automated runtime application self-protection and mobile application security testing, combined with real-time threat monitoring to deliver the highest level of mobile app security. Discover how GuardSquare brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com.

16:52All right, so you've got Prettier. Christopher Chadeau, who is helping out, you're rolling things out to the community. What was the initial reaction to Prettier like? It was a mixed reaction for sure. I mean, there was a certain amount of virality to it to where I was surprised for sure at how quickly a percentage of the JavaScript user base adopted it like relatively quickly. Like it seemed like there was a decent amount of people that just kind of use it for a couple minutes and then totally got it and got prettier pilled, I guess, for the lack of a better word. But there was a decent amount of like pushback for sure.

17:25But like, this is the kind of thing that's like, we're not trying to sell something here. There's no money made. And I think that is kind of another interesting conversation, especially in the context of recent tailwind drama. Well, no, it's not really drama, but you know, the news about open source funding and things like that. But at the time, it's like, it was in our interest to sell people just because we thought it was better. But it's like, if you don't like this, then you don't have to use it. So we were happy with whoever wanted to come on board. And a lot of people did. And it was enough to kind of start the momentum of it growing pretty quickly.

17:54And so I think also, I think probably the hardest thing is that there was a lot of opinions that needed to be worked through of what the formatting should be. So I think that's kind of the most interesting thing to talk about in terms of the reaction, which is just like the pages and pages of GitHub issues about people being like, I don't like how it formats this or like, we haven't quite solved how it formats like comments when you have like an inline comment and like a turn areas. And then there's like a long or like turn areas specifically with something that took years. Like there was different formats that were tried that were switched back and forth.

18:27And so there's a lot of opinion. There's again, people do care about formatting. And so there's a lot of responses and opinions to that kind of a thing. That is something that was difficult, especially for me around that time for that first year, because you can do this for months and months at a time. And it seems like those kind of discussions don't really ever stop. So it's like, it feels like you're just like pushing a boulder up the hill forever. But I'm very grateful to the maintainers who kept working through all of those issues and kind of helped just the whole Prettier community that kind of helped work through a lot of those issues.

19:00And eventually, you just have to make a decision, right? Eventually, it's like, this is the issue. We're going to decide this formatting for this issue. We're going to close the issue. And we just got to move on because you can't just keep talking. So one must imagine the prettier maintainers happy. It is interesting, though, that open source, especially in the tooling space, is so notorious for burning people out and then money being difficult. I think the drama you're alluding to is that the Tailwind company over the last few years has had to lay off quite a few employees with the rise of AI and difficulty in showing off or selling their paid products now.

19:31Does the Prettier project have financial concerns? Is that something that's come up? It is something for sure that I have seen discussed. I'm to be totally honest, I'm not the best person to talk about this. I have not been really involved in this project at all, even for even for a couple years. I wasn't very involved for like the first nine months in 2017. Around that time, I was also trying to build my I left Mozilla and was trying to do self employed stuff. I did contracting, I was trying to build a product to see if I could scale up that product to see if that could cover enough of my expenses just to be kind of like a lifestyle business.

20:05So I had a lot of other things going on that was really hard to do kind of this like free open source work. And so I kind of scaled back a little bit and was, you know, involved in decisions for, for a while. But especially in the last couple of years, like I haven't really been super involved. So it's definitely like, yeah, I've seen, this is what Christopher should do. I think he deserves a ton of credit and totally deserve, I think for the entire sum of the life of Prettier, Christopher has put in way more work than I have. So I think like he, he deserves not only like, he definitely was like a co-creator, plus he kind of stuck around to help structure some of these how this money comes in and how it like it's dispersed to the maintainers so i know they have a structure there i know there's a decent monthly payment that goes towards the contributors but as far as i know like nobody's full-time working on prettier which is what is different from tailwind which they officially kind of formed a business around tailwind so prettier like there's no business as far as i know there's no business of prettier there's no one or two people who's who's trying to make this work and actually make this like a full-time thing.

21:05It's just kind of more of the typical open source thing where there's a couple of people doing it part-time and they should absolutely be compensated for that. And there is some compensation there. It's not enough. I think for like for open source stuff, they thrive on sponsors and like donations. And so that's never enough. I think that the amount of work that the maintainers do, they probably deserve more money. But it's not the kind of thing that there's not a business about to falter because there's not money coming I mean, it's just, hey, if Prettier doesn't get enough donations, then there might be a year or two where there's just not a ton of work done on it.

21:36And that kind of is what it is. But I can't tell you like currently exactly kind of like how bad things are. You know, I think it's I think as far as I know, it's OK. I think there should be more money coming in, basically, is always the case. For a tool that's existed for about a decade, looking on opencollective.com slash Prettier, the total raised money across those nine plus years is just about$243 ,000. dollars. Yeah, that is crazy. Consider the average dev salary in America today. Yeah, it's not enough. It's not enough. My wife, actually, it's funny, because when I started prettier, and I, you know, was investing a lot of time into it for those in 2018.

22:14My wife is like, okay, so like, I mean, you're gonna make money somehow, right? Like, how is this gonna make money? Like, why aren't you making money right now? Because you're putting all this time to it. And I was like, you don't understand. It's open source. It's awesome. Like, we're just working on stuff together. But the reality is yes like we spend time on things and we care about things but at a certain point it needs to translate into a reality where it becomes something that people are putting their weekly hours into something that's just maintaining and it's not like a joyful fun thing that they're just doing to be creative anymore it's an actual job and so yes it's a hard thing to figure out you touched on a really interesting point that i want to drill into before moving on to kind of higher level tooling discussions there is a big difference as you just alluded to between the initial explorations, the, so to speak, fun, exploratory parts of open source and product creation, and then the perhaps less fun for some and more for others maintenance phase of it.

23:02And you see often in these open source projects where you have a certain set of people join at the beginning or create the thing. And then over time, they transition to a different group of people, partially folks who are more excited about maintenance. What do you think is so different about the two forms, the difference between creating or exploratory phases versus maintaining or contributing phases? They're very different and they are still kind of, I think can be mixed together because I think like, I guess, for example, one thing that comes to mind is now, and this is something we could talk about more too.

23:33There is like the Rust rewrites of Prettier, which is like aux format. And that's a creative place to be, right? So there can be like a mixture. Like if you look at a whole timeline of a project, it's not just at the very beginning is this creative fun part. And then it's just like, it tails off into just this totally boring maintenance thing for 10 years, usually it's like, there's a, there's like a really bump of like the fun part of like, this is like a cool idea. And then it kind of goes down into maintenance, but then it's like, Hey, we should do like a plugin system. And then like, that becomes kind of a fun, creative thing where it's like, you are kind of doing something new again.

24:04And so that that's, that's kind of another bump. So it's kind of like, like a mixture of things, but I do think there's people who seek out and love to work on ambiguous ideas or kind of just see kind of things in the ether and really enjoy bringing those into reality. And there are certain people that find that really hard and just like, it's just not something that gives them the right kind of energy. And they really do enjoy taking something that's existing and just making it one step better and doing that week by week. And by the end of the year, you've made something way better than it was at the beginning of the year.

24:37I think there's, I don't know if it's different personalities or it's just, I think there's different sources of like energy there. Now, I do say that I think everybody would enjoy to do what they consider the fun work more, right? So there's probably a very small amount of people who actually find the actual real boring parts, like, you know, going and just like really digging into those obscure bugs. But there's even people that do find that fun. So I think it's best for a project to kind of have complimentary people who, you know, some people find the things fun. How do you design this API?