Your tone is a bit off putting. But I don't think anyone claimed Prettier is the "ONLY" option. If you have better options or concepts for this sort of thing, I'm pretty sure anyone reading these comments would love to hear them. I would never claim Prettier is perfect, or the only/best option, or even the right option for everyone.
Tools are just tools, it's how you leverage them that provides value. I never go all-in on technology or tools, if there's something better then I'm always open to hearing/learning.
Again, it's not Pretier thats not the only option... It's opinionated autoformatters altogether. And it was not the comment on the post (wrote completely different thing there), but was a comment on the comment which was also highly opinionated. In that context, I completly stand by it, and think it's completely proper thing to state.
As for the arcle itself, as a suggestion can only add stuff like: educating the team, code reviews, pair programming, internal discussions about the standards (instead of pushing it top-down) and simple Eslint or langserver autofixers.
I'm not sure if you actually read anything in the article. It's an article about setting up Prettier. It may come as a shock, but if an article is about X, there's no obligation to also include Y, Z, T. It's not a versus, top10 or anything else. Prettier isn't the only option, it's the option that happens to be the subject of this particular article. Deal with it.
Highly opinionated is good. Choice for the sake of choice is stupid. As developers we have plenty of things to educate the team about or discuss at reviews. Design patterns, architecture, security, libraries, etc. Time spent on education on why to use tabs instead of spaces or single vs double quotes depending on context is pointless. There will be developers coming into the company or moving inside and the last thing you need is time wasted on reconfiguring IDE's to match the policies of that project. You use git hooks or not, autoformat on save or not, how do you format? Do you use tabs or spaces and which tab size? 2, 4 ... 6?
Thing is, everyone is opinionated. It's just that not everyone's opinion align and there's absolutely no objective reason (regarding formatting) to take one opinion over another, so that's why there are tools that are enforcing community drive standards - for no other reason that a bunch of people came together and agreed on something, which doesn't happen very often on projects.
@andreidascalu
, i think you're the one not reading. Read the thread. It was not the comment on the article. It all started with someone else suggesting to avoid Prettier altogether and me writing a short line that i second that. Only to be attacked with highly subjective, opinionated and also incorrect statements (i.e. that only single-team devs are against Prettier or the ones that dont want to write clean code, that Prettier can be configured any way you want, etc).
Now you pull that all out of context and think that was an article comment, while it was only a reply on another comment. Byt you still manage to add incorrect and misleading info, like mentioning tabs vs spaces, quotes, etc. It's exactly the aura arround Prettier, that it is often forcefully applied at many places just because "everybody does it" without really understanding the thing. Again an example from your post... Tabs!? You really think Prettier saved us from tabs inconsistencies in the past? Having to reconfigure editors? You really think all of us not using Prettier are forced to reconfigure editors?? Never heard of ESlint? Editorconfig? Point is, for some newbie reading this article, they might think those that dont use Prettier just have a mess of code, reconfigure editors all the time, have mixed tabs and spaces, etc. It's rediculous, doesnt help educate anybody and is simply incorrect.
And btw I use Prettier, when I have to. It's justa a tool, usefull in some circumstances, depending on the size and the quality of the team. Article was about small company "just reaching the point where inconsistency became a problem". So it's a very good comment/advice to look alsewhere!
Those holy wars and personal attacks about softeare tools are just rediculus. I just don't understand how is it possible to have such an emotianla reaction if somebody dislikes the tool you use?
" I just don't understand how is it possible to have such an emotianla reaction" - well, you should look at yourself. There's an article on how to setup a tool you don't use/like and feel the need to attack the tool & the people using it. The sane thing is to move on or just write a reaction post about your setup and why that's better. An article on how to setup X (not why X is great, X vs others, etc) doesn't need to mention what you think it should.
I'm also glad that you fixated on my sarcasm about tabs. Definitely too subtle for you.
The point isn't that Prettier itself is a great tool, it's that opinionated formatters are great because they take away the debate. Just look at your own points: Prettier doesn't conform to how YOU want YOUR code to look like (on which you can already see why some might think that Prettier-haters are lone devs) not that it breaks some community-promoted coding standards (which it doesn't, even at defaults). On top of that you're worried that this particular article (out of the sea of articles on this platform about code formatting) might give some newbie the idea that Prettier is the only tool out there (horrifying) - which says more about you than some potential newbie who happens to hit this article as the top Google result and somehow decides to stop looking.
If a newbie has no idea about code formatting and happens to stumble into Prettier and decides to use it (though clearly it's a lone dev, because as part of a team a newbie would definitely not get the last word on project setup), why is that an issue? It solves a problem, it has sane defaults (even if YOU don't happen to like it), it covers multiple languages (so you can cover the full stack, not just JS) and it's easier to configure (sure, editorconfig is even easier, but only deals with very basic generic editor formatting rules, not language-specifics).
This comment thread is the very reason why I love opinionated tools - there's absolutely too much debate (and obviously emotion) about code formatting. Way more than the subject deserves.
Youre just not reading at all. Me atacking people using Prettier?! Where? Can you quote me? Im pretty sure Im just replying to people who attack me for not using it or saying anything agains it.
But you just keep repeating the same stuff over and over again. Except one thing... Why is it not ok to comment on article about XYZ setup and state that there are better alternatives sometimes? Are there any community or moral standards about it? If comments like this were not allowed on dev.to I'm pretty sure I wouldn't read it at all. What is the point of single-sided views of any article and censorship on comments that disageree?
Then again you relate my comments to article excluaively while I told like 3 times to read the thread and the context. Article will not paint that picture I mentioned to a newbee! Comments I replied to, including yours, will.
Last thing Ill try to correct one more time is this long talk about Prettier benefits. I agree with every single one of them, and because of some of them, I use Prettier sometimes. But your view on it is single-sided and mentions no downsides, ever! Like it is a no brainer and universally better. And if anybody disagrees youre there to correct it and name them single devs or the ones that don't care about the formatting. It like religion.
But in reality it has compromises like anything else and you should waight pros and contras for each different implementation/situation. Prettier is far from universaly accepted as a standard, forums about it are far from peaceful, it is completely incorrect to say it can be configured any way u want, etc. Nothing like your comments (and some other) describe it. It's a compromise which is sometimes not worth it compared to other methods, and sometimes is worth it. So stop blaming it on devs or their setup exclusively, if they dont like it.
Software Engineer based in West London. With 20 years of experience in IT industry I specialise in building carefully crafted responsive and accessible projects
Oh dear, that escalated quickly.... Small hint for you guys: if you cannot discuss things in internet in polite manner take some offline hobby instead, I don't know, grow carrots, or something? :) And come back here only when you grow up? :)
And RTFM: dev.to/code-of-conduct
@piotrlewandowski
, I did that very, very long time ago. Might say the same, but it would be personal insult and is not my style. I admit to be passionate in discussions, as any average Mediterranean is, but not personal. Closest to that I came was saying "you don't read" after being acused for the same. On the other hand, I was treated with stuff like "solo dev", not wanting to write consistent code, being to shallow to get sarcasm,... and now to be a kid that needs to grow up.
Enough said in this thread. For the sake of the few reading this long thread,... Why/when not Prettier? If you have small enough team and are willing to setup your own formatting standards you can agree on them and implement them with tools like Eslint or your langserver: autofix formatting, do it on save, require it on commit, etc. You may spend more time configuring but decissions about formatting standards will not be taken away from your team and almost the same consistency can be achieved. In example, if you want to allow matrix style layout for props/params sometimes, or 'hide' some repeating long lines of code to avoid scrolling down to more important stuff, etc... you might find that Prettier code is not allways prettier nor more efficient to manage. The bigger your team is, or more diversified, ... opinionated formatters will be more usable. You'll win some and loose some but in general win will be bigger.
But again, for small(er) teams, at least run some of your projects through Prettier and see if it causes more frustration than it cuts down formatting inconsistencies, compared to non-opinionated tools like Eslint.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your tone is a bit off putting. But I don't think anyone claimed Prettier is the "ONLY" option. If you have better options or concepts for this sort of thing, I'm pretty sure anyone reading these comments would love to hear them. I would never claim Prettier is perfect, or the only/best option, or even the right option for everyone.
Tools are just tools, it's how you leverage them that provides value. I never go all-in on technology or tools, if there's something better then I'm always open to hearing/learning.
Again, it's not Pretier thats not the only option... It's opinionated autoformatters altogether. And it was not the comment on the post (wrote completely different thing there), but was a comment on the comment which was also highly opinionated. In that context, I completly stand by it, and think it's completely proper thing to state.
As for the arcle itself, as a suggestion can only add stuff like: educating the team, code reviews, pair programming, internal discussions about the standards (instead of pushing it top-down) and simple Eslint or langserver autofixers.
I'm not sure if you actually read anything in the article. It's an article about setting up Prettier. It may come as a shock, but if an article is about X, there's no obligation to also include Y, Z, T. It's not a versus, top10 or anything else. Prettier isn't the only option, it's the option that happens to be the subject of this particular article. Deal with it.
Highly opinionated is good. Choice for the sake of choice is stupid. As developers we have plenty of things to educate the team about or discuss at reviews. Design patterns, architecture, security, libraries, etc. Time spent on education on why to use tabs instead of spaces or single vs double quotes depending on context is pointless. There will be developers coming into the company or moving inside and the last thing you need is time wasted on reconfiguring IDE's to match the policies of that project. You use git hooks or not, autoformat on save or not, how do you format? Do you use tabs or spaces and which tab size? 2, 4 ... 6?
Thing is, everyone is opinionated. It's just that not everyone's opinion align and there's absolutely no objective reason (regarding formatting) to take one opinion over another, so that's why there are tools that are enforcing community drive standards - for no other reason that a bunch of people came together and agreed on something, which doesn't happen very often on projects.
Tabs
We should all be free to use x's for indentation and suffix each line with an ASCII dragon.
@andreidascalu , i think you're the one not reading. Read the thread. It was not the comment on the article. It all started with someone else suggesting to avoid Prettier altogether and me writing a short line that i second that. Only to be attacked with highly subjective, opinionated and also incorrect statements (i.e. that only single-team devs are against Prettier or the ones that dont want to write clean code, that Prettier can be configured any way you want, etc).
Now you pull that all out of context and think that was an article comment, while it was only a reply on another comment. Byt you still manage to add incorrect and misleading info, like mentioning tabs vs spaces, quotes, etc. It's exactly the aura arround Prettier, that it is often forcefully applied at many places just because "everybody does it" without really understanding the thing. Again an example from your post... Tabs!? You really think Prettier saved us from tabs inconsistencies in the past? Having to reconfigure editors? You really think all of us not using Prettier are forced to reconfigure editors?? Never heard of ESlint? Editorconfig? Point is, for some newbie reading this article, they might think those that dont use Prettier just have a mess of code, reconfigure editors all the time, have mixed tabs and spaces, etc. It's rediculous, doesnt help educate anybody and is simply incorrect.
And btw I use Prettier, when I have to. It's justa a tool, usefull in some circumstances, depending on the size and the quality of the team. Article was about small company "just reaching the point where inconsistency became a problem". So it's a very good comment/advice to look alsewhere!
Those holy wars and personal attacks about softeare tools are just rediculus. I just don't understand how is it possible to have such an emotianla reaction if somebody dislikes the tool you use?
" I just don't understand how is it possible to have such an emotianla reaction" - well, you should look at yourself. There's an article on how to setup a tool you don't use/like and feel the need to attack the tool & the people using it. The sane thing is to move on or just write a reaction post about your setup and why that's better. An article on how to setup X (not why X is great, X vs others, etc) doesn't need to mention what you think it should.
I'm also glad that you fixated on my sarcasm about tabs. Definitely too subtle for you.
The point isn't that Prettier itself is a great tool, it's that opinionated formatters are great because they take away the debate. Just look at your own points: Prettier doesn't conform to how YOU want YOUR code to look like (on which you can already see why some might think that Prettier-haters are lone devs) not that it breaks some community-promoted coding standards (which it doesn't, even at defaults). On top of that you're worried that this particular article (out of the sea of articles on this platform about code formatting) might give some newbie the idea that Prettier is the only tool out there (horrifying) - which says more about you than some potential newbie who happens to hit this article as the top Google result and somehow decides to stop looking.
If a newbie has no idea about code formatting and happens to stumble into Prettier and decides to use it (though clearly it's a lone dev, because as part of a team a newbie would definitely not get the last word on project setup), why is that an issue? It solves a problem, it has sane defaults (even if YOU don't happen to like it), it covers multiple languages (so you can cover the full stack, not just JS) and it's easier to configure (sure, editorconfig is even easier, but only deals with very basic generic editor formatting rules, not language-specifics).
This comment thread is the very reason why I love opinionated tools - there's absolutely too much debate (and obviously emotion) about code formatting. Way more than the subject deserves.
Youre just not reading at all. Me atacking people using Prettier?! Where? Can you quote me? Im pretty sure Im just replying to people who attack me for not using it or saying anything agains it.
But you just keep repeating the same stuff over and over again. Except one thing... Why is it not ok to comment on article about XYZ setup and state that there are better alternatives sometimes? Are there any community or moral standards about it? If comments like this were not allowed on dev.to I'm pretty sure I wouldn't read it at all. What is the point of single-sided views of any article and censorship on comments that disageree?
Then again you relate my comments to article excluaively while I told like 3 times to read the thread and the context. Article will not paint that picture I mentioned to a newbee! Comments I replied to, including yours, will.
Last thing Ill try to correct one more time is this long talk about Prettier benefits. I agree with every single one of them, and because of some of them, I use Prettier sometimes. But your view on it is single-sided and mentions no downsides, ever! Like it is a no brainer and universally better. And if anybody disagrees youre there to correct it and name them single devs or the ones that don't care about the formatting. It like religion.
But in reality it has compromises like anything else and you should waight pros and contras for each different implementation/situation. Prettier is far from universaly accepted as a standard, forums about it are far from peaceful, it is completely incorrect to say it can be configured any way u want, etc. Nothing like your comments (and some other) describe it. It's a compromise which is sometimes not worth it compared to other methods, and sometimes is worth it. So stop blaming it on devs or their setup exclusively, if they dont like it.
Oh dear, that escalated quickly.... Small hint for you guys: if you cannot discuss things in internet in polite manner take some offline hobby instead, I don't know, grow carrots, or something? :) And come back here only when you grow up? :)
And RTFM: dev.to/code-of-conduct
@piotrlewandowski , I did that very, very long time ago. Might say the same, but it would be personal insult and is not my style. I admit to be passionate in discussions, as any average Mediterranean is, but not personal. Closest to that I came was saying "you don't read" after being acused for the same. On the other hand, I was treated with stuff like "solo dev", not wanting to write consistent code, being to shallow to get sarcasm,... and now to be a kid that needs to grow up.
Enough said in this thread. For the sake of the few reading this long thread,... Why/when not Prettier? If you have small enough team and are willing to setup your own formatting standards you can agree on them and implement them with tools like Eslint or your langserver: autofix formatting, do it on save, require it on commit, etc. You may spend more time configuring but decissions about formatting standards will not be taken away from your team and almost the same consistency can be achieved. In example, if you want to allow matrix style layout for props/params sometimes, or 'hide' some repeating long lines of code to avoid scrolling down to more important stuff, etc... you might find that Prettier code is not allways prettier nor more efficient to manage. The bigger your team is, or more diversified, ... opinionated formatters will be more usable. You'll win some and loose some but in general win will be bigger.
But again, for small(er) teams, at least run some of your projects through Prettier and see if it causes more frustration than it cuts down formatting inconsistencies, compared to non-opinionated tools like Eslint.