If you have a server running legacy Java code, especially implementing abstract classes and interfaces, it would be much easier to adopt the Java Spring Framework, however, if you are starting from scratch or adding to an existing NodeJS codebase, ExpressJS would be easier to get going. I suggest to use helmet.js in conjunction with ExpressJS apps. https://github.com/helmetjs/helmet

To build on Mev-Rael's fine reply, I would also suggest using a database abstraction layer that maintains a stable API boundary between the application layer and the database. If you develop your application such that it is tightly coupled with your database solution, you build technical debt, associated with any future changes in database and/or scaling. Using a database abstraction layer gives you freedom and stability. Fortune.js is a good option for a database abstraction layer. http://fortune.js.org/

I would use neither of these two solutions. I would refactor using node-fetch. Why? Because node-fetch has the same API as fetch in the browsers, which is sleek and promise based.

Here is a relevant link: https://hacks.mozilla.org/2017/11/entering-the-quantum-era-how-firefox-got-fast-again-and-where-its-going-to-get-faster/

Right on. As per your awesome Wikipedia link, "These threads share the process's resources, but are able to execute independently. " Imagine worker threads being able to write directly to the framebuffers used by canvas elements. Wow. Cool huh?

I have seen performance gains in applications that do a lot of redis interaction. I am a big fan of ES modules. I look forward to ES modules becoming a first class citizen. http://2ality.com/2017/09/native-esm-node.html

Do you believe an evolution to a multithreaded UI browser model is necessary to for continued performance growth in the face of diminishing returns in JS VMs?