Hvad LAMP, MERN, MEAN, TALL og andre web stacks betyder

Navne på webudvikling stacks bliver hurtigt forvirrende. PHP er et sprog. Laravel og Symfony er frameworks. WordPress er et CMS bygget på PHP. React er et frontendbibliotek. MERN, MEAN, LAMP og TALL er stacks, fordi de beskriver flere teknologier, der bruges sammen.

Betegnelserne er ikke altid helt præcise, og udviklere bruger ordene lidt forskelligt. Derfor bør det praktiske spørgsmål være: hvad indeholder stacken, hvilken type website passer den til, og hvor svær bliver den at vedligeholde efter lancering?

For mindre danske virksomheder er den rigtige stack sjældent det nyeste akronym. Det er den stack, der holder websitet hurtigt, stabilt, redigerbart, crawlable og realistisk at supportere.

Hvad en web stack egentlig er

En web stack er sættet af teknologier, der arbejder sammen om at levere et website eller en webapplikation.

Som minimum dækker den ofte:

• Server eller hosting
• Backend-sprog eller runtime
• Framework, CMS eller applikationsstruktur
• Database eller indholdskilde
• Frontendlag til templates, komponenter, styling og browseradfærd
• Hjælpesystemer som cache, queues, søgning, mail, CDN, deployment, statistik og overvågning

Derfor er “Laravel” alene ikke en fuld stack. Laravel er et PHP-framework. Et Laravel-projekt kan bruge PHP, Laravel, Blade, MySQL, Redis, queues, Tailwind CSS, Alpine.js, Nginx, GitHub Actions, Cloudflare og en betalingsudbyder. Den samlede kombination er stacken.

Det samme gælder Symfony, React, Angular, Vue, Astro, Django, Rails og WordPress. De er vigtige dele af en stack, men ikke hele driftsbilledet.

Klassiske PHP-stacks

PHP-stacks betyder stadig noget, fordi de driver en stor del af det praktiske web: WordPress, WooCommerce, Laravel-applikationer, Symfony-applikationer, medlemssites, bookingsystemer, intranet, dashboards og custom forretningsværktøjer.

LAMP

LAMP betyder Linux, Apache, MySQL eller MariaDB og PHP.

Det er den klassiske PHP-stack. Den er almindelig, velkendt, bredt understøttet af hostingudbydere og stadig helt relevant til mange websites. Et WordPress-site på almindelig shared hosting er ofte en form for LAMP.

LAMP passer til:

• WordPress og WooCommerce-sites
• Mindre virksomhedswebsites
• PHP-applikationer der ikke kræver usædvanlig infrastruktur
• Projekter hvor hostingsupport og forudsigelig vedligeholdelse betyder mere end nyhedsværdi

Svagheden er sjældent PHP i sig selv. Svagheden er typisk et tungt tema, for mange plugins, dårlig caching, gamle PHP-versioner eller hosting, der er for svag til trafik og adminarbejde.

LEMP

LEMP betyder Linux, Nginx, MySQL eller MariaDB og PHP.

Forskellen fra LAMP er webserveren: Nginx i stedet for Apache. Nginx er almindelig i VPS-, container- og performanceorienterede opsætninger. Mange moderne PHP-deployments bruger Nginx sammen med PHP-FPM.

LEMP passer til:

• WordPress- eller Laravel-sites der kræver mere serverkontrol
• Indholdssites med højere trafik
• Custom PHP-applikationer med tilpasset caching og routing
• Projekter hvor en udvikler eller managed host ejer serverlaget

For en dansk virksomhed kan LEMP være nyttigt, når performance og serverkonfiguration betyder noget, men det kræver også, at nogen ejer opsætningen ordentligt.

WAMP, MAMP og XAMPP

WAMP, MAMP og XAMPP er normalt lokale udviklingsstacks.

• WAMP: Windows, Apache, MySQL, PHP
• MAMP: macOS, Apache, MySQL, PHP
• XAMPP: cross-platform Apache, MariaDB, PHP og relaterede værktøjer

De er nyttige til at køre PHP lokalt, især til WordPress-test. De bør ikke forveksles med en produktionsarkitektur.

WordPress som stack

WordPress er ikke bare “PHP”. En reel WordPress-stack indeholder:

• PHP
• WordPress core
• MySQL eller MariaDB
• Et tema
• Plugins
• Mediehåndtering
• Brugerroller og redaktørflows
• Caching
• Backups
• Opdateringer
• Hosting og CDN-regler

Stacken er stærk, når ikke-tekniske brugere skal redigere indhold, udgive artikler, styre landingssider eller drive WooCommerce med kendte værktøjer.

