O Node.js é uma estrutura? [fechadas]

35

Continuo vendo recrutadores, desenvolvedores etc. referir-se ao Node.js como uma estrutura. Na minha opinião, isso é ignorância do que realmente é o Node.js.

Muitas vezes, nas descrições de tarefas, o Node.js é agrupado como uma biblioteca entre AngularJS , React etc. Geralmente, eu vejo isso como sendo inserido por alguém que não conhece a diferença (RH, recrutador etc.).

Na minha opinião, o Node.js é uma plataforma ou um ambiente de tempo de execução; ele alterna a API do DOM (JavaScript no navegador) para várias outras APIs, como o sistema de arquivos (uma vez que é executado como servidor e não no navegador).

Por que as pessoas pensam que o Node.js é uma estrutura; estou errado? É realmente uma estrutura?

ndugger
fonte
5
Não particularmente, mas pude ver a confusão.
Ndugger 6/10/15
1
Há muito tempo, quando o nó foi lançado pela primeira vez, publiquei uma resposta no SO que dizia que o nó não era uma estrutura. Essa resposta foi extremamente prejudicada na época. Hoje, muito poucas pessoas que usam o nó acreditam que é uma estrutura. É uma estrutura no mesmo sentido em que Swift é uma estrutura ou Go é uma estrutura ou Rust é uma estrutura. As linguagens de programação modernas simplesmente têm APIs de nível muito alto que costumavam ser implementadas como estruturas. "Plataforma" é uma boa palavra. Eu diria que é um intérprete me (usando o tradicional unix significado dessa palavra)
slebetman
Observe que o nó não altera a API do DOM e tudo o que você pode executar com javascript ainda está disponível para você, com ou sem o nó.
Rob
@slebetman Qual é o "outro" significado de intérprete? Eu também não sabia que havia um debate lá! : S
J. Abrahamson

Respostas:

44

É 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:

  1. 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."
  2. O Node.js, como um pacote, contém um intérprete e um compilador. Ele apenas rouba estes do V8.
  3. 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.
  4. 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".

J. Abrahamson
fonte
ei, notavelmente equilibrado! portanto, probably have no idea'framework' é uma palavra que você pode entender sem ser um programador, um recurso útil, se poupado para quando realmente faria a diferença.
N611x007 06/06
"O Node.js adiciona funcionalidade ao JavaScript bruto na maneira de expandir o idioma." Não é verdade, está expandindo a funcionalidade e não a linguagem, não muda a maneira como você precisa escrever código, como muitas estruturas exigem. Existem outras funções ou objetos adicionados, como uma biblioteca incluída pode ser adicionada. Você pode chamá-lo ou usá-lo como qualquer nova função ou objeto. O estilo de programação não muda, os conceitos básicos de linguagem são os mesmos 'apenas' adicionam algumas funcionalidades. Portanto, não é uma estrutura ou expansão da linguagem, javascript com bibliotecas de plataformas padrão adicionadas e, portanto, funcionalidade.
Codebeat 20/07
Claro, eu posso seguir completamente o seu lado. Eu acho que a linha aqui é confusa. Qualquer maneira de pensar faz sentido. Como ponto estrito, o nó expande o JS fornecendo uma FFI, que é a peça principal que permite que o nó forneça posteriormente mais bibliotecas do sistema. Por outro lado, enquanto o nó “principal” é apenas o tempo de execução (e esse FFI), na maioria das vezes quando as pessoas discutem o nó, na verdade elas querem dizer “o tempo de execução principal, as extensões de FFI e a funcionalidade básica da biblioteca construída sobre ele”, como este é como o nó é empacotado.
J. Abrahamson
20

O Node.js® é um tempo de execução JavaScript criado no mecanismo JavaScript V8 do Chrome.

fonte

Nó é um tempo de execução ou ambiente. Não é uma estrutura. As pessoas (eu sinto) geralmente entendem errado, porque estruturas como express são onipresentes com o nó.

mais leitura sobre tempos de execução versus estruturas, se você estiver interessado.

rlemon
fonte
inb4 "mas a página about diz 'Como uma estrutura orientada a eventos assíncronos'" Estou ciente.
Rlemon
3
A v8 incorporada não é o tempo de execução? ;-)
johannes
@johannes Estou inclinado a concordar com você sobre isso. V8 é o tempo de execução e o nó simplesmente expande as ferramentas disponíveis para o desenvolvedor (servidor http, util, etc), portanto, acho que o rótulo da estrutura ainda funciona. Ainda assim, é um ambiente v8 modificado; nó não é algo que você apenas "inclui" em seu projeto. É tudo uma questão de perspectiva, eu acho.
nick
@rlemon, a estrutura da peça foi removida.
ebram Khalil