Il tipo di Nodo è difficile da confrontare direttamente perché è un po 'strano uccello. La cosa fondamentale da capire è che sì, mentre JS blocca, che è inteso come comportamento desiderabile nel caso del Nodo, l'altra metà del sistema è le operazioni C ++ sotto il cofano che possono infatti funzionare in parallelo l'una con l'altra. Questa è la ragione per cui fai quasi tutto in modo asincrono con il JS in Node. La cosa fondamentale da capire è che ci sono due livelli. Dirigi il traffico e gestisci strutture dati semplici con JS e la sua natura di blocco agisce come una sorta di sistema di accodamento automatico. Come bonus, ottieni tutti i vantaggi di JS essendo un linguaggio oscenamente facile da implementare con i paradigmi di messaggistica / eventi. Per tutto ciò che è probabile che richieda un po 'di tempo, non importa in che cosa lo scrivi, è meglio farlo con il C ++.
Il punto dell'interfaccia di blocco di JS in cima è quello di seppellire tutto quel materiale di gestione dei thread sgradevole / disordinato SENZA effettivamente ridurre l'utilizzo di un solo processore.
Senza dubbio le persone scriveranno alcune cose assolutamente orribilmente performanti con Node per ignoranza, ma non vedo alcuna ragione per cui non possa scalare per un framework di livello aziendale (ew @ terminology) e personalmente sto ottenendo sempre più entusiasta di questo, più lo uso (che è stato finora principalmente per ridurre la complessità di configurazione / configurazione di una web app a triplo stack di Rails, .NET e Java).
Inoltre, i moderni compilatori JS JIT hanno migliorato le prestazioni di JS di un ordine di grandezza negli ultimi anni e Node è stato creato su Chrome V8. Sarei sorpreso se JS non fosse almeno in grado di confrontare favorevolmente con Python per velocità single-threaded e come Python, è possibile gestire la colla architettonica di un'app con molto meno codice che tende a rendere le cose meno disordinate e più facili da gestire in termini di prevenzione del lavoro di base e di scrittura di un'app leggibile, modificabile e manutenibile, in cui non devi mai pensare a cosa dovrebbe (IMO) essere ovvio a livello superiore.
Come si misura in modo semi-oggettivo per il confronto? Escludendo una sorta di competizione con una massiccia partecipazione per scrivere la stessa app con diversi stack, non puoi davvero. Penso che il meglio che puoi fare sia osservare come le app tendono a comportarsi, ciò che il team conosce meglio, quali strumenti sono disponibili e non ti preoccupare dei confronti delle prestazioni a meno che lo strumento in questione non abbia un rappresentante per crummy perf su tutta la linea. Nella mia esperienza, Java vince le guerre di micro-benchmark, ma in genere è notoriamente poco performante sul web lato server rispetto a Rails, PHP, Python e ASP.net post-MVC per applicazioni web di base e non di base che Ho lavorato su.
Questo non vuol dire che Java non potrebbe sovraperformare alcuna app in un'altra lingua o che non lo fa mai. Né sto dicendo che non ho mai visto malamente scritto JS, Python o PHP. Tuttavia, data la qualità del tuo team Java medio di grandi dimensioni rispetto a un gruppo MUCH di dimensioni più piccole di JS o Python ninja che fanno un'app web di media complessità per probabilmente meno paghe totali (e sì, sto assolutamente offrendo un parere puramente soggettivo basato su esperienza personale perché è tutto ciò che rimane) Metterei i miei soldi su un'app prodotta da alcuni sviluppatori esperti con un linguaggio che può essere fatto molto di più con meno verbi e nomi senza limitare la tua capacità di strutturare le cose.
Ma alla fine, quello che presumo tu voglia sapere è se va bene usarlo e ciò implica preoccupazioni soggettive.
Quindi ti piace l'idea di scrivere app con un determinato linguaggio / struttura dello stack, ti piace ciò che la comunità sta facendo con esso, e escludendo preoccupazioni più specifiche non fa schifo in generale a prestazioni nell'80% dell'uso ovvio- casi? Nel caso di Node, personalmente direi di si, si, e sì.
Ma se non sei realmente interessato a come funziona e non ti interessa davvero per JS, necessariamente, me ne starò lontano perché quelle sono le due cose fondamentali che danno valore a Node e sono requisiti per mantenerlo performante.
Finora per me, si sta comportando esattamente come mi aspetterei da un buon strumento JS. Riduce la complessità come un campione, permettendomi di avvolgere un processo intrinsecamente fragile / disordinato in qualcosa che sia robusto e leggibile. Ecco perché JS ha vinto il posto indiscusso che ha avuto nell'interfaccia utente del browser e continuerà ad espandersi come linguaggio di uso generale.