Den bliver svag, når hvert problem løses med endnu et plugin. Et langsomt dansk WordPress-site er ofte ikke langsomt, fordi det bruger WordPress. Det er langsomt, fordi stacken er blevet uoverskuelig: tunge plugins, sider uden cache, store billeder, databasevækst, tredjepartsscripts og uklart ejerskab.

Hvis det er situationen, er WordPress-udviklerhjælp i Danmark eller en WordPress performance-audit et bedre første skridt end en fuld genopbygning.

Laravel, Symfony og PHP-applikationsstacks

Laravel og Symfony er frameworks. Stacken er det, der bygges omkring dem.

Laravel-stack

En Laravel-stack indeholder ofte:

• PHP
• Laravel
• Blade, Livewire, Inertia, Vue, React eller en anden frontendtilgang
• MySQL, MariaDB, PostgreSQL eller en anden database
• Redis eller et andet cache- og queuelag
• Scheduler, queues, workers, mail, storage, API’er og deploymentværktøjer

Laravel passer til forretningssystemer, hvor WordPress bliver for upræcist: bookinglogik, dashboards, API-integrationer, interne værktøjer, custom arbejdsgange, betalings-callbacks, baggrundsjobs og strukturerede datamodeller.

En dansk servicevirksomhed kan eksempelvis have brug for bookingregler, CRM-synkronisering, betalingsstatus, interne dashboards og automatiske mails. Det er normalt applikationsarbejde, ikke page-builder-arbejde.

Se Laravel-udvikler i Danmark og klik.villas PMS-casen for den type driftsnært arbejde, hvor backendarkitektur betyder noget.

Symfony-stack

En Symfony-stack indeholder ofte:

• PHP
• Symfony-komponenter eller hele Symfony-frameworket
• Doctrine til databasemapping
• Twig, API Platform eller et separat frontendlag
• PostgreSQL, MySQL, Redis, queues, workers og deploymentværktøjer

Symfony er almindeligt i større custom PHP-systemer og applikationer, der kræver stærk struktur, langsigtet vedligeholdelse, genbrugelige komponenter og tydelig arkitektur.

For en mindre virksomhed kan Symfony være fremragende, hvis projektet reelt kræver den struktur. Det kan også være unødvendigt, hvis behovet er et enklere website, et almindeligt WordPress-site eller en fokuseret Laravel-applikation.

TALL stack

TALL betyder Tailwind CSS, Alpine.js, Laravel og Livewire.

Det er en Laravel-baseret stack til interaktive server-renderede applikationer uden at gøre alt til en stor single-page app. Laravel håndterer backend, Livewire forbinder server-side state med frontendinteraktioner, Alpine tilføjer små browserinteraktioner, og Tailwind håndterer styling.

TALL passer til:

• Admin dashboards
• Interne værktøjer
• Bookingstyring
• Formularer og arbejdsgange med moderat interaktivitet
• Applikationer hvor server-side Laravel-logik skal være central

Det er ofte et praktisk mellemvalg. Man får interaktivitet uden kompleksiteten fra et separat React- eller Vue-frontend.

JavaScript- og TypeScript-stacks

JavaScript-stacknavne er lette at blande sammen, fordi frontend, backend og build tooling alle kan bruge JavaScript eller TypeScript.

MERN stack

MERN betyder MongoDB, Express, React og Node.js.

Det er en JavaScript-stack, hvor Node.js kører backend, Express håndterer serverroutes eller API’er, React håndterer frontend, og MongoDB gemmer data som dokumenter.

MERN passer til:

• Custom webapplikationer
• Dashboards og app-lignende interfaces
• Projekter hvor samme JavaScript- eller TypeScript-team håndterer frontend og backend
• Datamodeller der passer godt til dokumentlagring

MERN er ikke en PHP-stack. Den bruger som udgangspunkt ikke Laravel, Symfony, WordPress eller PHP.

Risikoen er, at mange MERN-projekter bliver mere komplekse, end forretningen har brug for. Hvis projektet mest handler om indhold, ydelsessider, artikler og henvendelser, kan MERN tilføje bevægelige dele uden at forbedre resultatet.

MEAN stack

MEAN betyder MongoDB, Express, Angular og Node.js.

Den minder om MERN, men Angular erstatter React. Angular er et fuldt frontendframework med stærkere holdninger til applikationsstruktur.

MEAN passer til:

• Større frontendapplikationer
• Teams der foretrækker Angular-konventioner
• Dashboards, portaler og interne apps med tydelige frontendarkitekturbehov

