15

Ho sempre considerato JavaScript una grande aggiunta (o piuttosto, per gli ultimi due anni, come un must) al lato client di qualsiasi applicazione web. Anche quando ho iniziato a usare Mootools, che fa un grande passo avanti rispetto alla manipolazione del DOM, e punta a uno scopo generale, il framework OO, non pensavo ancora che avrei preso in considerazione l'utilizzo di JavaScript per lo sviluppo lato server. JavaScript appartiene al fronte, periodo - è quello che pensavo.Ha senso costruire semplici applicazioni web basate su JavaScript (lato client e server)?

Bene, mi sembra according to some damn smart people, mi sono sbagliato. Per la prima volta in assoluto, il concorso per la piattaforma di sviluppo web chiamato Plat_Form ha accettato un team che utilizzava JavaScript puro sia sul server e sul lato client. Inoltre, ecco cosa hanno detto gli organizzatori del concorso:

"Abbiamo una singola applicazione di un team, Upstream Agile, che funzionerà con JavaScript sia sul server che sul lato client. diventare una tendenza importante nei prossimi anni, consideriamo la loro partecipazione uno sguardo al futuro e accettiamo questa squadra anche se nessun altro con questa piattaforma ha applicato. "

Quindi la mia domanda è: è davvero un concetto fattibile, per creare applicazioni web multilivello esclusivamente su JavaScript? In tal caso, quali sarebbero i vantaggi dell'uso di JavaScript sia per il front-end che per il back-end?

MODIFICA: Il collegamento nella risposta di Vanwaril (Why node.js is totally awesome) rivela un'interessante discussione nella sezione commenti che vale la pena leggere. Io, per esempio, ho deciso che, anche se l'utilizzo di Javascript sul lato server è un concetto fattibile e potrebbe avere i suoi benefici, sicuramente non inizierei a creare un'applicazione enterprise con quell'architettura. Almeno per ora. Questa domanda potrebbe dover essere chiesta di nuovo tra un anno, posso immaginare che la risposta cambierà drasticamente nel prossimo futuro.

risposta

12

Prima di tutto, hai dato un'occhiata a node.js? JavaScript è una delle lingue che, negli ultimi anni, ha visto passi da gigante nello sviluppo, ed è probabile che continui a crescere.

In termini di funzionalità, è meno maturo rispetto ad altre tecnologie server-side, ma la comunità attiva non è in ritardo.

Infine, poiché è un linguaggio che funziona sia sul fronte che sul back-end, le sue implicazioni per il riutilizzo di codice e i formati di scambio dati rendono lo sviluppo di applicazioni molto più veloce.

Non sono sicuro che sia ancora pronto per la produzione (a meno che tu non sia disposto a contribuire al codice base) ma JavaScript sul lato server è una buona opzione per sperimentare.

+0

node.js sembra dolce, devo ammettere! Grazie per il link e i tuoi approfondimenti. –

+0

Hmmm, V8 è veloce, ma devo chiedermi perché altri motori Javascript che si trovano su stack Web più maturi non sembrano avere lo stesso slancio. – CurtainDog

+0

@CurtainDog node.js offre qualcosa di nuovo ed eccitante alla tabella: full async. gli altri motori (io lavoro con/per RingoJs) sono più tradizionali e così "meno sexy". – oberhamsi

1

Quindi la mia domanda è: questo è davvero un concetto fattibile, per costruire applicazioni web multilivello esclusivamente su JavaScript?

Sì, anche se gli strumenti sono relativamente immaturi rispetto a molte altre lingue.

Se sì, quali sarebbero i vantaggi dell'utilizzo di JavaScript sia per il front-end che per il back-end?

  • No Passa da una lingua per gli sviluppatori
  • Il riutilizzo del codice (ad esempio Vuoi controllare che i dati sono sana di mente? Lo stesso codice può essere utilizzato sul client e il server).
4

Stiamo costruendo i nostri frontend CMS & utilizzando http://Helma.at, attualmente in servizio ~ 250 milioni di pagine al mese. Questo è JavaScript attraverso & attraverso.

Nota che questo non è il sanguinamento tecnologia, come ti sembra di assumere: Helma è in sviluppo dal 1998 e lo usiamo in produzione dal 1999.

+0

Grazie per questo, sono colpevole come accusato, ho davvero pensato che questo cada sul lato sanguinante. –

+1

Bene, il tuo sito Web 250M pagine/mo è ora inattivo - http://down.is/helma.at –

+0

che non è il sito di cui sto parlando. – oberhamsi

1

Questa non è una nuova idea. In effetti è così vecchio di essere stato di moda e poi è uscito e ora sta tornando di nuovo.

Clasic ASP su server Windows IIS può utilizzare javascript come linguaggio di scripting lato server. può parlare con filesystem locale e SQL sever ecc. roba molto molto semplice.

Si potrebbe facilmente scrivere un codice ASP che restituisca JSON per essere consumato dal proprio script lato client ajax.

Il problema è che gli Stati membri hanno ignorato ASP classico e si è trasferito a asp.net (C# o VB.net) quindi dobbiamo aspettare per la comunità di reinventare lato server JavaScript per tornare al punto in cui siamo, dove nel 2001 .

5

Unhosted è un "progetto" che è completamente su applicazioni JavaScript di sola che vengono eseguiti in solo il browser web e utilizzano server di altrettanto archiviazione per i dati (criptato). Troverete alcuni esempi lì.

4

Per rispondere effettivamente alla domanda: sì, è perfettamente fattibile creare applicazioni web client-server interamente in JavaScript e strutture che hanno ottenuto la trazione nei due anni intercorsi da quando è stata posta la domanda - in particolare Meteor - rendere questo molto più facile di un tempo:

Una lingua. Scrivi sia il client che il server parti dell'interfaccia in JavaScript.

- http://docs.meteor.com

2

codice lato server deve essere particolarmente robusta e ben progettata, in quanto gestisce più di un cliente in un ambiente multi filettato. La complessità dei processi dei livelli aziendali e la necessità di un accurato riutilizzo del codice mi hanno sempre portato a scrivere codice lato server in Java. Non prenderei in considerazione l'utilizzo di script Java perché è finalizzato a un diverso utilizzo.

Detto questo, io uso lo script Java sul server per replicare gli script di convalida lato client, ad esempio. In questo modo è possibile utilizzare l'unico codice di convalida ad entrambe le estremità. L'utente ottiene la convalida del browser reattivo, ma il back-end lo convalida nel caso in cui qualcuno ignori la convalida del front-end.