gebruik js vs php
Zelf gebruik ik vaak PHP om HTML te genereren. Het is server-side en je bent niet afhankelijk van de browser. Toch zie ik ook regelmatig dat JavaScript (JS) wordt gebruikt om HTML te genereren.
Bijvoorbeeld, ik wil een menu tonen. Via PHP en een foreach loop creëer ik de divs met daarin de naam van het menu-item. Echter, er zijn ook programmeurs die het anders doen. Die leveren aan een menu-script een JSON string aan met daarin enkel de namen van de menu-items, en vervolgens bouwt dat script dan een menu. De uitkomst is min of meer gelijk, maar waarom zou je voor het een of voor het ander kiezen? Een vergelijkbaar voorbeeld. Ik heb een forum en ik wil een ledenlijst tonen. Zelf zou ik dan gewoon in PHP een foreach loop maken die een tabel genereert met in iedere rij de naam van een lid. Echter, je zou dit ook weer met een script kunnen doen waaraan je in een JSON string enkel de namen van de leden aanlevert. Dat script maakt dan vervolgens de tabel aan.
Wat is nu eigenlijk het wezenlijke verschil om te kiezen om het serverside (PHP) of cliëntside (JS) af te handelen?
Om aan te sluiten op een van je voorbeelden: als een vereniging duizenden leden heeft, is het onhandig om daarvan één grote tabel te tonen. Dat past op geen enkel scherm. Dan bouw je dus al gauw filters en paginering in. En dan komt ook pas die ontwerpbeslissing om de hoek kijken: wáárvoor wordt die tabel gebruikt en wat is in die gebruikscontext de handigste oplossing?
Dat kan ook, maar was niet helemaal mijn vraag.
Jouw voorbeeld is wel een goede. Je hebt dus duizenden leden. Dan kan ik dus op het moment dat ik op "pagina 2" klik ervoor kiezen om de pagina volledig opnieuw in te laden, of ik update de leden via Ajax. Maar waarom het een of juist het ander?
Maar om nog even terug te komen op mijn eerdere voorbeeld (om het even makkelijk te houden). Stel we hebben een menu met 10 items. Ik zou dat dus in z'n geheel via PHP opbouwen (dus de complete HTML genereren), maar er zijn ook programmeurs die een JavaScript-menu gebruiken, en die dus dat menu via JavaScript opbouwen. Waarom zou je voor het een, of juist voor het ander kiezen?
Toevallig heb ik afgelopen weekend met de HTML5 Application Cache zitten spelen. Dáár ligt alvast een deel van je antwoord. Je kunt de complete applicatie cachen op de client. Zelfs offline.
Je stapt dus af van het klassieke request/response-systeem. Een complete webpagina opnieuw laden is eigenlijk gewoon niet efficiënt, zeg nou zelf, als daarin maar één onderdeel moet worden bijgewerkt.
Dat is een afweging. Maar stel je zit op een webshop, en je wilt op een gegeven moment op pagina 25. Je besluit om een dag later verder te gaan kijken. Nu moet je eerst 25 keer klikken om de juiste pagina te bereiken, terwijl je zoder AJAX direct de exacte link had kunnen bookmarken.
Maar nog even naar het voorbeeld van dat menu. Waarom opbouwen via JS of via PHP? Wat zou daarin een overweging kunnen zijn?
Het lijkt me juist eerder dat het mis kan gaan als je met JS werkt. Met een server-side opbouw heb je veel minder kans dat het misgaat. Dus daarom snap ik het niet helemaal. Wel een voordeel is dat je als je via een JSON string informatie doorgeeft en via JS verwerkt, dat je minder data hoeft te versturen ... zou snelheid dan een overweging zijn?
Als je ziet hoeveel 'troep' er verder nog met je pagina meekomt (advertenties, analytics, en weet ik veel wat voor zooi er verder nog bijgefrommeld wordt) dan lijkt de optimalisatie die je noemt me daarbij redelijk in het niet vallen.
Daar komt nog bij dat het tegenwoordig best lastig is om een internet-abonnement af te sluiten met een snelheid van mínder dan 100 Mbps...
Dat zou je inderdaad denken. Maar waarom doen ze het dan wel?
Overigens interessant punt dat je aansnijdt wat betreft snelheid. Houdt dit ook in dat (micro)optimalisatie (denk aan caching en gezipte overdracht) steeds minder belangrijk wordt?
Performance is sowieso altijd een overweging. Je moet er toch niet aan denken dat je tekstverwerker compleet opnieuw geladen moet worden zodra je een wijzing opslaat? Dat geldt dan ook voor veel webapplicaties.
Vroeger gebruikten we JavaScript vooral voor browsers die :hover uit CSS niet of niet volledig ondersteunden.
VRROEGÂÂÂHHH! :)
Ik snap wel wat je bedoelt, maar ervan uitgaande dat het resultaat exact hetzelfde is en er in een bepaald element geen sprake is van interactie of states, waarom zou je dan voor JS of PHP kiezen of vice versa. Waarom zou je een menu met wat divjes in de browser opbouwen via JS in plaats van op de server via PHP?
>> ervan uitgaande dat het resultaat exact hetzelfde is en er in een bepaald element geen sprake is van interactie of states, waarom zou je dan voor JS of PHP kiezen of vice versa.
Dan is er maar één juiste keuze: PHP.
Of geen keuze dus.
Feitelijk is dat dan een keuze tussen HTML + CSS gegenereerd door PHP enerzijds of JavaScript anderzijds.
Ja precies! En waarom is PHP dan de enige juiste keuze?
> steeds minder belangrijk wordt?
In ieder geval wordt micro-optimalisatie steeds minder interessant. Als het dat al was. ;-)
Caching zal belangrijk blijven, maar ik denk wel dat de focus zal verschuiven naar server-side. Bij gegenereerde pagina's valt aan de client-kant weinig te cachen, maar de server kan vaak een heleboel hergebruiken.
Verder moeten we als webbouwers nog wel rekening houden met onze mobiele medemens. De bandbreedtes zijn daar wel weer een stuk kleiner en bovendien heb je beperkingen aan de hoeveelheid data die je maandelijks kunt gebruiken. Zippen en cachen zal voor mobiele platforms dus altijd belangrijk blijven.
Wat betreft server-side caching heb ik wel een mooi voorbeeld: Op mijn werk hadden we vroeger een nood-site. Als we veel bezoekers verwachtten, werd de hele site off-line gehaald en kreeg je alleen maar een statische pagina te zien (die wel elke minuut werd ververst). In principe kan dat, omdat op dat moment vrijwel iedereen toch alleen maar die ene pagina wil zien.
Het probleem zat hem erin dat om die pagina te genereren, elke Apache-worker XML door een XSLT-parser moest halen, en dat kost best veel resources. Om dat te optimaliseren werd het resultaat weliswaar een minuut onthouden, maar dat bleek op drukke momenten nog steeds niet voldoende, en bovendien kwam het zelfs voor dat wanneer je de pagina ververste, je oudere informatie te zien kreeg, omdat je dan toevallig een worker trof die een oudere versie in zijn interne cache had.
Vervolgens heb ik de site onder handen genomen. Ik heb een los script gemaakt dat die XML elke 10 seconden door de XSLT-parser haalt en de gegenereerde HTML in de memcache zet. De Apache-workers hoeven dan alleen nog maar de kant en klare HTML door te schuiven. Het resultaat is een site die actuelere data genereert en die niet meer onderuit gaat wanneer er in een kwartier honderdduizend pageviews worden gedaan.
En om de boel weer enigszins on-topic te trekken: ik had dit ook kunnen oplossen door de XML door te geven aan de browser, die er vervolgens met JS een mooie pagina van kan maken. Echter, de backend-server die de XML genereert had dan in drukke periodes nog steeds duizenden requests per minuut te verwerken gekregen (in plaats van 6 per minuut, zoals nu).
Gewijzigd op 15/01/2015 16:34:02 door Willem vp
Het doet me denken aan VROEGÂÂHHH :)
Toen ik voor het eerst thuis het internet op ging met een modempje. Bliep bliep bliep... :) En als je dan eens iets wilde downloaden van een paar MB was je daar gewoon een paar uur zoet mee. Gek als je daar over nadenkt. Waar zijn we dan over een jaar of 20 vraag je je af. Dan speelt snelhied wellicht geen enkele rol meer. Oooh, konden we maar eens in de toekomst kijken :)
*zucht* die goeie ouwe tijd...
Toen (25 jaar geleden, om precies te zijn) kostte een harddisk nog 10 gulden per megabyte. Een 4TB-schijf waar je vandaag zo'n 150 euro voor betaalt zou met die megabyte-prijs 18151208,64 euro kosten, en dan heb ik nog niet eens inflatie-correctie toegepast. ;-)
Gewijzigd op 15/01/2015 16:43:36 door Willem vp
(Wanneer krijgt het forum ook een duimknop?)
:-)