Tidigare har jag summariskt sammanfattat mitt utsiktsfönster mot it-branschen med “data kommer in, lagras och plockas ut för presentation”. Denna gång kommer några funderingar runt den sista delen, presentationen.
Före webbens intåg var det enkelt. Alternativen var få. Teckenerans listor och formulär var endimensionell både till form och färg. På terminalens tid var antalet rader 24 och varje rad hade 80 tecken. Därav uttrycket 24×80 som alla ärrade kämpar från förr så väl kommer ihåg. Presentera uppgifter med begränsade tekniska möjligheter ingick i utvecklarens vardag. Med webben kom en förändring. Mångfalden av möjligheter beträffande utseende har medfört en delning av arbetsuppgifter. En specialisering har utvecklats där öga för det visuella är central. Det som tidigare ingick i utvecklarens ansvarsområde har blivit ett eget kunskapsgebit, designerns.
Gränsdragningens svårigheter mellan olika kunskapsområden har jag tidigare berört. Konstigheter som uppkommer när oklarheter råder beträffande uppdelning mellan utvecklare och applikationsspecialister. Skiljelinjen mellan utvecklare och designers är inte heller problemfri. Ur min erfarenhetsbank plockar jag följande. Några websidor skulle få en ny modernare look. Från mitt utvecklarperspektiv ville jag ha färdiga komponenter för de templates som skickades ut till användarens browser. Något som designern inte accepterade. Naturligtvis ville han ha full kontroll över både html och css. Detta dilemma återkommer i många frameworks. Talrika är exemplen där kod blandas med html. Vanligt är också lager som läggs ovanpå html. Orsaken är naturligtvis begränsa skrivandet men vad som tjänas i ena ändan förloras i en klar uppdelning. Min uppfattning är att kod och html/css ska separeras helt. Html ska vara ren från kod och i koden ska ingen html genereras. Html och css är designerns område och utvecklarens uppgift blir att förse gränssnittet med dynamiska uppgifter.
När hela branschen verkar samlas kring html5 så är utvecklarens arbetsredskap i clientdelen javascript. Ett språk som väcker blandade känslor. Attackerna mot språket har varit många. Google var tidigt ute med sitt GWT där utvecklaren jobbar med javakod som sedan kompileras till javascript. Dart är deras senaste bidrag. Frågor som infinner sig är om övriga browsertillverkare nappar och om en kritisk massa av utvecklare är beredda att lämna javascript. Ett annorlunda grepp har tagits med coffescript. Där är siktet inställt på javascripts många gånger svåra syntax. En uppsjö av javascriptbibliotek finns också. En viktig beståndsdel i dessa är att överbrygga olikheter i implementationen av javascript mellan olika browsers.
Webapplikationer dominerades länge av dokument med hela htmlsidor och länkar. Med ajaxanropen kom möjligheten att uppdatera delar av sidan. Ett sätt att utnyttja denna möjlighet fullt ut är det som går under namnet SPA, Single Page Application eller Single Page Interface (SPI). Ett sätt att strukturera applikationen och fördela uppgifterna mellan client- och serverdelarna. Applikationens statiska delar laddas ner direkt och de dynamiska delarna hämtas via ajaxanrop. Det sker inga traditionella requests av hela sidor. Med denna uppdelning blir “binding” mellan designerns visuella komponenter över ajaxanropens transport till backends lagringsfunktion något centralt. Här har en ny typ av javascriptframework börjat dyka upp för att underlätta struktureringen av clientdelen. Backbone och Ember är några exempel. Detta var några funderingar om vad som rör sig i de tekniska kulisserna bakom presentationsskiktet.