Frontend

Tester du UI-komponentene dine ved å klikke omkring i applikasjonen og gjenskape situasjoner manuelt? Unødvendig. Tidssløseri. Frustrerende. Bruce Hauman viser vei med Devcards.

Min favorittjulekalender til helårsbruk. Full av triks, tips, testing og forskning om frontendytelse. Vel verdt å lese hvis du er opptatt av å lage raske websider.

• Uinit - Et inisialiserings-system for UI-komponenter.

I jula som var satt jeg og nerdet litt innimellom all julekosen. Jeg prøvde å finne et lite bibliotek for enkel håndtering av websockets i en nettleserapplikasjon. Nå følger det jo med en standard WebSocket implementasjon i alle nettlesere, men jeg ville også at den skulle ha støtte for automatisk gjenoppkobling og pulskontroll mot server. Etter å ha søkt litt på npm som seg hør og bør, fant jeg ikke noen som helt fristet å dra inn. Kanskje jeg skal lage et lite bibliotek selv da? Hva om jeg implementer det ved å basere meg på en Finite State Machine i bunn? Det hadde vært digg om biblioteket hadde en funksjonell kjerne og at sideeffekter håndteres separat. Her er det bare å brette opp armene å se hva vi kan få til.

Det er 2020, og nettleseren har fortsatt ikke UITableView. Det er ikke fordi de som lager nettlesere er inkompetente, men fordi WC3-spesifikasjonene gjør det umulig å lage kjappe implementasjoner av GUI-rendring på web.

Derfor lever vi med at Slack bruker 2gb minne for å vise et lite knippe tekstlinjer. (Desktop-appen til Slack er et webview.)

Men vi har to store unntak: både Google Docs og Visual Studio Code klarer å rendre enorme dokumenter på null komma svisj, med lav minnebruk og greier. Hvordan klarer de det?

I forbindelse med bloggposten om en enkel frontendarkitektur som funker, spurte Ove: «Hvis du har en tekstboks og en knapp, hvem har ansvaret for å ta verdien fra tekstboksen og sende den til eventbussen når man trykker på knappen?» Det er et betimelig spørsmål med noen interessante detaljer.