Why I Stopped Using Prettier

[@michaelns9887]

5:14 Entire point of prettier is not to make things more "readable" (even if there were an objective measurement or "readability"). The point of prettier is to eliminate friction. So that you don't have to think about your formatting, you don't argue with your colleagues about formatting on code review and you don't mess up git history each time you touch a file and want to format something in a different way because you "feel like it". And eslint is not a formatter. It's a linter. These are different tools with different purposes.

[@MIO9_sh]

that's why Rome came out to address this problem, put linting and formatting onto one single package

[@RandomGeometryDashStuff]

It's not for easier minified file reading!?

[@Weaver_Games]

What "friction"? You join a team then the first day hold an emergency meeting cause they aren't formatting code exactly how you want it? Are people rejecting PR's cause there's a double newline? Maybe I've just been doing this way, way too long but I have no trouble reading code in different formats. I switch languages every day between front and back end anyways. I've never joined a company in the last 10 years that didn't have some kind of auto formatter in place when I started. Back in the olden days it was a little more fast and loose.

[@jmathew6956]

The point of a _formatter_ in general is readability. Otherwise a tool that just mashes all the code into one big line would be considered a formatter. I mean it is, but not in the sense that anyone would want it... because it wouldn't be readable. The _opinionated_ part of Prettier is what allegedly solves conflicts between devs. Although, in my experience we are all only in agreement that prettier made choices none of us would and it's lack of flexibility was frustrating. ESLint is indeed only a linter and is distinct from formatters. However, that distinction has only been made clear over the last few years as evidenced by the numerous deprecated formatting options in ESLint. And even with the deprecation, ESLint formatting options cover 80% of what I'd want a formatter to deal with, so it can still be sufficient. Further, with certain formatting options like allman braces, Prettier says "we're opinionated" and suggests using... ESLint. The confusion is warranted. JS world is lacking an unopinionated formatter and it's worse for it. Going back to allman style, our shop is C# and TS, allman brace style would be great for us to keep some consistency between _our_ two most used languages. Is it for every shop? No, but it helps our flow. Much like the folks above, even with a team of juniors and ESLint only, we didnt have much "friction" at all. We set standards, but they didnt cover everything Prettier covers and we were fine.

[@Weaver_Games]

I've found the same thing with it. 99% of my problems all stem from line breaking - formatting JSX and JS objects is an implicit way to tell your team members the intent of the structure. Eg, if I spread the object out instead of one lining each member I'm telling them modifying the contents is more important than ordering. If like the example you showed I have everything on one line, I'm telling them that the order is more important to see than the contents which shouldn't need much modification.

[@kischinhevsky]

Finally someone saying what needs to be said. I've always hated working with Prettier and now hate it even more after getting a job at a bigger company. It's just impossible to come to a consensus with a large number of people in the same code base about code formatting. Sometimes they'll auto format the entire project after merging a branch only for me to come back to my task and not find anything in a file I was working in just a few minutes before. Besides finding a middle ground with other developers, I think Prettier needs an alternative ASAP.

[@ifydev]

That is not an excuse as your company can set up the code base to format according to the codebase own rule before merging

[@wepranaga]

@@ifydev it is exactly why it should be enforced, so everyone has consistent git blame instead of having changes mess the blame up because of formatting

[@s.espinoza1167]

This was incredible useful, I have the same complains about prettier and I was wonder it ESLint could just be a standard solution for team projects without Prettier. I had the same headache when trying to set Prettier working with ESLint. Thank you for sharing!

[@EricMurphyxyz]

Setting it up to work with ESLint was always the biggest headache. Glad it helped!

[@NoName-1337]

The default formatter in vs-code is great. I miss just one or two settings. Would use this than uglyfier (prettier). At work we use Biome with Linting. The styling is ok and it's fast.

[@gosnooky]

I've heard so many people say to always use Prettier alongside ESLint, and leave the formatting to Prettier. I found this to be BS. Linting *is* coding standards and style - and semicolons and quote type are part of formatting. I didn't see why I needed to have two dev dependencies doing the work that one can and should do. My biggest gripe is its opinionated nature. I don't like other people's choices imposed on me.

[@clintothomas1418]

Could you please share the theme you are using? Thank you!

[@PotatoTroll]

It's probably Tokyo Night

[@wk4240]

Great video. Most auto-formatting utilities/plugins will do this eventually - there are just too many individual preferences to consider. Thankyou for sharing.

[@electricz3045]

YT Autoplaid me a vid on how to setup prettier and a guy explaining how cool it is right after this one 😂😂

