Biome [0], a fast Prettier-compatible formatter, is currently working on adding class sorting [1]. We expect to ship the feature with the next release (on February). We are discussing which options to provide for the feature (mainly on the Discord of Biome).
I commend anyone for trying to make the tooling ecosystem better, but I’ve never once thought Prettier was too slow. It runs in a fraction of a second on file save.
The performance comparison on Biomejs’ site shows a Prettier run taking 14 seconds, which I can imagine on a very large code base might be true - but that’s a one-off case surely? Once it’s run, it’s just a case of format on save or commit which is back to near-instantaneous.
Typically, you would check the formatting of the entire codebase on the CI or even locally (to ensure that you are doing the same checks on the CI and locally). On a large code base this can take several seconds, reducing developer experience. Yes, you can use git hook to check only changed files. However, this requires more setup and may lead to some misses.
Biome can also format malformed code. It supports formatting as you type.
Biome has less known non-idempotent formatting (For some edge cases you need to run twice Prettier to get a stabilized output).
Biome is also a linter. You get two tools that are closely compatible.
git commit hooks & ci checks that ensure everything is formatted because that one coworker refuses to set it up to run on save and keeps forgetting causing merge conflicts down the line
> The plugin will respect your tailwind.config.js file and work with any Tailwind plugins you’ve installed, but _there is no way to change the sort order_.
Really like that they don't give options to change the settings. Just one less thing to bike shed within teams. Really doesn't matter what is picked, just as long as it is consistent (and not obviously stupid).
This actually has a semantic purpose, it's not just about bike shedding. CSS classes, if applied to the same element, will prefer the class that's defined later in the CSS file. The plugin sorts them via priority order so it's more clear is one tag might override another.
Yes, the specificity/precedence is all determined statically from only the .css files, the class order has nothing to do with it. This is a good thing because it allows for methods like https://developer.mozilla.org/en-US/docs/Web/API/DOMTokenLis... to not need to concern themselves with insert positions.
> If the competing selectors have the same values in all the three columns, the proximity rule comes into play, wherein the last declared style gets precedence.
I used to work in a restaurant where the thing that held the knives was agnostic about which direction the blade faced. It's quite beneficial to know which direction the knife is facing when grabbing it, so we wanted to establish a standard. There was a lengthy discussion about which was better, we picked one, then we had to train the rest of the staff and remember to tell new hires. And people still forgot, so having a standard was pointless.
If the knife storage had been opinionated, we would have expended no effort and achieved consistency. The choice of direction was essentially arbitrary, but making a choice and sticking to it was valuable.
Whether they do make obviously stupid choices or not doesn't invalidate the principle.
As to whether they do make obviously stupid choices - I personally don't mind any of their choices (even if I wouldn't have made the same choice myself), and I know I'm not alone in this position, which means that by definition they're not "obviously" stupid. You can disagree with the choices and the trade-offs, sure, that doesn't make it obviously stupid.
I detailed the reasons at length in the issue thread. It might not be obvious if you haven’t seen the code examples, but once you see it, it’s pretty clear.
I also completely disagree with your reasoning above.
The fact that many people believe or do some thing does not mean that “by definition” that that thing is not obviously stupid. E.g., inhaling glue, smashing things with one’s head, “the secret”, mukbang videos… the list is nearly endless.
Finally, “the principle” behind Prettier is also flawed when taken to the extreme they do. Paraphrasing my final comment on the github issue,
> It can be used to defend literally any styling choices, even ones that deliberately misaligned conditional branches with others at its logical level (much like prettier already is doing on a small scale in the example I referenced).
> Yes human beings are adaptable, but some things are easier to adapt to than others. It's objectively easier to spell Spanish than English, for example. It pays off to have consistency at a deeper level than simply making the same idiosyncratic choices each time an identical situation comes up.
Tienes razon sobre el asunto de que uno puede escribir palabras mas facil en otras lenguas. Pero lo importante en este caso es que la gente encuentran lo que esperan. Si la mayoria de la gente buscan `} else {` sera mejor darles lo que esperan. Posiblemente una investigacion cientifica podia descubrir que `else {` seria mejor para los que ya no se acostumbraron a `} else {`, pero estamos en un mundo lleno de gente que ya se acostumbraron. Pues `} else {` sirve bien, lo mismo que sirve bien usar una lengua familiar aunque otra lengua tiene ventajas.
Translation: You're right on the point that one can spell words more easily in other languages. But the important thing in this case is that people find what they expect. If the majority are looking for `} else {` it's better to give them what they expect. It's possible that a scientific investigation might find that `else {` would be better for those who haven't yet become accustomed to `} else {`, but we're in a world full of people who've already become so accustomed. So `} else {` still works better, just as it works better to use a familiar language even though another language has advantages.
Consistency has more value than the subjective advantage of the proposal that you're comparing to the objective advantage of being phonetic. I think the prettier maintainers made the right choice.
People were trying to get the broken behavior fixed. I was more in the camp of simply removing the offending rule. But, contrary to your claim above, they did already have some config options.
Ultimately, the solution is to use Biome or another formatter instead, but many devs have Prettier forced on them at work.
Oh, for sure. If you don't want to live with the decisions from the project whose goal is not letting you make your own decisions, you should use something with a different goal. There is a reason most of those projects grow a bit and then die.
What you don't do is insist the developer adds the option. Even if you feel like the developer is more approachable than your boss.
In the hundreds of people who interacted on that thread, I don’t think a single person insisted that the dev do anything.
It’s a dishonest characterization of the issue thread to imply that it was its nature. People shared discussed the problem with the tool’s behavior, shared examples and motivations.
Prettier’s (IMO wrong) decision was theirs to make but the response was also gratuitously smug.
Because it saves time and sanity. First, you don't have to deal with endless debates about stupid crap every other code review. Second, local wanna be controlling personalities have less space to nitpick choices of others and other do not have to deal with them.
The more realistic outcome is they get onto bikeshedding other choices like pickigng a more configurable tool since, you know, you haven't actually eliminated choices, just reduced them without constraining: infinity - 1 = infinity
Prettier removes any parentheses that aren't strictly necessary. So if you type:
value = (a ? ((a * b) + c) : d);
It turns into:
value = a ? a * b + c : d;
This is just a very basic example, there are many situations where the result is way worse. I feel pretty confident in saying that this is quite obviously stupid.
Does anyone know if it's possible to get Tailwind class sorting in Elixir Phoenix HEEX templates. It would be a great addition to the Elixir formatter.
Maybe we could write a formatter plugin in Elixir that does the same thing if this one isn't usable directly.
Thanks! I'll try it out soon. Looks exactly what I wanted, including the feature to order variants automatically (`dark:sm:... -> sm:dark:...` from the repo's readme).
I do work in JavaScript, but I also had no idea what Biome was. Apparently the Rome project rebranded. The main appeal, I think, is that it is written in native code and significantly faster than Prettier.
I had learned of both Biome and Rome, but didn’t know about the rebrand. Makes me think they’ll switch gears to focus on improving the linter after reaching 100% parity.
A contributor is currently working on this feature [0]
We are currently discussing which options to add to the rule on the Discord of Biome.
We expect to ship the feature with the next release (on February).
A nightly will be released earlier to gather feedback.
Let's add another step in our toolchain & deployment bundle.
It saddens me to see people new to web development don't realize that to deploy a webpage, all it takes is just uploading (SFTP) a single .html file onto a web server.
Nothing more is technically required than that, but we've made it so complex you'd never know.
Deploy it to what? How? Via what? Who is managing it? Who is paying for it? Who physically installed the server, and setup your ability to DrawTheRestOfTheHTML?
Personally - while we want abstraction in our deployment understandings to smooth ramp understanding - its important to see all the supporting inputs that made your SFTP of an .html possible.
>>I once saw him teach a philosophy lesson about a pencil. A Fuckin' Pencil!
> all it takes is just uploading (SFTP) a single .html file onto a web server
Yes, it's unfortunate that new developers don't know the basics. However, that's not an option for a multi-page site with complex user interactions.
There's no point in complaining about new tools being created which serve a need. If it makes someone's job easier when they're creating complex web apps, it's a good thing.
That's how you get very-important layout classes (hidden, flex, etc) put arbitrarily in the middle of purely-visual ones (border, etc.). I've seen this in practice, and it makes grokking exiting code a massive pain.
But then I'm so old school I prefer just putting the CSS in the CSS, or even the `style` attribute. (I must say I do appreciate the pseudo-class support in tailwind.)
Both MDN and the W3C complain about Prettier putting closing slashes on HTML tags such as <input />. While allowed due to backward compatibility to XHTML, they have never been specified, do nothing, and browsers ignore them so it is pointless to put them there.
> While allowed due to backward compatibility to XHTML, they have never been specified, do nothing, and browsers ignore them so it is pointless to put them there.
> Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
You are looking at what I said. What you are quoting says it's allowed, and it "has no effect", but if you look at the actual element specification[1], it never says to use it. In fact, it says nothing at all about it.
It very clearly says it has no effect on void elements, and then directly follows up with describing the effect it does have.
And the link you provided is specifically for the input tag, which has nothing to do with the syntax definition in general. Why would they repeat a generally applicable rule in more specific sections?
I added some links to my original post that you need to read.
That the specification for the input element--and ALL HTML elements--does not state to use a closing slash should mean something or at least indicate something. If it's required or has meaning you would think the specification would show that. It doesn't. It never has.
You also need to read up on what a foreign element actually is and it's not HTML.
Your point is still unclear there. The specification allows it, for historical reasons. The fact it doesn’t recommend it does not change that.
Many people, myself included, prefer to have code that is easily parseable (both mentally and by a program) without requiring a lookahead or awareness of a list of special elements. A slash for self-closing elements achieves that. It just makes sense. Can you imagine JSX allowing this?
In order to put a slash there, you need to already know that tag can take a slash, so nothing is gained by putting it there.
Though something is allowed, it is unspecified, not required, does nothing. So why would you want to write markup that is not needed and does nothing? This makes no sense whatsoever and I only find such discussions on public forums such as this one.
This is about readability. The point is that only if you _don't_ have an ending slash, you need to know the tag type. If there is one, you don't need to know anything to understand the tree structure, the code is self-evident.
Your use of the word superfluous is exactly what I'm saying. Why you want to write unnecessary, useless markup is beyond me. Even MDN and the W3C complain about it but that seems to mean nothing to you but I can tell when I can't teach someone values so I'm done here.
I see in your profile you've joined HN just a year ago. Welcome! I feel the need to point out that this is not a place to "teach someone values" though, but to have meaningful conversation. There doesn't have to be a winner.
React popularized it, and in its context having self-closing tags on React elements to indicate leaf nodes makes a lot of sense. Prettier just went with that and also does it for HTML.
I'm wondering why you are so triggered by that issue that you have to bring it up in a context where its off-topic (it could be brought up on any post related to Prettier).
The validator Wiki page even highlights that it's essentially a non-issue, except for interactions with unquoted attributes, which Prettier also converts to quoted attributes, so that interaction never happens. The other reason is for "teaching the wrong" mental model, which I guess is fair from the position of MDN, but Prettier was never designed as a "teaching formatter".
And if you, even with all that context want to opt-out of that formatting, there is a community-maintained plugin that adjusts the formatting to how you want it: https://github.com/awmottaz/prettier-plugin-void-html
Hope you never get tripped up by the "except for".
People were mixing XML and XHTML with HTML before React and got themselves into trouble.
Why are you so triggered by someone who thinks people should just follow the standard and not write unnecessary markup/code? That is a programmer's worst nightmare but people here seem to support it.
[0] https://biomejs.dev/ [1] https://github.com/biomejs/biome/pull/1362