Esiste un buon motivo per evitare node.js per le app web non in tempo reale?

is there any good reason to avoid Node.js for traditional web apps

Sì, se hai N anni in piattaforma web X, puoi chiaramente sviluppare un'applicazione in piattaforma X più velocemente.

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

Tutti i motivi generici del motivo per cui dovresti utilizzare una piattaforma piuttosto che un'altra.

the sort of CRUD apps you build for internal business applications?

Sì, ci sono altre piattaforme che ti permettono di scrivere un'applicazione generica più veloce, mi viene in mente un ruby on rails.

Tuttavia, questo ha detto. Ho esperienza con il nodo e non posso affermare che sceglierei un'altra piattaforma su un nodo a meno che non faccia una grande quantità di funzionalità fuori dalla scatola per me.

Fondamentalmente è una semplice domanda di

Does a tool exists that does all of this for me? No, then pick the most convenient platform to write the tool.

Non ci sono solidi motivi per cui node.js è una piattaforma inopportuna (altro che "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 web app run-of-the-mill con ... né, imo, è destinato a essere.

Ricorda che il nodo è il proprio server. Questo introduce complessità se si vuole eseguire più della semplice 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 che girano dallo stesso server (sulla porta 80, almeno). Ci sono framework per i nodi che probabilmente lo rendono possibile, ma questa è l'aggiunta di complessità che non ti serve se sei legato alle piattaforme web tradizionali. (Puoi, ovviamente, anche configurare i proxy mettendo un server web davanti al nodo, ma questo tipo di sconfigge il vantaggio dell'uso del nodo).

imo, Node è perfetto per lavorare con insieme a un server web tradizionale. Il modo in cui ora ho organizzato le cose è quello di pubblicare le immagini statiche html / js / tramite apache e gestire i dati "in tempo reale" necessari tramite un lungo polling all'applicazione nodo.

Un buon motivo per avere pensieri secondari sul nodo non sono tecnici: è fantastico e sorprendente in quello che fa.

Sono imprenditori e in particolare capitale umano, cioè 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 lo vogliono) è un sottogruppo dei più grandi gruppi di lavoratori.

Questa è una domanda molto buona, che dobbiamo chiedere, per avanzare ulteriormente 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 pregiudizi soggettivi e logica razionale.

Mi sono chiesto: POSSIAMO FILTRARE IL BIAS SOGGETTIVO E RIVOLGERSI A SOLIDE RISPOSTE A QUESTA IMPORTANTE QUESTIONE?

I punti rimanenti sembrano essere:

1. NodeJS non è maturo quanto i framework tradizionali. come suggerisce Paul d'Aoust, questo è solo un motivo momentaneamente rilevante, non per un completo elusione, ma piuttosto una revisione e due diligence. Ci aspettiamo che facciamo i compiti a casa come professionisti del web, ed è nostro compito determinare il miglior adattamento della tecnologia all'organizzazione, alle loro esigenze, al loro futuro, al team (e non a noi). La maturità è un'esigenza di chiarimento e un giudizio sull'appetito per il rischio, ma non sull'evitamento.

2. NodeJS come server proxy. Un consiglio saggio, di discussione preliminare, che vale la pena rivedere e considerare. È la nozione di utilizzare il nodo in correlazione con le tecnologie esistenti come modello di progettazione del proxy dell'interfaccia front-end. Ma anche, non è un motivo per EVITARE l'uso del nodo, ma piuttosto un motivo per non usarlo come sostituzione completa. Invece optando per un approccio corollario.

3. Debugging Node. In una conversazione con gli sviluppatori di nodi core di Joyent c'è molta complicazione attorno alla debuggabilità e traccia della causa principale dei problemi derivanti dal core (basata sull'esecuzione di un singolo thread e sull'incapacità di vedere nei thread precedenti). Ciò vale la pena di essere preso in considerazione e valutato, ma (di nuovo) probabilmente non è avversione per l'uso comune, solo i casi limite che possono spingere la busta. Forse i tuoi bisogni specifici rientrerebbero in questa categoria e forse non lo faranno.

