ReisebrevDotJS 2019

Tidlig i desember dro fire ITverkere på den største JavaScript-konferansen i Europa; DotJS. Og den var ikke lokalisert hvor som helst. Konferansen fant nemlig sted i Paris! Kul konferanse og fantastisk by - det kunne ikke bli bedre.

JavaScript-entusiaster og utviklere fra hele verden holdt talks. Formatet på konferansen varierte fra lengre talks på 20 minutter, til lightning talks og til og med en paneldebatt. Konferansen varte i to dager og disse dagene var delt inn med fokus på frontend og backend.

Den første dagen var fokuset frontend. To av talksene handlet om hvor viktig det er å få flere til å kode og tilrettelegge for dette.

The Complexity in Simplicity

En av talerne var frontend-utvikleren Sara Viera fra Portugal. Hun jobber for CodeSandbox som er en editor for kode på nett. Verktøyet gjør at man enkelt og raskt kan lage og dele webapplikasjoner, da det meste allerede er satt opp og man slipper å sette opp selv lokalt.

Hun la vekt på at verktøy som CodeSandbox fjerner kompleksiteten for utvikleren slik at man kun kan leke seg med kode. Hun la også vekt på at man som utvikler ikke alltid skal være så opptatt av at all kode skal se pen og ryddig ut, så lenge den gir en god brukeropplevelse (UX). En bruker vil ikke komme tilbake til en nettside kun fordi du som utvikler har kodet pent. Ofte må det litt hackete løsninger til for å få et godt brukergrensesnitt. Utviklerne må ta støyten så brukerne slipper og de må legge til rette for flest mulig brukere.

Viera viste et eksempel fra en nettside der man utfører et kjøp av en vare. Ved betaling må man ofte velge type kredittkort man vil betale med før man taster inn kortnummer. Dette mente hun var helt unødvendig og et ekstra klikk for brukeren da man enkelt kan gjenkjenne hvilket kredittkort som blir brukt ved å lese de første sifrene på kortet. En bedre løsning hadde vært at de første sifrene ble lest av kortet og at applikasjonen viste et bilde av kortet brukeren har lagt inn. Dette ble kanskje ikke like pent kodemessig, men kunne føre til flere fornøyde brukere. Det gjelder altså å være pragmatisk som utvikler.

Develop, Debug and Learn? A time to re-think our tooling

Den andre talken innenfor dette temaet ble holdt av Program Manager for Open Web and Browser i Microsoft, Chris Heilmann.

Han mener utviklere er sykelig opptatt av automatiserte prosesser og optimalisering, og har mistet empati for andre utviklere og sluttbrukere på veien. Utviklere prøver hele tiden å automatisere kjedelige og repetitive oppgaver, men glemmer å fokusere på brukeren. Vår oppgave som utviklere er å gjøre det enklere for folk å få gjort ting. Utviklere må tenke på at produktene skal være tilgjengelige for alle typer mennesker. Først når de grunnleggende kravene er dekket kan man begynne å tenke på “nice-to-haves”, som for eksempel å laste inn data i forkant.

Heilmann snakket også om de uendelig mange hjelpeverktøyene som eksisterer idag og at det kommer nye hele tiden. Det er umulig å følge med på alt som finnes og det kan gjøre det vanskelig for nykommere i bransjen. Det er viktig å fokusere på utvikling av verktøy som er behjelpende underveis i kodingen, f.eks. med hjelpetekster, i stedet for verktøy som gjør at koden kjører bittelitt raskere. På denne måten kan neste generasjon ha et større fokus på å levere og ikke være opptatt av å vite alt om verktøyene som finnes der ute.

Dag to av konferansen var det backend og JavaScript som språk som var hovedfokus. Også denne dagen var det mange inspirerende talks med god variasjon av temaer.

Green Developer Relations

