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 trial

JavaScript Build a Simple Dynamic Site with Node.js Creating a Basic Template Engine in Node.js Reading from Files

Thomas Santoro
Thomas Santoro
4,007 Points
Posted by Thomas Santoro
Thomas Santoro
4,007 Points

Sync 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?

JASON LEE
JASON LEE
17,352 Points

Another 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 a setTimeout 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 further response.write() action.

2 Answers

Seth Kroger
Seth Kroger
56,414 Points
Seth Kroger
Seth Kroger
56,414 Points

I 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
nfs
35,526 Points
nfs
nfs
35,526 Points

Thank you, Seth Kroger.