Nos primórdios da web, o CGI era de fato a única maneira (prática) de ter conteúdo dinâmico (você poderia fazer pipes nomeados de arquivos - e esses eram usados dias antes do cgi, mas isso não era prático em todos).
O CGI trabalha coletando um monte de informações no ambiente do processo que é bifurcado e, em seguida, executado (e possivelmente algum em stdin) e então pega o que sai do stdout e retorna ao solicitante.
Isso não importa nem um pouco sobre o que é a linguagem de implementação. De fato, escrevi meus primeiros CGIs no passado em C ou C ++. Foi meio doloroso. Mais tarde eu aprendi um pouco de perl no início dos anos 90 e isso foi muito menos doloroso.
Isso funciona, até certo ponto. O problema é escala. Cada solicitação CGI é um fork e exec de um processo. Milhares de solicitações significam milhares de processos. Isso realmente não funciona bem.
A solução para isso é remover bifurcações e execuções movendo-as para um encadeamento no próprio servidor da Web ou despachando a solicitação para outro processo que lide com a solicitação sem precisar bifurcar-se e exec. O mod_perl é uma dessas ferramentas para fazer isso (um plugin que move o perl para o apache). Php (final dos anos 90) também fez isso com a implementação da linguagem como um plugin no próprio servidor web, em vez de algo que foi bifurcado e excedido. Isso se tornou bastante popular, já que era perl-like (que era a linguagem dominante de programação web dominante) e poderia superar perl cgis. Ainda há um bom momento nesse período em meados dos anos 90 - antes que os servidores de aplicativos mais corporativos começassem a se apropriar de linguagens mais formais por trás deles. Se você pesquisar, pode encontrar muitas tentativas fracassadas no final dos anos 90 até o início dos anos 2000 também - linguagens e frameworks que simplesmente não funcionavam.
Isso nos leva aos servidores de aplicativos em que os encadeamentos internos são gerados (ou outras abordagens - não é o caso de tudo) para lidar com solicitações em vez de novos processos inteiros - o que pode ajudar com a escala. Como um processo externo, isso pode ser visto com o FastCGI e depois se tornou predominante com outros servidores de aplicativos. Observe que, com isso, a linha entre o servidor de aplicativos e o servidor da Web ficou um pouco borrada - muitos servidores de aplicativos podem funcionar como servidores da Web, embora não tenham sido otimizados para lidar com E / S de arquivos estáticos.
O servidor de aplicativos genéricos também abriu o caminho para as soluções em que, em vez de um servidor de aplicativos genérico , você tem o próprio aplicativo executando um servidor da Web incorporado ou sendo a implantação inteira. Em tais situações, não é implantado um aplicativo da Web em um servidor de aplicativos - ele apenas está sendo executado e manipulando solicitações. Novamente, o objetivo desse modelo é evitar o alto preço de lançar novas instâncias do aplicativo e, em vez disso, manipular as solicitações dentro do aplicativo com threads muito mais leves ou abordagens semelhantes.
Aqui está a questão - todas as soluções são deficientes de alguma forma ou forma. CGI, enquanto fácil tem sérios problemas com escala. Os plug-ins nos servidores da web são vinculados ao próprio servidor da web (apache vs nginx vs IIS vs ...) e perdem a funcionalidade comum do idioma. A Microsoft tem seu próprio desfile de tecnologias que gostaria de promover. E se você conhece um idioma, não prefere continuar programando em vez de ter diferentes idiomas em diferentes partes da pilha (javascript no cliente e Node.js)?
E você tem hoje. Algumas pessoas trabalham em uma pilha Java (com scala e clojure se tornando incomum). Outros em uma pilha de c #. Outros em uma pilha de JavaScript. Há um pouco de pilhas php lá fora. Muito python. Você ainda pode encontrar algumas pilhas perl lá fora (e se você olhar para alguns sites de baixo volume, você ainda encontrará CGIs). Com a computação em nuvem, o Google também promoveu o Go como uma linguagem Web do servidor viável.
Cada um tem suas vantagens, desvantagens, suas estruturas e seus servidores. A popularidade relativa desses fluxos e refluxos à medida que as tecnologias em torno deles mudam. Eles fazem coisas diferentes bem.