Short answer:
No, synchronous processing in node.js WILL cause performance problems.
Long answer:
You want to avoid synchronous processing in node as much as possible. Obviously, sometimes you're going to need it, but that may be a point at which you move the relevant synchronous code out of node and into something more suitable.
Basically, as node follows an evented model of concurrency, where a single thread runs a stack of events one at a time, any long-running events are going to block the execution of anything else. So, what you'll be looking to do is to scythe off as much functionality as possible into small, asynchronous, function calls.
What you'll want to do is look to use a library, such as async or Step, which allows you to avoid the "callback hell" approach to node programming. JQuery has a similar thing in the browser that you may have used, which is its promise() method and Deferred objects. This will make it much quicker to write, and maintain, your node source.
If you really do need to put a large synchronous procedure in your web app, then node is not the right tool for that job. Try looking at having another API that node can call out to when it needs to accomplish a long-running task, whether that's a command-line C++ app or a web API in a more standard-concurrency model language.
If the apps are distinct in terms of data, and purpose, I think modularizing them - making a number of smaller, separate pieces is better. If they do not share data, and if they do not have strong coupling in terms of how the user uses them, I would strive to keep them separate and small.
It all depends on the coupling between the fairly unique apps. If each is isolated and not dependent on lots of other things, it will be easier to test at a higher level. It will be easier to isolate bugs. Easier to upgrade.
You can use package manager functionality (e.g. queryIntentActivities) to find and help launch the other activities to get around problems of launching other apps.
The problems of forgetting to commit changes and other problems of that nature aren't coding or system design issues, those are practices and process problems.
Best Answer
One aspect of experienced programmers who move from an IDE to a console / xterm environment, is finding a replacement for the indexing of source code objects (function names, variables). I believe the general term used for Microsoft's Visual Studio is Intellisense or something like that.
In the Unix/Linux world, such as vim, one tool used if
ctagsor the popular multiple language Open Source implementation, exuberant ctags. It is notvimspecific, and is supported by a number of Unix, Linux, MS Windows, Mac OS text editors, including Emacs, CRiSP, vile & a number of other vi clones, nedit, gedit, JED, UltraEdit, BBEdit, and DreamWeaver (some of these are via third-party plugins).Beyond that, good design and thoughtful decomposition, organization of larger projects makes the project manageable in that there are only 1-2 obvious potential places to look for any given bit of information (
typedeforclassdefinitions, etc.).Also I use multiple instances of vim (often via
viewfor read-only viewing of source files), as well as a limited use of multiple edit buffers per vim instance (primarily for moving or refactoring code between files). I find using only a few source files open at a time can help in its own small way, to keep me focused on the task on hand.