Concettualmente, l'app web a pagina singola è più efficiente dell'app Web che carica pezzi della pagina per ogni pagina? [chiuso]

Naviga le tue risposte
0

Ho cercato molto, ma nessuno sembra averlo spiegato, né dato un esempio appropriato.

Ho una pagina come questa:

IlmioteamdicechedesideraprogettareilcodiceinmodotalechelesezioniTitle,MenueFootersianoconservateinfileHTMLseparatiedisponganodifileJSPseparatiperognipagina,incuiognifileJSPcaricadinamicamenteifiletitle.html,menu.htmlefooter.htmlutilizzandoJQuery.

IlmiosuggerimentoèstatoquellodiutilizzareunsingolofileJSP/HTMLchegiàcontieneTitle,MenueFooter,ecaricareilcontenutodiCenterinmododinamico(apppersingolapagina).

Hotredomande:
1.Perun'appWebchedeveutilizzaremenolarghezzadibandadellaretepossibile,èpreferibileutilizzareunapproccioperappapaginasingolaol'approcciodicaricamentomultiplodiunapagina?Interminipercentuali,sideterminerebbeungrandecambiamentonellalarghezzadibandaseTitlecontenessesolounlogoeuntestodipiccolomarchioeMenueFootercontenesserosolotestoestili.

  • Se il contenuto deve essere caricato dinamicamente in una pagina, poiché frame è deprecato e ho sentito che iframe non è incoraggiato, è un ordinario div l'opzione migliore per caricare Center contenuto o Title , Menu , Footer ecc. O c'è un modo migliore di caricarlo in modo che funzioni anche in IE ?

  • Quando le pagine vengono suddivise come title.html , menu.html ecc., devono contenere le pagine <html>' and tags or can they just contain the necessary 's? Do the loaded HTML 'ereditano le proprietà della pagina padre?

    • posta Nav 16.01.2015 - 11:50
    fonte

    3 risposte

    2

    Fondamentalmente, trovo molto utile mantenere il "titolo", "menu" e "piè di pagina" in file indipendenti.

    Quello che mi chiedo veramente è: perché non li metti insieme sul lato server ???

    <%@include file="title.jsp" %> <%@include file="menu.jsp" %> <%@include file="footer.jsp" %>

    Non preoccuparti della larghezza di banda

    La differenza tra le due soluzioni sarà trascurabile e non mi preoccuperei. La maggior parte dei browser carica i file e li recupera solo una volta. Avere una foto sul tuo sito web consumerebbe molta più larghezza di banda, quindi evita qualsiasi immagine. Vuoi salvare bandwitdh giusto? ...stavo solo scherzando. Non è solo un posto di cui preoccuparsi. Bandwitdh è economico.

    Ci sono cose molto più importanti di cui preoccuparsi

    È sicuro?

    Più javascript hai sul tuo sito, più probabilmente le cose possono andare storte. Con la grande varietà di browser / SO / dispositivi, devi stare attento! Se il tuo javascript si rompe da qualche parte, a causa tua o di una dipendenza, potrebbe causare che nulla funzioni più. ... e i tuoi utenti non saranno felici se la navigazione sul tuo sito non funziona più.

    Tenendo conto di ciò, la tua soluzione è più soggetta a errori

    È webby?

    Sai, pagine di bookmarking? Storia? Pagina precedente? Condividi un link? ;) ... con caricamento dinamico, non ottieni tutte queste cose ... o ci sono un sacco di lavoro extra e fonti di bug.

    La tua soluzione non lo fornisce.

    È gestibile?

    ... sai, facile da leggere / capire / cambiare. Personalmente, trovo più semplice pubblicare pagine complete con collegamenti normali piuttosto che comprendere la navigazione javascripted. I miei 2 centesimi.

    Penso che la tua strada sia più complicata

    Le app web a pagina singola sono un concetto alla moda, ma non tutto ciò che è nuovo e lucente è meglio delle cose buone.

    L'esecuzione della "fusione" sul lato server presenta diversi vantaggi

    • È semplice
    • È facile da capire
    • Non si romperà mai sul client perché non dipende da JavaScript
    • È utile per SEO perché i crawler possono indicizzarti facilmente
    • Le persone possono "aggiungere un segnalibro" alle pagine e così via, lo sai
    • La pagina è completamente caricata in una singola richiesta
    risposta data 16.01.2015 - 16:57
    fonte
    3

    Sarebbe interessante sapere cosa pensava la tua squadra sul tuo suggerimento. Penso che abbia molto merito. Per rispondere alle tue domande.

    1. Larghezza di banda, per entrambe le opzioni direi che il caching sul browser dell'utente finale o tramite un ADN o CDN risolverebbe questo problema per voi. Se un'applicazione web sta ottenendo tre file: Titolo, Menu e Piè di pagina, che non cambiano, questi possono essere memorizzati nella cache. Per entrambi ci sarà il colpo iniziale mentre tutto è pronto per la prima volta.
    2. Se usi jQuery, i metodi AJAX al suo interno dovrebbero consentire di scrivere contenuti in qualsiasi tag che scegli. I DIV dovrebbero andare bene.
    3. I file inclusi che fanno parte di una pagina Web non dovrebbero avere e tag, altrimenti avrai HTML non valido nella pagina finale.
    risposta data 16.01.2015 - 12:26
    fonte
    1

    1. Sì, ma la maggior parte del browser ha già memorizzato nella cache cose come image / css / js, quindi il risparmio di larghezza di banda non ti farebbe impazzire, ma ancora nessun bip video e meno richiesta è piacevole avere

    2. iframe ha un posto, ma penso che per il tuo caso, AJAX sia il migliore. c'è un'altra tecnica come usare knockout in modo che il server invii solo JSon (invece di una vista parziale) e successivamente verrà reso in html per knockout.

    3. se non vuoi usare tag html iframe non è necessario.

    risposta data 16.01.2015 - 12:24
    fonte

    Leggi altre domande sui tag

    Sviluppo della sincronizzazione "reale" [chiusa] tempo di esecuzione di nested mentre si esegue il ciclo all'interno di loop