Hvad LAMP, MERN, MEAN, TALL og andre webstacks betyder

Navne på webstacks bliver hurtigt forvirrende. PHP er et sprog. Laravel og Symfony er frameworks. WordPress er et CMS bygget på PHP. React er et bibliotek til frontend. 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 afgørende spørgsmål være: hvad indeholder stacken, hvilken type hjemmeside passer den til, og hvor svær bliver den at vedligeholde efter lancering?

For mindre virksomheder er den rigtige stack sjældent det nyeste akronym. Det er den stack, der holder hjemmesiden hurtig, stabil, redigerbar, nem for søgemaskiner at gennemgå og realistisk at vedligeholde.

Hvad en webstack egentlig er

En webstack er det sæt af teknologier, der arbejder sammen om at levere en hjemmeside eller en webapplikation.

Som minimum dækker den ofte:

• Server eller udbyder
• Sprog eller kørselsmiljø i backend
• Framework, CMS eller applikationsstruktur
• Database eller indholdskilde
• Frontendlag til skabeloner, komponenter, udseende og browseradfærd
• Hjælpesystemer som cache, køer, søgning, mail, CDN, udrulning, 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, køer, 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 web, virksomheder faktisk bruger: WordPress, WooCommerce, Laravel-applikationer, Symfony-applikationer, medlemssider, bookingsystemer, intranet, kontrolpaneler og specialudviklede 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 udbydere og stadig helt relevant til mange hjemmesider. En WordPress-hjemmeside på et almindeligt delt webhotel er ofte en form for LAMP.

LAMP passer til:

• WordPress- og WooCommerce-hjemmesider
• Mindre virksomhedshjemmesider
• PHP-applikationer der ikke kræver usædvanlig infrastruktur
• Projekter, hvor hjælp fra udbyderen 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 cache, gamle PHP-versioner eller en server, der er for svag til trafik og administration.

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 hastighedsorienterede opsætninger. Mange moderne udrulninger af PHP bruger Nginx sammen med PHP-FPM.

LEMP passer til:

• WordPress- eller Laravel-hjemmesider, der kræver mere serverkontrol
• Indholdshjemmesider med højere trafik
• Specialudviklede PHP-applikationer med tilpasset cache og ruter
• Projekter, hvor en udvikler eller en administreret udbyder har ansvaret for serverlaget

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

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ørernes arbejdsgange
• Cache
• Sikkerhedskopier
• Opdateringer
• Server 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. En langsom WordPress-hjemmeside er ofte ikke langsom, fordi den bruger WordPress. Den er langsom, fordi stacken er blevet uoverskuelig: tunge plugins, sider uden cache, store billeder, databasevækst, tredjepartsscripts og uklart ansvar.

Hvis det er situationen, er WordPress-udviklerhjælp eller en gennemgang af WordPress-hastigheden 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 lag til cache og køer
• Planlagte opgaver, køer, baggrundsprocesser, mail, lager, API’er og værktøjer til udrulning

Laravel passer til forretningssystemer, hvor WordPress bliver for upræcist: bookinglogik, kontrolpaneler, API-integrationer, interne værktøjer, særlige arbejdsgange, svar fra betalingssystemer, baggrundsopgaver og strukturerede datamodeller.

En servicevirksomhed kan eksempelvis have brug for bookingregler, CRM-synkronisering, betalingsstatus, interne kontrolpaneler og automatiske mails. Det er normalt applikationsarbejde, ikke arbejde i en sidebygger.

Se Laravel-udvikling og casen om et administrationssystem til ferieboliger for den type driftsnært arbejde, hvor arkitekturen i backend 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, køer, baggrundsprocesser og værktøjer til udrulning

Symfony er almindeligt i større specialudviklede 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 en enklere hjemmeside, en almindelig WordPress-hjemmeside eller en fokuseret Laravel-applikation.

TALL stack

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

Det er en Laravel-baseret stack til interaktive servergenererede applikationer uden at gøre alt til en stor enkeltsideapplikation. Laravel håndterer backend, Livewire forbinder tilstanden på serveren med brugerens handlinger i frontend, Alpine tilføjer små interaktioner i browseren, og Tailwind håndterer udseendet.

