Kendt webudvikler advarer: Vi er ved at gentage grum fejltagelse fra 90’erne

Mange webudviklere forherliger de nyeste teknologier, men glemmer nogle helt grundlæggende principper i webudvikling, advarer en af udviklerne bag Microsofts nye Edge-browser.

Indrømmet: Denne artikel skulle egentlig have handlet om noget helt andet. Den skulle beskrive de seneste trends inden for webudvikling og viderebringe et magisk glimt ind i krystalkuglen for at komme med en tvivlsom besvarelse af spørgsmålet: Hvad bliver det næste hotte inden for webudvikling? Hvad er det, alle vil tage for givet, når vi engang kigger tilbage på HTML5 på samme måde, som vi nu kigger tilbage på Flash?

Anledningen var webudvikler-konferencen At The Front End, hvor flere ledende webudviklere blev samlet for at øse ud af deres indsigt.

Men jeg må desværre skuffe. Efter at have konfronteret webudvikler-evangelisten Chris Heilmann fra Microsoft med spørgsmålet, kommer der et lidt anderledes svar:

»Det spørgsmål hører man alt for meget i tech-pressen. Vi er blevet for begejstrede for ny teknologi i branchen, og det er blandt andet mediernes skyld. Der foregår et rotteræs i teknologi-virksomheder og blandt udviklere for hele tiden at lave nye udgivelser. Det er en farlig ting, fordi vi kommer til at udgive halvfærdige ting,« siger han og fortsætter:

»Vi er inde i en teknologi-boble, hvor vi er en lille elite med adgang til en masse teknologi, mens den gennemsnitlige bruger kun sidder med sin skrivebordscomputer eller bærbare. Men i stedet forventer vi, at folk har adgang til den sejeste teknologi og bygger derfor i virkeligheden tingene for os selv i stedet for folket.«

Chris Heilmann bruger pixel-perfekte hjemmesider, som eksempler på, hvordan udviklere bruger mere krudt på at smide lækre effekter på som parallax-scrolling i stedet for at sørge for, at hjemmesiden også er brugbar for dem, der sidder med en gammel uddateret browser.

Alt for ofte er det tilfældet, at hjemmesider er optimeret til en bestemt browser og er afhængig af eksempelvis javascript, lyder det fra Microsoft-udvikleren, der blandt andet har været med til at udvikle den kommende Microsoft Edge-browser til Windows 10.

Der var engang - især i 90’erne - da de fleste hjemmesider som standard krævede, at man besøgte dem med Internet Explorer. Forsøgte man sig med andre browsere, kunne det betyde, at hjemmesiden slet ikke kunne vises. Dette er heldigvis ved at være ovre, men det betyder ikke nødvendigvis, at alle udviklere har lært lektien og gjort sig platformsuafhængige ifølge Chris Heilmann, der også er tilknyttet Mozilla Developer Network.

»Vi er ved at gentage de samme fejltagelser fra 90’erne igen med Chrome, fordi det er den mest coole browser lige nu. Men vi er nødt til at holde os uafhængige af browsere og kapabilitet, ellers så kommer vi til at sidde her om fem år og være irriterede over, at folk måske ikke bruger Chrome længere,« siger han og påpeger, at den største vækst i internetbrugere sker fra Kina, hvor folk går på nettet med alt fra gamle mobiler til ældre version af Windows til de nyeste smartphones.

»Vi kan ikke kontrollere brugernes miljø, og hvis vi kunne, ville det være enden på internettet,« siger han og fortsætter:

»Det er noget fis, når man som bruger får at vide, at ens ‘device ikke er understøttet’. Lad være med at gentage denne fejl, bare fordi en anden browser er fancy lige nu, ellers ender du med at gøre folk sure.«

Javascript-afhængighed kan ødelægge web-oplevelsen

Den primære fejltagelse fra mange webudviklere består ifølge Chris Heilmann i, at de ikke designer hjemmesiderne ud fra en grundlæggende forståelse af, hvordan man gør kernefunktionaliteten tilgængelig for brugerne på tværs af alle platforme - også de ældre. Denne metode kaldes også for Progressive Enhancement (PE).

