... is there only a very technical reason behind this, maybe simply because the V8 wasn't developed with server side Javascript in mind? Or is there a reason more related to the architecture and nature of Node.js? Is there a reason why I should consider to use Node.js for streaming and piping rather than for loading and processing bigger amounts of data, besides "because then you have to increase the memory limit"?
1 Answers
The primary reason why there is a limit at all is to protect the rest of the system from out-of-control memory consumers (i.e. when you have several processes running, and one of them consumes all the memory it can get, you want that one to run into its own limit rather than affecting everything else in the system). This is particularly true for the browser scenario (you don't want one tab to consume all your memory at the expense of all other tabs), but applies in many server-side scenarios as well.
The default value of the limit is more or less arbitrary; it seems to be a reasonable compromise for most purposes. If you need more, feel free to raise it. 64-bit builds of modern V8 versions ("modern" = from the last few years) support extremely large heaps if your app needs them.
Regarding your last question, "streaming and piping" are generally useful techniques for working with large amounts of data, regardless of whether you're using Node.js or any other technology. Code that reads all of its input data in one go tends to be easier to write, but is always prone to running into limits: for example, physical memory size of the machine it's running on. You can "fix" that one by buying more memory, but if your code uses streaming and reasonably sized buffers, it'll be able to process much bigger input data with much lower hardware requirements, and it might even run faster.
Related