JS Frameworks: Hvorfor og hvordan front-end overtar

JS Frameworks: Hvorfor og hvordan front-end overtar

Javascript er et programmeringsspråk som har eksistert i cirka tjue år, og dets popularitet har gått opp og ned gjennom årene. Hver enkel webutvikler har nok gjort seg både positive og negative erfaringer og har sine anekdoter å fortelle.

Tidligere ble teknologien brukt i begrenset omfang for å berike nettsider med små grafiske effekter, men etterhvert har dette språket blitt et uunnværlig verktøy, mye takket være jQuery Framework som ble lansert i 2005. Slagordet "Write less, do more" har fascinert oss, og allerede i 2011 hadde jQuery oppnådd 90% av markedsandelen for JavaScript Framework. I dag benyttes språket til mye mer enn bare enkle DOM endringer og JavaScript rammerverkene utvides og utvikles stadig. Spesielt siden 2012 har vi observert en ekte industrialisering av front-end.

Rammeverker overalt og for alt mulig? Men hvorfor har dette skjedd så plutselig?

HTML5 modning: en større lekeplass

Hovedgrunnen til at JS-rammeverkene nå har blitt så populære, er HTML5. HTML5 blir stadig mer modent og tillater nå teknikker som tidligere har blitt ansett som for lite «utviklete» til å finne en plass i weblandskapet vårt. Jeg tenker spesielt på WebSockets for utvikling av ekte sanntidsapplikasjoner med god ytelse, eller Web Storage som er bedre tilpasset dagens behov for lagring av forskjellige data i nettleseren. Ja mye bra har skjedd! På den grafiske siden er vi etter hvert også blitt ganske bortskjemt: jeg tenker selvsagt på Canvas, som gir JavaScript mulighet til å vise hvor mangefasettert det egentlig er. Bruk av Canvas lar oss tegne ut alt fra enkle tegninger og kurver til komplekse animasjoner i nettsidene. Alt dette er jo fantastisk, men det blir enda bedre når denne funksjonaliteten kan håndteres på en lettere måte gjennom JavaScript-rammeverkene.

MVC og MV *: ytelse på klientsiden

Det berømte "model view controller" systemet må ikke lenger bevise sin effektivitet. Det har blitt vedtatt og bevist av utviklerne for lenge siden. Men MVC for front-end hørtes fortsatt litt sprøtt ut. Nå sikrer imidlertid Backbone, Angular, Ember, Knockout, Agility (og mange flere) oss endelig mer struktur på «vår» side. Logikken basert på hendelsene (events) er nå separert, og API’en spiller rollen som modell. Utviklingen er forenklet og ytelsen øker betydelig, spesielt med den berømte single-page teknikken. Alle er fornøyde når den første siden er lastet, og andre overføringer på serveren representerer bare noen få Kb av JSON. Til tross for at det er behov for et tilleggsrammeverk og en dobbel MVC-modell, har brukeropplevelsen aldri vært så god!

Teste front-end biten i en applikasjon: et lenge følt behov har endelig blitt en realitet

Teste sin applikasjon, en selvfølge? Back-end delen gjennomgår systematisk en serie av tester før leveranse, men hva skjer når det kommer til front-end biten? Oftest blir denne delen testet visuelt og manuelt fordi det tidligere ikke var noen bedre løsninger. Dette problemet tar nå JavaScript-rammeverkene seg av: Mocha, Jasmine, Protractor, PhantomJS og en rekke andre test-rammeverk sørger for at funksjoner er riktige og at moduler er sikre og selvstendige. Denne kombinasjonen gjør det endelig mulig for front-end utviklere å lage gjenbrukbare moduler der stabiliteten er testet og godkjent.

Mobile Platforms: en akseptert utfordring

At mobile plattformer er tilstede overalt ble lenge ignorert fordi det manglet midler til å skaffe brukeren den riktige opplevelsen. JQueryMobile har forsøkt å møte utfordringen, men har ikke alltid vært i stand til å tilfredsstille oss til tross for en svært aktiv community. Oppgaven er vanskelig og brukerne stiller høye krav: Multiple-OS, HTML5-støtte, touch-events visuell interaksjon, responsiveness, ytelse. Utfordringen er der fortsatt, men nå er mange flere med på å utvikle fremtiden ved å tilby sin hjelp: jQTouch, Sencha Touch, Titanium, Wink Toolkit, NimbleKit. Når det finnes så mange rammeverk, er det ikke alltid lett å se klart, og det kan være nyttig å ta en titt på "Mobile frameworks comparison". Men mange av oss er nok glade for flere JavaScript-rammeverk og hva disse kan tilby av løsninger på dette som vi fortsatt oppfatter som et "problem", ikke sant?

Server-side Javascript: Vil back-end utviklere komme over det?

JavaScript er et programmeringsspråk. Et ekte språk, ja, som bruker samme tittel og definisjon som C, Ruby, PHP etc. Etter å ha vært uglesett i lang tid, er JavaScript nå tilbake for å vise hva det egentlig er i stand til å gjøre! Med Node.js ser det litt… annerledes ut! Ja, fordi JavaScript dukker opp på serversiden – Uff, en back-end utvikler vil nok gå til angrep der - Javascript utenfor nettleseren... men det er mulig det? En hel ny verden har åpnet seg for oss, en helt ny måte å programmere på, basert på events. Bare gøy, selvfølgelig. Men la oss være ærlige, Node.js er ikke virkelig et rammeverk ... Men shhh ...

Er det realistisk å tenke seg et webprosjekt uten JS-rammeverk i 2015?

Når blir det nødvendig? Hvilke valg skal man ta? Finnes det en løsning for å håndtere bibliotekene? I følge statistikken kjører i dag 35% av nettsteder og web-applikasjoner uten rammeverk. Så ja, det er selvsagt mulig å klare seg uten. Men vi burde heller spørre oss: hvorfor droppe det? Det er avgjørende å kartlegge behovene knyttet til applikasjonen vi skal utvikle for å kunne ta riktige valg. Mange nettsteder refererer til rammeverker, deler erfaringer og hjelper oss med å velge. Det har dukket opp flere enestående verktøy som bør sjekkes ut, deriblant Grunt og/eller Todomvc.

What else? Det er bare å kaste seg ut i det! Lykke til!

Le Pontois, Marion

Le Pontois, Marion

Konsulent // Enterprise 2.0
marion.lepontois@acando.no

 

Om bloggeren:
Frontend utvikler som jobber med moderne rammeverk, med et spesielt øye for design og grafisk utforming. Solid erfaring fra store scrum prosjekter for virksomheter som Sporveien, Orkla og TINE. Opptatt av sluttbrukerens perspektiv og brukskvalitet. Interesse for problemstillinger rundt fleksibilitet på jobb og nye måter å arbeide på.

comments powered by Disqus