O que há de tão exclusivo no Node.js? [fechadas]

48

Recentemente, houve muitos elogios para o Node.js. Eu não sou um desenvolvedor que teve muita exposição a aplicativos de rede. Do meu entendimento do Nodes.js., sua força é: temos apenas um thread que lida com várias conexões, fornecendo uma arquitetura baseada em eventos.

No entanto, por exemplo, em Java, posso criar apenas um encadeamento usando NIO / AIO (que é APIs sem bloqueio do meu entendimento) e lidar com várias conexões usando esse encadeamento, além de fornecer uma arquitetura baseada em eventos para implementar os dados manipulação de lógica (não deve ser tão difícil fornecendo retorno de chamada etc.)?

Como a JVM é uma VM ainda mais madura que a V8 (também espero que seja executada mais rapidamente), e a arquitetura de manipulação baseada em eventos parece ser algo não difícil de criar, não sei por que o Node.js está atraindo tanta atenção. Perdi alguns pontos importantes?

Adrian Shum
fonte
3
Eu me pergunto por que ele foi rebaixado ... Eu sinto que essa pergunta é mais uma discussão de programação, então eu não coloquei no stackoverflow. Também tentei pesquisar tópicos semelhantes, mas só encontrei informações sobre a força do Nodes.js, mas meu problema é que eu realmente não entendo por que a "força" é tão única (que ainda não consigo encontrar)
Adrian Shum
6
Tente implementar esse padrão em Java. Funciona, é claro. Mas você verá uma coisa: será muito, muito detalhado em Java: você precisa de toneladas de retornos de chamada, o que quase sempre significa criar novas classes. Isso pode parecer um pequeno detalhe, mas em um grande programa ele pode ficar feio e pesado rapidamente.
Joachim Sauer
6
Os retornos de chamada Javascript são tão propensos a se tornar pesados ​​- e esse espaguete é muito mais fácil de depurar e refatorar em Java do que em Javascript IMO.
Funkybro 19/06/12
5
@AdrianShum: é um efeito slashdot, qualquer coisa que não se encaixe com a mentalidade do grupo será votada abaixo - como elogiar a Microsoft em /.
Gbjbaanb
3
Estou surpreso de não ver ninguém mencionando o hype.
deadalnix

Respostas:

33

Embora esse conceito possa realmente ser implementado em muitas linguagens (e como o dodgy_coder mencionou, ele foi implementado no Ruby e Python pelo menos), não é tão trivial quanto você afirma.

É verdade que o Java possui APIs de IO sem bloqueio. Assim, você pode executar E / S de disco / rede brutas de maneira não-bloqueadora. No entanto, toda API que de alguma forma envolve ou manipula E / S também precisa ser implementada de maneira não-bloqueadora. Todo analisador XML, todo driver de banco de dados, todo conversor de formato de arquivo precisa ser gravado para oferecer suporte a E / S sem bloqueio. Porque se uma única biblioteca está bloqueando esse padrão, isso reduz o desempenho dos servidores a valores da idade da pedra.

O Node.js possui essa infraestrutura de biblioteca, porque sempre foi projetada dessa maneira: toda biblioteca que se esforça para se tornar popular deve fornecer uma API assíncrona ou ela não será usada.

Joachim Sauer
fonte
18
Sim. Em outras palavras: a força mais importante do Node.js. é a fraqueza mais importante do ECMAScript: a biblioteca padrão do ECMAScript incrivelmente ruim. Como os desenvolvedores do Node.js. tiveram que reinventar cada roda de qualquer maneira, eles tiveram a chance de reinventá-la da maneira certa.
Jörg W Mittag
4
Bem, até onde eu sei, o ECMAScript sempre foi projetado como uma linguagem incorporada; portanto, não havia necessidade de APIs no nível do sistema operacional de qualquer tipo (mesmo as E / S de rede eram abstraídas). Essa falta foi realmente uma vantagem para o Node.js.
Joachim Sauer
"toda biblioteca que se esforça para se tornar popular precisa fornecer uma API assíncrona ou não será usada" Acho que é exatamente isso que estou procurando. Existe algum recurso para analisar como a API assíncrona é fornecida, por exemplo, análise XML e acesso ao banco de dados, no Node.js.
Adrian Shum
11
O @AdrianShum em geral, procura exemplos de programação orientada a eventos. Implementações específicas podem ser encontradas em vários idiomas. Além dos módulos Node.js, você pode ver exemplos Twisted em Python, twistedmatrix.com/trac/wiki , exemplos de POE em Perl, poe.perl.org e Ruby possui EventMachine, github.com/eventmachine/eventmachine
mghicks
19