Et eksempel på dette er den meget udbredte brug af javascript med tilhørende populære frameworks som eksempelvis AngularJS. Det er ikke så meget det, at udviklere bruger javascript, der er problemet ifølge Chris Heilmann, men snarere det, at mange hjemmesider slet ikke fungerer, hvis javascriptet ikke loader.

»Javascript er ikke fejl-tolerant. Hvis der er en fejl, så er der ofte intet, der virker. Og der er mange måder, som javascript kan fejle på,« siger Chris Heilmann.

I stedet bør man som webudvikler designe en hjemmeside således, at brugeren stadig har adgang til kernefunktionaliteterne, selvom javascriptet fejler, lyder anbefalingen.

Et eksempel på dette er Googles søgninger. Som bekendt begynder Google allerede at vise nogle resultater på ens søgning i det øjeblik, man begynder at skrive i søgeboksen, og denne funktionalitet bliver leveret med javascript. Men hvis javascript er slået fra, vil søge-funktionaliteten stadig fungere fint, selvom man som bruger ikke får den ekstra oplevelse af øjeblikkelige søgeresultater.

»Du kan godt bruge Google uden javascript. Det er ikke smukt, men det er heller ikke defekt,« siger Chris Heilmann og uddyber:

»På den måde bliver oplevelsen bedre, hvis brugeren har et bedre miljø, men det er ikke et krav at have et bedre miljø for at benytte sig af tjenesten. Det er med til at beskytte Googles kerneforretning: at facilitere søgninger og vise reklamer.«

Idéen med Progressive Enhancement er, at man lægger forskellige lag oven på hjemmesiden, hvor de mest basale funktioner er tilgængelige lige meget hvad. Det kan ifølge Chris Heilmann sammenlignes med en rulletrappe: Selvom der ikke er strøm, så kan man stadig bruge den som en almindelig trappe. Rullefunktionen er en ekstra luksus, som dog ikke er afgørende for, at folk kommer fra a til b.

»Progressive Enhancement er et varmt emne lige nu inden for webudvikling,« siger han.

Et par eksempler:

I stedet for at lade brugeren vente i lang tid på at indlæse en tung web font, bør udviklere ifølge Chris Heilmann vælge en standard-font og så erstatte den med den nye font, efter at den er indlæst.

Og det er også en dårlig idé at lave sign up-formularer, der kræver javascript til validering af brugernes input for at virke.

»Så kan brugeren altid slå javascript fra og skrive ting, der ikke er tilladt. Du åbner dig selv for hackere på denne måde,« siger han.

Heilmann: Progressive Enhancement betaler sig i det lange løb

Progressive Enhancement kan oversættes som ‘trinvise forbedringer’ og er en tankegang, der begynder allerede før, man som udvikler begynder at skrive den første linje kode. På et konkret plan handler det om at omgive de forskellige funktionaliteter med en if-erklæring, der kun tillader en feature, hvis brugerens browser understøtter den.

»Når du tester for kapabiliteter, så slipper du for problemet med at antage, om noget virker eller ej. På den måde undgår du også at skulle registrere, hvilken browser brugeren har og holde styr på, hvad de forskellige versioner understøtter,« siger Chris Heilmann.

Et andet udbredt eksempel på, hvordan webudviklere glemmer Progressive Enhancement, er i de knapper med farveovergange på hjemmesiderne, som især blev kendte med iPhonens udbredelse. Problemet opstår ifølge Chris Heilmann, fordi mange af knapperne blev lavet med en webkit gradient, som virker specifikt til iPhonens Safari-browser, men som ikke bliver vist korrekt i andre browsere. Hvis teksten på knappen er hvid, og knappens farveovergange ikke bliver vist, ender brugeren med at se på en uforståelig knap, hvor det ikke er til at læse en hvid skrift på en hvid baggrund.

»Så har man glemt at definere en anden baggrundsfarve at falde tilbage på, hvis effekten med farveovergangen ikke virker,« siger Chris Heilmann.