Asim Hussein fra Microsoft holdt en tankevekkende talk som kan sies å være veldig i tiden akkurat nå, der han snakket om hvordan man kan bygge og kjøre applikasjoner mer miljøvennlig ved å gå serverless. Det kreves mye CO2 for å både opprette nye servere og drifte de, så når de ikke blir utnyttet 100% er det rett og slett sløsing av ressurser og CO2. Faktisk slipper inaktive servere ut nesten et halvt tonn CO2 i året, så her er det mulig å spare mye!

Dette var også hovedargumentet for å gå serverless, da dette gjør at man kan utnytte servere fullt ut, som vil kreve færre servere totalt. Her ble flere alternativer nevnt (og hvilke som jobbet for å være carbon-neutral), men ettersom Hussein jobber i Microsoft var hovedfokuset på Azure Functions. Siden dette tross alt er en JavaScript-konferanse snakket han også om Nitro, som er en template for å bygge og deploye serverless Node.js-applikasjoner på Azure.

Fast by default: Algorithmic optimization in practice

En annen interessant talk sto Vladimir Agafonkin for. Han står bak blant annet Leaflet, et av de mest brukte open source-bibliotekene for interaktive kart i JavaScript. Nå jobber han i MapBox, så dette er en fyr som åpenbart er god på kart. Han er også selverklært algoritme-geek, og talken hans handlet om optimalisering av kode, med noen gode tips til hva man kan se etter for å gjøre koden din raskere. Agafonkin har selv bidratt til utallige open source-prosjekter og viste noen eksempler på bibliotek som er blitt optimalisert og de store forskjellene på kjøretidene før og etter, før han ga oss en enkel algoritme for å gjøre kode raskere:

1. Finn en flaskehals
2. Finn ut hvorfor den er treg
3. Gjør den raskere

Ingen hokus pokus der altså, så da er det bare å begynne å skrive om kode! For å hjelpe oss litt på vei viste han oss noen typiske ting man burde bli mistenksom på om man ser i koden. Etter et litt selvsagt eksempel med for-løkker fikk vi også se noen kodesnutter med innebygde funksjoner i JavaScript som kanskje ikke er så rask, blant annet har flere array-funksjoner lineær kjøretid og kan være "skjulte" flaskehalser.

Agafonkin snakket litt om datastrukturer og minnebruk, som kan være et godt sted å starte optimalisering. Her er det enkelte innebygde funksjoner som allokerer en del (unødvendig) minne. Så dersom minnebruk er viktig for applikasjonen kan det være verdt å se på om man egentlig trenger å bruke string.split eller array.map, for eksempel. Til slutt poengterte Agafonkin at vi ved å kontinuerlig etterstebe forenkling og forbedring av kode, vil bli bedre til å skrive rask kode fra starten av. På den måten kodeoptimalisering er vinn-vinn for alle parter.

Deno

Bert Belder fra Node.js kjerneteamet holdt senere på dagen en talk om Deno, prosjektet han mener skal ta livet av Node.js.

Node.js ble designet i 2009. 10 år har gått siden da og mye har endret seg i JavaScript-verden. For eksempel:

• Promises, Iterators og async/await
• ES Modules
• Typed Arrays
• TypeScript

Flere svakheter ved Node.js har etterhvert blitt veldig tydelige. Dårlig designet modulsystem, med sentralisert distibusjon, mange utdaterte APIer som må støttes og manglende sikkert - for å nevne noe.

Ryan Dahl (mannen bak Node.js), Bert Belder med flere, har derfor igjen funnet sammen for å lage et nytt JavaScript Runtime, Deno.
Prosjektet har allerede fått endel oppmerksomhet og GitHub repoet har i skrivende stund over 40 000 stjerner.
Men, som Bert presiserte, er Deno fortsatt et godt stykke unna versjon 1.0.

I følge talken fra Belder skal Deno alltid distribueres som en single executable. Teamet ønsker å gjøre Deno uavhengig av system libraries, og at executablen er alt du skal trenge for å kjøre en Deno-applikasjon både på Windows, Mac og Linux.

Deno skal gjøre det mulig å kjøre uverifisert kode på en trygg måte. For eksempel kan du kjøre en applikasjon direkte fra internett ved å kjøre

