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.