Pro e contro di un'app Web solo HTML / JavaScript [chiusa]

Ho usato questa tecnica esclusivamente per un'applicazione web su cui stiamo lavorando. Il mio back-end è ospitato su Google App Engine utilizzando Java SDK e il mio frontend utilizza HTML, CSS e JavaScript (con jQuery).

Il progetto è più piccolo con solo me stesso e un web designer, e entrambi riteniamo che questo metodo ci abbia aiutato a lavorare molto più velocemente e a ottenere qualcosa sul mercato molto prima.

Vantaggio: lavorare con i web designer

Il vantaggio principale di questa tecnica è che il web designer, che conosce un po 'di PHP ma non si considera un programmatore, può lavorare senza essere ingannato in HTML e CSS senza dover guadare attraverso infinite linee di JSP, tag taglib e altro il markup lato server che ci è stato detto per anni è supposto per rendere la vita dello sviluppatore front-end molto più facile.

Senza tutto il markup lato server, siamo stati più agili. Il web designer è stato scambiato direttamente e modificato il suo progetto originale 3 o 4 volte, con pochissime modifiche da parte mia.

Il suo commento a me è stato che si sentiva come se l'HTML fosse vivo in quanto poteva modificarlo e quindi vedere immediatamente i cambiamenti sulla sua macchina con dati dinamici. Abbiamo entrambi beneficiato di questo in quanto l'integrazione è prevalentemente automatica.

Codice lato server e Handoff HTML / CSS

Nei progetti passati, ha dovuto trasferire gli sviluppatori HTML e CSS agli sviluppatori Java che avrebbero poi preso il suo codice HTML e CSS e lo avrebbero riscritto completamente utilizzando la tecnologia JSP. Ciò richiederebbe un sacco di tempo e di solito si tradurrebbe in differenze sottili ma importanti nel rendering effettivo delle pagine e nella convalida del validatore W3C.

Nel complesso, siamo entrambi abbastanza contenti di questa tecnica e nelle pagine HTML non ho ancora pagine JSP o codice lato server.

Trappole della tecnica REST / JSON

Forse le più grandi insidie sono quelle che non abbiamo ancora incontrato. Mi aspetto di avere qualche disaccordo con gli sviluppatori Java più esperti che sono stati sottoposti al lavaggio del cervello da ciò che la fondazione Apache e il team di Spring hanno detto loro su come le librerie di tag rendano più facile agli sviluppatori di frontend lavorare con il codice. Mi aspetto che ci sia una curva di apprendimento man mano che questo progetto si espande e assumiamo altri sviluppatori che potrebbero dover disimparare queste tecniche obsolete che, nella mia esperienza, ha reso il lavoro dei progettisti Web più difficile .

Un altro trabocchetto è che il codice JavaScript è diventato molto massiccio. Questo è più un problema forse perché sto usando questa tecnica per la prima volta, e perché abbiamo introdotto un leggero debito tecnico nel lavorare verso una rapida pubblicazione. Forse scegliere un quadro migliore avrebbe aiutato ad alleviare gran parte della maggior parte del codice. A mio parere, nessuno di questi è stato un ostacolo e sono incoraggiato a continuare ad usare questa tecnica ea perfezionare le mie capacità in questo settore.

Vantaggio: è possibile creare altre applicazioni sulla piattaforma

Infine, dovrei menzionare un vantaggio nascosto. Poiché esiste un buon grado di separazione tra i miei servizi Web RESTful e il mio frontend backend, ho anche creato una piattaforma che posso facilmente estendere.

Una delle nostre operazioni, i ragazzi volevano provare un proof of concept in un'altra applicazione, e grazie ai miei servizi RESTful, siamo stati in grado di creare un frontend completamente diverso per l'applicazione per risolvere un problema completamente diverso. La dimostrazione del concetto rapidamente sviluppata usava il proprio HTML, CSS e JavaScript, ma utilizzava i servizi RESTful come back-end e origine dati.

Alla fine, un altro project manager ha visto quello che avevo fatto e divenne subito chiaro che la funzione doveva essere più di una semplice dimostrazione di concept, quindi il suo team l'ha implementata.

