[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.

[dAEk]

Ursprungligen postat av randis

Med dagens uppkopplingar anser jag inte att det är försvarbart att optimera så.

Blir det snabbare är det förstås trevligt men det är inte därför man gör på det sättet.

Ursprungligen postat av randis

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

Nä, och de är heller inte lika långsamma som den långsammaste heller.

Båda sätten funkar och vilken väg man väljer beror på hur man vill jobba. För- och nackdelar finns alltid.

[randis]

Vad är det mer specifikt du syftar på med responsivitet då?

[dAEk]

I det här fallet: tiden det tar för klienten att läsa in data.

[randis]

Ja man får väl väga de 100-delar man tjänar på ett normalstort dokument jämfört med enkelheten att underhålla och införa ändringar när man har det med samma mallar som övriga siten.

Vad du inför genom att låta javascript hantera data är ytterligare än felkälla då du först ska låta serversidan hantera och formater datan, och sedan ska den hanteras ytterligare en gång på klienten med javascript.

Jag kan inte föreställa mig när JSON-data innebär fördelar när innehållet i en hel div ska bytas ut. Ett tu tre vill du ha en flik som heter almanacka eller något som inte passar med de satta UL-listorna med satta klasser. Då måste du arbeta på flera ställen istället för att bara skapa en ny controller och template för serversidan som genererar hela innehållet åt dig. Nya javascript och jobbig logik på klientsidan behövs inte. Bara en ny flik som gör en korrekt httprequest behövs.

Du skapar dessutom möjligheter för de som inte har javascript att komma åt sidan genom att göre en include på serversidan.

JSON-data har helt klart användningsområden det med.