TALL passer til:

• Kontrolpaneler til administration
• Interne værktøjer
• Bookingstyring
• Formularer og arbejdsgange med moderat interaktivitet
• Applikationer, hvor Laravel-logik på serveren skal være central

Det er ofte en fornuftig mellemvej. Man får interaktivitet uden kompleksiteten fra et separat React- eller Vue-frontend.

JavaScript- og TypeScript-stacks

Navne på JavaScript-stacks er lette at blande sammen, fordi frontend, backend og buildværktøjer 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 serverruter eller API’er, React håndterer frontend, og MongoDB gemmer data som dokumenter.

MERN passer til:

• Specialudviklede webapplikationer
• Kontrolpaneler og applignende brugerflader
• 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 applikationer i frontend
• Teams der foretrækker Angular-konventioner
• Dashboards, portaler og interne apps med tydelige frontendarkitekturbehov

Det er sjældent det oplagte førstevalg til en simpel virksomhedshjemmeside. Det kan være et godt valg til en reel applikation med et hold, 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 passer ofte bedre.

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 generere sider på serveren, bygge statiske sider, kalde API’er og skabe applignende brugerflader. De er nyttige, når et projekt kræver en moderne frontend med ruter, komponenter og serveradfærd i samme framework.

De kan også blive overbrugt. Hvis en hjemmeside primært består af stabilt indhold, kan en løsning som Astro, der som udgangspunkt bygger statiske sider, være lettere at vedligeholde.

Statiske, headless og edge-stacks

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

JAMstack

JAMstack betød oprindeligt JavaScript, API’er og markup. I praksis beskriver det en arkitektur, hvor sider bygges på forhånd, leveres fra et CDN og kobles til API’er, når der er brug for dynamisk adfærd.

JAMstack passer til:

• Hurtige indholdshjemmesider
• Dokumentation
• Landingssider
• Blogs og guides
• Headless CMS-projekter
• Hjemmesider, hvor de fleste sider ikke skal genereres på serveren ved hver forespørgsel

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

Headless WordPress-stack

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

Det kan fungere, når redaktører har brug for WordPress, men den offentlige hjemmeside kræver bedre hastighed, mere kontrol over frontend eller en anden model for udrulning.

Det tilføjer kompleksitet: forhåndsvisning, viderestillinger, medier, cache, API’er, kompatibilitet med plugins og udrulning skal have tydelige ansvarlige. Læs guiden til headless WordPress, før det behandles som en automatisk opgradering.

Astro- og Cloudflare-stack

En Astro- og Cloudflare-stack bygger som udgangspunkt statiske sider:

• Astro til sider, komponenter, ruter og indholdssamlinger
• Markdown eller MDX til struktureret indhold
• TypeScript-modeller til validering af indhold
• Cloudflare til DNS, CDN, viderestillinger, HTTP-headere, cache og levering tæt på brugeren

Det er en stærk løsning til indholdstunge hjemmesider, der har brug for hurtige sider, teknisk SEO, tydelige interne links og vedligeholdeligt indhold. Det er også den type stack, der bruges i denne Astro-case om en indholdsplatform.

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

Serverløse stacks og edge-løsninger

Serverløse stacks og edge-løsninger bruger administrerede funktioner, workers, køer, lager og API’er i stedet for en traditionel server, der altid kører.

De passer til:

• Kontaktformularer
• Letvægts-API’er
• Webhooks
• Logik til viderestillinger og HTTP-headere
• Billedbehandling
• Planlagte opgaver
• Indholdshjemmesider med mange læsninger og få skrivninger

De kan reducere servervedligeholdelsen, men kræver klare beslutninger om grænser, logning, langsom første opstart, 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, skabeloner eller en separat frontend, cache, baggrundsprocesser og værktøjer til udrulning.

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

Ruby on Rails-stack

En Rails-stack bruger Ruby on Rails, normalt med PostgreSQL, servergenererede visninger eller en JavaScript-frontend, baggrundsopgaver, cache og værktøjer til udrulning.

