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


35

Vengo da un background di moduli ASP.NET e ho trovato la codifica lato server molto potente in passato. Più recentemente, tuttavia, ho voluto eliminare gradualmente il codice lato server del front-end e sostituirlo con puro HTML / JavaScript, che accede ai dati tramite i servizi Web JSON. Non ho esperienza reale in questo, e quindi vorrei sapere se questo è un modello provato e testato. Inoltre, quali sono le insidie ​​che lo circondano?

Trovo molto utili i controlli utente ASP.NET, quindi vorrei mantenere la teoria dietro di essa memorizzando i modelli di markup in file HTML separati sul server. Questi verranno recuperati e utilizzati rispettivamente tramite jQuery AJAX e il plug-in dei modelli HTML jQuery.

Qualsiasi input sarà estremamente apprezzato.

PS Ci scusiamo per la domanda noob, ma questo tipo di architettura Web è ciò che viene chiamato web-2.0 o sono completamente fuori strada?


1
Vuoi sostituire i controlli asp.net con HTML / JavaScript o vuoi esporre l'intera logica aziendale (validazione, ecc.) Al front-end?
šljaker,

1
Buona domanda. Sto pensando di fare il frontend solo in html / javascript per schiarire la pagina in modo che sia più veloce su cellulari / pad. Quindi probabilmente sostituisci solo i controlli asp.net. Tutte le chiamate al server tramite un servizio web, quindi il servizio wcf dovrebbe in qualche modo gestire la convalida, ecc. Pensi che sia possibile?
hofnarwillie,


@hofnarwillie per la convalida, penso che dovresti usare il lato client JS.
smwikipedia,

1
@smwikipedia Grazie, ma trovo che la convalida lato client debba essere utilizzata solo per facilitare gli utenti. La vera convalida dovrebbe essere eseguita sul lato server. La convalida lato client rende la tua app intuitiva, ma la convalida lato server garantisce sicurezza e validità, poiché la convalida lato client può essere facilmente disattivata.
hofnarwillie,

Risposte:


31

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

Il progetto è più piccolo con solo me stesso e un web designer, ed entrambi riteniamo che questo metodo ci abbia aiutato a lavorare molto più velocemente e ad 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 restrizioni in HTML e CSS senza dover guadare innumerevoli linee di JSP, tag taglib e altri lato server il markup che ci è stato detto per anni dovrebbe rendere la vita di uno sviluppatore front-end molto più semplice.

Senza tutto il markup sul lato server, siamo stati più agili. Il web designer ha sostituito e rivisto direttamente il suo progetto originale 3 o 4 volte, con pochissime modifiche da parte mia.

Il suo commento per me era che sentiva che l'HTML era vivo in quanto poteva modificarlo e quindi vedere immediatamente le modifiche sulla sua macchina con dati dinamici. Ne abbiamo entrambi i benefici in quanto l'integrazione è per lo più automatica.

Codici lato server e handoff HTML / CSS

In progetti passati, ha dovuto consegnare HTML e CSS a sviluppatori Java che avrebbero poi preso il suo HTML e CSS e riscritto completamente usando la tecnologia JSP. Ciò richiederebbe molto tempo e di solito comporterebbe differenze sottili ma importanti nel rendering effettivo delle pagine, nonché la sua convalida nel validatore W3C.

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

Insidie ​​della tecnica REST / JSON

Forse le insidie ​​più grandi sono quelle che non abbiamo ancora incontrato. Mi aspetto pienamente di essere in disaccordo con gli sviluppatori Java più esperti a cui è stato fatto il lavaggio del cervello da ciò che la fondazione Apache e il team di Spring hanno detto loro su come le librerie di tag rendono più semplice per gli sviluppatori frontend lavorare con il codice. Mi aspetto pienamente che ci sarà una curva di apprendimento mentre questo progetto si espande e assumiamo più sviluppatori che potrebbero dover disimparare queste tecniche obsolete che, nella mia esperienza, hanno reso il lavoro dei progettisti Web più difficile .

Un altro inconveniente è 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 un rilascio rapido. Forse la scelta di un framework migliore avrebbe contribuito ad alleviare gran parte del codice. A mio avviso, nulla di tutto questo è stato uno spettacolo, e sono incoraggiato a continuare a utilizzare questa tecnica e affinare le mie capacità in questo settore.

Vantaggio: altre applicazioni possono essere costruite sulla piattaforma

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

