Waarom een standaard portfolio je niet meer opvalt?

De meeste developer-portfolio’s zien er hetzelfde uit. Hero-sectie, zwevende mockups, contactformulier. Dat was drie jaar geleden al saai. Wil je opvallen, dan bouw je iets dat mensen niet verwachten. Een IDE-interface is zo’n keuze: die laat direct zien hoe je denkt als developer, nog voor iemand een regel code leest.

Ik begrijp waarom de meeste portfolios op elkaar lijken. Je zoekt een template, past de kleuren aan, voegt je projecten toe en klaar. Werkt ook prima als je gewoon een URL wilt sturen. Maar als je echt wilt laten zien dat je code schrijft en systemen bouwt, is een generieke pagina een gemiste kans.

Een IDE-stijl portfolio doet iets anders. Het laat de manier zien waarop je werkt, niet alleen de uitkomsten. Bezoeker klikt op about.html in een file-tree aan de linkerkant, en de inhoud verschijnt rechts. Dat voelt als VS Code. Voor een developer-doelgroep is dat onmiddellijk herkenbaar.

Dit is de sterkste route als je solliciteert bij een tech-bedrijf of freelance-klanten aantrekt die zelf ook technisch zijn. Voor een kapper of een coach raad ik dit af, want die doelgroep heeft er niets aan. Maar voor een developer? Perfect. Check ook hoe AI-code-editors zoals Cursor en Windsurf je bouwtijd flink kunnen verkorten.

Welke tech stack gebruik je voor een IDE-portfolio?

De kern is Next.js voor routing en componentstructuur, Tailwind CSS voor de strakke geometrische styling, en GSAP voor animaties. GSAP staat voor GreenSock Animation Platform: een JavaScript-bibliotheek waarmee je complexe, vloeiende animaties bouwt die je met gewone CSS niet voor elkaar krijgt. DotLottie verzorgt lichte vectoranimaties voor de laadschermen.

Next.js is hier de logische keuze. Je krijgt automatisch routing op basis van je bestandsstructuur, en Vercel deployt het zonder configuratie. Dat scheelt je minstens een uur aan deployment-gedoe.

Tailwind CSS zorgt voor de strikte CSS grid die het IDE-gevoel geeft. Geen flexbox-gedoe waarbij de sidebar ineens over de content schuift op mobiel. Met Tailwinds utility-classes bouw je exact de layout die je wilt, en je stelt de breakpoints strak in.

Dan GSAP. Dit is waar de magie zit. De preloader gebruikt een zogenaamde split-gate reveal: twee donkere vlakken die van het scherm schuiven, omhoog en omlaag, zodat de IDE eronder tevoorschijn komt. Dat bouw je met een GSAP-timeline, zo:

gsap.timeline()
.to('.gate-top', { y: '-100%', duration: 0.8, ease: 'power2.inOut' })
.to('.gate-bottom', { y: '100%', duration: 0.8, ease: 'power2.inOut' }, '<')

De '<' laat beide animaties tegelijk starten. Simpel maar effectief. Voor de knipperende terminal-cursor gebruik je gewoon een CSS keyframe-animatie op een solid blok: geen extra library nodig.

Hoe bouw je de file-tree navigatie die als router werkt?

De file-tree is de kern van de interface. Bestanden zoals about.html of projects.js staan in een linker sidebar. Klik erop en de rechter weergave wisselt van inhoud. In Next.js implementeer je dit met een state-variabele die bijhoudt welk bestand actief is, gecombineerd met conditionele rendering van je content-componenten.

De file-tree zelf bouwen is niet het moeilijkste. Je maakt een array van objecten met bestandsnamen en bijbehorende componenten, en rendert die als een lijst. Klikken zet de actieve state, en de content-zone toont het bijbehorende component.

Schematisch ziet dat er zo uit:

const files = [
{ name: 'about.html', component: <About /> },
{ name: 'projects.js', component: <Projects /> },
{ name: 'experience.ts', component: <Experience /> },
];