4. Risorse umane. Questa è la ragione migliore per EVITARE di usare JS in questa pagina e, a mio modesto avviso, è una verità spiacevole e scomoda. Si pone la domanda: la tua azienda ha i professionisti di talento giusti a portata di mano per vedere il progetto attraverso l'intero ciclo di vita? Se così non fosse, non c'è dubbio che devi evitare NodeJS. Oppure considera A) localizzando il talento corretto, oppure B) Educando il talento esistente.

Reclami: La mia osservazione dei reclami su JavaScript è che, molti risultano più dall'errore degli utenti che da errori coerenti del linguaggio. Abbiamo smascherato molte affermazioni contro "The Hate JavaScript Diatribe" e continueremo a sfatare molti di più. Problemi come - la documentazione non è abbastanza buona, non è abbastanza sexy, ma alla gente non piace, è il cancro, è il diavolo, o è troppo "tipografico" (-CRIChardson), sono soggettivi e reclami tendenziosi che devono essere eliminati per un accurato processo decisionale aziendale.

Alla fine, la risposta corretta potrebbe essere - 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 capire meglio NodeJS - e cercare avversioni concrete. Nella ricerca di essere aperti a capire esattamente dove Node.JS è immaturo, troviamo esattamente dove dobbiamo renderlo migliore. E questa è una benedizione.

Buona domanda. Io per primo rimango curioso che qualcuno mostri una ragione migliore per evitare NodeJS - di questi.

C'è qualche vantaggio nell'usare il nodo su X per le 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 nomi GRANDI con milioni di utenti che li utilizzano.
• Una lingua per frontend e backend : è uno scherzo, proprio come "Scrivi una volta eseguito ovunque" di Java
• Caldo e sexy : l'unico punto valido. Ma a nessuno importa che il tuo sito web stia usando tecnologia innovativa!

Vantaggio dell'utilizzo di X over Node per applicazioni non in tempo reale:

• Best Practice : poiché il nodo è nuovo, ha un minor numero di best practice rispetto ad altre piattaforme, specialmente per le applicazioni Web CRUD.
• Lingua Javascript : le persone non amano Javascript. Mentre Node.js è caldo, Javascript no. 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 in molti anni per i siti Web CRUD. Mentre puoi implementare applicazioni simili in Nodo, è più semplice da fare nel framework di tuo nonno.
• Stabilità : i framework web del nodo stanno migliorando a un ritmo più veloce. Significa che stanno cambiando e avranno più incompatibilità API nel prossimo futuro.
• Librerie e strumenti : le vecchie tecnologie con più utenti hanno più librerie e strumenti.

La mia risposta sicuramente non sarà valida nel 2015. Nel 2014, ignora il nodo per le 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 bla bla bla, ma l'utilizzo di uno strumento è una preferenza personale. Ho dato a Node.js quattro volte e non ero contento. Ecco le mie ragioni. Tieni presente che alcuni di questi motivi sono obsoleti o semplicemente personali: P

• Ho preferito una lingua / sintassi diversa (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 del nodojs sono piuttosto ossessionati dai callback anziché dal modello di evento, dall'osservatore o dai futures.
• Sono disponibili soluzioni per ciò che voglio fare in Ruby, Python, Java, sviluppato nel 2005, ho solo bisogno di modificare il file di configurazione.

HTTP è senza stato, quindi non esiste effettivamente un'applicazione web non in tempo reale e quindi 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 è il codice che contiene opzionalmente un po 'di html.

Questo significa che se la tua app è un modulo html standard senza uno script lato client, PHP sarà più semplice. Il nodo ha strumenti per i modelli, ma ovviamente non è maturo come qualcosa di simile a PHP.

Se si hanno molti script sul lato client e si salvano i dati con ajax, si finisce con le funzioni di chiamata client html statiche sul server. Questo è esattamente ciò a cui il nodo è bravo. Sebbene non sia il modo in cui le app CRUD vengono di solito create, puoi produrre qualcosa di carino con il framework giusto.