sslxy

philosophy

Rustige code. Duidelijke structuur. Niets opblazen wat ook eenvoudig kan.

Deze pagina beschrijft niet alleen hoe ik websites bouw, maar vooral waarom ik ze op deze manier bouw. Veel daarvan komt niet uit leerboeken of uit de wens om bijzonder modern te lijken, maar uit lange praktijk, uit oude computers, uit beperkingen en uit de eenvoudige behoefte dat techniek ook later nog begrijpelijk blijft.

Voor mij is goede webontwikkeling geen podium. Het is eerder een vorm van technische orde. Het moet functioneren, leesbaar blijven, niet onnodig zwaar worden en ook dan nog beheersbaar zijn wanneer er jaren voorbij zijn gegaan en je zelf opnieuw in de code moet kijken.

Philosophy Diagnostic

> CORE PRINCIPLES
METHOD handgeschreven / rustig / navolgbaar PRIORITY leesbaarheid / onderhoudbaarheid / duidelijkheid JS POLICY gericht, niet allesomvattend LAYOUT duidelijk in plaats van effectbeladen SEO schone structuur / eerlijke informatie / bezoekers vóór trucs A11Y bedienbaarheid vóór decoratie TOOLS moderne gereedschappen toetsen, niet eerbiedig overnemen GOAL lang bruikbaar, niet alleen kort indrukwekkend
Techniek hoeft niet luid te zijn om goed te zijn. Ze moet vooral geloofwaardig gebouwd zijn.
[core/mindset]

Grondhouding – techniek moet rustig, leesbaar en duurzaam blijven

Ik heb weinig op met het onnodig groter of ingewikkelder maken van websites alleen omdat het technisch mogelijk is. Veel van wat vandaag als vooruitstrevend wordt verkocht, is in werkelijkheid vaak alleen zwaarder, onoverzichtelijker en sneller verouderd. Wat mij aan webontwikkeling interesseert, is niet hoe je er zoveel mogelijk techniek in stopt, maar hoe je met zo weinig mogelijk onnodige techniek een stabiele en eerlijke oplossing bouwt.

Deze houding heeft veel te maken met de computergeschiedenis die eraan voorafging. Wie met systemen heeft gewerkt waarbij geheugen, gegevensdragers en stabiliteit echte grenzen waren, ontwikkelt bijna automatisch een andere discipline. Je denkt eerder na over wat werkelijk nodig is. Je scheidt belangrijker zaken eerder van versiering. Je leert dat duidelijkheid niet ouderwets is, maar meestal de robuustere oplossing.

Goede code is voor mij daarom geen verzameling slimme ingevingen, maar eerder een schone orde. Als ik een bestand maanden of jaren later opnieuw open, mag het niet als een vreemd lichaam aanvoelen. Het moet leesbaar zijn, rustig opgebouwd en innerlijk logisch blijven. Precies dat is voor mij technische kwaliteit.

„Goede code verklaart zich niet door luidheid, maar door innerlijke orde.“

[markup/discipline]

Waarom HTML met de hand

Handgeschreven HTML is voor mij geen romantiek en ook geen doel op zich. Het is eenvoudigweg de meest directe en best controleerbare vorm om een pagina te bouwen. Ik zie meteen wat er werkelijk op de pagina staat, hoe inhoud is gestructureerd en wat later door zoekmachines, browsers en mensen daadwerkelijk wordt gelezen. Er is geen onnodige tussenlaag die alles ingewikkelder maakt.

Juist bij kleinere en middelgrote websites is die directheid een voordeel. In plaats van structuren eerst uit een systeem te moeten onderhandelen, kun je ze direct, schoon en eenduidig schrijven. Koppen, alinea's, lijsten, navigatie, afbeeldingen, semantische gebieden – dat alles laat zich eenvoudig en duidelijk opbouwen zonder dat er een zwaar kader nodig is.

[Markup_Principle]
> write structure directly
> avoid layers without clear benefit
> keep hierarchy readable
> html should remain human-readable

