C'è un buon motivo per evitare node.js per le app Web non in tempo reale?

Ho visto molte discussioni su quanto sia straordinario Node.js per le app Web in tempo reale - cose che richiedono socket, Comet, comunicazioni pesanti AJAX e così via. So che il suo modello basato su eventi, asincrono, basato su thread è anche buono per la concorrenza con costi generali bassi.

Ho anche visto tutorial di Node.js per app più semplici, "tradizionali" e non in tempo reale (ad esempio, l'esempio di blog standard, che sembra essere il "Hello World" standard per le persone che imparano lo sviluppo di app). E so anche che il nodo statico ti consente di servire risorse statiche.

La mia domanda è: c'è qualche buona ragione per evitare Node.js per le app Web tradizionali, come annunci, forum, il suddetto esempio di blog o il tipo di app CRUD che costruisci per le applicazioni aziendali interne? Solo perché eccelle in tutte le cose funky in tempo reale, è controindicato per usi più stabili?

L'unica cosa che mi viene in mente, a dir poco, è la mancanza di librerie mature (anche se questo sta cambiando).

(Il motivo per cui mi sto chiedendo è che sto pensando di abbandonare PHP per Node.js, soprattutto per superare l'impedenza non corrispondente del passaggio tra le lingue, ma anche così posso riutilizzare il codice di validazione e quant'altro. Il mio super-io mi ammonisce di scegliere il lo strumento migliore per il lavoro ; tuttavia, non ho molto tempo per imparare quindici lingue e tutte le loro librerie di utenti solo per avere un arsenale completo. È anche rassicurante che Node.js possa darmi un percorso di ottimizzazione più semplice di PHP / Apache in futuro quando dovrò iniziare a pensare al traffico intenso.)

[EDIT] Grazie per le risposte finora, gente; Voglio solo vedere se qualcun altro peserà prima di scegliere una risposta. La risposta di @Raynos in qualche modo conferma ciò che sto pensando, e i collegamenti dei commentatori hanno fornito un buon spunto di riflessione, ma voglio vedere se qualcun altro ha delle risposte specifiche del nodo, come "NON USARE IL NODO PER IL PROBLEMA X '. (Oltre alle attività con CPU elevata, lo so già :-)

c'è qualche buon motivo per evitare Node.js per le app Web tradizionali

Sì, se hai N anni nella piattaforma Web X, allora chiaramente puoi sviluppare un'applicazione nella piattaforma X più velocemente.

Se vuoi fare Y e la piattaforma X ha una soluzione pre-made Y che fa X allora fallo.

Tutti i motivi generici del perché dovresti usare una piattaforma piuttosto che un'altra.

il tipo di app CRUD che crei per le applicazioni aziendali interne?

Sì, ci sono altre piattaforme che ti consentono di scrivere un'applicazione generica più velocemente, mi viene in mente Ruby on Rails.

Tuttavia, ciò detto. Ho esperienza con il nodo e non posso affermare che sceglierei un'altra piattaforma rispetto al nodo a meno che non faccia una quantità enorme di funzionalità per me.

Fondamentalmente è una semplice domanda di

Esiste uno strumento che fa tutto questo per me? No, quindi scegli la piattaforma più conveniente per scrivere lo strumento.

Non ci sono validi motivi per cui node.js sia una piattaforma scomoda (a parte "odio javascript")

Dopo aver lavorato con il nodo per alcune settimane, direi di sì, è molto bello. Ma non necessariamente qualcosa che vorresti usare per sostituire le tue app web run-of-the-mill con ... né, imo, dovrebbe essere.

Ricorda, il nodo è il suo server. Ciò introduce complessità se si desidera eseguire più di una sola applicazione node.js. cioè se hai più di un sito / dominio ospitato su una macchina. Non è come uno stack LAMP, in cui è possibile avere una dozzina di applicazioni PHP per una mezza dozzina di domini diversi in esecuzione sullo stesso server (almeno sulla porta 80). Esistono framework per il nodo che probabilmente lo rendono possibile, ma ciò aggiunge l'aggiunta della complessità che non ti serve se ti attacchi alle piattaforme web tradizionali. (Naturalmente, puoi anche impostare i proxy mettendo un web server davanti al nodo, ma quel tipo di sconfigge il vantaggio dell'uso del nodo).

