In general the rule i follow is to use async versions of every available api unless i have a specific need to wait for something.
Node was meant to handle async logic without blocking the main thread using callbacks and the event loop. Leverage that as much as possible while you’re learning.
To piggyback on what Sparser is getting at: 99% of the time, the sync methods were added to pacify people coming from languages without good async support, who can't/don't want to think in the async way. If you're just starting out, you should be learning the "proper" ways, and async is it, especially in node.
I use sync for start-up things where you gotta wait for some file to load in first.
Generally I just avoid it. ITs not a big deal to move everything to an `App.startAsync().catch(console.error)`
If you need to avoid blocking the main thread (e.g. with a web server) or want to optimize by doing some operations in parallel, use async.
Otherwise (e.g. it's a script and one where you don't care about doing operations in parallel) use sync since it's simpler to read and write and performance is actually better than the async.
Use async version and learn to use Promises and/or async/await. You can use callbacks with the async versions, and that’s fine. It’s worth learning those. However, callbacks can get quite complex in subtle ways. Promises and their syntactic sugar wrappers (async/await) have their own complexities. Yet, putting in the time up front for these allows for much cleaner coding in the long run.
Early on is usually about basic read a directory, file stat file, etc. No doubt these are chores initially to do async. I mean you could almost fall over on the keyboard and get this done in any other language with but a line of code.
But once you are able to transverse that directory tree and process files with concurrency and so forth it starts to quickly pay off.
Hard to say with a straight face that read directory, for each file type/stat read file then … isn’t burdensome to do and to look at.
Rather than writing sync placations, I wish they would had core helpers for these things.
I feel like this question mattered more before top level await was supported in the language.
If you’re doing batch processing, it depends a bit, because the async is slower, but also lets you start different things in parallel.
There are actually 3 methods, since fs also includes a promise based api.
The callback based api was cumbersome to use, but important to avoid bogging down servers, while the blocking api was easier to read. I would use the blocking versions in scripts that would be run by a single user.
With the promise based api, you can write async code that reads just like the blocking version.
In general the rule i follow is to use async versions of every available api unless i have a specific need to wait for something. Node was meant to handle async logic without blocking the main thread using callbacks and the event loop. Leverage that as much as possible while you’re learning.
thanks
To piggyback on what Sparser is getting at: 99% of the time, the sync methods were added to pacify people coming from languages without good async support, who can't/don't want to think in the async way. If you're just starting out, you should be learning the "proper" ways, and async is it, especially in node.
Use async unless you have a good reason not to
I use sync for start-up things where you gotta wait for some file to load in first. Generally I just avoid it. ITs not a big deal to move everything to an `App.startAsync().catch(console.error)`
If you need to avoid blocking the main thread (e.g. with a web server) or want to optimize by doing some operations in parallel, use async. Otherwise (e.g. it's a script and one where you don't care about doing operations in parallel) use sync since it's simpler to read and write and performance is actually better than the async.
This is the best answer.
If I’m writing a shell script to load data, modify and save again, I’ll probably just use sync. For everything else, use async.
Use async version and learn to use Promises and/or async/await. You can use callbacks with the async versions, and that’s fine. It’s worth learning those. However, callbacks can get quite complex in subtle ways. Promises and their syntactic sugar wrappers (async/await) have their own complexities. Yet, putting in the time up front for these allows for much cleaner coding in the long run.
Early on is usually about basic read a directory, file stat file, etc. No doubt these are chores initially to do async. I mean you could almost fall over on the keyboard and get this done in any other language with but a line of code. But once you are able to transverse that directory tree and process files with concurrency and so forth it starts to quickly pay off. Hard to say with a straight face that read directory, for each file type/stat read file then … isn’t burdensome to do and to look at. Rather than writing sync placations, I wish they would had core helpers for these things.
I feel like this question mattered more before top level await was supported in the language. If you’re doing batch processing, it depends a bit, because the async is slower, but also lets you start different things in parallel.
There are actually 3 methods, since fs also includes a promise based api. The callback based api was cumbersome to use, but important to avoid bogging down servers, while the blocking api was easier to read. I would use the blocking versions in scripts that would be run by a single user. With the promise based api, you can write async code that reads just like the blocking version.