Dat betekent niet dat alles altijd ultraminimaal moet zijn. Het betekent alleen dat elke extra laag gemotiveerd moet zijn. Wanneer een bestand na verloop van tijd groeit, is dat prima, zolang er nog steeds een herkenbare orde in zit. Wanorde ontstaat niet door lengte, maar door ontbrekende structuur.

[layout/clarity]

Structuur en CSS – vormgeving moet leiden, niet bedekken

CSS is voor mij geen plek voor effectbejag. Natuurlijk mag een pagina visueel schoon en coherent ogen. Maar vormgeving moet inhoud dragen en oriëntatie geven, niet van beide afleiden. Daarom geef ik de voorkeur aan rustige layouts, duidelijke afstanden, navolgbare kleuren en een letterkeuze die ook bij langere teksten niet vermoeit.

Juist bij informatieve pagina's is dat belangrijk. Als elke box, elke regel en elk gebied om aandacht schreeuwt, verliest de eigenlijke inhoud aan gewicht. Goede vormgeving is vaak eerder de kunst om onrust te vermijden. Kleuren, lijnen, randen, markeringen en afstanden moeten niet decoratief om zichzelf heen draaien, maar logisch zijn.

Visuele rust

Een rustige layout helpt de inhoud. Ze schept oriëntatie zonder voortdurend aan de oppervlakte aandacht te eisen.

Afstanden als logica

Goede afstand is niet alleen cosmetica. Ze laat zien wat bij elkaar hoort, wat overkoepelend is en waar een gedachte eindigt.

Herkenbaarheid

Terugkerende klassen, vergelijkbare boxen en consistente patronen maken een pagina niet saaier, maar onderhoudbaarder en begrijpelijker.

Minder show

Effecten mogen nooit belangrijker worden dan leesbaarheid. Een pagina is geen showroom, maar een gebruiksvoorwerp.

„Vormgeving moet inhoud leesbaarder maken, niet luider.“

[script/restraint]

JavaScript alleen daar waar het werkelijk iets verbetert

Ik heb niets tegen JavaScript. Ik heb alleen iets tegen JavaScript op plaatsen waar het alleen wordt gebruikt omdat men eraan gewend is geraakt alles ermee op te lossen. Veel websites gebruiken scripts niet als gereedschap, maar als standaardreflex. Precies dat vind ik vaak een fout.

JavaScript is voor mij zinvol wanneer het de bediening verbetert, barrières vermindert of kleine dynamische taken overneemt die zonder script onnodig omslachtig zouden zijn. Een to-top-knop, een schone lightbox, een zinvolle datumstempel of gerichte kaartlogica – dat zijn voor mij verstandige toepassingsgebieden. Al het andere moet zich eerst verantwoorden.

[JS_Policy]
> use script only for real interaction gains
> prefer static output where possible
> reduce attack surface and maintenance load
> script is tool, not default atmosphere

Juist statische pagina's profiteren daarvan. Wat niet dynamisch hoeft te zijn, veroorzaakt geen onnodige complexiteit. En wat niet onnodig complex is, blijft meestal langer onderhoudbaar en veiliger. Voor mij is dat geen ideologie, maar praktische ervaring.

[content/seo]

SEO en inhoud – liever een schone structuur dan lege trucs

Zoekmachineoptimalisatie begint voor mij niet bij trucs, maar bij orde. Een schone paginatitel, een navolgbare structuur, eerlijke beschrijvingen, duidelijke interne links en coherente inhoud vormen voor mij de eigenlijke basis. Veel van wat als SEO-maatregel wordt verkocht, is in werkelijkheid slechts kortstondig lawaai.

SEO is belangrijk. Maar voor mij staat het niet boven de bezoeker. Een goede positie in zoekmachines heeft weinig nut als iemand daarna op een onduidelijke, verouderde of teleurstellende pagina terechtkomt. Zichtbaarheid is behulpzaam, vertrouwen, oriëntatie en eerlijke informatie zijn belangrijker.

