Tillfälligheter, ordet får karaktärisera mitt val att öppna dörren till databranschen och dess kodverkstad i mitten av 80-talet. När jag gräver i minnet hittar jag ingen bättre beskrivning för mitt beslut. Ordet strukturering poppar också upp. En ständig följeslagare sedan inträdet i kodandets labyrinter med utbildningens JSP-strukturer. Få ordning på koden genom uppdelning i mindre block. Frågor som infinner sig är varför och hur? Första frågan är lättare att besvara. Kod kan vara svår att följa och förstå. Genom uppdelning i mindre enheter så underlättas förståelsen. Viktigt om programvaran ska underhållas, rättas eller tillföras nya funktioner. Här vill jag också inflika att kod ska vara vacker. Det finns något tilltalande i enkelheten. Aha-upplevelsens skönhet. Hur uppdelningen ska göras är däremot inte lika självklar. Från mitten av 80-talet har jag kunnat följa många sidospår och återvändsgränder men också trendbrott.
Då i mitten av 80-talet var all datorkraft centraliserad. Alla program exekverades i en centralt placerad dator och därifrån skickades en dataström till dåtidens desktop, terminaler. IBM:s minidator S/38, som senare blev AS/400, var den miljö som gällde för mig. Uppdelning i kodblock var inte självklar. Den hade sitt pris sas det, försämrad prestanda. I diskussionen om struktureringen urskiljde jag två olika linjer. Först hade vi uppfattningen att program alltid genomlöper vissa faser. Koden grupperades efter dessa cykler. Operationer som var nödvändiga innan användargränssnittet presenteras samlades i ett block och fasen därefter utgjorde ett annat block. Den andra idén var händelsestyrning. Lyfta fram användardialogen. Låta den bli synlig i koden. Försök med standardisering gjordes också. Programpaket som med färdiga programblock lyfte bort detaljer. Programmeringen skulle gå snabbare och betala de kostsamma paketen. Synon och Asset är namn som dyker upp. Lovvärda försök men som det visade sig en återvändsgränd då användargränssnittet var teckenbaserat. Åttio tecken på 24 rader.
PC:ns intåg rörde om i grytan. Ett verkligt trendbrott. Till en början var de dyra. En statuspryl för chefspersonerna. Men med fallande priser fanns de snart på alla skrivbord. Hur skulle denna decentraliserade datorkraft tas tillvara? Med PC:ns grafikkort där pixlar var adresserbara var ett helt annat och mera tilltalande användargränssnitt möjligt. MicroSoft med sitt Windows firade stora triumfer. Frågan om strukturering och uppdelning av koden fick ställas på nytt. Nya förutsättningar gällde. Vad skulle hanteras centralt och vilken roll skulle tilldelas datorkraften på skrivbordet?
Från centralt håll brottades man med ett olösligt problem. Hur behålla den centrala kontrollen men utnyttja PC:s möjligheter beträffande användargränssnittet. Kommunikationen med klienten på skrivbordet var problemet. Försöken var många. Befintlig dataström omvandlades på en rad olika sätt för att utnyttja grafikens möjligheter. Vi har också försök med egna kommunikationsgränssnitt med allt var halvmesyrer, återvändsgränder. Den centrala lösningen hade gått in i väggen.
Lägga all kod lokalt, decentraliserat i PC:n, var inte heller problemfritt. Lokala enanvändarsystem fungerade bra men om flera användare skulle dela på samma uppgifter så sneglades åter på centrala lösningar. Gemensam server för lagring. Ett annat problem med decentraliserade lösningar var administrationen. När varje klient hade sin egen installation krävdes många timmar för att hålla ordning på alla klienter. Inte heller den decentraliserade lösningen var tillfredsställande.
En lösning som överbryggade svårigheterna fanns i protokollet http. På klientens förfrågan svarade den centrala servern med en html-sida. Från serversidan sett var kommunikationsproblemet löst. Kontrollen över koden kunde ligga kvar centralt. På klientsidan svarade standardiserade browsers för att omvandla html-sidan till en tilltalande användaryta. Netscape var tidigt ute och dominerade browsermarknaden men krossades av Microsofts penningmuskler. Firefox och Chrome är numera de två stora. Automatiska uppdateringar var svaret på administrationsproblemet. På serversidan får strukturering av koden enligt MVC-modellen stort genomslag. Bokstavskombinationen MVC står för model-view-controller. Koden delas upp i tre huvuddelar. Modellen står för den variabla datadelen medan view-delen är användargränssnittet. Controllern håller ihop det hela.
Det fanns mer att hämta i klientdelen. Än en gång flyttas fokus. Programmeringsspråket som användes i klienten, javascript, betraktades inte riktigt rumsrent. Åter korsas olika ide´er. En linje försöker lämna javascript och bygga plugins. Med dessa plugins kunde kodningen ske i ett annat språk. Flash och Silverlight är två sådana linjer. Men när browsertillverkarna nu börjar dra tillbaka stödet för dessa plugins är linjen ett sidospår som fasas ut. En annan ide är att skriva kod i ett språk som sedan konverteras till browserns javascript. Här har Google varit aktiva med GWT och Dart. Coffescript är ytterligare en ide. De försöker komma tillrätta med javascripts krångliga syntaxen.
Alla förkastade inte javascript som språk. Däremot skapade browsertillverkarnas olika implementering av språket problem. Alla hade sin version. Variationer i standardiseringen. En rad javascriptbibliotek försökte överbrygga skillnaderna och underlätta kodningen i javascript. Först i raden var Prototype. jQuery har nu lagt beslag på en dominerande marknadsandel.
Första generationens javascriptpaket hade inget stöd för strukturering av koden. Andra generationens paket försöker ta Model-View-Controller strukturen från serverdelen till klienten. Här har vi paket som Backbone, Ember, Knockout och AngularJs. Just AngularJS har tilldragit sig mitt intresse. Det underlättar för klient-utvecklaren. Bindning, kopplinen mellan javascriptkoden och html-sidan löses elegant. Koddelar isoleras i block via controllers. Det finns också direktiv som möjliggör komponentbyggande. På nätet finns rikligt med exempel vilket underlättar när inlärningströskeln ska passeras.