Nella nostra azienda, dobbiamo creare un'interfaccia Web su una piattaforma Linux incorporata. In un certo senso vedo 2 opzioni: usi una tecnologia in cui HTML e JavaScript vengono generati sul lato server (Think JSP, Grails, ma è qualcosa che utilizza C ++ e genera HTML / JavaScript) o crei un 'client' HTML5 applicazione che comunica con un backend di generazione JSON o XML.

Ho la sensazione che le applicazioni web tendano attualmente ad andare con quest'ultima, ma quali sono i vantaggi di farlo (gli sviluppatori del progetto scelgono la prima, principalmente in base al fatto che conoscono C ++ molto meglio di HTML e Javascript)

AJAX

Penso che la tua domanda si riduca a "La mia applicazione web dovrebbe generare HTML sul lato client o sul lato server?" La generazione lato client comunica con il server utilizzando AJAX, sebbene X (XML) sia stato generalmente sostituito con JSON, ma la maggior parte delle persone lo chiama ancora AJAX perché suona meglio. Sul lato server, il server crea semplicemente HTML sul server.

Ho molta esperienza con XML e quasi nessuna con JSON. Tutto quello che so su XML mi fa suggerire di usare JSON se possibile.

Pro AJAX:

• Invia meno dati su HTTP (S) in modo che possano funzionare più velocemente.
• Il server è essenzialmente un servizio Web in modo che altre persone (o te) possano scrivere i propri client. Ciò può essere utile durante la creazione di una versione mobile del tuo sito. Inoltre, molte invenzioni diventano popolari per motivi che il loro creatore non ha mai voluto. I servizi sono più amichevoli con le persone che trovano nuovi usi per il tuo codice.
• Sembra un'applicazione più recente

Contro AJAX:

• Debug di JavaScript
• Complessità?
• Le cose che puoi fare con JavaScript sono spesso completamente impossibili da usare per persone non vedenti o portatori di handicap.
• Potrebbe richiedere più codice totale (maggiore spazio di archiviazione complessivo sul dispositivo incorporato)

Client / Server

Tutte le applicazioni Web utilizzano l'architettura client-server. Il protocollo HTTP obbliga le applicazioni Web a comportarsi in questo modo. AJAX utilizza una soluzione alternativa per tale limitazione di progettazione, ma il modello base di base di HTTP è ancora client-server. Non rimarrei deluso dal modo migliore per applicare MVC alle applicazioni web. Se devi fare MVC per motivi politici, guarda come lo fa Ruby / Rails. In realtà, Rails è una grande architettura da copiare (o utilizzare).

Servizio vs. app.

Un buon servizio è quasi sempre meglio di un'applicazione. Ma fare un buon servizio è difficile! Potrebbe essere necessario creare l'applicazione prima di poter scrivere una specifica ben progettata per un servizio. Non rendere il tuo lavoro più difficile di quanto debba essere. Per la versione 1, concentrati sulla creazione di un'ottima applicazione. Fino a quando la tua applicazione non è relativamente stabile e sei sicuro che soddisfi i requisiti dei tuoi utenti, avere un servizio probabilmente non ti farà comunque bene. Progettare il servizio sbagliato troppo presto è una perdita di tempo che continua a sprecare mentre si tenta di riparare l'interfaccia di servizio e gestire il refactoring massiccio del codice server e client che seguirà.

C / Web