Daarom probeer ik pagina's zo te schrijven dat ze eerst voor mensen begrijpelijk zijn. Wanneer een pagina logisch is opgebouwd, echte informatie bevat en niet onnodig om de kern heen draait, is dat technisch meestal ook de betere basis. Slechte inhoud wordt door metadata niet goed. Goede inhoud wordt door een schone structuur beter vindbaar.

Daarbij hoort ook dat ik weinig op heb met kunstmatige overoptimalisatie. Het heeft geen zin teksten te overladen met steeds dezelfde begrippen als ze daardoor slechter leesbaar worden. Goede SEO is voor mij eerder een vorm van technische en taalkundige discipline.

„Een pagina moet niet voor zoekmachines klinken, maar voor mensen. Schone techniek helpt beide – maar de bezoeker komt eerst.“

[accessibility/usability]

Bedienbaarheid – techniek moet niet alleen laden, maar ook gebruikt kunnen worden

Bedienbaarheid is voor mij geen extra en geen laat nabehandelwerk. Het hoort vanaf het begin in de structuur thuis. Een pagina die optisch ordelijk lijkt, maar slecht omgaat met toetsenbord, focus, beweging of leesbaarheid, is technisch niet af. Ze is alleen oppervlakkig af.

Daarom let ik op duidelijke koppen, begrijpelijke focusstaten, goed leesbare contrasten, zinvolle linkteksten, betrouwbare navigatie en reduceerbare beweging. Juist kleine details maken hier veel uit. Een pagina hoeft niet als speciaal toegankelijkheidsproject gebouwd te zijn om respectvol en bruikbaar te zijn. Maar ze zou niemand onnodig mogen uitsluiten.

[accessibility_notice]

Bedienbaarheid is geen versiering. Ze beslist erover of techniek daadwerkelijk toegankelijk blijft.

Ook hier geldt mijn gebruikelijke principe: niet opblazen, maar schoon bouwen. Goede toegankelijkheid ontstaat vaak niet door steeds meer techniek, maar door schone semantiek, duidelijke logica en de bereidheid onnodige spielerei weg te laten.

[security/discipline]

Veiligheid en technische discipline

Veiligheid begint voor mij niet bij dramatische maatregelen, maar bij discipline. Minder onnodige afhankelijkheden, minder bewegende delen, minder vreemde integraties en minder overbodige dynamiek betekenen vaak automatisch een kleiner aanvalsoppervlak. Niet alles wat modern of comfortabel lijkt, is ook verstandig.

Daarom geef ik op veel pagina's de voorkeur aan statische oplossingen, weinig externe afhankelijkheden en een architectuur die niet bij elk detail extra risico's binnenhaalt. Veiligheid is voor mij niet alleen een set headers of een checklist, maar ook een kwestie van terughoudendheid.

[Security_Approach]
> reduce dependencies
> avoid unnecessary dynamic features
> keep behavior understandable
> discipline is part of security

Juist op kleine en middelgrote sites is dat belangrijker dan veel mensen denken. Een overzichtelijke technische basis is niet alleen makkelijker te onderhouden, maar meestal ook moeilijker kapot te maken.

[maintenance/years]

Onderhoud door de jaren heen – de eigenlijke test van goed werk

Veel websites zien er in het begin ordelijk uit. De werkelijke kwaliteit laat zich echter pas later zien. Na maanden. Na jaren. Na veel kleine wijzigingen, aanvullingen, correcties en nieuwe pagina's. Pas dan merk je of de basisstructuur standhoudt of dat alles met elke wijziging zwaarder en onoverzichtelijker wordt.

Precies daarom denk ik bij code bijna altijd in langere tijdvakken. Kan ik later dezelfde patronen opnieuw gebruiken? Blijft het bestand navolgbaar? Is een gebied schoon gescheiden? Zijn klassen en blokken consistent genoeg zodat ze niet telkens opnieuw uitgevonden hoeven te worden? Voor mij is dat geen bijzaak, maar de kern van professionele rust.

Herbruikbaarheid