Der ligger mere udviklerarbejde med at indtænke Progressive Enhancement i en hjemmeside, fordi det kræver en nøje overvejelse af, hvordan man bedst tester, om brugeren kan benytte sig af de forskellige funktionaliteter, og samtidig opstiller brugbare alternativer.

Alligevel betaler det sig i det lange løb, når et site skal videreudvikles, og der kommer nye versioner af de forskellige browsere på markedet, som vælger nye teknologier og fravælger at understøtte gamle. Eksempelvis trak Google med version 42 af Chrome-browseren i april stikket for understøttelsen af Java. De hjemmesider, som var afhængige af Java for at fungere, havde derfor en større udviklingsopgave foran sig.

»Progressive Enhancement beskytter din virksomheds kerneforretning. Dem, som ikke benytter sig af PE, kommer til at betale mange penge for ekstra-udvikling, når der kommer nye telefoner og tablets på markedet,« siger Chris Heilmann.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Rune Jensen

Jeg synes så der er forskel på en web APP og en alm. hjemmeside.

Ikke fordi en web APP ikke skal være tilgængelig - det er SVJKS det ARIA er til også ved AJAX - men det er altså svært at lave en web APP som ikke er afhængig af javascript...

Lad os tage en chat.

Her er man så nødt til, for at have reel fallback uden JS, at bruge en iframe med POST. Og så lave kode for både AJAX og den "rene" HTML posting.

Ja, det kan lade sig gøre, men arbejdet er EMM for stort set i forhold til, man så supporterer en døende teknologi. Ligesåsnart man ser ordet "APP" så burde det vel være klart at det involverer javascript...

At så ARIA på ingen måde er fuldt logisk, er noget andet. Men jeg vil hellere at man har den mulighed med ARIA, som er mere rettet imod fremtiden, og så arbejder efter brug af javascript end at bruge iframe-modellen (som på den anden side bør kunne laves, så den virker i HTML3.2).

Hvad angår alm. hjemmesider, så er det vel bare at følge hvad man altid har gjort udfra best practice. Her er det ikke så svært igen at lave alt tilgængeligt uden for meget kodespild. Unobtrusive javascript og eksternt CSS/javascript, og iøvrigt så lidt JS som muligt...

  • 1
  • 1
Rune Jensen

Jeg plejer at teste siderne i netrenderer.de

Her kan man bla. teste, hvordan brug af CSS til mere avancerede baggrunde kan laves fallback til netop med at sætte en baggrundsfarve separat (enten før eller efter CSS3 erklæringen),for de browsere,som ikke understøtter de nyeste ting.

Når en CSS-erklæring mødes i browseren, som ikke understøttes, så droppes hele erklæringen. Det er et godt udgangspunkt at lave fallback i designet på.

  • 2
  • 0
Jesper Sørensen

»Så kan brugeren altid slå javascript fra og skrive ting, der ikke er tilladt. Du åbner dig selv for hackere på denne måde,«

Jeg tror de fleste hackere er ret ligeglade med, om der var JavaScript-validering på en formular i første omgang. Hvis der ikke er backend-validering har udvikleren alle dage været, om ikke inkompetent, så meget grøn i faget.

Jeg er enig i at man selvfølgelig ikke skal lade sine hjemmesider være afhængige af css-vendorprefixes - hvorfor det kan være smart at bruge eksempelvis stylus med nib.

Når det kommer til JavaScript er jeg ikke helt enig med artiklen. Jeg synes ærligt talt selv man har besluttet at få en dårlig - eller ingen - oplevelse hvis man slår JavaScript fra. Det er rimelig let at skrive JavaScript som ikke bliver forældet (læs: følger standarden), og langt de fleste JavaScript-problemer jeg oplever skyldes stadigvæk browsere, som ikke lever op til de nuværende standarder. Så jeg kan ikke helt se, hvordan vi på denne front skulle havne i en ny IE-situation.

  • 2
  • 3
Simon Mikkelsen

