Hoe komt HTML structuur professionele website tot stand?

Door Mark Hogeveen op 22-10-2021 21:18 gewijzigd op 22-10-2021 21:22

3.540 views

Misschien een rare vraag en niet echt belangrijk, dus daarom in de koffiehoek.
Ik kijk voor de lol wel eens naar de broncode van sites van bedrijven.
Soms kleine bedrijven waarbij je kunt herkennen dat ze bijvoorbeeld Wordpress of Joomla gebruiken, soms bij echte grote websites zoals Bol.com, en soms bij webapplicaties (zoals bijvoorbeeld Spotify web player).

Ik zie dan vaak enorme HTML structuren, class names die heel raar uitzien, enzovoort. Ook kun je eruit opmaken dat er allerlei layout technieken worden gebruikt. (Met layout technieken bedoel ik bijvoorbeeld een ouderwetse "clearfix").
Een pagina is vaak heel simpel (visueel gezien) en toch kom je hele lappen tegen in de broncode, waarbij je denkt "dat kan toch makkelijker?".
Ik verdiep me eigenlijk al meerdere jaren zeer hobbymatig in webdesign en maak wel eens een kleine website, maar dan voor mezelf.
Maar die ingewikkelde dingen die je in de broncode van andere sites tegenkomt, krijg ik niet "aangeleerd". Terwijl het lijkt alsof dit juist het professionele font-end webdevelopment is.
Het is moeilijk uit te leggen, maar is er hier iemand die echt goed is in front-end ontwikkeling en ervaring heeft in hoe dit groeit?
Als ik bijvoorbeeld een horizontale menubalk wil maken, dan schrijf ik...


<nav>
    <div class="site-menu">
        <ul>
            <li><a href="">Home</a></li>
            <li><a href="">Nieuws</a></li>
            ...
        </ul>
    </div>
</nav>

En dit style ik dan met CSS (zoals float en display:inline-block) zodat het eruit ziet zoals ik wil.
Kijk ik naar iets soortgelijks bij een andere website, dan kom ik bijna altijd enorme blokken tegen, met veel meer lagen eromheen. Ook class names zijn dan vaak zoals... menu, menu-container, menu-section__, __menu-item

Rob Doemaarwat

23-10-2021 10:09 gewijzigd op 23-10-2021 10:14

Ik kan niet het hele plaatje invullen, maar wel een paar losse flodders.

Zo'n website is meestal over een aantal jaren "gegroeid".

Eerst is er een designer aan het werk gegaan, en die heeft een (nog redelijk gestructureerde) lap HTML opgeleverd. Dan gaat er een front-end developer aan het werk, en die komt er achter dat ie soms een paar extra "handvaten" nodig heeft om z'n JavaScript magic aan op te hangen. Krijg je dus vaak "wrapper divs" (een extra div om een al redelijk stuk afgebakende HTML).

Vervolgens moet de site door een stuk server-side code gegenereerd worden (denk menu's vullen met actuele pagina's, selects met actuele lijstjes, enz). Dat levert niet altijd de cleane HTML op die je met het handje zou typen (maar het functioneert wel hetzelfde).

Ook wordt de uiteindelijk HTML vaak gegenereerd vanuit een "template engine", waar je met losse blokken werkt ("header", "footer", "side-bar", enz - die over meerdere pagina's hergebruikt worden). Op het moment dat iemand een wijziging aan zo'n "blok" maakt heeft ie vaak niet het hele plaatje voor zich, en ziet het resultaat er (qua HTML) wat raar uit (maar wederom: het werkt wel). Ook is het dan vaak "handiger" om een stukje script wat je nodig hebt voor lokale functionaliteit ook meteen ter plekke toe te voegen - daarom zie je soms meerder <script> blokken her en der (script voor het uitklappen van een menu zit dan bijvoorbeeld ook meteen in het blok "menu").

Na een tijdje moeten er dan allerlei "extra's" worden toegevoegd:
- niet zichtbare meta data, tracking pixels, A/B test scripts, enz.
- zichtbare bling-bling ("Nu speciale aanbieding - klik hier"), cookie popups, enz.

En marketing gaat zich er natuurlijk mee bemoeien: "Als ze binnen 2 tellen met de muis naar de bovenkant schieten dan een melding 'Niet gevonden wat je zocht? Misschien is dit wat voor je!'".

En bij grote projecten, over meerdere jaren, werken daar natuurlijk diverse ontwikkelaars aan (misschien wel verschillende externe partijen), die dingen allemaal even anders doen (onbewust, of omdat het hele bedrijf gewoon een andere focus heeft genomen - "voortaan gebruiken we framework X").

Nou, zo wordt het al snel een hele rambam aan "onsamenhangende code" ...

Nog wat losse punten:

Die "rare class names" is vaak het gevolg van "minify-en" van de code (om de data overdracht te minimaliseren; een meet-/pluspunt bij Google), of om het gewoon minder leesbaar te maken voor "geïnteresseerden"). Je ziet het veel in JavaScript (de *.min.js files), maar het kan ook voor stylesheets. Stap 1 is dan om alle white-space er uit te halen, maar je kunt natuurlijk ook de selectors verkleinen (zoals in JavaScript de variabelen altijd worden teruggebracht tot "a", "b", "c", enz). Dan moet je uiteraard in je HTML ook dezelfde, verkorte class namen gaan gebruiken (gaat meestal geautomatiseerd).

Die class names met streepjes en underscores zijn meestal gerelateerd aan een methode die BEM heet: https://en.bem.info/methodology/key-concepts/ . Hiermee houdt een designer z'n class names een beetje uniek / uit elkaar. Ook zie je dat bepaalde bibliotheken hun class names prefixen (bijvoorbeeld met "xyz-") om te voorkomen dat een class name "botst" (dezelfde naam heeft, en dus dezelfde opmaak krijgt) met een class in een andere bibliotheek (of het algehele ontwerp).