Gode grensesnitt: JavaScript
I enda en innsats i sjekklisteprosjektet, kommer her nok et innlegg under kategorien webstandarder. Idag er det JavaScript som står på menyen.
Webstandarder
JavaScript
JavaScript er ikke, som de foregående innleggene har handlet om, en W3C-standard. Men, det betyr ikke at det er proprietær teknologi. JavaScript baserer seg på, og implementerer standarden for ECMA Script (som er en standardisering av Netscapes JavaScript). Microsofts implementasjon heter egentlig JScript, ikke JavaScript. JavaScript brukes vanligvis som et begrep om alle tre språkene.
Dette innlegget handler om JavaScript på klienten, ikke på serveren (en teknologi på fremmarsj).
Ikke-påtrengende ("unobtrusive") JavaScript
Ikke-påtrengende JavaScript ( "unobtrusive JavaScript") er praksisen å skille JavaScript fullstendig fra grensesnittets to andre lag: struktur/HTML og design/CSS samt beholde tilgjengelighet selv når vi scripter mye funksjonalitet.
Når vi skriver ikke-påtrengende JavaScript skriver vi kode som
- ikke ødelegger for brukere uten JavaScript
- ikke plager brukeren når noe går galt
- forsikrer seg om at funksjonalitet finnes før det brukes for å unngå feil
- er like funksjonelt med tastatur som med mus
- fungerer godt sammen med annen JavaScript (bilioteker, kode fra andre utviklere mm)
Hold all JavaScript ekstern
Å holde JavaScript ekstern er viktig stort sett av de samme grunnene som gjør det smart å holde CSS eksternt. Eksterne JavaScript-filer lar seg lett cache på klienten samtidig som funksjonaliteten holdes sentralt slik at det er lett å oppdatere og endre på.
Et viktig punkt som mange glemmer i denne sammenhengen er å også fjerne inline event-handlere. I stedet for å tilegne onclick-attributtet til en lenke i HTML-en bør du ha noe kode som aksesserer DOM-en og setter eventen i stedet. Jeg har gitt
fyldigere eksempler på denne praksisen tidligere.
Hvorfor?
- Tilrettelegger for caching
- Maksimalt skille mellom lagene
- Lettere å endre, ta bort og legge til funksjonalitet (ingen endring kreves i HTML-en)
- Oppfordrer til gode fallback-løsninger
Hvordan?
- Samle script i et fåtall filer og inkluder dem, gjerne nederst i HTML-fila
- Sett event-handlere gjennom JavaScript og DOM-metoder
Ikke stol på JavaScript
JavaScript er et funksjonalitetstillegg til nettsidene dine, ikke en sikkerhetsinstallasjon. Sannheten er at du kan ikke stole det minste på JavaScript - brukerne kan selv skru av støtte for det. Nettopp derfor er det viktig at vi utvikler forretningskritiske ting som skjemavalidering på server-siden også, ikke kun i JavaScript.
Lager du en tjeneste som bruker store mengder JavaScript kan det være en utfordring å gi fallback-løsninger for alt. I slike tilfeller kan det være bedre å heller tilby en alternativ versjon av tjenesten som ikke bruker JavaScript i det hele tatt. I dette tilfelle trenger du ikke å ta alle forholdsregler i JavaScript-versjonen, men sikkerhetshensynene gjelder fortsatt!
Hvorfor?
- JavaScript foregår på klienten, og også på klientens nåde
Hvordan?
- Implementer forretningskritisk funksjonalitet på server-siden først
- Planlegg for brukere uten JavaScript
Skriv forsvarlig JavaScript
Å skrive "forsvarlig JavaScript" er et relativt ullent begrep. Jeg har tidligere skrevet om JsLint, en syntakssjekker for JavaScript. Vel, egentlig er JsLint mer enn bare syntakssjekk. Den sjekker også at det ikke benyttes praksis som er kjent for å skape trøbbel.
Hvorfor?
Ved å kjøre en slik sjekk på koden vil du kunne forsikre deg om at koden din er godt rustet til å fungere sammen med annen kode (rammeverk, andre utviklere), og at du har tatt de viktigste forhåndsreglene mot at koden din feiler på klienten.
- Unngå problemer med eksterne script og rammeverk
- Unngå at script feiler på klienten
- Skriv kode som er lettere for andre å forstå
Hvordan?
-
Sjekk kode med JsLint
- Unngå udefinerte (implisitt globale) variabler og funksjoner
- Avslutt uttrykk med semikolon
- Ikke utelat { og } for enkeltlinje-blokker
- Bruk
===og!===når du trenger å sjekke på både type og verdi (false,null,'',osv) -
Ikke bruk
with
- Ligg unna nettleserspesifikke tillegg så langt som mulig, bruk standard JavaScript/ECMA Script
- Sjekk at objekter/metoder finnes før du bruker dem hvis det er tvil om hvorvidt de finnes eller om de har riktig type
Som med CSS kommer jeg tilbake til mer om JavaScript når jeg ser på krav til ytelse i grensesnittet. Hvilket punkter er dine viktigste krav til kvalitet for JavaScript?
Oppdatering: Takk til Ola som tipset meg om at eZ hadde kvesta alle de interne lenkene i dette innlegget. De skal være i orden nå.