Det er sjældent det oplagte førstevalg til et simpelt marketingwebsite. Det kan være et godt valg til en reel applikation med et team, der allerede kender Angular godt.

MEVN stack

MEVN betyder MongoDB, Express, Vue og Node.js.

Den følger samme mønster som MERN og MEAN, men bruger Vue til frontend. For nogle teams kan den være lettere at gå til end Angular og stadig stærk nok til seriøst applikationsarbejde.

PERN stack

PERN betyder PostgreSQL, Express, React og Node.js.

Den minder om MERN, men erstatter MongoDB med PostgreSQL. Det betyder noget, når data er relationelle: brugere, ordrer, bookinger, betalinger, produkter, lager, fakturaer og rapportering.

For mange forretningssystemer er PostgreSQL et bedre standardvalg end MongoDB, fordi data har relationer og konsistensregler. Akronymet er mindre kendt end MERN, men databasevalget kan være mere praktisk.

Next.js, Nuxt og SvelteKit stacks

Next.js, Nuxt og SvelteKit er framework-centrerede JavaScript-stacks.

• Next.js er bygget omkring React
• Nuxt er bygget omkring Vue
• SvelteKit er bygget omkring Svelte

Disse stacks kan rendere sider på serveren, generere statiske sider, kalde API’er og bygge app-lignende frontends. De er nyttige, når et projekt kræver et moderne frontend med routing, komponenter og server-side adfærd i samme framework.

De kan også blive overbrugt. Hvis et site primært er stabilt indhold, kan en static-first opsætning som Astro være lettere at vedligeholde.

Statiske, headless og edge-stacks

Ikke alle websites har brug for en traditionel applikationsserver for hver sidevisning.

JAMstack

JAMstack betød oprindeligt JavaScript, APIs og Markup. I praksis beskriver det en static-first arkitektur, hvor sider prebuildes, leveres fra en CDN og kobles til API’er, når der er brug for dynamisk adfærd.

JAMstack passer til:

• Hurtige indholdswebsites
• Dokumentation
• Landingssider
• Blogs og guides
• Headless CMS-projekter
• Sites hvor de fleste sider ikke kræver serverrendering ved hver request

Fordelen er hastighed, sikkerhed og enklere levering. Svagheden viser sig, når projektet faktisk kræver loginflows, kompleks realtidsdata eller mange dynamiske forretningsregler.

Headless WordPress-stack

En headless WordPress-stack beholder WordPress som CMS, men bruger et separat frontend som Astro, Next.js, Nuxt eller et andet framework.

Det kan fungere, når redaktører har brug for WordPress, men det offentlige site kræver stærkere performance, renere frontendkontrol eller en anden deploymentmodel.

Det tilføjer kompleksitet: preview, redirects, medier, caching, API’er, plugin-kompatibilitet og deployment skal ejes tydeligt. Læs headless WordPress i Danmark før det behandles som en automatisk opgradering.

Astro og Cloudflare stack

En Astro og Cloudflare stack er static-first:

• Astro til sider, komponenter, routing og content collections
• Markdown eller MDX til struktureret indhold
• TypeScript-schemas til content-validering
• Cloudflare til DNS, CDN, redirects, headers, caching og edge-adfærd

Det er en stærk løsning til indholdstunge danske websites, der har brug for hurtige sider, teknisk SEO, tydelige interne links og vedligeholdeligt indhold. Det er også den type stack, der bruges i WhyBangkok.com Astro-casen.

Den dybere forklaring ligger i Astro + Cloudflare til AI-klare websites i Danmark.

Serverless og edge-stacks

Serverless og edge-stacks bruger managed functions, workers, queues, storage og API’er i stedet for en traditionel server, der altid kører.

De passer til:

• Kontaktformularer
• Letvægts-API’er
• Webhooks
• Redirect- og headerlogik
• Billedbehandling
• Scheduled tasks
• Content-sites med mange læsninger og få skrivninger

De kan reducere servervedligeholdelse, men kræver klar tænkning om limits, logging, cold starts, datalagring og platformspecifik adfærd.

Andre almindelige applikationsstacks

Nogle stacks er ikke PHP- eller JavaScript-first, men de er almindelige nok til at kende.

Django-stack

En Django-stack bruger Python og Django, ofte med PostgreSQL, templates eller et separat frontend, cache, workers og deploymentværktøjer.

Den passer til indholdsplatforme, admin-tunge applikationer, databaserede systemer og teams, der foretrækker Python. Djangos indbyggede admin kan være en praktisk fordel.