imo, Node è perfetto per lavorare in combinazione con un web server tradizionale. Il modo in cui ho organizzato le cose ora è servire l'html / js / images statico tramite apache e gestire le esigenze di dati "in tempo reale" mediante un lungo polling all'applicazione del nodo.

Un buon motivo per pensare in secondi al nodo non è tecnico - è fantastico e sorprendente in quello che fa.

Sono affari e in particolare il capitale umano, vale a dire programmatori che lo sanno, quanto costano e la loro disponibilità. Non è così difficile da imparare, ma come con qualsiasi tecnologia più recente il numero di persone che lo conoscono bene (o vogliono) è un sottotitolo dei più grandi gruppi di lavoratori.

Questa è un'ottima domanda, che dobbiamo porre, al fine di far avanzare troppo lo stato dell'arte.

Ero molto curioso di sapere (come Paul d'Aoust) dove esistono i limiti di Node.JS. Purtroppo, molte risposte sono piene di parzialità soggettiva e di motivazioni temporaneamente rilevanti.

Mi sono chiesto: POSSIAMO FILTRARE LA BIAS SOGGETTIVA E RIPRENDERSI ALLE SOLIDE RISPOSTE A QUESTA DOMANDA ATTINENTE?

I punti rimanenti sembrano essere:

1. NodeJS non è maturo come i framework tradizionali. Come suggerisce Paul d'Aoust, questo è solo un motivo temporaneamente rilevante, non per evitarlo completamente, ma piuttosto rivedere e due diligence. Ci aspettiamo di fare i compiti come professionisti del web, ed è nostro compito determinare la soluzione migliore della tecnologia per l'organizzazione, le loro esigenze, il loro futuro, il team (e non noi). La maturità è un bisogno di chiarimenti e un giudizio di appetito per il rischio, ma non di evitamento.

2. NodeJS come server proxy. Un saggio suggerimento, di discussione precedente, che vale la pena rivedere e considerare. È l'idea di utilizzare Node in correlazione con le tecnologie esistenti come modello di progettazione proxy dell'interfaccia front-end. Inoltre, non è un motivo per EVITARE di usare il nodo, ma piuttosto un motivo per evitare di usarlo come una sostituzione completa. Invece optando per un approccio corollario.

3. Nodo di debug. In una conversazione con gli sviluppatori di Node core di Joyent c'è molta complicazione riguardo alla debuggabilità e alla rintracciabilità della causa principale dei problemi derivanti dal core (basato sull'esecuzione di un singolo thread e sull'incapacità di vedere nei thread passati). Vale la pena prendere in considerazione e valutare - ma (di nuovo) probabilmente non l'avversione per l'uso comune, solo casi limite che potrebbero spingere troppo. Forse le tue esigenze specifiche rientrerebbero in questa categoria e forse no.

4. Risorse umane. Questo è il motivo migliore per EVITARE di usare JS in questa pagina e, a mio modesto parere, è una verità netta e scomoda. Sorge la domanda: la tua azienda ha a disposizione i professionisti di talento giusti per vedere il progetto attraverso l'intero ciclo di vita? In caso contrario, non c'è dubbio che è necessario evitare NodeJS. O invece considera A) la ricerca del talento corretto o B) Educazione del talento esistente.

Reclami: la mia osservazione dei reclami su JavaScript è che, molti derivano più dall'errore dell'utente che da errori coerenti della lingua. Abbiamo smascherato molte affermazioni contro "The Hate JavaScript Diatribe" e continueremo a ridimensionare molte altre. Problemi come - la documentazione non è abbastanza buona, non è abbastanza sexy, ma alla gente non piace, è il cancro, è il diavolo, o è troppo "incline" (-CRichardson), sono soggettivi e reclami di parte che devono essere eliminati per un accurato processo decisionale aziendale.