Provavelmente, o principal motivo é que ele usa JavaScript para gravar componentes do servidor para itens como servidores da Web, aplicativos da Web ou serviços da Web. Isso unifica o JavaScript da linguagem de desenvolvimento front-end (lado do cliente) tradicional com o idioma do lado do servidor.

Você está certo - o fato de não ser bloqueador, o uso do padrão do reator não é único - já foi feito antes do uso de outras linguagens e estruturas, como o Ruby EventMachine ou o Python's Twisted, por exemplo.

dodgy_coder
fonte
5
muito poucas tecnologias têm características verdadeiramente únicas, a singularidade vem de sua combinação particular de todas as suas características
jk.
11
Concordou, há uma lista aqui de bibliotecas que a apoiam em todos os principais idiomas ... Padrão Reactor na Wikipedia
dodgy_coder
10

As três principais razões que eu daria são:

  1. E / S sem bloqueio / E / S assíncrona. Isso está dividido em todos os lugares na web e nos pôsteres anteriores. Uma coisa que eu contribuiria é que projetar seu código para assumir explicitamente comportamentos assíncronos ajuda o mecanismo do compilador a maximizar o hardware. Sim, muitos dos compiladores JIT e processadores hyperthreading usam código síncrono e ajudam a paralelizar a execução. É claro que essa é a melhor abordagem de esforço. Por outro lado, ao criar explicitamente o aplicativo para assíncrono io, você garante que o mecanismo e o hardware possam maximizar o tempo de execução do seu código. É certo que não tenho dados quantificáveis ​​para provar isso, mas isso me faz sentir quente por dentro dessa maneira.

  2. Base de código única para cliente e servidor. Isso tem várias vantagens: ajude a otimizar os custos do datacenter, podendo mover a lógica de negócios do servidor para o cliente; ajudar a reutilizar a lógica de negócios / validação de dados; reduza a complexidade das habilidades do desenvolvedor que precisam existir para oferecer suporte ao produto (vs. Python e javascript).

  3. Baixa barreira à entrada. De muitas maneiras, Javascirpt é como Basic, Pascal e Perl do ano passado. É super fácil começar a escrever código e não requer muito conhecimento de domínio para prosseguir. Isso também ajuda a reduzir seus custos de desenvolvimento, podendo atrair mais desenvolvedores jr e aumentar o desempenho de um projeto. [É claro que você precisa superar os ideólogos que acreditam que as linguagens de programação devem ser difíceis para eliminar os desenvolvedores com baixo desempenho]

cflat
fonte
Não tenho certeza se recomendo a criação de uma equipe do Node inteiramente com o jr. JS devs. A arquitetura não é realmente algo em que precisamos pensar em mais projetos web / UI de nível jr, e o JS leva muito tempo para se tornar realmente bom em termos de construção a longo prazo, como qualquer outro idioma, mesmo que você possa obter resultados relativamente rápido em um nível mais baixo de experiência em projetos menos complexos do que é típico.
precisa saber é o seguinte
Eu concordo com @ErikReppen; uma equipe de arquitetura inteiramente formada por desenvolvedores juniores (independentemente da linguagem) é como projetar e construir uma casa usando carpinteiros que são bons em construir cadeiras, mesas e casas de cachorro.
Curinga