Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialThomas Santoro
4,007 PointsSync vs Async: please explain reason for differing syntax.
(1) "We don't need a call back because it is synchronous this time" - WHY?
(2) "let's set the variable as file contents", again presumably because it is synchronous this time. WHY would you execute the same task as a function (with a callback) when it is asynchronous and then put it into a variable when you refactor it to be synchronous?
(2.1) And related to that, why is so much stuff put into a variable in JavaScript any way? it seems a bit odd, for example, to require a library like "fs" into a variable.
Also, take a breath man. You do not save us time with this frenetic effort to get to the end because to follow along--without adequate explanation--we have to rewatch and decrypt your lesson. I'm sure it's easy stuff. Really obvious. And after I went back it wasn't hard to sort out. But why do I have to do this so much more with this guy than with other instructors?
2 Answers
Seth Kroger
56,413 PointsI recently got an answer request for this so I'll give it a go.
The functions in this library have asynchronous and synchronous versions. The synchronous versions have "Sync" added to their name. Being synchronous means then won't return until they have a result and will return the result directly. This is unlike the asynchronous version where you give it a callback that accepts the result and return immediately to continue on with other things. You'll will also hear this referred to as blocking I/O because you are waiting for it to finish.
Think of it like having an assistant, Bob. The synchronous version is you saying "Bob, I need you to go get a file for me from the file room. It's very important to me and can't continue work without it." vs. "Bob, I need you to go to the file room and retrieve this file. I have other things to do in the meantime so give it to Alice when you've got it. She'll know what to do with it."
You'll usually avoid blocking I/O as much as possible in NodeJS but using non-blocking asynchronous I/O would over complicate the current project.
nfs
35,526 PointsThank you, Seth Kroger.
JASON LEE
17,352 PointsJASON LEE
17,352 PointsAnother observation I made -- it's possible to use the original async version
readFile
and make it work.In the router.js file where the functions are called, I tried delaying the
response.end( )
using asetTimeout
and delay for 1000ms or so. Obviously, not good practice, but just helpful to understand (and debug?) why the async version didn't work in the video example.I believe the command
response.end()
, once executed, will prevent any furtherresponse.write()
action.