Il mio lavoro principale è realizzare applicazioni HTML. Con ciò intendo le applicazioni di tipo CRUD utilizzate internamente con molte visualizzazioni di griglia modificabili, caselle di testo, menu a discesa, ecc. Attualmente stiamo utilizzando i moduli web ASP.NET, che fanno il loro lavoro, ma le prestazioni sono per lo più tristi e abbastanza spesso tu saltare attraverso i cerchi per ottenere ciò di cui hai bisogno. Cerchi che sono appesi al soffitto e incendiati.
Quindi mi chiedo se forse sarebbe una buona idea spostare tutta l'interfaccia utente sul lato JavaScript. Sviluppa un solido set di controlli riutilizzabili che sono specificamente adattati alle nostre esigenze e scambia dati solo con il server. Sì, mi piace il paradigma "control" (alias "widget"), abbastanza adatto a tali applicazioni. Quindi sul lato server avremmo ancora un layout di base simile al nostro attuale markup ASPX, ma che verrebbe quindi inviato al client una sola volta e la parte Javascript si occuperebbe di tutti i successivi aggiornamenti dell'interfaccia utente.
Il problema è che non l'ho mai fatto prima e non ho mai visto nessuno farlo, quindi non so quali sarebbero i problemi. In particolare, sono preoccupato per:
- Performance ancora. Il benchmarking mostra che attualmente il ritardo principale è sul lato client, quando il browser tenta di eseguire nuovamente il rendering della maggior parte della pagina dopo un aggiornamento AJAX. Il markup generato dai webform ASP.NET dà un nuovo significato alla parola "web", e i ricchi controlli Devexpress aggiungono il proprio livello di complessità Javascript. Ma sarebbe più veloce ricalcolare tutte le modifiche necessarie sul lato Javascript e quindi aggiornare solo ciò che deve essere aggiornato? Si noti che sto parlando di moduli che hanno diverse visualizzazioni di griglia modificabili, molte caselle di testo, molti menu a discesa ciascuno con dentro mezzo mezzo di elementi filtrabili, ecc.
- Facilità di sviluppo . Ora ci sarebbe molto più Javascript e probabilmente si mescolerebbe con il markup HTML della pagina. Questo o qualche tipo di nuovo motore di visualizzazione dovrebbe essere prodotto. Intellisense per Javascript è anche molto peggio che per il codice C # e, a causa della natura dinamica di Javascript, non ci si può aspettare che migliori molto. Le pratiche di codifica possono migliorarlo un po ', ma non di molto. Inoltre, la maggior parte dei nostri sviluppatori sono principalmente sviluppatori C #, quindi ci saranno alcune curve di apprendimento ed errori iniziali.
- Sicurezza . Molti controlli di sicurezza dovranno essere effettuati due volte (lato server e lato UI) e il lato server di elaborazione dati dovrà includerne molti di più. Attualmente, se si imposta una casella di testo in sola lettura sul lato server, è possibile dipendere dal suo valore che non cambia attraverso il roundtrip client. Il framework ha già abbastanza codice per garantirlo (attraverso la crittografia viewstate). Con l'approccio basato solo sui dati, diventa più difficile, perché devi controllare manualmente tutto. D'altra parte, forse le falle di sicurezza saranno più facili da individuare, perché avrai solo dati di cui preoccuparti.
Tutto sommato, questo risolverà i nostri problemi o li peggiorerà? Qualcuno ha mai provato questo, e quali sono stati i risultati? Ci sono delle strutture là fuori che aiutano in questo tipo di attività (a parte jQuery ed equivalenti morali)?
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.Stai descrivendo esattamente cos'è ASP.NET, il che mi dice che probabilmente non lo stai usando correttamente. :) Nelle applicazioni ASP.NET se si inseriscono componenti all'interno dei pannelli di aggiornamento, la libreria javascript ASP.NET eseguirà postback asincroni sul lato server e eseguirà nuovamente il rendering dei componenti specificati.