2. Node is *NOT* single-threaded... the primary event loop and JS engine are single threaded. You can use workers and forks to get around/beyond that. Node uses a thread pool for I/O work, and this is accessible for compute heavy tasks as well. Portions of crypto/hashing all have async interfaces, and most I/O is async, which uses the pool for these events. What this means in practice, is that you should *NOT* do compute heavy or otherwise long running tasks in your main event loop, it's perfectly fine to queue/pool/orchestrate these types of tasks with node and/or use workers for them. This type of scaling tends to affect many apps eventually, it's only that you have to think about them sooner with node.
3. While most of the backing engine and i/o for node are written in C++, many parts are indeed in JS itself. [1]
5. see #2
6. see #2
11. outdated answer, see Worker Threads [2]
13. see #2
14. this only works for async functions, node's primary legacy interface is via callbacks with an error first argument.
16. Should also mention setImmediate. Though the behavior is probably reverse of what they should be.
18. Should note that some of the JS implementations in the browser are less than optimal in terms of listeners, and that you can use a DOM node in place of an EventEmitter, which can perform better.
19. While the answer is correct, most would not know this off the top of their head, and few would do this in practice. It is helpful to know as many frameworks add a lot of overhead that isn't needed depending on what you are trying to do.
21. *sigh* see #2 .. while the pool does help, clustering for services will scale better. That said, if you're using an orchestration tool or cloud platform, would be easier to manage more small nodes than cluster orchestration via Node directly. Depends on use case.
22. should mention async generators[3] and for await of[4], which can be much cleaner in practice, streams does support this method of interaction. It would be nice to be able to use regular generators for sync i/o in terms of ETL chores though. I've thought about creating a pair of CSV libraries, one sync, one async for this type of work, node's async is a bad fit for standalone worker jobs that deal with this type of work.
23. Transform is a subset of duplex conceptually.
26. should note that buffers are now effectively a wrapper for a typed array.
27. not sure I like the answer as the results are muddled... readFile will read all of the file into memory (correct), while createReadStream will create a readable stream against a file handle, and the reads are indeed chunked, but also buffered.
33. Promises and async functions should be mentioned.
34. before 33.
35. should be before 33, and should be followed by a question on async functions.
39. Inaccurate answer... depends on how npm is deployed and the environment as defaults and configuration values vary slightly based on OS and deployment. NVM on *nix has a different behavior from Node.js installer on Windows.
51. Should note that an .env file requires either a loader, or a shell load before application use.
52. should note that setInterval for a short timer is dangerous and should be avoided, only use setInterval for longer periods of time (at least several seconds) to avoid getting backed up.
53. should followup or note that fs.mkdir does not do checks or create nested/dependent directories.
55. should note that the results are both files and directories and fs.stat is needed to differentiate between them.
56. should also note the different handling for uncaught promises.
57. Add procedural and imperative
63. should note that classical syntax in JS is mostly sugar over prototype inheritance which is what is actually used in practice for JS. Deeply nested hierarchies over large sets of object/class instances can be performance hindering in practice.
64. Outdated... Prior to ES6 functions were the only closure for JS. As of ES6, loops and even raw {} can create a closure, let and const are scoped to the closure, not to the function.
73. Should note that console.log is buffered and not synchronized, while console.error is synchronous and blocking.
74. Should note upcoming ESM syntax
[1] https://github.com/nodejs/node/blob/master/lib/
[2] https://nodejs.org/api/worker_threads.html
[3] https://medium.com/@segersian/howto-async-generators-in-nodejs-c7f0851f9c02
[4] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of
2. Node is *NOT* single-threaded... the primary event loop and JS engine are single threaded. You can use workers and forks to get around/beyond that. Node uses a thread pool for I/O work, and this is accessible for compute heavy tasks as well. Portions of crypto/hashing all have async interfaces, and most I/O is async, which uses the pool for these events. What this means in practice, is that you should *NOT* do compute heavy or otherwise long running tasks in your main event loop, it's perfectly fine to queue/pool/orchestrate these types of tasks with node and/or use workers for them. This type of scaling tends to affect many apps eventually, it's only that you have to think about them sooner with node. 3. While most of the backing engine and i/o for node are written in C++, many parts are indeed in JS itself. [1] 5. see #2 6. see #2 11. outdated answer, see Worker Threads [2] 13. see #2 14. this only works for async functions, node's primary legacy interface is via callbacks with an error first argument. 16. Should also mention setImmediate. Though the behavior is probably reverse of what they should be. 18. Should note that some of the JS implementations in the browser are less than optimal in terms of listeners, and that you can use a DOM node in place of an EventEmitter, which can perform better. 19. While the answer is correct, most would not know this off the top of their head, and few would do this in practice. It is helpful to know as many frameworks add a lot of overhead that isn't needed depending on what you are trying to do. 21. *sigh* see #2 .. while the pool does help, clustering for services will scale better. That said, if you're using an orchestration tool or cloud platform, would be easier to manage more small nodes than cluster orchestration via Node directly. Depends on use case. 22. should mention async generators[3] and for await of[4], which can be much cleaner in practice, streams does support this method of interaction. It would be nice to be able to use regular generators for sync i/o in terms of ETL chores though. I've thought about creating a pair of CSV libraries, one sync, one async for this type of work, node's async is a bad fit for standalone worker jobs that deal with this type of work. 23. Transform is a subset of duplex conceptually. 26. should note that buffers are now effectively a wrapper for a typed array. 27. not sure I like the answer as the results are muddled... readFile will read all of the file into memory (correct), while createReadStream will create a readable stream against a file handle, and the reads are indeed chunked, but also buffered. 33. Promises and async functions should be mentioned. 34. before 33. 35. should be before 33, and should be followed by a question on async functions. 39. Inaccurate answer... depends on how npm is deployed and the environment as defaults and configuration values vary slightly based on OS and deployment. NVM on *nix has a different behavior from Node.js installer on Windows. 51. Should note that an .env file requires either a loader, or a shell load before application use. 52. should note that setInterval for a short timer is dangerous and should be avoided, only use setInterval for longer periods of time (at least several seconds) to avoid getting backed up. 53. should followup or note that fs.mkdir does not do checks or create nested/dependent directories. 55. should note that the results are both files and directories and fs.stat is needed to differentiate between them. 56. should also note the different handling for uncaught promises. 57. Add procedural and imperative 63. should note that classical syntax in JS is mostly sugar over prototype inheritance which is what is actually used in practice for JS. Deeply nested hierarchies over large sets of object/class instances can be performance hindering in practice. 64. Outdated... Prior to ES6 functions were the only closure for JS. As of ES6, loops and even raw {} can create a closure, let and const are scoped to the closure, not to the function. 73. Should note that console.log is buffered and not synchronized, while console.error is synchronous and blocking. 74. Should note upcoming ESM syntax [1] https://github.com/nodejs/node/blob/master/lib/ [2] https://nodejs.org/api/worker_threads.html [3] https://medium.com/@segersian/howto-async-generators-in-nodejs-c7f0851f9c02 [4] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of