Executando verificação de segurança...
5

Excelente artigo, André!

Você tocou no ponto chave: "delegar ao ambiente". E é muito importante a gente lembrar o tem por trás dessa "delegação mágica":

A ideia original do Node era bem "simples" e genial: conectar o V8, o interpretador de JavaScript do Chrome, com o libev – uma biblioteca em C, feita pra I/O assíncrono em sistemas Linux. O V8 cuidava do JavaScript e o libev fazia o trabalho sujo de falar com o sistema operacional de forma assincrona!

Aí, para portar essa maravilha para o Ruindows, que acabou substituindo o libev até no Linux. Claro, hoje Node.js é um projeto muito mais complexo, mas era fundamentalte:

  1. O V8 um intetrepetador de JS escrito em C++ executa seu JS
    Encontrou um fetch() ou fs.readFile()? Ele não sabe fazer isso.

  2. Ele entrega a tarefa pro libev.
    libuv (em C) se vira com as chamadas de sistema do SO (em C) pra fazer a requisição de rede ou ler o arquivo.

  3. Quando o SO terminar o libev entrega o resultado de volta para o V8.

E é aqui que está a beleza da coisa, o motivo pelo qual ele se tornou esse gigante. O Node.js não tentou reinventar a roda. Pelo contrário, ele foi o eixo perfeito que conectou duas rodas que já eram incrivelmente potentes e testadas em batalha: de um lado, o V8, otimizado ao extremo pelo Google; do outro, as capacidades de I/O assíncrono que existe e é refinado há décadas em C no Linux.

É por isso que essa "camada de abstração" foi tão disruptiva. O sucesso estrondoso do Node.js não veio de uma complexidade, mas sim de uma simplicidade genial. Ele é a prova de que a melhor engenharia, muitas vezes, é sobre ser a "cola" certa no lugar certo.

Ele deu superpoderes a milhões de desenvolvedores JavaScript, permitindo-lhes construir servidores de alta performance e resto, como dizem, é história. Mas isso só aconteceu por que alguém entendia de C, C++ e dos fundamentos e que acreditou que uma gambiarra simples era melhor que o status quo.

Carregando publicação patrocinada...