Het lege HTML-mysterie

Probeer het eens: rechtermuisklik op een grote site als Netflix of Twitter en kies 'Bron bekijken'.

Wat je ziet? Weinig. Een handvol meta-tags, een link naar CSS en dit:

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

Dat is alles. De echte inhoud – teksten, afbeeldingen, structuur – komt later. JavaScript haalt het op en pompt het in die lege div. De browser downloadt eerst dikke JS-pakketten, runt ze en dan pas verschijnt de pagina.

Zo werkte het vroeger niet. Wie dit snapt, bouwt slimmere webapps. Vooral als performance, toegankelijkheid of SEO telt.

Vroeger: het web als document

Het oorspronkelijke web was simpel. Browser vraagt HTML op, server stuurt het, browser toont het. Alles op je scherm stond in de HTML. Bekijk de bron, en je zag precies wat er gebeurde.

Dat was geen gebrek, maar een kracht. Context maakte alles duidelijk. Een datum in een verhaal? Omringd door uitleg. Een link? Met beschrijvende tekst ernaast. De pagina was compleet op zichzelf, altijd te inspecteren.

'View Source' was geen debug-truc. Het was pure openheid.

Zelfs met dynamische servers (CGI, PHP) bleef dat zo. Data uit databases, templates en logica versmolten tot één volledig document. Jij kreeg de hele pagina, klaar voor gebruik.

De ommekeer: AJAX verandert alles

Toen kwam XMLHttpRequest. Browsers konden data ophalen zonder de hele pagina te herladen. Mid-jaren 2000 noemden we dat AJAX. Google Maps was de ster: soepel, interactief, bijna als een app.

Logisch toch? Waarom alles herladen voor één update? AJAX maakte het web rijker, responsiever. Gebruikers en devs wilden dat.

Maar er zat een addertje onder het gras.

De prijs van vooruitgang

Rond 2010 werd het de norm:

1. Stuur minimale HTML (een lege houder)
2. Laad een JS-app
3. Haal data via API's
4. Vul de boel runtime met JS

Frameworks als React, Angular en Vue maakten dit mogelijk. Ze tackelden echte pijn: state, herbruikbare componenten, schaalbare teams. Zonder ze geen complexe apps.

Toch markeerde dit een breuk met het oude web.

Wat we kwijt zijn (en waarom dat telt)

Het web is niet meer direct te lezen.

De HTML toont zelden wat je ziet. Inhoud, data, UI? Weg. Die <div id="app"></div> wacht op JS om gevuld te worden.

Voor devs: debuggen vraagt nu JS-logica volgen, API-calls traceren, states nabootsen. Geen simpele inspectie meer.

Voor machines? Searchbots, AI-scrapers en accessibility-tools worstelen. Ze moeten JS draaien, clicks faken en effects afwachten. SEO wordt lastiger. Toegankelijkheid hapert. AI's verspillen rekenkracht in headless browsers.

Symptoom van een grotere verschuiving

Het draait niet om JS of frameworks. Het is een mindset-kanteling.

Oud: Pagina = Zelfverklarend document
Nieuw: Pagina = Houder voor een interface, betekenis elders

Documents lezen zichzelf. Interfaces eisen interpretatie. We wonnen snelheid en rijkdom, maar verloren leesbaarheid.

Voor tools als Figma of Slack is dat prima – dat zijn apps. Maar simpele blogs of landingspagina's? Die hoeven geen SPA te zijn. We zijn doorgeslagen.

Waarom dit NameOcean-klanten raakt

Bij NameOcean draait het om jouw domein en hosting die passen bij jóúw behoeften. Geen onnodige gedoe.

Voor content-sites, landing pages of tekstzware pagina's? Kies SSR of static generation. Laat HTML de inhoud dragen. SEO knalt meteen. Langzame connecties tonen tekst vóór JS.

Voor dashboards of real-time apps? Client-side mag. Maar weeg de nadelen af.

Kies bewust, niet omdat het hip is.

De weg vooruit

Het web zoekt balans. Frameworks als Next.js, Svelte en Astro mixen het beste: SSR voor de start, client-side voor interactie, static voor vaste content.

Geen zwart-wit: document óf app. Je kunt beide hebben.

Belangrijkste les: baseer keuzes op wat je bouwt. Houd het leesbaar, indexeerbaar en toegankelijk, naast rijk en snel.

Transparantie en kracht? Die werken samen, geen vijanden.