3 ms·

I've been using async/await especially for file access. const fs = require('fs').promises const path = require('path') const filePath = path.j

I've been using async/await especially for file access. const fs = require('fs').promises const path = require('path') const filePath = path.join(__dirname, 'package.json') const fileContents = await fs.readFile(filePath, 'utf8') console.log(fileContents)

drevil-v2 7y ago
Well I personally would use a synchronous method rather than async for something like that where the next code path depends on the return data; if you can't get the file contents then you want to throw an error straight away.
- galaxyLogic 7y ago
  That would seem to make sense, using readFileSync() instead. I assume it would really do much the same thing as the await example. Is there any difference? If they do the same thing, then what's the benefit of async/await? I guess it's that you can now write your own "fs.readFileSync()" or something like that in JavaScript when needed.
  - jeswin 7y ago
    fs.readFileSync() blocks the event loop preventing any other code from being run or other events/requests from being processed. Await yields control back so that other requests can be processed while the file is being read.
    - galaxyLogic 7y ago
      Ah I see. Genius. So is there ever a use-case for NOT using the Async/Await -version of readFile()? Is fsReadSync() now just legacy which we don't need any more?
ihuman 7y ago
Is there an advantage to using "await fs.readFile" over "fs.readFileSync"?
- mayank 7y ago
  You haven't blocked the entire event loop (i.e., other async functions that may be waiting on I/O) while the file is being read.
- hombre_fatal 7y ago
  Synchronous code blocks the event loop, so in real world code you'd only use the sync-version in some special cases, like when you're reading config files before you "server.boot()" and other scenarios where it's just a one-time cost. Though the few sync functions in the stdlib become less and less convenient, first when promises came out, then with async/await, and now with top-level await.

drevil-v2 7y ago

Well I personally would use a synchronous method rather than async for something like that where the next code path depends on the return data; if you can't get the file contents then you want to throw an error straight away.

galaxyLogic 7y ago
That would seem to make sense, using readFileSync() instead. I assume it would really do much the same thing as the await example. Is there any difference? If they do the same thing, then what's the benefit of async/await? I guess it's that you can now write your own "fs.readFileSync()" or something like that in JavaScript when needed.
- jeswin 7y ago
  fs.readFileSync() blocks the event loop preventing any other code from being run or other events/requests from being processed. Await yields control back so that other requests can be processed while the file is being read.
  - galaxyLogic 7y ago
    Ah I see. Genius. So is there ever a use-case for NOT using the Async/Await -version of readFile()? Is fsReadSync() now just legacy which we don't need any more?

ihuman 7y ago

Is there an advantage to using "await fs.readFile" over "fs.readFileSync"?

mayank 7y ago
You haven't blocked the entire event loop (i.e., other async functions that may be waiting on I/O) while the file is being read.
hombre_fatal 7y ago
Synchronous code blocks the event loop, so in real world code you'd only use the sync-version in some special cases, like when you're reading config files before you "server.boot()" and other scenarios where it's just a one-time cost. Though the few sync functions in the stdlib become less and less convenient, first when promises came out, then with async/await, and now with top-level await.