É um pouco difícil de dizer, porque essas palavras não são bem definidas. Em linguagem comum, acho um pouco atípico chamar o Node.js de estrutura, com certeza, mas seria difícil argumentar sobre o porquê exatamente não é.
Isso tudo fica arriscado, e muitas vezes vejo usos muito ruins da linguagem, por isso vou ser explícito e começar do fundo
JavaScript é uma linguagem de computador, ou seja, estritamente, um conjunto de convenções que nos permitem ler e interpretar um monte de texto como tendo semântica de execução - uma palavra sofisticada para "maneira de interpretar a linguagem como um conjunto de instruções". Classes de programas chamados intérpretes , compiladores , transpilers , linters , marcadores , etc. todo o texto tomar e tentar fazer algo com esse entendimento convencional de como executar o código.
- Na verdade, os intérpretes executam a semântica de execução operando alguma máquina - geralmente o seu computador. Você pode pensar neles como um homenzinho dentro do seu computador, alternando interruptores como "imprima esse caractere" com base nas instruções escritas no seu programa JavaScript.
- Os compiladores tentam converter o texto JavaScript em um novo conjunto de textos que possui semântica de execução para um idioma diferente - talvez um com a propriedade especial de que os computadores possam executá-lo diretamente.
- Os transpilers são uma forma generalizada de compilador, na medida em que recebem o texto JavaScript e enviam o texto de alguma outra linguagem. A diferença é, portanto, um pouco subjetiva, mas geralmente se pensa em um compilador como saída de código de nível muito baixo e um transpiler como saída de código de alto nível .
- Linters , marcadores , verificadores de tipo , etc. , todos recebem texto em JavaScript e produzem algum tipo de produto analítico, com texto destacado, por exemplo, que é influenciado pela semântica da execução, mas não é realmente representativo.
Agora, vamos nos aprofundar na semântica de execução. Geralmente, a semântica de execução envolve um processo de leitura do texto da linguagem e de chegar a uma descrição de uma máquina abstrata ou a uma descrição dos efeitos colaterais observáveis . O que eu gostaria de sugerir é que ambos assumem a necessidade de haver algum tipo de "API de baixo nível" para operar a máquina ou para executar os efeitos observáveis. Geralmente, eles são considerados parte do ambiente de tempo de execução
- O ambiente de tempo de execução ou tempo de execução é um conjunto de primitivas assumidas que a convenção de idioma requer para existir para operar. No que diz respeito à linguagem, pode haver alguma suposição sobre seu comportamento, mas eles são inobserváveis. Nas imagens do intérprete acima, o "homem interior" apenas pressiona os interruptores do tempo de execução - ele não pode inspecionar pessoalmente o que eles estão fazendo.
A palavra tempo de execução geralmente é abusada para significar o conjunto de primitivas assumidas e uma instanciação real delas.
Então, agora chegamos a algo cabeludo. Uma linguagem é um conjunto de convenções que pressupõe a existência de um tempo de execução para fornecer significado à sua semântica de execução. Ele nunca "investiga neles", pois estão fora do escopo.
Para realmente usar uma linguagem, você deseja algo como um compilador ou intérprete ao lado de uma implementação em tempo de execução. O compilador / intérprete e esse tempo de execução andam de mãos dadas na execução do seu código.
- O V8 do Chrome , geralmente chamado de mecanismo , é um pacote que contém uma implementação de intérprete, compilador e tempo de execução compatível com a interface de tempo de execução exigida pelas convenções JavaScript padrão da ECMA.
Então, onde o Node.js se encaixa nisso?
Temos que dividi-lo em partes:
- O Node.js expande a linguagem JavaScript , fornecendo um conjunto maior de primitivas do ambiente de tempo de execução - aquelas que estão fora do escopo dos padrões da ECMA. Isso inclui coisas como E / S de arquivo . Isso significa que o Node.js altera o idioma e, de certa forma, é um novo idioma: "JavaScript do Node.js."
- O Node.js, como um pacote, contém um intérprete e um compilador. Ele apenas rouba estes do V8.
- O Node.js fornece uma implementação do ambiente de tempo de execução do Node.js., que permite que "JavaScript do Node.js." seja executado.
- O Node.js fornece um conjunto de bibliotecas padrão criadas sobre as novas primitivas, que as tornam mais acessíveis aos usuários finais do "Node.js. JavaScript".
Então o Node.js é um monte de coisas!
Mas é uma estrutura?
É aqui que a terminologia se desfaz totalmente - ninguém tem uma definição boa, consistente e significativa do que realmente é uma estrutura.
Há debates que se enfurecem: "o que é uma estrutura versus uma biblioteca" e eles terminam em coisas insatisfatórias como "uma biblioteca é algo que você chama e uma estrutura é algo que chama você". Eu realmente nem quero dar uma explicação tão triste à luz do dia - mas o JavaScript e o JavaScript do Node.js em particular, são um golpe enorme nessa definição, pois toda a técnica de passagem de retorno de chamada significa que você está constantemente alternando entre chamadas. e sendo chamado.
Na minha opinião pessoal, há algo substancial aqui. Eu não quero desenhar uma linha brilhante, mas vou apenas dizer
- Um conjunto de códigos é semelhante a uma biblioteca se funcionar como um conjunto de legos : divisíveis e feitos para montagem. Embora possa haver alguns exemplos de como usar a biblioteca, geralmente é do próprio usuário reuni-la de acordo com suas necessidades.
- Um conjunto de códigos é semelhante a uma estrutura, se não for divisível e implica convenções *: separar partes dela pode causar muitas suposições a falhar; portanto, você precisa entender o uso convencional para poder usar uma estrutura adequadamente.
Esta é uma linha ondulada, com certeza, mas quero destacar um ponto realmente interessante sobre estruturas:
Estruturas implicam um conjunto de convenções de como interpretar código; eles são, portanto, uma linguagem por si só.
Isso pode ser algo sobre o qual as pessoas querem discutir também, mas se você comprou minha definição anterior de que uma linguagem é apenas um conjunto de convenções que dão vida a um bloco de texto, sempre que você estabelece uma nova camada de convenções, ' construímos um novo idioma. Talvez com estruturas as matérias-primas sejam as interpretações semânticas de sua linguagem hospedeira, em vez de arquivos de texto bruto, mas a idéia é a mesma!
Então, com tudo o que foi dito, estou totalmente feliz em chamar o Node.js de quadro, mesmo que seja um pouco contra a norma! O Node.js adiciona funcionalidade ao JavaScript bruto na maneira de expandir o idioma . Com ele, traz novas suposições e ferramentas para trabalhar nessa linguagem expandida. Funcionalmente, essas idéias são as mesmas de outras estruturas bem aceitas, como Ruby on Rails .
Eu diria que, neste momento, você se sente um pouco enjoado e quer argumentar que há uma enorme divisão entre Ruby on Rails e Node.js dessa maneira, então estou com você , é claro. O tipo de mundo conceitual em que os dois vivem é dramaticamente diferente - eu apenas quero dizer que eles são o mesmo tipo de coisa: conjuntos de convenções para expandir os poderes de uma linguagem básica dentro de um domínio específico.
Também estou feliz em sugerir que o domínio do Node.js. é pequeno e restrito e, portanto, as convenções adicionadas são simples de raciocinar e relativamente fáceis de corrigir. OTOH, Ruby on Rails vive em um domínio complexo e mal definido de "aplicativos da web de negócios", o que significa que as convenções estabelecidas são certamente imprecisas e quebradas.
Mas tudo isso é um longo caminho para dizer, sim, os recrutadores provavelmente não têm idéia do que querem dizer quando dizem isso. Suponho que "framework" pareça uma palavra melhor e mais grokkable do que "runtime" ou "engine".