Una delle nostre operazioni ragazzi voleva provare una prova di concetto in un'altra applicazione e, grazie ai miei servizi RESTful, siamo stati in grado di creare un frontend completamente diverso all'applicazione per risolvere un problema completamente diverso. La dimostrazione del concetto sviluppata rapidamente utilizzava proprio HTML, CSS e JavaScript, ma utilizzava i servizi RESTful come backend e origine dati.

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

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


2
Grazie. Questo risponde completamente alla mia domanda. Apprezzo il tempo impiegato per dare una risposta chiara e concisa. +1
hofnarwillie

2
Lavoro in un'azienda in cui l'intera applicazione Web interna è html / js solo con servizi di backend che servono dati con codifica json. Funziona davvero bene ed è molto più veloce per creare nuove app usando questo modello, e perché gli sviluppatori backend e fronted lavorano in parallelo. Dovresti davvero provare questo.
nohros,

@ jmort253 Mille grazie per l'ottima risposta. Stavo pensando esattamente alla stessa architettura e la tua pratica mi rende sicuro di seguirla. Ho fatto domande simili qui: stackoverflow.com/questions/33934101/… e qui: stackoverflow.com/questions/34020543/… .
smwikipedia,

12

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

Pro :

  • se fatto bene, le applicazioni sviluppate in questo modo sono molto reattive
  • hai una chiara 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, nessuna piastra di presentazione)
  • più facile da sviluppare GUI simili a desktop, poiché sei meno dipendente dal paradigma di richiesta / risposta

Contro :

  • devi scrivere il tuo codice client in Javascript, o una lingua che può essere compilata in Javascript, perché questa è l'unica cosa disponibile in un browser
  • l'utilizzo delle risorse sul client potrebbe essere maggiore, quindi l'applicazione potrebbe non funzionare bene su dispositivi scadenti (si pensi a browser mobili ecc.)
  • non funzionerà affatto con javascript disabilitato; se si tratta di un sito Web rivolto al pubblico, è necessario riflettere seriamente se si è disposti a correre questo rischio (soprattutto se si considera la SEO e l'accessibilità - un approccio pesantemente javascript di solito è devastante su questi due fronti)
  • molta logica deve essere scritta due volte: una volta sul client e ancora una volta sul server (perché non si può mai fidare del client)
  • la concorrenza può essere un inferno, quindi è necessario progettare il codice lato client con molta attenzione ed essere pronti a risolvere tutti i tipi di problemi di concorrenza

2
Grazie. Puoi fare un esempio dei problemi di concorrenza che sarebbero causati da questo modello?
hofnarwillie,

3
Esempio: se l'utente fa clic su Vota in alto e quindi fa rapidamente clic su Vota in basso prima del termine della chiamata del server di voto in alto, quanti voti ci sono?
JBR Wilkinson,

@JBRWilkinson Flag booleano che verifica lo stato, il timeout o l'intervallo?
Alper Turan,

1

È sicuramente possibile e probabilmente incoraggiabile come best practice. Quello che stai proponendo è quello di dividere l'interfaccia utente dalla logica aziendale in modo che vi sia una netta separazione delle preoccupazioni. Questo è veramente buono.

Troppo spesso i framework che abbiamo provato a confondere le cose insieme e si finisce con un pezzo monolitico di software in cui l'interfaccia utente, la logica aziendale e i dati sono tutti intrecciati tra loro. Ciò rende più difficile la manutenzione e la modifica.

Dopo aver diviso l'applicazione in 2 parti, puoi 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 difficili che troverai quando fai questo è che un po 'di codice che teoricamente dovrebbe essere nel server sarebbe meglio posizionato sul client - la convalida, ad esempio, è più veloce e più reattiva per l'utente di mettere il codice di validazione su un modulo sul client piuttosto che colpire il server per verificare, diciamo, 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.


1

Un aspetto negativo è che è necessario 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 si desidera chiedere al server di controllare ogni piccola cosa ("L'utente è autorizzato a premere questo pulsante o selezionare questa opzione in questa situazione?"), Ma non si vuole dipendere sul client come l'unico che esegue la convalida poiché l'utente ha il controllo sul client.


0

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

  • Progetta la tua applicazione pensando a SOLID
  • Disabilita ViewStatesu 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, sovrascrivi il metodo OnInit ed esegui tutte le inizializzazioni lì:

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

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

  • Immagini a carico lento
  • Cache oggetti complessi

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


Questo è davvero un sito veloce. Grazie mille per l'input. Molto apprezzato.
hofnarwillie,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.