Rails er produktivt til specialudviklede applikationer med tydelige konventioner. Det kan være stærkt, når holdet kender Rails, og projektet skal frem hurtigt uden at opfinde strukturen 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 store virksomheder og miljøer, der bygger tungt på Microsoft. For mindre virksomheder giver den mening, når eksisterende systemer, integrationer eller udviklerkompetencer peger den vej.

Go-stack

En Go-stack bruger Go til tjenester i backend, normalt med PostgreSQL, skabeloner eller en separat frontend, køer, API’er og udrulning i containere.

Go kan være stærkt til tjenester med høje krav til ydeevne, API’er og infrastrukturtunge systemer. Det er normalt ikke førstevalget til en simpel præsentationshjemmeside.

Shopify-stack

En Shopify-stack er en administreret e-handelsløsning. Den kan bestå af Shopify, Liquid-temaer, Shopify-apps, betalings- og fragtintegrationer, specialudviklet kode til butikken og nogle gange Hydrogen eller en separat frontend.

Den passer til e-handel, hvor produkter, betaling, lager, prisregler og administrative arbejdsgange håndteres bedre af en administreret platform end af en fuldt specialudviklet 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 en offentlig hjemmeside, et CMS, en webshop eller en specialudviklet applikation?
2. Hvem skal redigere indhold efter lancering?
3. Har hjemmesiden brug for login, booking, betaling, kontrolpaneler, API-integrationer eller baggrundsopgaver?
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 ligge, sikkerhedskopieres, overvåges og udrulles?
7. Hvor vigtige er adgang for søgemaskiner, hastighed, teknisk SEO og struktureret indhold?
8. Hvad kan fejle, og hvem opdager det?

Googles aktuelle dokumentation om søgning peger stadig tilbage på hjælpsomt indhold skrevet til mennesker, sider der kan gennemgås, klare sidetitler, nyttige links og en god sideoplevelse. Stacken betyder noget, fordi den kan gøre de grundlæggende ting lettere eller sværere — ikke fordi ét akronym automatisk giver bedre placeringer.

For en virksomhedshjemmeside er mine normale beslutningskriterier:

• Brug WordPress, når redigering, kendte arbejdsgange i CMS’et og udvalget af plugins betyder noget.
• Brug Laravel, når projektet reelt er en specialudviklet forretningsapplikation.
• Brug Astro og Cloudflare, når hjemmesiden 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, blot fordi en nyere stack lyder renere. Ofte er den bedre løsning forsigtig PHP-udvikling og modernisering eller målrettet teknisk SEO-hjælp.

Ofte stillede spørgsmål

Er “Laravel” eller “WordPress” en komplet stack i sig selv?

Nej. Laravel er et PHP-framework, og WordPress er et CMS; den faktiske stack er alt det, der er bygget omkring dem, som database, cachelag, server, CDN og værktøjer til udrulning. Hvis man kun nævner frameworket eller CMS’et, mangler det meste af driftsbilledet.

Er en langsom WordPress-hjemmeside som regel langsom, fordi den bruger WordPress?

Nej. Hjemmesiden er som regel langsom, fordi stacken er blevet uoverskuelig: tunge plugins, sider uden cache, for store billeder, databasevækst og tredjepartsscripts. Selve platformen er sjældent den reelle flaskehals.

Bør en nyere JavaScript-stack erstatte en fungerende PHP- eller WordPress-hjemmeside, bare fordi den lyder mere moderne?

Nej. Et eksisterende system, der allerede skaber henvendelser, bookinger eller omsætning, bør ikke erstattes af den grund alene. En nyere stack kan også tilføje flere bevægelige dele, end en indholdsfokuseret hjemmeside reelt har brug for.

Gør headless WordPress automatisk hjemmesiden hurtigere?

Nej. Det tilføjer reel kompleksitet: forhåndsvisning, viderestillinger, medier, cache og kompatibilitet med plugins skal alle have tydelige ansvarlige på tværs af to systemer i stedet for ét. Det bør derfor være et bevidst valg, ikke en standardopgradering.

Konklusionen

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. En mindre servicehjemmeside, en webshop, et bookingsystem og en specialudviklet intern platform kan sagtens kræve forskellige stacks.

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