Dette kan føles noe usikkert med mindre man er helt trygg på hva applikasjonen faktisk kan gjøre. Med Deno er det enkelt å styre rettighetene applikasjonene har på systemet ved hjelp av kommandolinje flag.

Med Deno trenger man ikke lenger være avhengig av en sentralisert distributør av tredjeparts kode. Ikke noe npm, ikke noe node_modules, men ganske enkelt:

Med en slik løsning trengs ikke lenger noen sentralisert server.
Ved kjøring fetches, caches og kompileres koden slik at disse importene fint kan fungere offline etter å ha blitt cachet.

Deno har TypeScript kompilator innebygget og bruker V8 Snapshots for rask start av TypeScript. Så man kan altså importere TypeScript moduler direkte.
Deno shipes også med integrerte typedefinisjoner for seg selv. Målet er å kunne mikse og migrere fra JavaScript > TypeScript > Rust eller Web Assembly.

Dette prosjektet er interessant og virker veldig lovende. Det blir spennende å følge Deno fremover.

Fixing JavaScript Date

Etter en bedre lunsj bestående av deilige franske godbiter, var det klart for en talk av Maggie Pint, en av utviklerne bak Moment.js. Hun snakket om datohåndtering i JavaScript. Et tema de fleste js-utviklere har et mer eller mindre anstrengt forhold til.

Det sies at Brendan Eich i 1995 fikk 10 dager på å lage JavaScript og få dette implementert i Netscape.
Dato-håndtering er en sentral del av nesten alle programmeringsspråk, så selvsagt måtte også JavaScript ha dette på plass. Brendan fikk beskjed om å "make it like java", derfor kopierte han date-objektet fra den da ferske java.Util.Date datoimplementasjonen. Denne holdt ikke akkurat høy kvalitet, og nesten alle dens metoder ble deprektert og erstattet i Java 1.1 som ble lansert i 1997. Over 20 år senere må vi i JavaScript fortsatt forholde oss til den originale implementasjonen. Maggie Pint listet opp det hun mener er de største svakhetene med dagens implementasjon.

• Ingen støtte for andre tidssoner enn brukerens lokale og UTC.
• Parseren er så upålitelig at den er ubrukelig.
• Date-objektet er mutable.
• DST er uforutsigbart.
• Bregenings-APIene er uhåndterlige.

Heldigvis har Maggie bestemt seg for å fikse datohåndtering i JavaScript.
Dagens implementasjon kan ikke enkelt endres til noe som fungerer bra pga kompabilitetskrav. Hun har sammen med et knippe ande utviklere derfor utformet et nytt forslag til TC39 kalt Temporal. Dette er bygget rundt et sett prinsipper:

• Alle temporal APIer er non-mutating. Alle temporal-objekter er immutable.
• Alle datoverdier er basert på den gregorianske kalenderen.
• Alle tid-på-dagen-verdier er basert på en standard 24 timers klokke.
• Skuddsekunder er ikke representert.

Forslaget er i skrivende stund på Stage 2 hos TC39. Det har solid støtte, og vil ganske sikkert bli implementert i en fremtidig release.
Foreløpig må det benyttes en polyfill for å ta i bruk Temporal allerede nå. Denne polyfillen er under kontinuerlig utvikling, så det er verdt å tenke to, tre eller fire ganger før man bruker den i produksjon.

Fremtiden vil vise hvorvidt Temporal blir en del av vår utviklerhverdag. Det er i hvert fall godt å vite at det jobbes med å forbedre denne frustrerende delen av JavaScript.

Inspirerte og med koffertene fulle av ny kunnskap og nye klistremerker satte vi kursen tilbake mot Oslo. Og ja, vi kom oss hjem til tross for transportstreik i Frankrike.

Av: Vilde, Glenn og Hanne

Les mer om konferansen her eller her.

Toppbildet tatt på dotJS 2019 i Paris 5-6 Desember, 2019 av Thomas Decamps. Det er underlagt creative commons lisens og hentet fra dotConferences sin flickr profil