Det ville være dejligt hvis man kunne slå Javascript fra og så virker det stadig. Den slags kan man lave på statiske sider som version2 og google.com, men har man en webapp med funktionalitet kræver det en helt separat frontend og det er de færreste kunder der vil betale for det.

Chris tager eksemplet google.com og generaliserer ud fra det, men mange moderne sider er langt mere komplicerede end det. Gmail eller Microsofts tilsvarende tjenester virker næppe uden Javascript.

  • 4
  • 3
Magnus Jørgensen

Er det her ikke ret beset et problem hos Microsoft?
Hvis de havde samme udviklings cyklus som, Chrome, Firefox, Opera og Safari og samtidig udrulnings system der ikke er baseret på hvilken version af Windows man kører, så ville man vel ikke have de her problemer.

Altså bare helt generelt. Folk der kører Chrome på windows Vista, 7, 8 og 10 har jo alle sammen den samme version installeret. Som iøvrigt bliver udrullet helt automatisk.

Burde MS ikke bare adskille IE og Windows?
De kan jo stadig lægge det på som en standard installation osv.

  • 5
  • 3
Rune Jensen

Er det her ikke ret beset et problem hos Microsoft?

Ikke som jeg har forstået det.

Chrome og WebKit er ved at udvikle sig til hvad IE6 var omkring 2001. Hvor visse offentlige personer i DK (som burde vide bedre) fuldt alvorligt foreslog, at vi skulle droppe W3C og køre udelukkende efter MS-standard. Fordi IE6 havde 98% af brugerne eller lign.

Det samme er ved at ske nu. Chrome og webkit er ved at overtage samme magt som IE6 havde med ikke-W3C standard vendor-prefixes til følge, som ikke forstås af andre browsere (OK, Firefox følger nogenlunde med Webkit).

You remember...?
http://www.anybrowser.org/campaign/

Det er vitterligt irriterende at skulle lave særlige hacks til IE. Men forskellen fra før til nu er, at før var det IE, som var "vendor-specific" og ikke fulgte W3C.

Nu er det Chrome/Webkit (og til dels Firefox), som har "fede features" (prefixed), som man (nogle) bare plugger på - og ikke laver fall back til.

Så årsagen til, man skal lave hacks til IE i dag er tit... at man ikke følger W3C... i hvert fald fra IE10 og op.

Når man bruger ikke-W3C godkendte feature i sin APP, fordi "det supporterer Webkit/Firefox jo", så er det egentlig lidt dårlig stil. Fordi netop fra IE9, så er Microsoft jo begyndt at køre efter W3C standarden.

Så hvis man udelukkende kørte efter W3C (i det mindste i en produktions APP), så burde der ikke være nødvendigt at lave hacks... heller ikke til IE.

Til gengæld, så bliver koden måske nok også det længere, hvis man udelukkende kører efter standard. Man skal jo så lave visse features med "gammel" teknologi...

Og diskussionen om manglende features pga. de ikke er godkendt af W3C endnu og derfor ikke støttes af alle browsere, den vil nok rase.

Men historien tror jeg egentlig vil gentage sig. Selv om jeg absolut ikke håber det.

Vi ender med at skulle sidde og lave "hacks" til webkit, fordi, ja, lige den her prefixed feature, den gjorde det altså ikke ind i W3C standarden...

Med det sagt, så kan jeg godt se, at jeg selv er begyndt at slække på kravene til full W3C compliancy.

Simpelthen fordi...jeg vil gerne kunne bruge de her nye features. Lære dem at kende.

Så med lige en enkelt APP jeg er i gang med, der bliver det altså så som så med IE-support.

Men den tilgang er altså ikke tilrådelig generelt, og ja, det er dårlig stil. Når man kigger på sidste browserkrig... Det kommer til at bide os i r...

  • 7
  • 0
Rune Jensen

Burde MS ikke bare adskille IE og Windows?
De kan jo stadig lægge det på som en standard installation osv.

Jo... det er jeg enig i.