Non posso sottolineare abbastanza quanto sia riutilizzabile questa architettura, sia a livello di applicazione che HTML / CSS / JavaScript, e sicuramente ti incoraggerei a provare questo nel tuo prossimo progetto.

È certamente una strategia valida, ma non è un proiettile d'argento.

Pro :

• se fatto bene, le applicazioni sviluppate in questo modo sono molto reattive
• hai una netta separazione tra logica (sul server) e presentazione (sul client); il server non deve preoccuparsi affatto degli aspetti di presentazione dell'applicazione
• utilizzo potenzialmente più efficiente della larghezza di banda della rete (si inviano solo dati non elaborati, nessun testo di presentazione)
• più facile sviluppare interfacce grafiche simili a desktop, dal momento che dipendi meno dal paradigma richiesta / risposta

Contro :

• devi scrivere il tuo codice cliente in Javascript, o un linguaggio che può essere compilato in Javascript, perché è l'unica cosa disponibile in un browser
• l'utilizzo delle risorse sul client potrebbe essere più elevato, quindi l'applicazione potrebbe non funzionare correttamente su dispositivi scadenti (si pensi ai browser per dispositivi mobili ecc.)
• non funzionerà affatto con javascript disabilitato; se ha un sito web pubblico, devi pensare seriamente se sei disposto a correre questo rischio (specialmente se consideri il SEO e l'accessibilità - un approccio javascript-pesante di solito è devastante su questi due fronti)
• un sacco di logica deve essere scritta due volte: una volta sul client e ancora sul server (perché non puoi mai fidarti del client)
• la concorrenza può essere un inferno, quindi è necessario progettare il codice lato client con molta attenzione e prepararsi a tutti i tipi di problemi di concorrenza

È sicuramente possibile e probabilmente incoraggiante come best-practice. Quello che stai proponendo è dividere l'interfaccia utente dalla logica del business, quindi c'è una netta separazione delle preoccupazioni. Questo è veramente buono.

Troppo spesso i framework tentano di confondere le cose e si finisce con un software monolitico in cui l'interfaccia utente, la business logic ei dati sono tutti intrecciati l'uno con l'altro. Ciò rende più difficile la manutenzione e la modifica.

Una volta divisa l'applicazione in 2 parti, è possibile sostituire completamente l'interfaccia utente con qualcos'altro, un programma desktop o un'altra interfaccia utente per dispositivi mobili rispetto ai browser desktop.

I bit complicati che troverai quando fai questo è che un po 'di codice che teoricamente dovrebbe essere nel server sarebbe posizionato meglio sul client - la convalida ad esempio, è più veloce e più reattiva per l'utente per mettere la convalida codice su un modulo sul client piuttosto che colpire il server per verificare, ad esempio, che un campo di testo contenga solo caratteri alfanumerici. Lo stesso vale spesso per i dati e i livelli aziendali. Devi solo prendere decisioni informate e pratiche su quando violare la distinzione tra i livelli.

Uno svantaggio è la necessità di duplicare parte della logica in JavaScript e ASP.net. Questo potrebbe non essere un grosso problema per te a seconda della tua applicazione. Si presenta spesso perché non vuoi chiedere al server di controllare ogni piccola cosa ("È permesso all'utente di premere questo pulsante o selezionare questa opzione in questa situazione?") Ma non vuoi dipendere sul client come l'unico che esegue la convalida poiché l'utente ha il controllo sul client.

Se stai ancora utilizzando Web Form di ASP.NET e vuoi velocizzare le tue applicazioni, ecco cosa dovresti fare:

• Progetta la tua applicazione con SOLID in mente
• Disattiva ViewState su tutte le pagine e i controlli utente

• Non utilizzare i controlli lato server

  <%: VeiwModel.Title% > invece di < asp: Literal id="Title" runat="server" >

• Nel backend, sostituisci il metodo OnInit e fai tutto l'inizializzazione lì:

  override void OnInit (System.EventArgs e) {     CreateViewModel ();     base.OnInit (e); }

• Comprimi tutti i file .css e .js in 1 utilizzando SquishIt

• Caricamento lento delle immagini
• Cache oggetti complessi

Infine, controlla www.porsche.se. Non è un sito dannatamente veloce?