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

[dAEk]

Hmm, vi verkar inte vara på samma bana. Jag försöker förklara lite mer konkret.

Ursprungligen postat av 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.

Mitt förslag var aldrig att skapa en ny mall för Ajax-anropen utan att använda den befintliga Html-koden som levereras av servern när man går in på sidan. Låt oss säga att vi har sidan /messages, i Html:n finns fliksystemet och om vi väljer ut en av flikarna skulle innehållet i den kunna se ut såhär:

<h3>Skickade meddelanden</h3>
<ul id="sent-messages">
	<li class="template">
		<span class="date"></span>
		<span class="title"></span>
		[...]
	</li>
</ul>

Man kan också tänka sig att servern skickar med dom n senaste posterna när man går in på /messages om man vill använda progressive enhancement för SEO-syften till exempel. Jag har inte sett någon nämna det i den här tråden men det är hur som helst möjligt.

För att fylla sidan med meddelanden anropar vi servern med ett Ajax-anrop. När svaret levererats fyller vi vyn med innehåll och det gör vi genom att klona templaten, loopa igenom svaret och för varje post använder vi klonen genom att lägga till innehåll i respektive placeholder (.date, .title etc). Sedan lägger vi till klonen i en container som inte är kopplad till DOM-trädet. Först när loopen är klar lägger vi till containern på sidan. Ja, klienterna får jobba lite mer. Fördelarna är som jag skrev förut att man kan ändra struktur i vyerna, använda olika templates på olika ställen men fortsätta använda samma metod som hämtar data utan att behöva ändra i nån logik. Den här lösningen passar kanske inte för alla scenarion men det är det inte mycket som gör. Så länge det inte finns några särskilda krav tycker jag att det här är en bra lösning.

Ursprungligen postat av randis

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.

Servern hanterar inte datan förutom att göra den till JSON. Använder man en JSON-serialiserare behöver man inte tänka på den biten. Man kan låta en Html-sida, Flash, Silverlight eller ngn annan form av app anropa servern om den bara returnerar data. Det är så jag vill ha det. Bakas Html in i svaret blir det mycket krångligare att hantera det. Antar att man kan säga att jag ser Ajax-metoderna som en WebService där det brukar vara upp till frågeställaren att bestämma hur svaret ska formateras/presenteras.

Ursprungligen postat av randis

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.

Jag ser Ajax som ett sätt att transportera data och gärna så koncist som möjligt så ja, det stämmer. Någon tipsade om ett Mustache tidigare och det såg ju ut att vara smidigt.

Ursprungligen postat av randis

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

Se ovan (progressive enhancement). Det är inte ett problem.

[randis]

Jag köper det mesta du skriver, även om det inte passar mitt sätt så bra. Liknelsen med en web service var bra och kommer göra att jag tänker en gång till innan jag väljer tillvägagångssätt nästa gång.

När det gäller exemplet med almanackan håller jag inte med dig, men jag vet inte om jag orkar utveckal scenariot så det är förståeligt utan att använda bilder att förklara med. Det är väl just det scenariot som gjort att jag generellt låter PHP baka ihop hela kakan åt mig och javascriptet får bara byta ut innehållet i diven. Motsvarande jquery.load() helt enkelt.

[dAEk]

Den biten var jag inte helt med på verkar det som. Det finns säkert scenarion där det är bättre att baka ihop Html:n i svaret men jag kommer troligen göra som jag brukar ändå.

[linusoleander]

icanhazjs.com

Ursprungligen postat av icanhazjs

Simple & powerful client-side templating for jQuery or Zepto.js