Men man kan jo lissom ikke kræve de skal gøre det. Hvad man kan kræve er, at de arbejder hen imod W3C standarder i deres browsere. Og det gør de sådan set... Og så kan man jo selv køre udelukkende imod W3C også på hjemmesider/APPs. Så vil man allerede få IE8 med langt henad vejen med CSS2.1 f.eks.. uden hacks.

  • 2
  • 0
Rune Jensen

Jeg tror de fleste hackere er ret ligeglade med, om der var JavaScript-validering på en formular i første omgang. Hvis der ikke er backend-validering har udvikleren alle dage været, om ikke inkompetent, så meget grøn i faget.

Ja, det var et lidt dårligt eksempel. Det er mere ovre i emnet "sikkerhed", hvor backend validation alle dage har været best practice...

Men iøvrigt, hvorfor så bruge JS validation.

Når man kan bruge HTML5 regex validation?

;)

  • 1
  • 0
Toke Herkild

Synes det er en ret billig udmelding at komme med, ikke mindst når man ved at de fleste nu engang laver fallback løsninger, og at det største problem stadig er hacks der er nødvendige for at få tingene til at virke i IE 9 og 8. IE 7 vil jeg slet ikke begynde på.

Som webudvikler er det i stigende grad færre gange der skal rettes for browserinkombalitet, synes efterhånden, hvis man ser bort fra offentlige løsninger, at det er ved at lykkes at få folk til at lave serverside validering. CSS der virker på tværs af browsere. Samt at undgå ensidig brug af browser specifik teknologi.

Hvis MS er så bange for det her scenarie kunne de jo passende melde sig under fanerne og hjælpe til med at besvare problemstillingerne når de dukker op på stackoverflow, det interressante er jo i hvor stor grad det netop er deres afvigelser der skal arbejdes udenom, dog er det blevet mærkbart bedre fra IE 10.

  • 3
  • 0
Troels Henriksen

Hvad man kan kræve er, at de arbejder hen imod W3C standarder i deres browsere. Og det gør de sådan set...

Har du læst W3C-standarderne? Forstod du dem til pixel-perfektion, og kan du huske dem? Med så komplekse standarder, så er det uundgåeligt at man som udvikler koder op imod en implementering frem for en specifikation. Når det så ikke virker i en (eller flere) af implementeringerne af standarden, så er det ikke altid nemt at se hvem der har lavet fejlen.

  • 1
  • 0
Joachim Michaelis

Der synes at være to overordnede retninger som nettet bevæger sig i:

Statisk: Nettet er ligesom en masse sider i en bog, og disse kan vises og parses af en væld af forskellige browsere/readere/whatever, og meta-data kan ekstrapoleres. Tænk wikipedia og web 2.0.

Dynamisk: Nettet er en interaktiv størrelse lidt a'la et spil eller en app. Dokumenter kan ikke parses lige så let, eftersom det kræver at et eller flere scriptsprog skal kunne parses og eksekveres.

Det store spørgsmål er vel egentlig: Hvad vil vi? Det ene eller det andet?

  • 0
  • 0
Rune Jensen

Det store spørgsmål er vel egentlig: Hvad vil vi? Det ene eller det andet?

Egentlig havde jeg håbet på fuld erstatning af Flash og native programmering med ren HTM5 og javascript til APPs.

I så fald ville APPs i HTML/JS fint kunne eksistere side om side med alm. hjemmesider. Man kan komme langt, hvis man giver sig tiden, med kompatibiliteten browsere imellem.

Det kan lade sig gøre med mindre APPs. Netop fordi man faktisk kan lave nær pixel-perfekte designs, som skalerer i HTML5/CSS3 (hint: @media, vh og vw). Nu fokuserer jeg på én side APPs, som er kendetegnende ved, at de kun fylder en side, ingen scroll barer, og nok ser bedst ud i full screen mode. Dvs. også at alle opdateringer sker med JS/AJAX.

Men til større APPs, der ved jeg det ikke. En del er jo gået bort fra den cross platform egenskab, som HTML giver og gået tilbage til native programmering. Bla. som jeg forstår det, at performance hensyn. Men måske også fordi man på den måde kan optimere endnu mere i designets pixelperfekthed.

