JAMStack är ett enkelt koncept, men kan vara tekniskt komplicerat och leder ofta till förvirring. Vi ska göra ett försök att reda ut vad JAMStack är och varför vi valde att bygga hemsidor i det.

Själva grundidéen för JAMStack är att ge utvecklare möjligheten att bygga hemsidor som laddas så snabbt som möjligt utan att tumma på varken design eller funktion. För att åstadkomma maxad prestanda används trion JavaScript, API’s och Markdown (JAM) som en överenskommen standard, där det mest intressanta kanske är M’et. Markdown är, likt HTML, ett så kallat markup-språk. Dvs det är inte ett programmeringsspråk utan ett språk som används för att beskriva innehåll och visa upp det på ett snyggt sätt på en datorskärm. 

Själva innehållet på en hemsida som texter och bilder, rubriker, blogginlägg, nyheter, länkar, kontaktinformation osv. måste kunna skrivas och redigeras av andra än programmerare. Något som görs i ett Content Management System (CMS). På detta vis funkar de flesta hemsidor, JAMStack och icke-JAMStack. Den stora skillnaden är NÄR detta innehåll hämtas. För en hemsida byggd utan JAMStack är det standard att innehållet hämtas EFTER att hemsidan har laddats ner av besökaren och att det i efterhand bakas in i hemsidans HTML. Fördelen med detta är att det har varit enkelt att bygga dynamiska sidor som anpassar utseendet efter innehållet från ett CMS utan att själva hemsidan behöver byggas om av programmerare. Nackdelen blir sämre prestanda, sämre SEO, sämre säkerhet och svårare skalbarhet. 

Med JAMStack vänder man på detta och hämtar direkt hem allt innehåll och bakar i förväg in det i hemsidans HTML. Det vill säga, hämtningen av innehåll sker INNAN hemsidan laddas ner av en besökare. Genom att standardisera allt innehåll i Markup (M'et) och bygga kraftfulla JavaScript-ramverk, som laddar detta innehåll via ett API (ofta GraphQL), skapas all HTML i det så kallade “bygg”-steget av hemsidan då de statiska filerna skapas. 

Genom att hämta innehållet i förväg plockar man bort behovet för webbläsare att hämta data från en server, och det är detta faktum som leder till fördelarna med JAMStack. Dels tar det onödig tid att hämta innehåll från ett CMS varje gång hemsidan laddas av en webbläsare, men det är också så att en server är betydligt långsammare på att leverera data än det CDN där hemsidan hämtas ifrån. Prestanda-boosten från detta är betydande och det är mer eller mindre omöjligt att nå samma resultat med en dynamisk hemsida utan att på något vis plocka bort servern från denna ekvation.

Det är även stor skillnad mellan ett CDN och en server. Servern kör kod som hämtar data från någon form av databas medan ett CDN endast levererar statiska filer. En server innehåller operativsystem, program och databaser varav alla dessa går att hacka och innebär säkerhetsrisker. Speciellt om ditt CMS råkar vara WordPress. Då gäller det att hålla sig ajour med de säkerhetsuppdateringar som kommer ut, för operativsystemet, för databasen, för WordPress och för alla de plugin man använder. Att uppdatera kod innebär också en risk att hemsidan slutar funka och behöver plåstras om. Detta kräver en hel del jobb som man helt enkelt slipper med JAMStack.

Sist men absolut inte minst bör utvecklarupplevelsen för oss programmerare omnämnas. Att kunna jobba i ett modernt JavaScript-ramverk (i vårt fall GatsbyJS, byggt på ReactJS) är en fröjd. All den kraft och potential som dessa kommer med ska inte på något vis underskattas. Själv utsattes jag för PHP (det språk WordPress är byggt i) tidigt i min karriär och har sedan dess hållit mig på behörigt avstånd. Eftersom JAMStack-hemsidor genereras upp i förväg gör också att förutsägbarheten för hur den kommer se ut för en besökare är 100%. Det finns ingen kod på en server som kan ställa till det, utan du vet exakt vad som levereras till webbläsaren.