← Software Engineering Daily
Software Engineering Daily
Prettier and Opinionated Code Formatting with James Long
00:50:35
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,
Loading summary
Transcript65 lines
- [00:00]
Narrator
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 he 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 bluesky, Fostodon and dot com as Joshua K. Goldberg.
- [01:53]
Josh 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.
- [02:04]
James Long
Thank you Josh. Very happy to be here.
- [02:06]
Josh Goldberg
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?
- [02:18]
James Long
Sure. So I'm James. I've been coding really since I've been in the industry for over two decades. But you know, I was kind of the typical cliche like 90s kid that was hacking on computers just kind of always. We happened 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 Cubasic 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 1, 2, 3, 4, I'm pretty sure. And I think the thing that really draw 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 what was really cool is you could actually play notes too. Like 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.
- [03:33]
Josh Goldberg
We'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?
- [03:44]
James Long
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 was 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. So the web was a little bit more. It was just more. 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 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. So 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.
- [04:50]
Josh Goldberg
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?
- [04:59]
James Long
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 were getting really good, where you could have hot reloading and do a lot of visual stuff. You could be in something where you could select elements and move them around, then patch script elements to them, but you can't share it. You can't just give somebody a URL. Of course, eventually once WebGL and all of that got good enough, then you can do that too. Yes, the web had a very instant gratification for like, creativity.
- [05:28]
Josh Goldberg
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?
- [05:39]
James Long
Prettier is a JavaScript formatter. It takes your code and then you give it basically one. One parameter. It'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 for the original reason was mainly to just get rid of these kind of like fights and little nits between teams. Right. Or 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 knits. 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, that, that you were using. So it was like this thing that tended to fall into some of our OCD or perfectionism traits that maybe a lot of people just couldn't help but care about the formatting. And this is a tool that is automating a way so that you can kind of relieve that care about it and have perfectly consistent code base across all of your teams. And it's just something that you can accept now. 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 formatter embedded into your editor as you're 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. And that was a surprisingly effective thing that actually I actually was not building it for and actually was like something that was unexpected.
- [07:35]
Josh Goldberg
Well, Prettier came around in around 2017, right?
- [07:38]
James Long
Yes, I think at the end of 2017 was when it started. It actually launched January 2018, if I am remembering that right.
- [07:46]
Josh Goldberg
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?
- [08:03]
James Long
I 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 a hundred rules. And these weren't even including the actual semantic rules. These are just the formatting rules. And so like it didn't solve the team dynamics of the you wanting to have control over the formatting. I forget exactly why we would still have the problem of PR knits and actually I think that leads me to my second point. I do remember why it was because even though you could, even though Eslint had multiple, multiple, I think over 100, I don't know exactly how many rules based off of the formatting. It still didn't cover everything. Right. So there are things about how you in JavaScript that are very dynamic 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 like 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. You need a much more expressive dynamic, like a holistic formatter that can reason about where that function 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 and 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.
- [09:40]
Josh Goldberg
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. I don't like how prettier removes my ability to do that. What would you say to someone giving you that pushback when you're trying to
- [10:05]
James Long
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 an attachment to the code that you wrote. That argument just wasn't correct. There was not meaning there. Once you kind of start using it, you see that you're still able to understand the code just as much as it was harder to make the argument in 2018, 2019 when people were pushing back this a little bit more at the beginning. And I think what we would try to tell people is kind of what I just said, but in a more gentle way. 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 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, then they would try it out and kind of see that I 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.
- [11:41]
Josh Goldberg
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 like prettier?
- [11:56]
James Long
So this is a good time to also talk about Christopher Chedeau, who I actually consider a co creator of Prettier. I think like he and I both individually say that we created Prettier and I like, 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 Christopher Shadow Birth of Prettier, then 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 and 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 Go format. And the difference between Go Format and Prettier is that go format is. It's very, I'm trying to think about the right word. It's even more opinionated than Prettier. Basically like it. It doesn't support some of the sophisticated breaking Patterns that Prettier does. So it's like it will always format like a struct or things and it will always break it across a 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 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 in JavaScript if you had 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 goformat, it just didn't support that kind of thing at all. 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 and it just didn't work because it just failed way too quickly on all kinds of real world patterns. That looks 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. I might have just gotten lucky with my marketing. And it just part of these kind of things are always luck, right? That like I just might have 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.
- [15:07]
Josh Goldberg
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 20151617 had a lot more callback hells and pyramids of doom than the code we write today, and especially compared to other languages.
- [15:23]
James Long
That's a great point. Actually, that is very much true.
- [15:27]
Narrator
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. So 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 sedaily 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 Guard Square brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com all right, so you've got
- [16:55]
Josh Goldberg
prettier Christopher Chedeau, who is helping out. You're rolling things out to the community. What was the initial reaction to Prettier?
- [17:02]
James Long
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. Relatively quickly. It seemed like there was a decent amount of people that just kind of used 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. But 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, not, 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. And 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 ternary and then there's like a long or like ternaries specifically was something that took years. Like, there was different formats that were tried that were switched back and forth. And 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. 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 Predator community that kind of helped work through a lot of those issues. And 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.
- [19:10]
Josh Goldberg
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 does the Prettier project have financial concerns? Is that something that's come up?
- [19:37]
James Long
It is something for sure that I have Seen discussed. 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 a couple years. I was 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. So 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 years, like I haven't really been super involved. So it's definitely like a. Yeah, I've seen this is what Christopher Chedau, 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. It'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, is some 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, 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. And 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. And 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 okay. I think there should be more money coming in. Basically is always the case for a
- [21:47]
Josh Goldberg
tool that's existed for about a decade. Looking on opencollective.com prettier, the total raised money across those nine plus years is just about $243,000.
- [21:59]
James Long
Yeah, that is crazy.
- [22:00]
Josh Goldberg
Consider the average debt salary in America today.
- [22:04]
James Long
Yeah, it's not enough. It's not enough. My wife actually, it's funny because when I started prettier and I was investing a lot of time into it for those in 2018, my wife is like, okay, so like, I mean, you're going to make money somehow, right? Like, how is this going to make money? Like, why aren't you making money right now? Because you're putting all this time into it. 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 it. 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.
- [22:43]
Josh Goldberg
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. And 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?
- [23:23]
James Long
They're very different and they are still kind of, I think, can be mixed together. Because I think, I guess, for example, one thing that comes to mind is now, and this is something we could talk about more too. There is the Rust rewrites of Pretty, which is like ox 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 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. And so that's kind of another bump. So it's kind of like a mixture of things. But I do think there is 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. I 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 about, like how do you design this API and how do you like create this new thing and how do you bring that into the world and how do you execute it? Plus the people who really care about the current state of things, improving it day to day, talking to users and like fixing bugs. So it's, it's just a. I found that there's always people. Once you create something that's exciting, there's always kind of these couple people that come in. This happened with actual. My personal finance app. I open sourced it and now there's this one guy who Spends a ton of time maintaining it and he's not getting much money from it. I think there is like a similar level of contributions, but he just seems to really love maintaining this project. He loves watching users come in and download the product and help them getting it running and it solves part of their daily life. So I think people get different sources of joy, I guess, you know, and so it's really interesting to kind of see this in action.
- [25:52]
Josh Goldberg
Let's say that you had infinite time and infinite money, and the only stipulation was that you had to spend that time working on something for Prettier, what would you work on?
- [26:02]
James Long
That is a great question. Because I think what's interesting about Prettier is that unlike projects, I guess Tailwind comes to mind just because of recent events. Tailwind must evolve with the browser, and the browser and CSS is always evolving, right? There's always new features added to it. Prettier feels like our project more to me, that has a better chance of being kind of completed in a way. I mean, there's new JavaScript syntax, but it's relatively rare to get a new JavaScript syntax that is a fundamental new syntax that you need to rethink large parts of the system. If I had to do anything, if I had infinite time and money, I think it's an interesting question because prayer is a thing that I use every single day and it covers all the things that I use in JavaScript. So to me, it kind of is completed. To be totally honest, I don't know, because I understand the Rust rewrites. I understand people run prettier on their entire code base and they want that to be fast. I don't really even resonate with that performance need. Like you're rewriting an entire project in Rust. I respect it. I think you should do it. I think OX format is a great tool if people want to spend their time on it. But I run prettier in my buffer, in my Emacs buffer. It run always runs fast enough and it just feels like a completed project from my perspective. And I'm sure there's all sorts of use, so I don't really use it markdown or format, all these other things. So I'm also not exposing myself to this entire world of plugins. So I embedded Prettier into Obsidian. So as I'm working in a code block, I can run a keystroke and it runs prettier on just that code block. Like I never want to run it on the rest of the markdown. File it. Just run it onto that code block. And so I don't know if I have anything. I'm sorry to disappoint you. To me, like it's perfect. To me it's like completed and I'll happily switch to AUX format if it works just as well and it's like a T bit faster.
- [27:58]
Josh Goldberg
That's interesting on two points. One, you have to love open source maintainers saying that the thing is done. You don't get that in corporate life as much. But two, you don't use prettier on Markdown. I would have thought for the same reasons. It's useful in JavaScript, you know, consistency, ease of writing code, not having to manually format. Is that not a thing for you?
- [28:16]
James Long
I use prettier in kind of a weird way in Markdown. I personally don't find it as useful to format my markdown code or my markdown narrative content like that is the content that I am writing paragraphs on. I'm typing out paragraphs. I do a little bit of Markdown syntax and it's just not. There's not nearly as much structure there as code. Now for the code blocks though, I run prettier on the code blocks, but the way I do it is in Obsidian, as I'm writing code in the code block and it could be like a hundred lines, I have a keystroke that runs prettier on just that code block, right? Like I do run prettier on the code in my Markdown files, but I don't run it on the entire Markdown file. Like I don't just reformat the entire Markdown file every time as I'm writing code in Markdown, I reformat the code block that I'm working on because that's the only thing I'm interested in. And maybe I don't hit these perf problems because like I do write massive posts. I want to be able to write 20 page posts. And the formatting of my code block is because it's always only applied to the code. It's always instant, it's always super fast. I'm not needing to reformat the entire Markdown file every time, if that makes sense. So it's a little bit of a maybe esoteric setup that does make sense.
- [29:35]
Josh Goldberg
When you talk to companies like voidzero or organizations like Biome, oftentimes they describe the user need their targeting as sort of one step higher or larger in scale than the common open source project, where a company might have thousands, tens of thousands more files. And if they let's say update a dependency like Prettier, then they need to run on all thousands upon thousands of files and then they get into performance issues. So what do you think of kind of that user pain or that solution of rewriting in Rust? Does that feel reasonable to you?
- [30:06]
James Long
I think it's totally reasonable. I think it's a question of resources and if there's the right number of people that are going to invest in this and it's not going to be a, you know, if it's managed well and resourced well. I think, you know, there is a couple part time maintainers of Prettier. Like if a user was going to come in and say, hey, you all need to rewrite this in Rust, it's like for the current state of things it's better for the current maintainers to just work on the current JavaScript code base and make that better. But if there is a whole separate group of people working on like this OX format tools and Biome and they have like funding to pay developers to work on this full time for like a year or two, I think it's amazing. I think it does solve a pain point for sure. So I'm fully supportive of those tools. Like I'm not again, I'm also not like super involved in Prettier right now, so this might not be surprising. But I'm not, I don't have any super emotional investment in Prettier. If Prettier was to go away and say AUX format was to completely replace it, as long as it meets the similar needs and works like a similar way and it formats the code in a similar fashion, then I'm all for it and I fully support those tools.
- [31:10]
Josh Goldberg
It's very pragmatic. I want to take a step back and kind of talk about JavaScript and web tooling as a whole. There's a criticism sometimes targeted towards the ecosystem that we have a million tools, it's hard to keep track of them. They all do different things, it's hard to set up. And on the one hand Prettier has been stable for a very long time. Although we just discussed modern ish competitor ish to Prettier, it's for the most part just what people use. That being said, there are a lot of tools that it has to integrate with. How do you feel or what is your reaction to people criticizing the fluid, ever changing form of JavaScript dev tooling?
- [31:44]
James Long
Yeah, it's kind of a mixed bag because I think that there was a time, you know, I remember when we were Tweaking our webpack configs and just hyper optimizing things and the ability to compose together kind of a unique system that only applies maybe if you're at a company. You know, Stripe was a super complex company and so they use webpack. They're moving to. I think they're moving to Vite now actually. But the ability to kind of compose your own system that meets your needs, if your company is kind of like has specific needs that something out of the box, I think there's a higher risk of something out of the box that doesn't. Is supposed to do everything together when you can't use that because it works a certain way. Right. So that there's a benefit for things being composable and you can kind of hack them together. I would say that those complaints though are. Well, like, I think they are grounded in something real, like a real pain point. We've also seen tools like Bun, right. Which just, they literally just work. You don't have to do anything. You don't. I never run. No. When I was using Node you'd run into all these kind of issues where an import was trying to import a file with like a wrong file extension. I just don't hit those things in button. And there is a significant user experience improvement with tools that do just. Just work where you don't have to kind of like duct tape things together. And I also think like tool like Vite I think is another great example of this. And I think Vite is just a really great tool because it does allow you to configure things to a certain level. And that's why a company like Stripe is actually able to adopt Vite. However, Vite has that sort of out of box feeling. Right. You can take Vite. It doesn't take hardly anything to configure it. You can get an index8html file that loads a JavaScript file and it renders something to the page very, very easily. We've grown a lot. I think those complaints were valid five years ago. I think since then the state of the tooling right now is much better. So I think that those complaints are either out of date and they just haven't used some of these newer tools, but I think we've certainly grown a lot out of that kind of pain. And I don't think there's as much pain anymore as there used to be.
- [33:43]
Josh Goldberg
It's funny, people still complain about how CSS the joke is it's difficult to center. And that's been a part of Flex for over a decade now. What do you see as kind of the next big pain point to be solved for web dev tooling then?
- [33:56]
James Long
I have to be honest that I'm really happy with tooling right now. A lot of my thought goes more on the web itself and the runtime of the web. So I don't have a great. I hope to not disappoint you Again, I don't have a great answer. I think BUN is amazing. I think BUN has solved the backend environment and the ability to run scripts very well. I think Vite has solved the bundling problem very, very well. I am not a huge fan of React server components. I'm just going to say that right now. So I don't. I think that the next JS and that world. I have a lot of hesitation around that kind of stuff. I think that has introduced a lot of pain points which you require tooling to kind of see what's going on in those things. But I think that the solution is not better tooling for those things. I just don't agree with that fundamental approach, generally speaking, which is maybe a different topic. But I think I'm thinking more along those lines, which is like, is React server components really the right thing here? How can the client and the server communicate better? What are better strategies? Like what is Remix doing? Those are kind of where most of my thoughts are right now. And I think we need better ways to do server side rendering with hydration and I think we should be exploring more things with that, which will probably require specific types of tooling to kind of be able to control those environments more.
- [35:15]
Josh Goldberg
Is there a stack out there that you think is closest to your target end state for this type of area?
- [35:20]
James Long
So I've been thinking about this. So I left Stripe back in October. So I've had a couple months to sort of reevaluate things at Stripe. I just didn't really have that much time. I'm still evaluating my opinions. I have been looking at solidjs a lot for the front end part. I really do like what they're doing in Solid JS a lot. I looked at Astro, which was interesting. I wasn't a huge fan of some of the way that they do like the syntax and how you actually have the Astro files, but like the actual Islands concept and things like that was pretty compelling. I think Remix three, I'm decent friends with like Michael and Ryan, the creators of Remix. And this, this new version that's going to be coming out soon that potentially might match some of my more Recent thoughts the most because I think there's some solid starter kits which do some sort of server side rendering with stuff. I'm not super familiar with that, but I would probably say Remix 3 is a very interesting take on this and probably is something that I'm going to keep a close eye on like the most.
- [36:21]
Josh Goldberg
Well, we'll have to look forward to having those folks on the show at some point. Is there anything else before we start talking about wrap up topics that you want to bring up about Prettier tooling around it and so on?
- [36:31]
James Long
One thing that might be more maybe to go dig into it a little bit more technically is and maybe to go back to your question about what I would work on in Prettier is the reason why duct taping these types of tools together gets really slow is because they have to parse the JavaScript into whatever they're doing and then they generate JavaScript out of that and every single tool in that step does that. And that's why I never, to be totally honest, I never liked the eslint Prettier plugin stuff because it's so slow. And like basically if you use that setup right and you that is the setup that you use to format your file that is so much slower than just invoking Prettier directly. Don't do that. If you're going to format your files, just call Prettier. Don't call eslint and tell it to call Prettier because there is a significant overhead there and maybe they've solved that, I'm not entirely sure. But at one point at least you solved it.
- [37:29]
Josh Goldberg
We did not. We just told people to stop doing that. I'm so happy to hear you say this. There are so many reasons why you shouldn't be running Prettier in eoslint. Primarily what you just referred to of the performance of it directly. But also we have a lot of slow rules now. Rules that use type information or import analysis, cross file info. And when you have auto fixers from those rules and auto fixers from prettier rules, you end up running all of them all the time, constantly. Eslint will rerun rules up to 10 times when there are fixes that conflict with each other. So you take sometimes multiple seconds after each save where it should have just taken maybe half a second, which is obscene as a user experience.
- [38:08]
James Long
Yes. And I think this is where going back to kind of the fragmentation of tooling also, which is like it's powerful, right? Because you can take these different tools and put them together in different ways. But there is a really compelling motivation for bundling things together into a single tool. And I honestly haven't looked super closely at what the AUX format and other. I think the interesting thing here, I think is that it is a suite of tools. So it. And this is what Biome, I think was kind of trying to aim to be also. But the reason why this is so compelling and actually I should have talked about this when I talked about my support of these tools. What probably does excite me most about these tools is that it solves this core problem where they have a standard workflow to work with ASTs and they reduce the amount of time that they're parsing JavaScript and generating JavaScript. And now they can parse JavaScript once, work with the ASTs, get the formatter to format the ASC and it stays in AST and then they pass the ASC to like a linter, then they can lint against the AST and it's a whole standardized toolchain. So it's not even just. I'm kind of guessing here. I'm not super close to how all of this is working. A lot of times a JavaScript to Rust rewrite isn't faster because it's in Rust. I mean, it probably is faster, but a lot of times it's faster because you've had a chance to rework all of the algorithms and how the entire thing works altogether. So the fact that they're able to do that and it probably is faster because it's Rust, but I think there are cases where there's been like a rewrite from some front end job or like a JavaScript thing to Rust and they use like webassembly and they say it's like 10 times faster. And then you go and look at it and it's just they use a completely different algorithm. Right. If they had rewritten it in JavaScript, it might have been just about the same. I don't think that's the case for these tooling, but I do think it's a fun. It's like an addition. Not only will Rust be faster, it's an additional reason to also optimize all of this kind of toolchain stuff too. So I'm very excited about that. I think that was the core problem with prettier and how it integrates with the rest of the ecosystem.
- [40:04]
Josh Goldberg
That is exciting. I've got two more topics to bring up with you, a technical and a non technical. For the technical topic, a lot of people might Be listening to this and thinking, wow, this is really cool stu stuff, or wow, this is really useful stuff. Ideally both. And they might want to get involved. I know a lot of developers get a little intimidated when you start throwing around terms like parsing and ASTs. Let's say you were talking to a relatively new developer who's not very confident in these areas. How would you explain what file parsing, ASTs, printing out, what that all means and what it means for tools like Prettier dslint?
- [40:34]
James Long
I would explain it as if you have code in a file, it's a string, you need to be able to work with that. Like the code that you're writing is not English, right? At least now with AI, most of the time we are writing English. But if you're going to talk about just code, it is a structured formatted thing. We have a specific grammar that you are abiding by. When you write code, you have like a function and you have the name of the function, then you have the arguments, and then you have a bracket to work with that in the compiler or whatever is running your code or doing whatever. It needs to be able to work with that somehow. Right? And so it's just a way of parsing that into a data structure that's kind of all that a compiler is. And the ASC is a data structure and it just is a thing. It's a tree and it represents the different pieces of the code. And it just gives semantic meaning to what you visually see on the screen, which is like the code which looks like it's a readable piece of thing. It's really a semantic tree of information. And so that's all that a parser is is. It takes that and creates that asc, which is a tree of semantic information. And then the compiler can take that ASC because it has all the semantic information embedded into it. It can do interesting things to it. It can say, oh, this is a JavaScript function, and let me compile that out to a go function. If you're working on like a JavaScript to go compiler or something like that, I think that would be the most basic explanation. Does that make sense?
- [41:59]
Josh Goldberg
That does make sense, but it brings up another question of, okay, so prettier as an example of a tool that works with abstract syntax trees and parsing, takes in your text, your string, turns it into an ast, then what?
- [42:11]
James Long
So prettier is a unique one in that it generates another layer, so there's like an intermediate representation. So most compilers, what they do is they take in an ast and then they will generate another ast and then they'll generate the code from that ast. And this is a very simplistic way to put it, but if you're like compiling C code to assembly, you. You have one thing in which is the AST for the C code and then something out. And there's different ways to do that out part. So prettier is like another version of that out part. And the way that it does that out part is it converts the AST into its own intermediate representation grammar, which is another data structure. It's not an ast. I'm not going to go into why. It's more like a flat array of description, which is like little pieces of text with additional information about where to break the code. And so it has this nested tree of arrays with the snippets of the text plus these break informations, which is where we encode how to format the code. And then there's one more pass which takes that data structure and generates a string. And that's how it kind of works the whole thing. So that's how all Prettier is basically a Compiler. It's a JavaScript to JavaScript compiler, right? And so you have source code to AST, to the compiler, to whatever intermediate output format is, and then something which generates the string from that intermediate output, and then you have the string in and string out.
- [43:38]
Josh Goldberg
Leading question. That sounds real easy. Why is it not easy?
- [43:43]
James Long
Yeah, compilers are really hard. A biggest thing is just performance. So you can be really naive and write actually pretty simple compilers. You need a lot of caching to make things really performant. There are a lot, especially for JavaScript. It's a very complex language. And so. And AST is a tree of nodes, but there could be a hundred different types of nodes, right? And so you need to, if we're talking about Prettier specifically, it needs to be able to know how to handle every single one of those nodes. And so there's like, could be one big compiler file that's thousands of lines long, that is a big switch statement that has like, switch on the node type. You have to implement every single one of those nodes, right? And then on the output of it, you need to also kind of do like similar things also. And something else that comes to mind that a lot of people don't think of is error handling. So when something goes wrong, you need to know where you were in that original source string. So you can say, oh, I failed on this Open curly bracket node. Or that's not actually a node, like a switch statement node. This is wrong right here. And so I need to throw an error. Well, you can't just tell the error. Hey, this switch statement is not correct. You have to tell the error. Oh, this switch statement is not correct. Here is the line of code that is not correct on and let me display you the piece of code and point to exactly where it's wrong. And that is really hard. It's actually really easy. You can sit down and write a compiler. And I think there's like simple tiny compiler instructions of how to do that out there right now that you could probably do pretty easily. But how to trace the source information through that compiler is a really hard problem. And there's like whole areas of research about how to do that. So it's the kind of thing that to make this workable in reality, it has a lot of little practical problems that make it hard.
- [45:22]
Josh Goldberg
I think this will be the last leading technical problem. What you just described sounds really cool, but also a fairly large amount of work. I'd rather do something more straightforward and simple like prettier. Printing out code is pretty easy, right?
- [45:34]
James Long
So here's a perfect example about why it's really hard actually is comments. So yes, you can take something and print it out easily, but how do you handle comments? So in specifically think this is a unique thing about a formatter, which is unlike a compiler, which if you're compiling C code to assembly, you just get rid of all the comments and you just output the assembly code for a formatter, you have to maintain all of those comments. And what's weird about it is because you've changed the code, you gotta like figure out where to put the comment. And that's a really weird problem because comments are not semantically meaningful, right? So I think that was the hardest thing in prettier is how do we handle comments? Like, comments are not an AST node either. When you parse something into an AST, it's not part of the AST. So we had to extend ASTs to have like a. I think this is how it worked. We could tag AST nodes with like, this was the comet and this is where it was around this node. And then when that was formatted, we could decide where to put the comment in the output. But there's so many weird edge cases where you can't just put a comment here because we've changed it. So now that we've collapsed it on one line, so we can't Put the comment in there, because the comment will comment out the entire rest of the line. Right. So we have to, like, move the comment up and it's a whole bucket of edge cases. It's hard.
- [46:51]
Josh Goldberg
Lovely. All right, last question for you. You have a fantastic personal site with a bunch of explorations. Can you tell us about things like the circle of fifths and Lydian scale? What is cool about sound and noise?
- [47:04]
James Long
Yeah. So this is something that I've been recently getting into is music theory. And I'm going to sound like a dork talking about this and also probably be very wrong because I'm very new to this. I think when I was learning piano years ago, it was like, to me, the simple conceptual way to think about it was that you just have to learn all of the keys, and as long as you play within those keys, then that's how you play music. What I've learned two years ago when I started picking this back up, is that is just so completely wrong. There's these things called harmonics, which, if you play a certain note, like a C. I'm not going to be able to say this right, but G is harmonic. With C, that's a fifth. And I do have a little synthesizer on my site because I was exploring this. What are the harmonics about this? And what's weird is that the circle of fifths are. I'm not going to be able to explain this well, but it's like frequencies that sound harmonic. But the way that the harmonics work with music theory is that if you keep walking up through the circle of fifths, you'll get into notes that sound harmonic. They're actually not in the same key. So in music, the thing that is fascinating to me about this, and it's not that it sounds perfectly in tune, but what's interesting is that, like, it's a little bit dissonant, but it's like a good dissonance. It's a dissonance that gets you to expect something else in the next note. So if you play A, I was just learning about this. So there's seventh chords, right? Well, there's actually major seventh and minor seventh chords. So if you play C, a C seventh, right? That's C, E, G and B. That is the C major seventh, but the C seventh, I think the default seventh is a minor seventh. So a C7 is actually a B flat. It actually is playing a C minor seventh, which is like the B flat is not in the key of C. And that is getting you to it. It's a little bit dissonant, but it's like a beautiful dissonance, and it's getting you to expect it to resolve either to a full C chord or something else. And so music is this beautiful movement about a little bit of dissonance and moving up and through the keys. And so it's something that's really fascinating to me, and I'm not explaining it well, but if anybody is here listening to this, that is in music theory, you know exactly what I'm talking about.
- [49:15]
Josh Goldberg
You're learning to play the piano again?
- [49:17]
James Long
I am learning, yes.
- [49:19]
Josh Goldberg
That's a beautiful instrument.
- [49:21]
James Long
Yes. The piano is great. So I try to learn the guitar for about a year, and it just doesn't map to the way guitar is crazy hard. I don't know how people play guitar. On the piano, you can see the entire chord and everything laid out perfectly. Right. With guitar, you have to learn patterns, and then the way that the strings relate to each other is really weird. And you're having to do these weird shapes. Piano is way easier for me, for sure.
- [49:45]
Josh Goldberg
Well, thank you for all this. This is great. I'm so excited to process everything you talked about. Not just with musical theory, of course, but also prettier and your thoughts and toolings. We talked about how prettier came to be, some of the problems that it solves for users, some of the pushback that users previously gave and tend to no longer. James, if people wanted to find you online and learn more about you or your work, where would you direct them to go?
- [50:07]
James Long
There's jlongster.com, which is my website, but then I'm also on Twitter X longster, so that's kind of the name that I use everywhere.
- [50:15]
Josh Goldberg
Well, for software engineering daily, this has been James Long and Josh Kohlberg. Thank you for listening, everyone. Cheers, Sam.