@LorenzoAncora @tennoseremel @lxo >it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations
You do not need any of those things.

If you wanted things to be asynchronous on the same page for a laugh, there's something called iframe.

>FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests
JavaScript requires multiple web requests just to load the JavaScript and then continuous web requests to do each operation, so really JavaScript loses again.

FastCGI really only needs a single request back and forth for every operation.

You can hand optimize the software on the FastCGI end with assembly if you want to minimize how computationally expensive each operation is.

Generally sequentially processing operations on one computer in an efficient manner (doing mostly the same operation over and over again is pretty cache efficient) uses less power than doing the operations in an inefficient way across 1000, 10,000 or millions of computers.

JavaScript is a way to just dump the processing onto the client (and as the client is the one who has to pay for the power, usually the JavaScript is left completely unoptimized).

>can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.
I'm not sure about the validity of this claim, as fastCGI usually takes user input as POST fields, which is usually properly escaped, unlike a lot of client side JavaScript, which seems to send JavaScript objects, or JSON blobs to the server.