Alla fine, potrebbe essere la risposta corretta: non ci sono buoni motivi per EVITARE NodeJS . Forse è per questo che sta vivendo una rapida crescita, adozione e contributo. Ma per tutti noi forse la risposta qui è continuare a valutare, ricercare e comprendere meglio NodeJS - e cercare avversioni concrete. Nel tentativo di essere aperti a capire esattamente dove Node.JS è immaturo, troviamo esattamente dove dobbiamo migliorarlo. E questa è una benedizione.

Buona domanda. Io per primo rimango curioso per qualcuno di far apparire un motivo migliore per evitare NodeJS - di questi.

C'è qualche vantaggio nell'uso di node over X per applicazioni non in tempo reale:

• Ridimensionamento : il nodo ha buone prestazioni ma anche altre piattaforme; PHP, Ruby, Python e Java tutti in scala. Puoi trovare GRANDI nomi con milioni di utenti che li utilizzano.
• Una lingua per frontend e backend : è uno scherzo, proprio come Java "Scrivi una volta eseguito ovunque"
• Caldo e sexy : l'unico punto valido. Ma a nessuno importa che il tuo sito web stia usando una tecnologia spigolosa!

Vantaggi dell'uso di X over Node per applicazioni non in tempo reale:

• Best practice : poiché Node è nuovo, presenta meno best practice rispetto ad altre piattaforme, specialmente per le applicazioni Web CRUD.
• Lingua Javascript : alle persone non piace Javascript. Mentre Node.js è caldo, Javascript non lo è. Questo è il motivo per cui le persone hanno creato Coffeescript per evitare di scrivere Javascript anche per il lato client.
• Velocità di sviluppo : i vecchi e noiosi framework inclusi e non limitati a Rails e Django sono ben testati e migliorati nel corso degli anni per i siti Web CRUD. Sebbene sia possibile implementare applicazioni simili in Node, è più semplice eseguirlo nel framework di tuo nonno.
• Stabilità : i framework Web di Node stanno migliorando a un ritmo più rapido. Significa che stanno cambiando e avranno più incompatibilità API nel prossimo futuro.
• Librerie e strumenti : le tecnologie più vecchie con più utenti hanno più librerie e strumenti.

La mia risposta sicuramente non sarà valida nel 2015. Nel 2014, salta Nodo per applicazioni Web non in tempo reale, ma tienilo d'occhio.

Ogni framework web ha un punto di forza. Sarai felice mentre lo stai usando per quel punto. Le applicazioni Web non in tempo reale non sono il punto di forza dei framework Web di Node.

Node.js è una piattaforma molto popolare e ha molte caratteristiche interessanti blah blah blah, ma l'uso di uno strumento è una preferenza personale. Ho dato Node.js quattro volte e non ero contento. Ecco i miei motivi Si prega di tenere presente che alcuni di questi motivi sono obsoleti o semplicemente personali: P

• Ho preferito diverse lingue / sintassi (mi piace Python, Scala, la mia lingua preferita è Prolog quindi sì).
• La qualità della documentazione per i framework e le librerie che ho usato non è buona per le librerie Java, Scala, Python.
• I progettisti dei nodejs sono piuttosto ossessionati dai callback anziché dal modello di eventi, dall'osservatore o dai futuri.
• Ci sono già pronti per quello che voglio fare in Ruby, Python, Java sviluppato nel 2005, ho solo bisogno di modificare il file di configurazione.

HTTP è senza stato, quindi in realtà non esiste un'app Web non in tempo reale e quindi nessun motivo per cui non è possibile utilizzare il nodo per tutto.

Detto questo, il nodo è più adatto per un particolare tipo di architettura dell'applicazione. PHP è un file html che contiene un po 'di codice. Il nodo è un codice che facoltativamente contiene un po 'di HTML.

Ciò significa che se l'app è in formato HTML standard senza script lato client, PHP sarà più semplice. Node ha strumenti di template, ma ovviamente non così maturi come qualcosa come PHP.

Se hai molti script lato client e salvi i dati con ajax, finisci con un client html statico che chiama le funzioni sul server. Questo è esattamente ciò in cui il nodo è bravo. Sebbene non sia il modo in cui le app CRUD di solito sono costruite, puoi produrre qualcosa di molto carino con il framework giusto.