Ye, why does this matter? It's practically instant already. I'm never saying no to improved performance, but sometimes it seems like it's just for show.
This is one of the reasons I keep using Rust for new projects. Cargo with it's built in linter, formatter, package manager, documenter, etc. makes projects so standardized across the whole ecosystem. Once you know any Rust, it's very easy to go from one project to something completely different, because you're basically guaranteed all the tooling is identical. Standard and performant tooling is an absolute must for any language going forward.
@@tombrown6183TS doesn't have "you're basically guaranteed all the tooling is identical", and it's hard to see how deno or anything else could change that now.
I personally hate rust tooling as it feels very unpolished. The biggest pain points for me are the autocomplete in my editor sometimes just doesn't work, some errors not being detected by the compiler before fixing other ones, errors showing up only after I save, the test runner being output being hard to read. Everyone in the rust ecosystem says how good these tools are, yet when compared to typescript tooling (which is admittedly scattered around multiple projects) it feels like these rust tools are in their alpha versions.
@@samuelwittlinger7790presumably those are problems of your editor / LSP integration, not of rust-analyzer itself. Because it has no such problems in VS Code.
@@samuelwittlinger7790 I'd rather that (which I definitely don't experience with VSCode btw) and a consistent ecosystem than every project I work on having a totally unique combination of tooling. Grunt vs Bun vs Deno vs Node vs TS vs JSDoc vs etc. etc. Onboarding onto a JS project is like learning a whole new world every time. And that's if you're lucky enough to join a new project. I had to jump into an existing AngularJS + Grunt + .NET project and everything was entirely bespoke. Took weeks to actually understand what the build system did, let alone what it was supposed to do.
We have a one and a half hour video interviewing Biome's main author on the Michigan TypeScript channel if anyone is more interested. Many topics about Biome covered but of course we get into this specific topic of prettier, as well. great video as always Theo!
yeah use jAvAsCrIpT-CaChE is the worst type of incrementalism-bandaid that people will try to pass as some of brilliant truth but just encourages stagnation.
I think everyone should have a look at Ruff from the python ecosystem. Other linters and formatters didn't necessarily feel slow, but Ruff is *instant*. I do agree that Prettier is slow even for JS standards, but I found the instant formatting of Ruff and rustfmt really pleasant. You can truly feel the difference.
5:30 from the man page: -P maxprocs Parallel mode: run at most maxprocs invocations of utility at once. If maxprocs is set to 0, xargs will run as many processes as possible.
In Python we ruff, which has been exploding in use because it's an all in one solution for many things that used to be in separate tools, an recently they also added formatting. I hope JavaScript gets something similar to it, it's simplified a lot our flow. PS: In python there is a push to have single imports per line. It's great because it simplifies diffs and reduces the possibility of having merge conflicts. Why haven't I've seen some option like it in JavaScript?
Merge conflicts like this appear as a result of inconsistency between your code styles. You either enforce block imports, or single ones. But that said, ruff has been absolutely excellent
@@dinckelman what I meant is that I want something like reorder-python-imports (ruff includes it). You should check in their repository at the section "why this style?", where they explain why it allows a reduction of merge conflicts caused by new imports in separate PRs
About building, it is worth mentioning that Evan You is working on a new project in Rust called Rolldown that is aiming at merging Esbuild and Rollup features
Prettier is the least of my problems in building applications. After configuring and installing it, creating a shareable plugin across all my projects, I literally never think about it again. After a project has been formatted, are people seeing more than a second for formatting a file or something?
It's not an area of optimisation I've ever worried about. It's already near instant in any use cases I depend on so I haven't a huge amount of interest in this work. In what scenario do we care about this optimisation?
It becomes an issue when you introduce it to pre-commit hooks or other scripts - the lag with Prettier is annoying. A formatter like Biome can format 1000s of files in under a second so you really don't notice it.
prettier just runs too slow for big codebases. node is discussing switching to biome as the formatter and it's capable of formatting the whole codebase in literally a second
I don't use it, but i have a strong eslint setup with hooks, so it forces developers to get their practices better with time, consistent code is the result.
I've switched my recent project from eslint to Biome, and my experience this time around is actually pretty good. During the Rome era it did not really work very well, but the current team is putting some good effort in. My only two issues at the moment, are that a lot of the linting rules can't be formatted without --apply-unsafe, and the editor plugins.... can use work
@@jaredsmith5826 it's not really about the speed, at my project scale, but I would understand why people strongly prefer that. For me, it was mostly about consistency, configurability, and uniformity. It's much easier to work with just one thing, than several conflicting tools. Obviously the upcoming Eslint alpha will be addressing this, but nonetheless
I'd use prettier if it allowed me to define what formatting rules to enforce. Sorry, but I just can't accept some of the "opinionated" things it has that I can't change.
I fully agree on the part that prettier or anything else removes the slow down on discussing code formatting. The only thing that bothers me about the prettier approach is that it s focused on the line length and not on meaningful diff of a commit
having almost 10yrs in webdev I'm convinced I don't like working with people obsessed with code formatting, just having tsc is good enough, tsc + dprint (or something as lightweight) is as far as I'd prefer to go
This is the one thing that I think makes JavaScript so confusing to some people. We have a language with tooling written in the same language, sometimes for the same runtime. The only reason we use Node for frontend is because all the tooling is in JS. But a majority of the code written in a frontend project that uses Node is never run on the Node runtime. It's wild.
@@Lamevire If you could point me to another widely-used programming setup where tooling and runtime code are both written in the same language and installed from the same repository, I would potentially revise my statement. But, from my understanding, it's pretty unique.
@@gFamWebI'm not sure if this is what you mean but a lot of C# and the .NET Framework is itself written in C# using the same developer tooling (ie Visual Studio) and the same package management system (NuGet) as end-users use, and the framework itself is published as packages on NuGet. Developers write C# code using tooling built with C#, and the projects contain NuGet packages for both dev tooling and runtime dependencies.
can you do a video where you go over a bigass open source codebase from top to bottom (such as prettier). A lot of us want to try contributing to open source but how no clue where to start reading and understanding how the code works and functions
You shouldn’t contribute to open source if you have no idea… Learn, deep dive, and just tinker with peoples work that interests you. If you find a way to make something better, do a PR. It’s such backwards thinking to start by wanting to contribute - even if you are clueless.
On a serious note, I think it would be fun to create a miniature JS formatter that can start from the top of a file (or where the cursor currently is in the file), and then format it using the same or similar rules as prettier. I’ll never be able to become good enough at rust (or JS) to be able to keep up with all the people doing it now that already are strong in both languages, but this would be a good project to get my feet wet.
Yeah I feel the same way about my project ideas. If they are at all doable for me, then someone else has already done it and its better than what I could ever do right now. But still worth building it I think, as it will be good learning opportunity
We again come to the conclusion that the only real thing js ever actually offered was job opportunities from cloud services and those who want to push ads in every corner of the desktop.
Prettier, I don't need faster at the moment, the prettifying is basically instant if you have them set up in IDEs. Linting, that's a different story altogether - CSS and JS linting are current major bottlenecks.
once these tools are faster, someone will make a wrapper around it with some extra feature, ruining the performance, still be fast on small projects, and thus be just as slow as today and 15 years ago.
Am i missing something? When I format a file it happens instantly. I've never considered it at all slow. What's the advantage of this apparent performance increase?
@@jameshobbs lol. Yeah that should have been obvious, thanks for spelling it out! So there's not any hidden benefit that I'm to dumb to understand, it's just a massive waste of time on premature optimisation!
On the user facing side this might seem negligible for the individual, but faster programs = less cpu = less energy. Multiply this saving by the numbers of users times eg a year and there’s a shitton to be saved. Then there are a lot of people who do not have the latest and greatest tech but want to get into this, and it might not be instant for them. Especially if running in a browser on an OS that hogs a lot of resources for telemetry and boulevard news. Also: it’s not rare to want to run these things on entire projects. Eg automated after push. And so on. So making things efficient aka fast is a matter of accessibility too.
I don't think those discussions are 'bickering': Formatting has a semantic component as well, I don't think there are hard and fast rules, only depending on the syntax.
finally they're addressing it. my vscode gets stuck everytime I try to save, sometimes it even makes me wait like 10s, and this is on a good speced pc, that's not running prettier fast.
Can you please explain how to properly protect a public nextJS API endpoint? I was always under the impression that the default same-origin CORS policy will restrict API access to only allow requests that are done from the same domain where the API is hosted. I recently had my emailing server attacked and all credits used up cause someone spammed my endpoint with Postman. I find Vercel's statement about default same-origin policy very misleading.
CORS prevents _browsers_ from using your API from disallowed origins. As in, no one can publish an alternate front end that calls your API. But it won’t prevent things like Postman and cURL from sending requests.
I mean, I'm fine with the convention being wrong as long as it is consistent... but it rarely is a block is a block, don't make a class different from a conditional block different from a loop body! also, Allman all the things! but that comes after the consistency
I was battling some not-very-intelligent re-formatting in prettier the other day and started wondering if maybe Javascript (and Typescript) should import some of the formatting rules as required language structure to reduce the need for formatters.
All fine and dandy until you need to store and somehow invalidate that cache in CI (which let's be honest, is the only case why prettier would be considered slow in most of cases). It's the same issues you'd run into when trying to cache node modules across branches, only now you don't have a single place to use as a cache key (i.e. lockfile), but files scattered around. Do you use the diff as cache key? How would that even work?
@@moodynoob Yes, that's what I am saying. Running prettier with a wrapper that provides cache doesn't make it faster in CI. Biome and the like would provide better cold-start time and less memory consumption.
I really don't understand how you can have any difficulty reviewing code that doesn't have the format you're used to. As long as a file doesn't change formatting midway, that's fine, really. I think developers bickering about such things should rethink their priority. Just imagine a firefighter saying, "I couldn't work on that house because the mailbox was on the wrong side of the door".
My question is - why prettier should be faster? (It already feels fast enough) Prettier not effecting build times. It runs once per file and modern PC fast enough to do it in a blink of an eye. If it's not - consider to split your 50k+ file.
I just use eslint for formatting. It works fine, and I don't see the need to use a separate plugin like prettier (which is not nearly configurable enough). I know people say to use eslint for code quality and prettier for formatting, but I've never heard any reason compelling enough to do so. If these tools could be written faster, fair enough, but their speed now doesn't really give me any pause.
5:58 are you sure ESLint team is doing that? Last I've seen the main maintainer of ESLint is pretty adamant to rewrite ESLint in vanilla JS and nothing else. Maybe I missed something or maybe that was just the JavaScript vs TypeScript debate. Regarding Prettier, I never felt like it was a bottleneck in any project I've worked on, but I definitely don't mind a faster tool or better yet a toolchain like Biome that does multiple things at once.
Project formatting shouldn't be enforced on developers it should be near invisible. For teams, rules should be a pre-commit or post-commit step not a local system enforced in-editor mutation on save. The idea that because I use spaces someone else is punished for trying to use tabs, or I can't use leading commas is absurd. We don't make other people use the same system fonts or syntax coloring.
I have used prettier in the past, but i think a more consistent layout is faster to read. My opinion is that if prettier is useful, most times your code need to restructure. Not to format different, but to restructure code, extract functionality, etc. That is why i dont use it anymore, just eslint with strict rules that will force you to write better code.
"native languages that perform a bit better" "A bit"? Look, you're either using a glorified scripting language at the speed of molasses, or you're using a native language at the speed of the processor. "A bit" is an understatement, unless the person doing the port writes it _very_ poorly/naïvely.
"vjeux" isn't pronounced like "veuks". It's pronounced like the French word "jeux" (search RUclips for a pronunciation example), with a v added to the start.
@@BleedingDev but it's not always possible to get the code to look very pretty with prettier. isn't that the whole point? the code should be pleasant to look at, easy to ready. Prettier fails to do that.
Wait a second. Prettier is not fast enough? It is so much faster than webstorm built-in fomatter, and definetly faster than linters. I never felt like it's too slow.
While I respect the utility of Prettier, I personally don't see it as "one the most important tools in the past 10 years of software development". Consistent code formatting in a project is important, but there are other tools that I find more important. Also, in my opinion, code formatting is a subjective matter, and adhering to a specific style enforced by Prettier or other tools like it limits the creative expression that programming offers. Programming is an art, allowing people to express themselves through their code, and enforcing a uniform style for all code limits the creativity you can have in programming.
Having people argue over formatting is such a low stakes issue and time waster that most people rather let a formatter decide. And reviewing PRs is soooo annoying when your team mates don't use a formatter or one with different configuration.
Wait. Do people lose time over formatting differences? That sounds so petty. I've lost exactly 0 minutes to this in python because any decent python developer just follows pep8. That is, if you count out time lose getting people to not use black which isn't pep8 compliant
I don't think prettier being an arbitrary formatting arbitration tool makes it important, just decide on some other tool because it Prettier isn't that good of a formatter.
Yes, this convenience of “format of save” is big. Although I often wonder whether did I developed a bad habit by relying on too much, as I it became a struggle when I need to produce a snippet in an environment without formatters…
Honestly I've never really liked a lot of the opinions built into prettier's formatting, especially for nested ternaries, and their attitude against adding more options. I've kept using HookyQR's Beautify even though it's no longer maintained since 2019 instead of switching to prettier. I'll probably have to switch to a new formatter at some point, but I'm waiting for something that's more configurable to better fit a customized eslint config. I don't want to have to have an extension like prettier-eslint, that has to run both prettier and then eslint --fix on every save; that's a massively hacky workaround for prettier not wanting to add config options.
But Prettier is so bad though. I hate that it uses line length as a core heuristic. I HATE that it will wrap some code when it just barely crosses the line length threshold, it makes consecutive lines that should look similar, look different. For example two useState on consecutive lines, one with short var names and the other with long var names, it will wrap the default param at the end on the second one but not the first, making it look unbalanced. And no, making the line length a big number is not a solution, because then prettier will just start _unwrapping_ lines instead! I hate it so, so much. Prettier is banned from all projects I maintain. It causes more friction than it helps because it has rules and behaviour that aren't configurable. Compare with go fmt and such which do a perfect job _without_ line length/wrapping. I wish that could be the goal, instead of getting test parity with prettier.
Because project formatting should not exist at the developer formatting level. And developers shouldn't care about the project-formatting once they checkout it out it's formatted to what they locally need. web-dev has gotten itself so twisted up.
just cache with javascript is such a cute lil mid-take, oh..sweety what's that? it improves performance uh huh.. sure honey. Now show us that compared to a rust version that also has a cache.
Making prettier faster is definitely something I didn't see happening in 2023...
Ye, why does this matter? It's practically instant already.
I'm never saying no to improved performance, but sometimes it seems like it's just for show.
@@modernkennnern it's fucking slow bozo
Sorry for calling bozo the slowness just pisses me off LMAO. If you have multiple files open and save all it's a nightmare
@@modernkennnern I'm assuming it can be relevant if you have a huge codebase
@@asdfghyter People won't change the whole codebase in a single commit, and I think we usually only need to prettify the modified part
This is one of the reasons I keep using Rust for new projects. Cargo with it's built in linter, formatter, package manager, documenter, etc. makes projects so standardized across the whole ecosystem. Once you know any Rust, it's very easy to go from one project to something completely different, because you're basically guaranteed all the tooling is identical.
Standard and performant tooling is an absolute must for any language going forward.
TS also has one and it's called deno
@@tombrown6183TS doesn't have "you're basically guaranteed all the tooling is identical", and it's hard to see how deno or anything else could change that now.
I personally hate rust tooling as it feels very unpolished. The biggest pain points for me are the autocomplete in my editor sometimes just doesn't work, some errors not being detected by the compiler before fixing other ones, errors showing up only after I save, the test runner being output being hard to read.
Everyone in the rust ecosystem says how good these tools are, yet when compared to typescript tooling (which is admittedly scattered around multiple projects) it feels like these rust tools are in their alpha versions.
@@samuelwittlinger7790presumably those are problems of your editor / LSP integration, not of rust-analyzer itself. Because it has no such problems in VS Code.
@@samuelwittlinger7790 I'd rather that (which I definitely don't experience with VSCode btw) and a consistent ecosystem than every project I work on having a totally unique combination of tooling. Grunt vs Bun vs Deno vs Node vs TS vs JSDoc vs etc. etc.
Onboarding onto a JS project is like learning a whole new world every time. And that's if you're lucky enough to join a new project. I had to jump into an existing AngularJS + Grunt + .NET project and everything was entirely bespoke. Took weeks to actually understand what the build system did, let alone what it was supposed to do.
We have a one and a half hour video interviewing Biome's main author on the Michigan TypeScript channel if anyone is more interested. Many topics about Biome covered but of course we get into this specific topic of prettier, as well. great video as always Theo!
Careful he'll make a half hour "reaction" video
Hey, I know you from somewhere 🕵🏼♂️
2-4x faster is good, but it misses the point entirely. Using a compiled language like Rust (or Zig, etc....) could be in the range of 10-100x faster.
yeah use jAvAsCrIpT-CaChE is the worst type of incrementalism-bandaid that people will try to pass as some of brilliant truth but just encourages stagnation.
@@TheNewton just imagine how much memory it will use
My company switched to Rome/biome and haven't looked back. It's been fantastic
What improved?
@@wagnermoreira786 nothing
By Xargs -p they presumably mean parallel processing - use xargs to spawn multiple copies of prettier working on different files in parallel.
I think everyone should have a look at Ruff from the python ecosystem. Other linters and formatters didn't necessarily feel slow, but Ruff is *instant*.
I do agree that Prettier is slow even for JS standards, but I found the instant formatting of Ruff and rustfmt really pleasant. You can truly feel the difference.
i believe ruff's formatter was initially based on biome's formatter infrastructure
I'm very disappointed with the clickbaity video title
Not at all
5:30
from the man page:
-P maxprocs
Parallel mode: run at most maxprocs invocations of utility at once. If maxprocs is set to 0, xargs will run as many processes as possible.
In Python we ruff, which has been exploding in use because it's an all in one solution for many things that used to be in separate tools, an recently they also added formatting. I hope JavaScript gets something similar to it, it's simplified a lot our flow.
PS: In python there is a push to have single imports per line. It's great because it simplifies diffs and reduces the possibility of having merge conflicts. Why haven't I've seen some option like it in JavaScript?
Merge conflicts like this appear as a result of inconsistency between your code styles. You either enforce block imports, or single ones.
But that said, ruff has been absolutely excellent
Because there's too many new ideas all the time
Bun brought a built-in formatter, no?
Fix the diff tools to show inline non-whitespace diffs instead of bloating every codebase.
@@dinckelman what I meant is that I want something like reorder-python-imports (ruff includes it). You should check in their repository at the section "why this style?", where they explain why it allows a reduction of merge conflicts caused by new imports in separate PRs
You should have put is-odd or leftpad as other dependencies on the thumbnail.
God damn this is a good idea
About building, it is worth mentioning that Evan You is working on a new project in Rust called Rolldown that is aiming at merging Esbuild and Rollup features
I could swear you would add Summoning Salt theme this time around 😂
The video was edited before I came up with the title 🤣 next time!
My 2 favorite topics, speedrunning and programming
Prettier is the least of my problems in building applications. After configuring and installing it, creating a shareable plugin across all my projects, I literally never think about it again. After a project has been formatted, are people seeing more than a second for formatting a file or something?
I'd assume no, but it makes for a great clickbait video topic!
It's not an area of optimisation I've ever worried about. It's already near instant in any use cases I depend on so I haven't a huge amount of interest in this work. In what scenario do we care about this optimisation?
It becomes an issue when you introduce it to pre-commit hooks or other scripts - the lag with Prettier is annoying. A formatter like Biome can format 1000s of files in under a second so you really don't notice it.
@@moodynoob Format only staged files?
prettier just runs too slow for big codebases. node is discussing switching to biome as the formatter and it's capable of formatting the whole codebase in literally a second
@@superchupu Why don`t setup formatting on save? Or your projects all 100k+ files?
I don't use it, but i have a strong eslint setup with hooks, so it forces developers to get their practices better with time, consistent code is the result.
dartfmt is the goat of having a built in formatter in the language
I've switched my recent project from eslint to Biome, and my experience this time around is actually pretty good. During the Rome era it did not really work very well, but the current team is putting some good effort in.
My only two issues at the moment, are that a lot of the linting rules can't be formatted without --apply-unsafe, and the editor plugins.... can use work
Prettier is already for the most part fast enough for me. But I'd give my eyeteeth to get a faster version of ESLint. Watching biome _very_ closely.
@@jaredsmith5826 it's not really about the speed, at my project scale, but I would understand why people strongly prefer that. For me, it was mostly about consistency, configurability, and uniformity. It's much easier to work with just one thing, than several conflicting tools. Obviously the upcoming Eslint alpha will be addressing this, but nonetheless
Currently using biome for my side projects, easier to configure and faster than prettier/eslint
I'd use prettier if it allowed me to define what formatting rules to enforce. Sorry, but I just can't accept some of the "opinionated" things it has that I can't change.
It shines in a team where every team member has a few things they won’t accept that others want. It just makes the conversation go away.
I fully agree on the part that prettier or anything else removes the slow down on discussing code formatting. The only thing that bothers me about the prettier approach is that it s focused on the line length and not on meaningful diff of a commit
having almost 10yrs in webdev I'm convinced I don't like working with people obsessed with code formatting, just having tsc is good enough, tsc + dprint (or something as lightweight) is as far as I'd prefer to go
! have no idea what u are talking about but I love the mustache!
This is the one thing that I think makes JavaScript so confusing to some people. We have a language with tooling written in the same language, sometimes for the same runtime. The only reason we use Node for frontend is because all the tooling is in JS. But a majority of the code written in a frontend project that uses Node is never run on the Node runtime. It's wild.
why is that confusing? this speaks for the language, no?
@@Lamevire If you could point me to another widely-used programming setup where tooling and runtime code are both written in the same language and installed from the same repository, I would potentially revise my statement. But, from my understanding, it's pretty unique.
@@gFamWebI'm not sure if this is what you mean but a lot of C# and the .NET Framework is itself written in C# using the same developer tooling (ie Visual Studio) and the same package management system (NuGet) as end-users use, and the framework itself is published as packages on NuGet. Developers write C# code using tooling built with C#, and the projects contain NuGet packages for both dev tooling and runtime dependencies.
You can try ESLint Stylistic too, not a 1:1 capabilities compared to Prettier, but hey it still gets the job done
Pretty sure Theo did a rant about why styling with eslint is a bad idea
ruclips.net/video/Cd-gBxzcsdA/видео.html
@@ronanru I haven't seen it, where can I see it?
@@cristopher5837 The video is titled "You're (Probably) Using Prettier Wrong"
ESLint also says to not do this, and all stylistic rules are deprecated (IIRC)
can you do a video where you go over a bigass open source codebase from top to bottom (such as prettier). A lot of us want to try contributing to open source but how no clue where to start reading and understanding how the code works and functions
You shouldn’t contribute to open source if you have no idea… Learn, deep dive, and just tinker with peoples work that interests you. If you find a way to make something better, do a PR. It’s such backwards thinking to start by wanting to contribute - even if you are clueless.
I feel if Javascript could only adopt actual optional typing (wrong type=error), it would solve a majority of the issues everybody deals with
You mean like TypeScript does today. Also typing is "optional" in TS if you didn't know. 😂 just need to make it so in the TS config.
@@RajinderYadavsounds like someone doesn't know all the problems exclusively caused by typescript
@@RajinderYadav Typescript doesn't exist at runtime
What is this Cmd+S? Does he mean :w?
Prettier has so many awful rules. Like pep anything not dictated by the language is going to be messy.
On a serious note, I think it would be fun to create a miniature JS formatter that can start from the top of a file (or where the cursor currently is in the file), and then format it using the same or similar rules as prettier. I’ll never be able to become good enough at rust (or JS) to be able to keep up with all the people doing it now that already are strong in both languages, but this would be a good project to get my feet wet.
Yeah I feel the same way about my project ideas. If they are at all doable for me, then someone else has already done it and its better than what I could ever do right now.
But still worth building it I think, as it will be good learning opportunity
video on arc browser soon?
why exactly do we need this performance increase
LMAO Yess ... Never have I thought "Why's prettier slow?"
Left side tab bar is sick ngl
I'd try it, but I don't want to put effort into it if other people are likely already going for the kill.
We again come to the conclusion that the only real thing js ever actually offered was job opportunities from cloud services and those who want to push ads in every corner of the desktop.
Prettier, I don't need faster at the moment, the prettifying is basically instant if you have them set up in IDEs.
Linting, that's a different story altogether - CSS and JS linting are current major bottlenecks.
Chosing Rust is misleading. Other languages, such as the mentioned Go, would make working on the solution more accessible.
once these tools are faster, someone will make a wrapper around it with some extra feature, ruining the performance, still be fast on small projects, and thus be just as slow as today and 15 years ago.
Am i missing something? When I format a file it happens instantly. I've never considered it at all slow. What's the advantage of this apparent performance increase?
🦗🦗🦗🦗🦗
@@jameshobbs crickets?
@@ruaidhrilumsden yeah, I think that's all we're going to hear as this doesn't seem to be a real problem (the speed of Prettier)
@@jameshobbs lol. Yeah that should have been obvious, thanks for spelling it out!
So there's not any hidden benefit that I'm to dumb to understand, it's just a massive waste of time on premature optimisation!
On the user facing side this might seem negligible for the individual, but faster programs = less cpu = less energy. Multiply this saving by the numbers of users times eg a year and there’s a shitton to be saved. Then there are a lot of people who do not have the latest and greatest tech but want to get into this, and it might not be instant for them. Especially if running in a browser on an OS that hogs a lot of resources for telemetry and boulevard news.
Also: it’s not rare to want to run these things on entire projects. Eg automated after push. And so on.
So making things efficient aka fast is a matter of accessibility too.
I don't think those discussions are 'bickering': Formatting has a semantic component as well, I don't think there are hard and fast rules, only depending on the syntax.
I started using prettier 20 days ago. Ive always used dprint.
Im not going back. Speed isn't all, specially for a tool like this
finally they're addressing it.
my vscode gets stuck everytime I try to save, sometimes it even makes me wait like 10s, and this is on a
good speced pc, that's not running prettier fast.
That's a clue that such things should not even be anywhere near your save step or in your editor.
Move it to pre- or post commit step.
The concern I felt reading the title 😟
I like you are using Arc as your browser :)
Can you please explain how to properly protect a public nextJS API endpoint? I was always under the impression that the default same-origin CORS policy will restrict API access to only allow requests that are done from the same domain where the API is hosted. I recently had my emailing server attacked and all credits used up cause someone spammed my endpoint with Postman. I find Vercel's statement about default same-origin policy very misleading.
CORS prevents _browsers_ from using your API from disallowed origins. As in, no one can publish an alternate front end that calls your API. But it won’t prevent things like Postman and cURL from sending requests.
I mean, I'm fine with the convention being wrong as long as it is consistent... but it rarely is
a block is a block, don't make a class different from a conditional block different from a loop body!
also, Allman all the things! but that comes after the consistency
Hearing about the $20k bounty for prettier in rust and then running to chat gpt 4 to ask if it can do it for me 😂😂😂
I can't tell if he is for spaces or tabs....
why just not use webstorm and use the supreme formatter?
What is that tab manager in the left side sir ???
I was battling some not-very-intelligent re-formatting in prettier the other day and started wondering if maybe Javascript (and Typescript) should import some of the formatting rules as required language structure to reduce the need for formatters.
All fine and dandy until you need to store and somehow invalidate that cache in CI (which let's be honest, is the only case why prettier would be considered slow in most of cases). It's the same issues you'd run into when trying to cache node modules across branches, only now you don't have a single place to use as a cache key (i.e. lockfile), but files scattered around. Do you use the diff as cache key? How would that even work?
Having no cache in CI for Biome isn't an issue - I've formatted 1000s of files in under a second with it, so its overhead is pretty minimal.
@@moodynoob Yes, that's what I am saying. Running prettier with a wrapper that provides cache doesn't make it faster in CI. Biome and the like would provide better cold-start time and less memory consumption.
I really don't understand how you can have any difficulty reviewing code that doesn't have the format you're used to.
As long as a file doesn't change formatting midway, that's fine, really.
I think developers bickering about such things should rethink their priority.
Just imagine a firefighter saying, "I couldn't work on that house because the mailbox was on the wrong side of the door".
I shall make one called “Sexier”.
What about "gyaTS"
How hard can it be to parse some text (to an ast) and re output it with the correct whitespaces ?? Am I crazy ?
Hopefully that 5% failing is them removing printWidth, god is it such a road blocker from switching away from stylistic ESLint rules
There is one thing i really wish it will be rewritten for better performance, the ts language server
Which browser is this?
My question is - why prettier should be faster? (It already feels fast enough)
Prettier not effecting build times. It runs once per file and modern PC fast enough to do it in a blink of an eye.
If it's not - consider to split your 50k+ file.
NAPI is not "Native API" as you said, it's a project to run Rust code in your JS/TS project.
Surprised you didn't mention oxc, my money is on them for this challenge and to take over the JS ecosystem overall
It already run in a split second.. why does it need to be faster than that? 😅
Does vjeux actually pronounce the x?
At work, I had to push prettier really really hard because our lead, do not like the code format that come out of prettier
I just use eslint for formatting. It works fine, and I don't see the need to use a separate plugin like prettier (which is not nearly configurable enough). I know people say to use eslint for code quality and prettier for formatting, but I've never heard any reason compelling enough to do so. If these tools could be written faster, fair enough, but their speed now doesn't really give me any pause.
the thing is, i never feel i have performance problem with prettier....ESLint hmm....
What browser is that that you keep exposing the vertical tabs to for a second?
It’s “Arc”. A new browser only for MacOS
@@kearneytaaffe7059Thanks. Ended up trying it out earlier tonight. Felt clumsy and slow, are there some legit value adds or is it mostly gimmick?
theo is using arc let's fuckin go
5:58 are you sure ESLint team is doing that? Last I've seen the main maintainer of ESLint is pretty adamant to rewrite ESLint in vanilla JS and nothing else. Maybe I missed something or maybe that was just the JavaScript vs TypeScript debate.
Regarding Prettier, I never felt like it was a bottleneck in any project I've worked on, but I definitely don't mind a faster tool or better yet a toolchain like Biome that does multiple things at once.
Time for bun to add a built in formatter and linter 😎😎
Project formatting shouldn't be enforced on developers it should be near invisible.
For teams, rules should be a pre-commit or post-commit step not a local system enforced in-editor mutation on save.
The idea that because I use spaces someone else is punished for trying to use tabs, or I can't use leading commas is absurd.
We don't make other people use the same system fonts or syntax coloring.
Why would you care about a "long tail of formatting logic" is you can do a single format with a new faster tool on a whole project and go from there?
I have used prettier in the past, but i think a more consistent layout is faster to read.
My opinion is that if prettier is useful, most times your code need to restructure.
Not to format different, but to restructure code, extract functionality, etc.
That is why i dont use it anymore, just eslint with strict rules that will force you to write better code.
"native languages that perform a bit better"
"A bit"? Look, you're either using a glorified scripting language at the speed of molasses, or you're using a native language at the speed of the processor. "A bit" is an understatement, unless the person doing the port writes it _very_ poorly/naïvely.
Expectation in 2000: In 2024 we will invent time machine.
Reality in 2023: How to format code faster.
😂
"vjeux" isn't pronounced like "veuks". It's pronounced like the French word "jeux" (search RUclips for a pronunciation example), with a v added to the start.
The biggest issue with Prettier is that it cannot be customized very much, too opinionated.
That is whole point od the tool. :)
@@BleedingDevand it sucks
@@QueeeeenZ no, its the Best feature of Prettier. Moře consistency, less configuration. :)
@@BleedingDev but it's not always possible to get the code to look very pretty with prettier. isn't that the whole point? the code should be pleasant to look at, easy to ready. Prettier fails to do that.
@@BleedingDevsounds like you're saying that consistency and configuration is more important than pretty code.
Can we not just run force prettier (and all its dependencies) in the Bun runtime with he -bun flag?
Yo, Theo, what's your browser?
It's Arc
@@ronanru thanks 🙏
What browser are you using ?
arc browser
CTRL+S > CMD+S
I got clickbaited so bad I am ashamed
Weird, I literally just configured ESLint and Prettier not to clash and then this video popped up
Lib is called eslint-config-prettier btw
I use this as well. I have no complaints and it seems to hold up well even with more complicated rule sets like Angulars recommended eslint.
Wait a second. Prettier is not fast enough? It is so much faster than webstorm built-in fomatter, and definetly faster than linters. I never felt like it's too slow.
Seriously who the hell is having any troubles with prettier speed?
While I respect the utility of Prettier, I personally don't see it as "one the most important tools in the past 10 years of software development". Consistent code formatting in a project is important, but there are other tools that I find more important.
Also, in my opinion, code formatting is a subjective matter, and adhering to a specific style enforced by Prettier or other tools like it limits the creative expression that programming offers. Programming is an art, allowing people to express themselves through their code, and enforcing a uniform style for all code limits the creativity you can have in programming.
Having people argue over formatting is such a low stakes issue and time waster that most people rather let a formatter decide.
And reviewing PRs is soooo annoying when your team mates don't use a formatter or one with different configuration.
We stopped bickering about formatting, everyone is equally unhappy instead. Weeeh!
Wait. Do people lose time over formatting differences? That sounds so petty. I've lost exactly 0 minutes to this in python because any decent python developer just follows pep8. That is, if you count out time lose getting people to not use black which isn't pep8 compliant
I don't think prettier being an arbitrary formatting arbitration tool makes it important, just decide on some other tool because it Prettier isn't that good of a formatter.
Yes, this convenience of “format of save” is big. Although I often wonder whether did I developed a bad habit by relying on too much, as I it became a struggle when I need to produce a snippet in an environment without formatters…
Thankfully i didn't use prettier for the last 5y and only relied on eslint, which made me code with _style_ right in
The problem with those tools is that it completely obfuscates what have been changed in our git history.
Is it really v-oox? It always pronounced it vee-jeu
Honestly I've never really liked a lot of the opinions built into prettier's formatting, especially for nested ternaries, and their attitude against adding more options. I've kept using HookyQR's Beautify even though it's no longer maintained since 2019 instead of switching to prettier. I'll probably have to switch to a new formatter at some point, but I'm waiting for something that's more configurable to better fit a customized eslint config. I don't want to have to have an extension like prettier-eslint, that has to run both prettier and then eslint --fix on every save; that's a massively hacky workaround for prettier not wanting to add config options.
But Prettier is so bad though. I hate that it uses line length as a core heuristic. I HATE that it will wrap some code when it just barely crosses the line length threshold, it makes consecutive lines that should look similar, look different. For example two useState on consecutive lines, one with short var names and the other with long var names, it will wrap the default param at the end on the second one but not the first, making it look unbalanced. And no, making the line length a big number is not a solution, because then prettier will just start _unwrapping_ lines instead! I hate it so, so much.
Prettier is banned from all projects I maintain. It causes more friction than it helps because it has rules and behaviour that aren't configurable. Compare with go fmt and such which do a perfect job _without_ line length/wrapping. I wish that could be the goal, instead of getting test parity with prettier.
I've been known to rewrite code to get around how prettier thinks it should be formatted. Not real proud of that...
Because project formatting should not exist at the developer formatting level.
And developers shouldn't care about the project-formatting once they checkout it out it's formatted to what they locally need.
web-dev has gotten itself so twisted up.
i am not gonna use anything else
Can’t see it
Plugins would be written in js anyway
just cache with javascript is such a cute lil mid-take, oh..sweety what's that? it improves performance uh huh.. sure honey.
Now show us that compared to a rust version that also has a cache.
Steps
1. No JS Prettier
2. No JS Linter
3. No JS
I see a great win
When saving a file, within a few tenths of a second the file is formatted. So, why again do we need a much faster prettier?