(also posted on the medium article as a comment)
First, I think that flow is pretty much a dead end. I know that it's backed and used by Facebook, so will probably be around for a while, but have the distinct impression that TypeScript has won out on this, and that the broader npm module systems have more thorough support for TS. TS has over 8m downloads a week, while Flow has around 16k.
Second, on if it's worth it, depends on how many developers and of what skill level you are working with. Beyond this, what kind of structure you enforce not to mention other potential aids/rails like code coverage for testing, etc. TS does allow for a nicer refactoring workflow, you break things and fix the breaks when you refactor. JS requires a more judicious approach, which isn't bad if you start with a clean directory/module structure and keep your code testable. To that last part, code coverage and testing help ensure, but do not guarantee a cleaner approach.
Personally, I find that I don't gain from having typed code in JS. That said, I can see the advantage on some projects/teams that are less experienced, or more likely to have different approaches on a project lifetime. It is not a replacement for clean or testable code. Aside, I'm also not a fan of the class approach in general and prefer more function based modules/libraries that act on general objects (can use interfaces in TS).
Tend to follow a similar structure... a minor difference though...
/ - baseline configuration
/scripts
/npm - node/npm configured scripts
/ci-cd - scripts for env/ci-cd
/client - client application
/index.js - main entry
/index-ssr.js - server-side render entry
/feature - all client features
/wwwroot - assets deployed in root (favicon etc)
/app - application wide components
/api - api client abstraction
/feature-name - components/logic/reducers/etc
/server - server/api application
/index.js - main entry point (see: npm os-service)
/feature - all feature structures
/webserver.js - main server start
/static.js - statically mounted resources, reverse proxies, etc
/middleware - middleware
/routes - routes for api
...
If there are multiple configuration targets, I'll have a /configuration/configs/TARGET-NAME directory for those configs/assets.
It's in TypeScript at this point (glad for that, got tired of squiggly lines in VS Code), but still a ways away, not in any browser proper at this point, and will need Babel/TypeScript etc for a few years after that.
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
While I like mocha and chai more than jasmine, I've started using jest as it wraps the bits needed for code coverage as well as support for parallel test runners.
One thing I tend to do differently, I keep tests next to the feature/component being tested. I'm not a fan of separate trees of files that are effective mirrors.
Two popovers on this blog are *REALLY* f-ing annoying to say the least. When looking at more than once a day, extra so.
If I want to share, I'll copy the address bar, or find a way. If I want to subscribe, I'd probably figure that out too. You're reaching a technical audience and these types of engagement patterns are a distraction to say the least.
I would suggest a fixed box in the lower right with a the standard share glyph/icon and a subscribe with an email glyph/icon. When clicking one of those, then have the popover dialog come up. NOTE: make room for it when scrolling to the bottom so it doesn't interfere with your footer.
----
row-reverse isn't the same as right alignment, it reverses the direction. justify-content on your #3 would be how you would align right.
Other than that, decent writeup.
Tend to follow a similar structure... a minor difference though... / - baseline configuration /scripts /npm - node/npm configured scripts /ci-cd - scripts for env/ci-cd /client - client application /index.js - main entry /index-ssr.js - server-side render entry /feature - all client features /wwwroot - assets deployed in root (favicon etc) /app - application wide components /api - api client abstraction /feature-name - components/logic/reducers/etc /server - server/api application /index.js - main entry point (see: npm os-service) /feature - all feature structures /webserver.js - main server start /static.js - statically mounted resources, reverse proxies, etc /middleware - middleware /routes - routes for api ... If there are multiple configuration targets, I'll have a /configuration/configs/TARGET-NAME directory for those configs/assets.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