Ruby on Rails-stack

En Rails-stack bruger Ruby on Rails, normalt med PostgreSQL, server-renderede views eller et JavaScript-frontend, background jobs, cache og deploymentværktøjer.

Rails er produktivt til custom applikationer med tydelige konventioner. Det kan være stærkt, når teamet kender Rails, og projektet skal frem hurtigt uden at opfinde struktur fra bunden.

ASP.NET-stack

En ASP.NET-stack bruger C# og .NET, ofte med SQL Server eller PostgreSQL, Razor, Blazor, API’er, Azure, containere eller Windows/Linux-hosting.

Den er almindelig i corporate, Microsoft-tunge og enterprise-miljøer. For mindre virksomheder giver den mening, når eksisterende systemer, integrationer eller udviklerkompetencer peger den vej.

Go-stack

En Go-stack bruger Go til backend-services, normalt med PostgreSQL, templates eller et separat frontend, queues, API’er og containerdeployment.

Go kan være stærkt til services med høj performance, API’er og infrastrukturtunge systemer. Det er normalt ikke førstevalget til et simpelt præsentationswebsite.

Shopify-stack

En Shopify-stack er en managed commerce-stack. Den kan bestå af Shopify, Liquid-temaer, Shopify-apps, betalings- og fragtintegrationer, custom storefront-kode og nogle gange Hydrogen eller headless frontendarbejde.

Den passer til ecommerce, hvor produkt, checkout, betaling, lager, moms og adminflows er bedre håndteret af en managed platform end af en fuldt custom løsning.

Sådan vælger du uden at drukne i navne

Vælg ikke stack efter akronym. Vælg efter begrænsninger.

Stil først disse spørgsmål:

1. Er det primært et offentligt website, et CMS, en webshop eller en custom applikation?
2. Hvem skal redigere indhold efter lancering?
3. Har sitet brug for login, booking, betaling, dashboards, API-integrationer eller baggrundsjobs?
4. Fungerer eksisterende kode allerede og skal forbedres frem for erstattes?
5. Hvilke udviklere kan vedligeholde løsningen om to år?
6. Hvor skal den hostes, backuppes, overvåges og deployes?
7. Hvor vigtige er crawlability, hastighed, teknisk SEO og struktureret indhold?
8. Hvad kan fejle, og hvem opdager det?

Googles aktuelle Search-dokumentation peger stadig tilbage på hjælpsomt indhold skrevet til mennesker, crawlable sider, klare titles, nyttige links og god page experience. Stacken betyder noget, fordi den kan gøre de grundlæggende ting lettere eller sværere — ikke fordi ét akronym automatisk rangerer bedre.

For et dansk virksomhedswebsite er min praktiske standardtænkning:

• Brug WordPress, når redigering, kendte CMS-flows og pluginøkosystemet betyder noget.
• Brug Laravel, når projektet reelt er en custom forretningsapplikation.
• Brug Astro og Cloudflare, når sitet primært er offentligt indhold, og hastighed, struktur og vedligeholdelse betyder meget.
• Brug en JavaScript-applikationsstack, når produktet faktisk er app-lignende, og teamet kan vedligeholde det.
• Behold ældre PHP, hvis det virker, og modernisér kontrolleret i stedet for at omskrive per refleks.

Det sidste punkt er vigtigt. Et eksisterende PHP- eller WordPress-system, der skaber henvendelser, bookinger eller omsætning, bør ikke erstattes bare fordi en nyere stack lyder renere. Ofte er den bedre løsning praktisk PHP-udvikling, modernisering af legacy PHP eller målrettet teknisk SEO-hjælp.

Den praktiske konklusion

En stack er et arbejdende system, ikke et mærkat.

LAMP og LEMP er klassiske PHP-serverstacks. WordPress er en CMS-stack. Laravel og Symfony er framework-centrerede PHP-applikationsstacks. TALL er en Laravel-stack. MERN, MEAN, MEVN og PERN er JavaScript-applikationsstacks. JAMstack, Astro, headless WordPress, serverless og edge beskriver forskellige måder at levere indhold og funktionalitet på.

Det rigtige valg afhænger af opgaven. Et mindre dansk servicewebsite, en webshop, et bookingsystem og en custom intern platform kan sagtens kræve forskellige stacks.

Hvis du er i tvivl om et eksisterende site bør blive på WordPress, flyttes mod Laravel, bygges i Astro eller kobles anderledes til API’er, kan du sende URL’en og hvad du vil forbedre. Så kan jeg hjælpe med at skille de nyttige arkitekturbeslutninger fra akronymerne.