[pelmered]

Det kommer troligen inte märkas någon större skillnad för användaren eller för belastningen på din server om det inte är stora mängder data med massa fält.

Är det en hel sida tycker jag du ska generera HTML på servern.
Är det delar eller enskilda fält beror det på hur många olika fält är det som ska uppdateras. Hur många är det?

[jayzee]

Det är en meddelande-sida, där man har ett antal flikar (inkorg, skickat, skicka nytt, ...). Antalet meddelanden kan vara svårt att förutse men så som det är nu funderar jag på att begränsa det till 20st.

[dAEk]

Låt servern svara med endast data eftersom:

• det blir lättare att återanvända kod och du får bättre struktur i projektet. Låter du servern skicka med markup är du låst till t.ex en ul-lista om du nu returnerar en sån. I framtiden kanske samma data ska användas på en annan sida men märkas upp på ett annat sätt, och då vill man ju helst inte kopiera den gamla funktionen och ändra Html:n eller lägga in fula if-elses i den befintliga funktionen.
  
  
• underhållsarbetet blir lättare. Ingen tycker om att leta efter och ändra Html-kod i server-kod.
  
  
• det blir mindre overhead i svaren. Svarar servern med markup och funktionen anropas 100 gånger skickas markuppen 99 gånger i onödan. Oftast är det här knappast ett problem men ändå.

Det blir lite mer jobb för webbläsarna men jag tycker att fördelarna är fler och väger tyngre än nackdelarna.

[Syke]

Jag skulle nog köra JSON-data från servern som sedan läggs in i html-template (ex. mustache) mha javascript. Mina $0.02.

[jayzee]

Tack grabbar, vi tänker i samma bana. JSON is a way to go.

[pelmered]

Ursprungligen postat av dAEk

Låt servern svara med endast data eftersom:

det blir lättare att återanvända kod och du får bättre struktur i projektet. Låter du servern skicka med markup är du låst till t.ex en ul-lista om du nu returnerar en sån. I framtiden kanske samma data ska användas på en annan sida men märkas upp på ett annat sätt, och då vill man ju helst inte kopiera den gamla funktionen och ändra Html:n eller lägga in fula if-elses i den befintliga funktionen.


underhållsarbetet blir lättare. Ingen tycker om att leta efter och ändra Html-kod i server-kod.

I beg to differ.
Jag skulle säga att det är väldigt mycket enklare att få bra struktur på server side-genereringen än om man ska hantera massa logik med JavaScript. JavaScript-kod är i min mening mycket svårare att strukturera, felsöka och underhålla. Därför tycker jag inte man ska ha för mycket logik där om det inte finns en uppenbar vinst med det(vilket jag är osäker på att det finns i det här fallet).

Gör man dessutom någon form av template där man stoppar in datan får man bra struktur med separering av data och och markupen.

Ursprungligen postat av dAEk

det blir mindre overhead i svaren. Svarar servern med markup och funktionen anropas 100 gånger skickas markuppen 99 gånger i onödan. Oftast är det här knappast ett problem men ändå.


Det blir lite mer jobb för webbläsarna men jag tycker att fördelarna är fler och väger tyngre än nackdelarna.

Jag tvivlar att på att det blir någon större skillnad på belastningen. Det som kostar prestanda är generellt sett att hämta datan från databasen(eller likande), inte att generera HTML-koden. Vid stora trafikvolymer är det väl nog endast på bandbreddsanvändningen som man skulle märka någon skillnad.
Med den här lösningen lägger du istället över mycket av beräkningarna på klienten så användare med långsammare datorer eller webbläsare med långsamma JavaScriptmotorer vilket mycket väl kommer ge en märkbar prestandaförsämring.

[jayzee]

Ursprungligen postat av ITisGood.se

I beg to differ.
Jag tvivlar att på att det blir någon större skillnad på belastningen. Det som kostar prestanda är generellt sett att hämta datan från databasen(eller likande), inte att generera HTML-koden.

HTML koden genereras utifrån resultaten från databasen.

[randis]

Jag håller med ITisGood till 100%. Det finns inget som hindrar dig från att jobba med View separat på servern även vid ett Ajax anrop. Jag tycker inte javascript ska användas för layout. Det är inte vad det är avsett för i min mening. PHP/Asp däremot är avsett för att generera HTML kod dynamiskt.

Du har ju sannolikt en template för hur sidan ska se ut som används av serversidan redan. Varför man då ska göra ytterligare en template för klientsidan att använda förstår jag inte. Det om något skapar ju problem vid uppdateringar.

Om inkorg visas som standard när man laddar "mina meddelanden" så gissar jag att inkorgen inkluderas redan på serversidan, och att det inte är förrän man byter till "skickat" eller annan flik i "mina meddelanden" som den utnyttjar Ajax. Sålunda har du ju redan allt på serversidan som krävs för att generera den layout du vill ha.

[dAEk]

Ursprungligen postat av ITisGood.se

Jag tvivlar att på att det blir någon större skillnad på belastningen.

Utan att veta något om själva mallen borde man väl inte anta någonting? Det skulle kunna vara en enkel u-lista eller en komplex tabell med diverse olika klasser för klientbeteende (sortable, draggable t.ex.).

Extra markup påverkar responsiviteten och det behövs inte mycket data förrän det blir påtagligt. Det är ju en av anledningarna till att man hellre använder JSON istället för XML.

[randis]

Med dagens uppkopplingar anser jag inte att det är försvarbart att optimera så. om det handlar om 0.5 - 1kb så är den hastighetsförlusten marginell jämfört med vad själva httpRequesten och svaret tar att generera. Men om vi pratar om stora datasamlingar med 50000 rader kan man säkert göra en noterbar vinst i nedladdningstid genom att bara svara med någon typ av ren data. Men då är det frågan hur snabbt klienten kan bygga upp sidan. Speciellt om den ska använda en separat template.

Alla webbläsare är inte så snabba som Chrome på att hantera Javascript.