Goede patronen mogen zich herhalen. Dat bespaart niet alleen tijd, maar houdt een pagina ook van binnen consistent.

Leesbaarheid later

Een goed bestand voelt ook na langere tijd niet vreemd aan. Je kunt het weer oppakken zonder alles opnieuw te moeten ontcijferen.

Veranderbaarheid

Niet alles hoeft meteen perfect te zijn. Maar het moet zo gebouwd zijn dat latere wijzigingen niet onnodig pijnlijk worden.

Rustige groei

Een pagina mag groeien. Beslissend is alleen of ze daarbij haar innerlijke orde behoudt.

„De ware test van code is niet de eerste indruk, maar de derde bewerking na meerdere jaren.“

[tools/present_day]

Moderne gereedschappen – AI en cloud alleen na praktische toetsing

Dat ik rustige, handgeschreven pagina's prefereer, betekent niet dat ik nieuwe gereedschappen principieel afwijs. Het betekent alleen dat ik ze niet automatisch geloof. Ook moderne gereedschappen zoals AI-modellen en clouddiensten interesseren mij – maar niet als mode en niet als vervanging voor oordeel. Wat mij interesseert, is wat ze in de echte dagelijkse praktijk werkelijk dragen.

Juist daarom toets ik zulke gereedschappen nuchter. Niet op reclametoon, niet op opwinding en niet op louter nieuwheidswaarde, maar op een eenvoudige vraag: helpt dit gereedschap werkelijk verder, of veroorzaakt het alleen extra ballast? Veel zaken lijken op het eerste gezicht indrukwekkend. Beslissend is echter of ze ook na de derde, vijfde of tiende inzet nog betrouwbaar zijn.

[Tool_Evaluation]
> test in practical use
> compare benefit against complexity
> observe limits, errors and breakpoints
> only keep what remains useful after the first impression

Voor mij zijn AI-modellen daarom geen autoriteit en ook geen speelgoed. Het zijn gereedschappen. Sommige helpen bij ordenen, vergelijken, formuleren of snelle tegencontrole. Andere produceren eerder schijnprecisie, onnodige lengte of nieuwe afhankelijkheden. Hetzelfde geldt voor clouddiensten. Ze kunnen nuttig zijn, maar alleen wanneer hun praktische voordeel groter blijft dan de extra inspanning, de onrust of de nieuwe technische afhankelijkheid.

De eigenlijke houding blijft daarbij dezelfde als vroeger: gereedschappen moeten zich bewijzen. Niet op slides, niet in marketingzinnen, maar in echt gebruik. Alles daarbuiten is voor mij alleen maar een extra naam zonder belastbare substantie.

„Nieuwe gereedschappen interesseren mij alleen wanneer ze in de dagelijkse praktijk werkelijk standhouden – niet wanneer ze alleen modern klinken.“

[avoidance/choices]

Wat ik eerder vermijd

Ik vermijd techniek niet als zodanig. Ik vermijd vooral techniek die haar eigen inspanning niet rechtvaardigt. Daaronder vallen voor mij opgeblazen structuren, onnodige framework-last, effecten zonder werkelijk nut, overvolle interfaces, uitwisselbare standaardoplossingen zonder eigen karakter en constructies die zich later moeilijk laten herlezen.

  • onnodig zware frontend-constructies voor eenvoudige pagina's
  • JavaScript als standaardreactie in plaats van als bewust gereedschap
  • visuele onrust die leesbaarheid en oriëntatie verzwakt
  • SEO-trucs zonder inhoudelijke substantie
  • structuren die later bij onderhoud meer schade dan nut veroorzaken
  • techniek die indrukwekkend moet lijken, maar in het dagelijks gebruik onnodig afremt

Dat betekent niet dat ik principieel tegen moderne gereedschappen ben. Het betekent alleen dat ik van techniek verwacht dat zij haar plaats verdient. Een gereedschap is goed wanneer het een probleem rustiger oplost – niet wanneer het alleen maar extra namen, extra ballast en extra onderhoudsdruk introduceert.

↑ Naar boven