Tom HTML-problemet

Prova det här: högerklicka på en stor sajt som Netflix eller Twitter. Välj "Visa källkod".

Vad ser du? Inte mycket. Kanske några meta-taggar, en länk till CSS och en ensam rad:

<div id="app"></div>

Inget annat. Allt innehåll – texten, bilderna, layouten – dyker upp senare. JavaScript-paket laddas ner i din webbläsare och fyller i resten efter att sidan ritats upp.

Så här har det inte alltid sett ut. Att fatta varför det blev så här är viktigt om du bygger webbappar. Särskilt om prestanda, tillgänglighet och SEO spelar roll.

Webben som dokument

På början var webben enkel. Webbläsaren bad om en HTML-fil. Servern skickade den. Webbläsaren visade den. Allt du såg fanns direkt i koden.

Det var en styrka, inte en svaghet.

Innehåll fick mening av sammanhanget. Ett datum i en artikel hörde ihop med texten runt omkring. En länk beskrevs av orden bredvid. Sidan var komplett och läsbart i källkoden.

Visa källkod var inte bara för felsökning. Det var ett löfte om öppenhet.

Även när servrar fick bli smartare med CGI, PHP eller ASP höll det ihop. HTML genererades från databaser, men användaren fick en färdig sida. Templats, CSS och logik smälte ihop innan den skickades.

Sidans kärna var alltid helheten.

Vendepunkten: AJAX förändrar spelet

Sedan kom XMLHttpRequest. Plötsligt kunde webbläsare hämta data utan att ladda om hela sidan.

Det fick namnet AJAX på 2000-talet. Google Maps visade vägen – silkeslent, snabbt, som en riktig app.

Behovet var äkta. Varför ladda om allt för en liten uppdatering? AJAX fixade riktiga problem. Användare ville ha mer flyt. Utveckare ville leverera det.

Men det kom med ett pris.

Offret vi gjort

Runt 2010-talet växte en ny approach fram:

1. Skicka minimal HTML, bara en behållare.
2. Ladda en JavaScript-app.
3. Hämta data via API:er.
4. Bygg upp gränssnittet i webbläsaren.

Ramverk som React, Angular och Vue hjälpte till. De löste svåra bitar: hantera tillstånd, återanvända komponenter, jobba i stora team. Vissa appar hade varit omöjliga annars.

Men det vände upp och ner på webben.

Vad vi tappat (och varför det spelar roll)

Webben slutade vara lätt att inspektera.

Idag stämmer inte HTML med det du ser. Innehållet saknas i koden. Den där <div id="app"></div> väntar på JavaScript.

För utvecklare betyder det krångel. Du måste spåra kod, API-anrop och tillståndsändringar för att fatta sidan.

För maskiner är det värre. Sökmotorer för SEO, AI som analyserar innehåll, skärmläsare för tillgänglighet – de kämpar. De måste köra JavaScript, simulera klick och följa förändringar för att greppa innehållet.

En sökmotor läser inte längre bara din HTML. Tillgänglighetsverktyg missar strukturen. AI för träning kräver headless browsers och massor av resurser.

Ett tecken på större förändringar

Det handlar inte bara om JavaScript eller ramverk. Det är ett tankeskifte.

Gammal modell: Sidan är ett dokument med inneboende mening.
Ny modell: Sidan är en behållare för gränssnitt, mening finns någon annanstans.

Dokument förklarar sig själva. Gränssnitt kräver tolkning. Vi vann smidighet och rikedom. Vi förlorade transparens.

För appar som Figma eller Slack är det värt det. De måste vara appar, inte dokument.

Men mönstret har blivit standard. Enkelna bloggar och landningssidor byggs som single-page apps. Vi har svängt för långt.

Vad det betyder för NameOcean-kunder

På NameOcean tänker vi på det här. Din domain och hosting ska passa din app – inte tvinga dig in i onödig komplexitet.

Bygger du innehållssajt, landningssida eller texttungt? Välj server-side rendering (SSR) eller statisk generering. Låt HTML bära mening. Sökmotorer fattar direkt. Långsamma uppkopplingar visar innehåll snabbt.

Bygger du interaktiv app – dashboard, designverktyg, realtids-samarbete? Client-side funkar bra. Men väg för- och nackdelar.

Viktigt: välj medvetet, inte för att det är trendigt.

Framtidens väg

Webben går mot balans. Moderna ramverk mixar: SSR för snabbladdning, client-side för interaktion, statisk för statiskt innehåll.

Next.js, Svelte och Astro visar att det inte är svartvitt. Du kan blanda dokument och appar.

Men det kräver eftertanke. Välj arkitektur efter behov, inte vana. Bygg så det är sökbart, tillgängligt och öppet – samtidigt som det är kraftfullt.

Webbens bästa stunder kommer när vi ser att transparens och styrka hör ihop.