// In de content-zone:
{active.component}

Let op: op mobiel blijft de standaardfout dat de sidebar open blijft na het klikken op een bestand. De content staat dan half verborgen achter de navigatie. De oplossing is een state-dispatcher die de sidebar automatisch sluit zodra je een bestand selecteert. Één regel extra logica in je click-handler, maar het scheelt veel frustratie bij gebruikers op telefoon.

Voor de styling gebruik je CSS grid met een vaste breedte voor de sidebar (w-48 of w-64 in Tailwind) en de rest voor de content. Zorg dat de grid niet breekt op kleinere schermen door de sidebar op mobiel standaard verborgen te zetten.

Hoe deploy je dit zonder hoofdpijn op Vercel?

Vercel en Next.js zijn gemaakt voor elkaar. Je pusht naar GitHub, Vercel detecteert automatisch dat het een Next.js-project is en bouwt het. Geen serverconfig, geen pipeline handmatig instellen. Je koppelt je domein aan Vercel’s nameservers en HTTPS is direct geregeld. Voor .dev-domeinen is HTTPS trouwens verplicht, niet optioneel.

De deployment is het makkelijkste deel van dit project. Maak een Vercel-account, koppel je GitHub-repository en Vercel doet de rest. Bij elke push naar je main-branch bouwt Vercel automatisch een nieuwe versie en zet die live. Geen handmatige FTP-uploads, geen server die je zelf beheert.

Eén ding om op te letten: gebruik je een .dev-domein, dan is HTTPS verplicht. Dat zit ingebakken in de TLD zelf. Browsers weigeren HTTP-verbindingen naar .dev-adressen. Vercel regelt dit automatisch via hun edge-netwerk, dus je hoeft er niets voor te doen.

Wil je het repository privé houden? Dat kan gewoon. Vercel heeft toegang tot je GitHub-repo voor de build, maar de code blijft privé voor de buitenwereld. Handig als je werk voor klanten in de repo hebt staan dat je niet wil delen.

Vergelijk je dit met traditionele WordPress-hosting: dit is sneller, goedkoper voor een statische site, en je hebt geen plugin-updates of beveiligingslekken om je druk over te maken. Voor meer context over WordPress beveiligingsupdates en wat je daarmee moet heb ik eerder geschreven.

Is dit voor elke developer de juiste keuze?

Eerlijk antwoord: nee. Een IDE-portfolio is indrukwekkend als je doelgroep technisch is. Maar bouw je websites voor lokale ondernemers of werk je als freelance designer voor niet-technische klanten, dan slaat dit concept de plank mis. Ken je doelgroep voordat je 60 uur in een custom preloader stopt.

Mijn onderbouwde standpunt: ik zou dit type portfolio alleen bouwen als je weet dat de mensen die het bekijken er iets mee kunnen. Een CTO die een developer aanneemt? Die snapt de file-tree direct en is onder de indruk. Een MKB-ondernemer die een website wil laten bouwen? Die raakt verdwaald en klikt weg.

Wees ook realistisch over de bouwtijd. GSAP leren, de split-gate animatie debuggen op Safari (want Safari doet altijd iets anders), de mobiele sidebar goed laten werken: reken op 40 tot 80 uur als je dit from scratch bouwt en GSAP nog niet kent. Ken je GSAP al, dan kom je eerder uit op 20 tot 30 uur.

Wil je sneller resultaat? Gebruik een bestaande template als startpunt en pas die aan. Dat levert in 8 tot 10 uur een werkende versie op. Minder origineel, maar wel sneller live.

Wil je AI inzetten bij het bouwen van dit soort animaties? Ik heb goede ervaringen met Claude Code voor web-animaties. Het schrijft GSAP-code op basis van een beschrijving, wat je veel trial-and-error bespaart. En als je wil weten hoe de rol van developers verandert in het AI-tijdperk, dat is ook de moeite waard om te lezen.