Unlimited Edition

Software anno 2020

Obs: Dette er ikke hakking p√• React og dets tilh√łrende milj√ł - de l√łser et problem p√• det beste viset de kan innenfor sine rammer og tilbyr verdi til utviklere og deres sluttbrukere. Dette er ganske enkelt en liten observasjon p√• hvor vi er kommet generelt sett, og dette dukket relativt nylig opp som en interessant manifestasjon av det hele.

Det ble flagget som en nyhet at det har blitt implementert en scheduleringsl√łsning i React for √• kunne gi styring/prioritering av f.eks. tegning av brukergrensesnitt opp mot IO-h√•ndtering.

Dette får meg til å tenke.

Vi har n√• da en datamaskin, typisk med en CPU med multiple kjerner (2+) og gjerne med st√łtte for multiple eksekveringstr√•der pr kjerne p√• maskinvareniv√•. Opp√• dette legger vi et operativsystem (OS) som har en scheduler for √• administrere hvor og n√•r de ulike prosessene og applikasjonstr√•dene vi √łnsker kj√łrende skal f√• nettopp kj√łretid. Typisk er denne scheduleren preemptiv slik at vi f√•r en f√łlelse av samtidighet, selv ved multiple oppgaver p√• samme CPU-tr√•d.

En av applikasjonene vi kj√łrer p√• dette OSet er en nettleser, som typisk kj√łrer et knippe applikasjons-tr√•der pr fane du har √•pen i tillegg til noen for generell funksjonalitet som brukergrensesnitt (vi √łnsker jo ikke at brukeren skal ha en d√•rligere enn n√łdvendig brukeropplevelse generelt selv om noen sider skulle henge litt - som i praksis er det samme argumentet som gj√łres for overnevnte funksjonstilvekst i React) og oppdateringssjekker mm. Disse gis da til OS-scheduleren for iblant √• f√• kj√łretid p√• maskinvaren.

I en av disse tr√•dene som kj√łres opp for en gitt fane s√• kj√łres det en javascriptmotor (f.eks. V8) hvis en av sine egenskaper er sin enkelttr√•dede event-loop scheduler som skal la utviklere skrive effektiv asynkron, IO-drevet kode, hvilket vi tar nytte av med tilbakekall og l√łfter.

I en slik applikasjonstråd gjenimplementerer vi nå da i praksis et subset av en scheduler tilsvarende det operativsystemet allerede har gjort mot maskinvaren (Concurrent mode/Suspense er noe mer meningsstyrt rundt bruk, men i bunn og grunn…).

Er det rart software generelt, og nettlesere med tilh√łrende nettapplikasjoner spesielt, i dag bruker perverst mye ressurser?

I tillegg kan vi da selvsagt for "g√ły" legge p√• denne som flytter nettleseren til "skyen".

La spesielt tanken på denne siste synke litt.

…

…

…

Siden dagens nettl√łsninger totalt sett bruker s√• mye ressurser som de gj√łr s√• tenkes det at l√łsningen er √• flytte h√•ndteringen av alt dette til ‚Äúskyen‚ÄĚ, og heller str√łmme det til deg lokalt.

Vi har da en klientklient <-> klient-i-skyen-som-ogs√•-er-en-str√łmmetjener <-> backend-l√łsning.

Min umiddelbare tanke: www og vår underliggende software/systemarkitetur er overmodent for et redesign (*).

Jeg er ikke sint - bare veldig fascinert.

(*) Det er et viktig poeng √• gj√łre at det er flere grunner til at weben har blitt s√•pass omfavnet og strukket til bristepunktet som applikasjonsplatform som den har; Blant annet de mange - og flere av disse, i dag, strengt tatt un√łdvendige - hindringene som gj√łr det s√¶rdeles vanskelig √• lage og distribuere kryssplatforml√łsninger p√• en m√•te hvor vi med stor grad av trygghet kan vite at det vil kj√łre som √łnsket. S√• for virkelig √• l√łse dette problemet m√• vi nok g√• dypere enn kun web.