Problemet er så igen, at programmerer man native, så er det jo netop imod en specifik producent/enhed. Brugere af andre enheder fra andre producenter vil så ikke få glæde af den APP, med mindre man også laver én til dem specifikt.

Det er på den anden side EMM en fejl hos webmasteren, hvis denne tror, at en APP og en hjemmeside er det samme.

En APP er givetvis mere pixelperfekt og optimeret imod én hovedfunktion, mens en hjemmeside udover at være ret fleksibel, bare skal skalere - og kan tit laves med ganske lidt javascript. Med pixelperfekt mener jeg alt også grafik. Det kan altid laves lidt løsere på en hjemmmeside end en APP.

Så hvis man benytter APP-tankegangen i en alm. hjemmeside, så får man det her JS-bloat hvor alt er lavet i javascript og HTMLen er et par DIVer. Det er ikke kønt på f.eks. en blog.

Men... hvis jeg skulle lave min (WebKit/Mozilla-optimerede) APP med - testet - fallback, så skulle jeg overveje brugen af f.eks. addEventlistener, classList, @keyframes og animation... Det er jo alt det "nye og fede", som så skal omdefineres, måske hackes en smule også.

Jeg synes, det er ret svært at lave en HTML APP efter de samme forskrifter til cross media og cross platform kompatibilitet/fall back samt tilgængelighed, som jeg ville kræve af en hjemmeside. Ikke mindst fordi ARIA er en standard for sig selv.

  • 0
  • 0
Heine Andersen

Det klinger lidt hult.

Microsoft account

JavaScript required to sign in

Microsoft account requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked.

To find out whether your browser supports JavaScript, or to allow scripts, see the browser's online help.

  • 4
  • 0
Rune Jensen

Med så komplekse standarder, så er det uundgåeligt at man som udvikler koder op imod en implementering frem for en specifikation.

Det er så rigtigt nok også fra browser producenternes side.

Jeg læste om det her, at det ikke altid er lige nemt at være 100% specifik i en standard og nogle forklaringer bliver så en smule vage.

Så i tvivlsspørgsmål der kan browserproducenterne have variationer og stadig følge W3C. De implementerer det simpelthen som de tror det skal være.. uden så at være helt sikre.

Men er der ikke færre af de variationer nu end der var under forrige browserkrig?

Er der nogen særlig stor forskel på, om du udvikler i Chrome, IE eller Firefox i dag, hvis man altså ser bort fra prefixed features?

Jeg kan jo kun sige udfra min egen erfaring, men mine sider er forholdsvist simple CSS3/HTML5 sider uden det store javascript. De lader til at vises fint fra IE9 og op i netrenderer.

Jeg tror ikke jeg har lavet noget IE-specifikt hack endnu. Andet end en baggrund som fall back. Så for mig ser det ud til en ganske kraftig forbedring fra sidste browserkrig.

  • 0
  • 0
Rune Jensen

Har du læst W3C-standarderne? Forstod du dem til pixel-perfektion, og kan du huske dem?

Nej. Og mest fordi de er hammer lange og ganske indviklede. De skal jo have alle scenarier med, så det er ikke bare 2-3 linjer om hver del.

Alene deres forklaring på classes og hvad der nedarves, det er hvad man kunne bruge længere tid på at læse og forstå, end at udvikle.

Men jeg må ind i mellem bruge den som opslag, fordi jeg kan f.eks. stadig ikke huske hvad forskellen er på <section> og <article>.

Jeg bruger iøvrigt LYNX og Orca, den indbyggede skærmlæser, samt http://wave.webaim.org/ til test for tilgængelighed og kontrast.

WebAim har også en Firefox extention, men man skal vænne sig til den. Jeg synes godt, den kunne forbedres.

http://wave.webaim.org/toolbar/

Kontrasten er vigtig, faktisk. Læs f.eks. her:

http://mrwweb.com/why-contrast-matters/

  • 0
  • 0
Log ind eller Opret konto for at kommentere