Most of the computation and work thrown at JavaScript on the client side is trivial. I mean, really, absolutely nothing. On top of that, that client is sporting some crazy-super-duper-intel-voodoo cpu with gigabytes of RAM. That's why things fly. On the server side, you're running on an instance with limited RAM and a CPU that is being cut into a multitude of pieces through virtualization. On top of that, the server is trying to provide for a multitude of clients at the same time. That's why you have to be careful.
But we all know this stuff already.
We know you can't brute-force things on the server side. You are working with very limited resources.
Any blocking operation will destroy an event loop and the process model will crumble. Threads are more resistant to this. The offending thread will block, the other threads will keep going. So what?
If you multiply processes with a balancer to try to avoid this, you've reinvented threading, in a really bad way. We know that too.
Please pay attention. Things are changing.
Remember what I started with? That lopsided power divide between client and server. We know this. That's why we're moving the heavy lifting from the server to the client.
Ryan, you're wrong. I'm not going to send the video encryption job to a different process. I'm going to send it to the client or to some distributed cloud thingie. My server can't handle it no matter how you skin that cat.
Ted, you're wrong. My server doesn't block on the CPU. Because there's not much of a CPU there to begin with. Threads won't make my barely-there-cpu any more present. What isn't there, isn't there.
All my server does is store data and retrieve data. It does nothing else. NodeJS, PHP, Python, Java, etc. etc. that entire layer has become just that. A layer. A layer that facilitates access to the data. That's it.
It doesn't matter what you use or how you use it, as long as you don't touch the CPU.
Because on the server, that CPU isn't really there and no magical model will make it appear. Do your computation somewhere else. Like on the client's computer, who is using his marvel of engineering for playing solitare.
But we all know this stuff already.
We know you can't brute-force things on the server side. You are working with very limited resources.
Any blocking operation will destroy an event loop and the process model will crumble. Threads are more resistant to this. The offending thread will block, the other threads will keep going. So what?
If you multiply processes with a balancer to try to avoid this, you've reinvented threading, in a really bad way. We know that too.
Please pay attention. Things are changing.
Remember what I started with? That lopsided power divide between client and server. We know this. That's why we're moving the heavy lifting from the server to the client.
Ryan, you're wrong. I'm not going to send the video encryption job to a different process. I'm going to send it to the client or to some distributed cloud thingie. My server can't handle it no matter how you skin that cat.
Ted, you're wrong. My server doesn't block on the CPU. Because there's not much of a CPU there to begin with. Threads won't make my barely-there-cpu any more present. What isn't there, isn't there.
All my server does is store data and retrieve data. It does nothing else. NodeJS, PHP, Python, Java, etc. etc. that entire layer has become just that. A layer. A layer that facilitates access to the data. That's it.
It doesn't matter what you use or how you use it, as long as you don't touch the CPU.
Because on the server, that CPU isn't really there and no magical model will make it appear. Do your computation somewhere else. Like on the client's computer, who is using his marvel of engineering for playing solitare.