Wow. Ho lavorato in C e Assembly per 3 anni prima di passare allo sviluppo web. Non riesco a pensare a una lingua peggiore in cui scrivere un'applicazione Web, soprattutto dal punto di vista della sicurezza. La convalida dell'input e l'escaping dell'output sono così importanti ... SANS pubblica ogni anno un elenco degli errori più comuni. Overflow del buffer, iniezioni, problemi tra siti (codifica errata dell'output) ... Tutti questi errori sono davvero facili da commettere in C o assembly. Almeno un linguaggio come Java ha una stringa che è immune agli overflow e un meccanismo di gestione delle eccezioni che generalmente impedisce agli errori off-by-one di consentire al codice dannoso di accedere alla memoria di sistema. Per non parlare della gestione di set di caratteri internazionali (usare UTF-8 quando possibile).

Se è necessario utilizzare C per motivi di memoria o firmware, questo è quello che devi fare. Solo stai attento!

Supporto per il browser

Il primo passo per creare un'applicazione Web è scoprire quali browser verranno utilizzati dai tuoi clienti? W3Schools e Wikipedia sono entrambe buone fonti di statistiche generali, ma YMMV.

Nel luogo in cui lavoro, attualmente confermiamo che la nostra applicazione crea solo HTML transizionale XHTML 1.0 valido. Usiamo anche Doctype e la formattazione specifici necessari per evitare la modalità Quirks in IE, che semplifica la scrittura di HTML cross-browser (vedi suggerimenti sul mio blog ). Testiamo sulle ultime 3 versioni di IE, oltre a Firefox e Chrome su Windows e Linux (Safari utilizza lo stesso motore di rendering di Chrome). Con tale convalida e test, la nostra applicazione funziona praticamente ovunque (Windows, Mac, Linux, iPhone, Android, ecc.) Ad eccezione del BlackBerry.

BlackBerry non ha mai avuto un vero browser con JavaScript, quindi non lo supportiamo. Gli utenti BlackBerry sono abituati a non avere un vero browser Web, quindi non si lamentano. Forse sta cambiando? Vorrei provare a chiedere ad alcuni clienti quali browser stanno usando e assicurarmi di provare con quei browser.

Sommario

Tutti i siti Web sono basati su HTML e HTTP. Avere un buon riferimento per queste tecnologie a portata di mano mentre si sta facendo la domanda. Nel corso della creazione di un'applicazione, anche con un toolkit, incontrerai problemi che richiedono una conoscenza di base di queste tecnologie per risolverle.

Probabilmente dovrai anche sentirti a tuo agio con i CSS e la compressione delle immagini per creare qualcosa di decente che risponda rapidamente. JavaScript, i web server e i browser sono ulteriori aree di conoscenza di cui alla fine avrai bisogno.

Se costruisci il tuo HTML sul lato server, la tua base di codice sarà probabilmente più piccola e potresti non aver bisogno di imparare JavaScript. Il modello lato server indica che i programmatori scriveranno (C?) Codice che genera HTML che possono guardare direttamente prima che venga inviato al client. Il modello AJAX significa che i programmatori scriveranno JavaScript che genera HTML. Non sono a conoscenza di molti strumenti per convalidare o addirittura visualizzare il codice HTML generato da JavaScript all'interno di un browser, rendendo più difficile la programmazione corretta.

Dove lavoro ora, utilizziamo un approccio ibrido che a volte coinvolge codice Java che genera JavaScript che genera HTML. Se siete nuovi nello sviluppo web, questo non è il punto di partenza. Immagino che dovrei dire che, a meno che tu non abbia validi motivi per usare un modello AJAX, inizierei con il vecchio modello di generazione HTML lato server e vedrò quanto ti spinge.

Quest'ultimo ha il vantaggio di rendere il tuo "back-end" un generico "servizio dati" (qualunque cosa ciò possa significare nel tuo contesto).

Il tuo client HTML è quindi solo uno dei tanti possibili consumatori di tali dati. Pensa all'app iOS, all'app Andriod, all'app Windows 8, alle API, ecc. Come altri consumatori.

Un modo comune in crescita di un'applicazione Web è un mix di entrambi, che tende all'una o all'altra parte.

Il primo approccio è più tradizionale, esiste da anni ed è ben documentato (anche se c ++ non è generalmente un linguaggio popolare per questo).

La seconda opzione è più moderna ed è presente nei blog e nei forum di sviluppo al giorno d'oggi. Uno dei motivi di ciò è la crescente necessità di offrire la stessa applicazione ad altre interfacce, API mobili e servizi. Il secondo approccio tende a un cliente più ricco e più reattivo.

Tutto sommato, ciò dipende da altri vincoli, come la familiarità del team e il business case.

Alcune domande che possono aiutarti a valutare le tue opzioni:

1. Il team ha esperienza nella lingua e nella piattaforma?
2. Il team è disposto a imparare nuovi approcci e tecnologie?
3. L'applicazione trae vantaggio dall'essere più facilmente programmabile per altri dispositivi (iPhone, Android, Windows 8, ecc.)
4. Altre app interne o esterne integrate con servizi o dati disponibili per l'applicazione?

Per tali applicazioni "intranet" utilizzo l'approccio fat-client (JavaScript / HTML5-app + JSON) con ExtJS4.

Per i normali siti Web "Internet" utilizzerei un approccio più "classico".

I client devono comunque eseguire il rendering del sito, quindi perché non caricarli con l'intero processo e fornire loro solo i dati da compilare. Semplicemente configura il codice del server per generare risposte (semplicemente JSON o XML), che consente di risparmiare prestazioni. Inoltre, poiché ci sono sempre più client che server, l'intero sistema si ridimensiona molto meglio se i client eseguono più lavoro.

Il codice client viene consegnato con HTTP, è ancora possibile inviare facilmente nuove versioni agli utenti senza alcun meccanismo di aggiornamento oscuro. (Basta sostituire HMTL / JS / CSS)

L'unica ragione per cui preferirei un approccio classico sui normali siti Web sono i motori di ricerca.