"Men, hva er egentlig Vite?"
kode24s Ole Petter har ved ett par anledninger stilt dette spørsmålet i kode24-timen.
Jeg tror at enkleste måten å forstå er å ta ett stort skritt tilbake og se litt på hvor vi kommer fra.
JavaScript i gamledager
Et godt stykke tilbake i tid var JavaScript ganske rett frem og ukomplisert. En la inn en tag i HTML-fila si, og skrev koden sin der. En kunne selvfølgelig velge å skrive det i en egen fil og referere til denne fra HTML-fila, men fortsatt var det ganske rett frem.
Denne enkle hverdagen hadde imidlertid sine utfordringer. Måten JavaScript er laget på gjør at det meste havner i et globalt navnerom, noe som fort kunne resultere i konflikter.
Hvis en lastet inn JavaScript fra tredjepart, eller begynte å få litt mye JavaScript kode selv, kunne en for eksempel ha variabler eller funksjoner som het det samme og på den måten skape feil som ikke bare var enkle å finne ut av. Dette var selvfølgelig også en egenskap som kunne utnyttes, og begreper som 'monkey-patching' oppsto - det vil si at en bevist overskrev eller 'tuklet med' andre sin JavaScript kode.
Etter hvert dannet det seg noen praksiser - eller mønster - for hvordan en kunne beskytte koden sin i et eget scope. Det var ikke lenger 'god kutyme' å legge koden sin i det globale navnerommet. Ei heller å utnytte at andre gjorde det.
QXL legger ned etter 23 år: - Dette er trist
IIFE - en modul blir til
IIFE er en forkortelse for Immediately Invoked Function Expression.
Enkelt forklart vil det si at en definerer en funksjon for så å kalle denne funksjonen umiddelbart. Funksjonen blir ikke gitt noe navn og vil ikke være mulig å bruke ellers i koden. Den er der ene og alene for å tvinge frem et nytt isolert navnerom.
På denne måten kunne utviklere beskytte sine variabler og funksjoner fra annen JavaScript kode. En kunne i større grad styre hvilken del av koden som skulle være tilgjengelig for annen kode, og hva som skulle anses som privat.
// Eksempel på IIFE
var teller = (function(){
var privatTeller = 0;
function nullstill() { privatTeller = 0; }
function tellOpp() { privatTeller += 1; }
function tellNed() { privatTeller -= 1; }
function teller() { return privatTeller; }
return {
teller: teller,
opp: tellOpp,
ned: tellNed
};
})I dette lille eksemplet vil det globale navnerommet ha en variabel teller. På denne variabelen finnes det tre funksjoner: teller(), opp() og ned(). Selv om det finnes en funksjon nullstill() vil en ikke kunne kalle denne funksjonen. En har heller ikke mulighet til å 'tukle' med variabelen privatTeller.
En felles standard == nok en standard
Etter hvert så ble det klart at det å bryte JavaScript koden opp i moduler på var en god ting. Men verktøyet en hadde tilgjengelig - IIFE - var kanskje ikke så bra.
En begynte også å leke med tanken om å bruke JavaScript server side, og i den forbindelse dukket CommonJS opp. En kunne nå definere en module og på denne kunne en ha exports. En kunne også benytte require( ) for å få tilgang til exports fra andre moduler.
CommonJS var greit nok, men hadde den svakheten at det lastet moduler synkront. I nettleseren betyr det at alt stopper litt opp mens en venter på at modulen lastes.
Nå har internett drept databladene – og jeg savner dem!
Det ville vært en fordel om en i stede kunne laste flere moduler samtidig slik at alt ble fortere klart. Og dermed fikk vi Asynchronous Module Definition (AMD) og deretter Universal Module Definition (UMD) slik at vi kunne få både i pose og sekk...
Jeg skal ikke dykke videre ned i historien her. Poenget er at det fantes ett behov for modularisering av koden, og det dukket opp flere løsninger for dette problemet. Noen løsninger var bra for bruk i nettleser, andre var bra for bruk med nodejs.
Det dukker nå opp verktøy for å hjelpe utviklerne med å utnytte de nye modulformatene. Verktøy som leser all kildekoden og forstår hvilken rekkefølge ting må lastes for at alle skal ha tilgang til alt de trenger til rett tid. En bruker også disse verktøyene til å samle all koden inn i én fil. Fjerne kode som ikke egentlig er i bruk. Rote til navnene til alle funksjoner og variabler slik at ikke 'hackere' kan trykke 'View Source' i nettleseren og stjele koden din.
ES6
På dette tidspunktet var en ganske enige om hvordan JavaScript skulle se ut og fungere. Og dermed lå veien åpen for å videreutvikle språket.
For eksempel ble det definert nye nøkkelord let og const som skulle ta over for var. Med const kunne en være trygg på at en variabel ikke ble endret utilsiktet. Og med let kunne en være trygg på at variabelen kun var tilgjengelig der den var ment å være tilgjengelig.
Både The Gathering og Dagbladet brukte dette hacket på 90-tallet
I samme utvidelse av EcmaScript standarden ble det også definert et nytt modulformat: ES6 modules. Denne definerte import og export nøkkelord som en kunne bruke for å hente inn avhengigheter fra andre moduler, og eksponere sitt eget api for andre.
Men det er ett problem med den nye standarden: Nettleserne støtter ikke standarden... I alle fall ikke alle...
Igjen lages det nye verktøy. Verktøy som kan ta den nye Javascript-koden og skrive den om til gammel Javascript-kode, slik at en er sikker på at nettleserne forstår den. Bytte let og const tilbake til var. Skrive om import og export til UDM eller AMD.
Webpack
Det tok ikke lang tid før Webpack sto frem som Løsningen med stor L.
Webpack prosesserer alle filene dine og pakker dem sammen til nye format. Ikke bare Javascript-kode, men ved hjelp av plugins kan den også lage css fra Syntactically Awesome Style Sheets (SASS). Eller komprimere bilder. Den kan også kaste stiler du ikke bruker, eller splitte all koden din opp i mindre moduler slik at ting lastes i nettleseren først når det trengs å lastes.
Webpack både er og var et kjempebra verktøy. Det er bare ett problem: Det går ikke veldig fort. Siden Webpack pakker sammen flere filer må den lese og skrive flere filer hver gang en gjør en endring. Mange av verktøyene Webpack bruker for å prosessere filene den leser er JavaScript baserte verktøy og det hjelper ikke på hastigheten.
Tande P viste internett til Norge i 1994
Vite
Vite ønsker først og fremst å gjøre noe med tiden utviklere bruker på å vente. Tiden det tar fra en gjør en endring på koden til en kan se endringen i applikasjonen.
Det er hovedsakelig to ting Vite har gjort for å få ned denne ventetiden:
- Den benytter ESBuild til å pakke sammen alle tredjeparts bibliotek du benytter. ESBuild er veldig rask på dette, og siden du sjeldent legger til nye avhengigheter trengs det ikke gjøres så ofte.
- Den utnytter det faktum at de fleste nettlesere i dag støtter ES-moduler. Det betyr at i stede for å pakke sammen all koden din i én fil, kan nettleseren laste én og én fil etterhvert som den trenger det. Dersom du gjør oppdatering på en fil, kan Vite be nettleseren om å laste denne ene fila på nytt i stede for å lage en ny stor pakke med alt.
«Prisen en har betalt for dette er litt mindre fleksibilitet.»
Men hva er da Create-React-App (CRA)?
Create-react-app er en ferdig sammensatt pakke av verktøy og konfigurasjon, laget for å gjøre det enkelt å komme i gang med React.
Dette har vært en bra ting for mange. En har sluppet å tenke på hvilket verktøy en skal bruke for å pakke sammen koden sin, og en har også kunne benytte seg av JSX uten å tenke på når og hvordan Babel gjør om JSX koden til React.createElement()-kall.
En har også fått ferdige script for å starte, teste og publisere applikasjonen sin.
Prisen en har betalt for dette er litt mindre fleksibilitet. Dersom en har behov som ikke dekkes av standard konfigurasjon har det vært tildels vanskelig å løse dette. CRA sin løsning har vært å 'skyte ut' (eject) applikasjonen - eller ta bort CRA og eksponere de underliggende verktøy og konfigurasjoner.
En annen pris en har betalt er at utviklerne av CRA ikke alltid er i stand til å holde tritt med resten av react-miljøet. Da for eksempel Vite kom med økt hastighet, er ikke dette noe brukere av CRA får glede av.
