The last question:

Node.js is important because
 A. It is compute-bound
 B. It is I/O-bound
 C. It supports greater concurrency
 D. All of the above.

is quite confusing. The reading states that Node.js utilizes event loops to achieve high concurrency and that it handles I/O bound http requests while it's not great at handling compute-bound requests. This questions is quite broad and confusing.

I'm sorry you found it confusing.

Node.js is neither compute-bound nor I/O bound. Problems are compute-bound or I/O bound. Database and web applications are typically I/O bound.

Node.js is suitable for I/O bound problems, because it can support greater concurrency.

Why is it harder to increase disk speed than it is to increase CPU/processor speed?

I didn't say that. It's not necessarily harder. Disks and processors are different technologies.

I'm confused on concurrency. Can you clarify concurrency? Can you explain why Nginx is so much faster if it is using only one thread? If nginx is so much faster than Apache, why use multithreading?

Concurrency means doing more than one thing at a time. AKA multi-tasking. Like working on your p-set while scrolling Instagram and responding to a group chat...

Nginx is not faster. It can do more things at once, because it has lower memory requirements.

There are lots of applications where threading is appropriate, particularly compute-bound ones.

I'm still a bit confused on how callbacks work. Can you show additional examples in class?

Sure. Callbacks are super-important in (front-end) web programming, but we haven't done that in this class, so it's new to most of us.

A callback is a function that gets executed later, at the appropriate time, to do the next part of the computation.

I am still a bit confused about what exactly an event loop is. How do they allow for concurrency/how is this different than threads?

The event loop executes a function until the function gives up control of the CPU by starting some I/O. It then goes on to execute another function from the to-do list.

When any I/O completes, the callback function is added to the to-do list.

So, there's only a single thread running the event loop

I'm still confused on this idea of waiting - we say that Node.js is good because there's no thread waiting for some code to finish executing, but in Node.js, is the callback function also not waiting for some event to happen? Or does the callback function not take up space the way a thread does?

You could say the callback is waiting, but not in the way we mean. To use my cake-baking metaphor, the callback is the written directions of what message to put on the cake. It sits on the counter until its needed by the baker.

I still don't really understand the workings behind blocking and non-blocking, despite know their impacts... Could you expand on the two please?

Sure. This is all very new.

Blocking I/O means that the thread waits for the I/O to complete. When the I/O completes, the thread continues.

Non-Blocking I/O starts the I/O and has nothing left to do so there's no need to wait. If there is anything left to do, it is packaged up into a function (a callback) that will get executed when the I/O completes.

So, to program with non-blocking I/O, you have to be able to divide your computation into the before and after, and package the after into a function.

(To be honest, there's now programming language support that can do this for you semi-automatically, but you still have to program in a slightly different way.)

What causes ""callback hell""?

If your computation divides into, say, 4 chunks, with I/O between them, that's a chain of callbacks, each embedded inside the previous.

What does it mean for a language to compile to JavaScript?

In CS, to "compile" means to translate from one language to another.

Since JavaScript runs in the browser, you could program in the browser using, say, Python, if you could translate (compile) Python into JavaScript.

How could you use node.js with MySQL?

Yes