[@WiseGuyFTW]

Abolutely hate PRs with formatting changes. Don't make me read 200 line PR with only 5 line of real changes. If you use prettier or any other formatter make sure you separate those changes in a separate PR or do that on your own without a PR depending on the merge policy.

[@Artrikz]

hey, wanted to thank you for your videos, they are very helpful and u are one of the people that influenced me to switch to linux! just started my journey, so have a lot to learn

[@EricMurphyxyz]

Welcome to Linux! Glad my videos have helped!

[@soanvig]

In addition to overconfiguration, there are overcomplicated build systems etc. It's literally like some hyperactive manager wanting to micromanage everything, creating tons of friction

[@tenone7726]

I only format javascript with prettier. For html and css I use the in build formatter.

[@EricMurphyxyz]

That's a good compromise as HTML and CSS are much less complex than JavaScript.

[@murtadha96]

This is very useful, thank you!

[@omerfarooqsyed7693]

I want to switch back to life, but my Moms basement doesn't let me.

[@Linkplay9]

I get the annoyances, but I think in the tradeoff of what prettier brings in exchange, It's not even measurable. Like others said, it removes friction. Configuring is way easier, and I think the options it provides should cover most peoples preferences. I agree the line breaking should allow more config options tho, as it can be annoying, but fixable in most cases. I personally don't have a problem anymore with the initial annoyances I had with it.

[@adamrich5819]

That's the problem: it's not configurable and the "options it provides" does not "cover most peoples preferences". I don't buy this argument at all. The idea it "removes friction" is pretty short-sighted in my opinion. If it were configurable, then all you'd have to do it is configure it _once_ and then leave it alone. Instead, you "remove friction" by just letting some third party enforce _their_ opinions on your codebase? If Prettier were _actually_ configurable and you could take an hour to configure it to your teams agreed on preferences and then roll with it from that point on.... then why not? The "friction" you're talking about is imaginary. If anything, we've wasted more time debating Prettier's conventions and if it's worth it itself than we would have just being able to have an actually configurable formatter. Having a code formatter with a config that is enforced is awesome. I 100% agree with the concept. But making it so "it's our way or the highway and you engineers are children who can't be trusted to configure our tool to your own preferences" is just fucking stupid and borderline narcissistic.

[@Weaver_Games]

What friction is everyone talking about all the time? Every time you guys join a team you call an emergency meeting the first day on how everyone should be formatting the code exactly how you want it? I've never been at a place that didn't have some kind of code formatting standard - be it prettier, some es-lint rules, or just some vscode formatting rules they provide.

[@soanvig]

Overconfiguration sucks. Too strict PR requirements, too strict lint rules. You are a developer, you know how to do things right. And if you don't, or you are too lazy I don't want to work with you. Prettier is overconfiguration at its essence

[@DelyanNinov]

Working on professional project with large or deeply nested complex components is a nightmare with prettier formatting. It breaks up the code into thousands of rows and you can't read nothing and concentrate on some prats of the code. Totally unreadable in html structure.

[@EricMurphyxyz]

Agreed, it absolutely butchers deeply nested HTML

[@greglane501]

I swear i saw this dude using vim and emacs though...

[@jackelofnar]

Hasn't prettier been depreciated?

[@EricMurphyxyz]

No? It is alive and well

[@oglothenerd]

I stopped using Firefox in favor of Brave because I was getting sick of Firefox's annoying Rally pop ups.

[@mrsansiverius2083]

I just use Librewolf. Never saw any of those.

[@oglothenerd]

@@mrsansiverius2083 I heard Librewolf breaks with WASM.

[@EricMurphyxyz]

What Rally popups? I think Brave is good but I recently switched back to Firefox

[@kevinwakhisi7001]

Currently there's wayland support for firefox thus good screensharing compatability switch back to Firefox

[@oglothenerd]

@@kevinwakhisi7001 Yeah, honestly, I try to avoid Wayland. I am a strong X user!

[@imorvit]

To be fair to Prettier, a max line length is very fair and is why all your lines get broken up.

[@emmetthoolahan]

u r a boss

[@anon-fz2bo]

greeting.slice(0,1).toUppercase() returns 'H' greeting.slice(1) returns 'ello'. So u don't even have to invoke .to lowercase() Also if ur trying to capitalize the string, just use greeting.toTitleCase()

[@KhaiyomOdinaev]

Wrong, 1) The initial string is not guaranteed to be lowercase by default, so toLowercase is not optional. 2) toTitleCase? Is this from ES2030???