Waarom backend developers zich niet aan frontend moeten wagen

Weet je nog? Toen we vrolijk onze PHP en HTML code door elkaar schreven? Of even snel een stukje HAML uittypte voor de zoveelste Ruby on Rails CRUD interface? Menig backend developer draaide haar hand niet om voor het schrijven van een stukje frontend. Maar wat kunnen tijden toch snel veranderen. Onder invloed van Atwood’s Law zagen we de mogelijkheden in de browser steeds verder toenemen, en daarmee ook de complexiteit van het frontend. Een XHR-request hier, een WebSocket daar. En kan je gelijk even checken of de website wel beschikbaar is als PWA?

Hoewel het gros van de backend developers geen voorliefde heeft voor frontend, is het nu tijd om de lijntjes definitief door te knippen. Want frontend is inmiddels echt een vak apart, maar waarom nu? Het internet zou immers niet bestaan zonder dat er frontend code wordt geschreven…

Frontend vereist een oog voor ontwerp

Wanneer wij aan het ontwerpen slaan, zijn we nooit in staat om alle mogelijke combinaties van elementen te ontwerpen. Dat zijn er simpelweg te veel. Hoe schaalt een ontwerp terug naar verschillende schermbreedtes (en mogelijk, schermhoogtes)? Hoe werkt een “intermediate state”, die we vooraf niet hebben kunnen voorzien?

Als frontend developer neem je niet klakkeloos over was een ontwerper uitgedacht heeft. Dat zou te makkelijk zijn. Het moeilijkste aspect van de implementatie van het ontwerp is het maken wat de ontwerper niet heeft ontworpen. Je voegt niet simpelweg de exacte gespecificeerd witruimte tussen elementen toe; je denkt eerst na hoe dit overeind blijft wanneer het element in een compleet andere context wordt gebruikt.

Als frontend developer neem je niet klakkeloos over was een ontwerper uitgedacht heeft. Dat zou teNatuurlijk zou je al deze vragen kunnen voorleggen aan je collega-ontwerper, maar dat is natuurlijk niet heel efficiënt. Een goede frontender is geen ontwerper, maar heeft wel gevoel voor ontwerp. Klopt de visuele hiërarchie tussen de verschillende elementen, bijvoorbeeld door correct gebruik van kleur en typografie? “Lijnt” de pagina goed, waardoor de bladspiegel rustig en overzichtelijk oogt?

Mocht het probleem complexer zijn dan dat, dan is het alleen maar logisch om de ontwerper even aan te schieten. Maar dan is het natuurlijk wel fijn als je elkaars taal spreekt en snapt welke afwegingen je samen dient te maken. Dat is dus ook precies de reden waarom onze ontwerpers ook begrijpen hoe frontend in elkaar steekt. makkelijk zijn. Het moeilijkste aspect van de implementatie van het ontwerp is het maken wat de ontwerper niet heeft ontworpen. Je voegt niet simpelweg de exacte gespecificeerd witruimte tussen elementen toe; je denkt eerst na hoe dit overeind blijft wanneer het element in een compleet andere context wordt gebruikt.

Frontend vereist een ander denkpatroon

Klassiek geschoolde backend developers denken in in abstracties. Hoe kan ik een bepaald concept generaliseren, zodat ik het op meerdere plekken kan hergebruiken? Op die manier schrijf je namelijk minder code en hoef je dus minder te onderhouden. Hoewel onze ontwerpen gebaseerd zijn op “design systems” (waarbij we denken in terugkerende en herbruikbare elementen, net als is onze frontend), is de werkelijkheid altijd weerbarstiger. Een systeem is altijd het uitgangspunt, maar we weten dat we altijd een uitzondering moeten maken.

Soms heeft een ontwerper een goede reden voor een uitzondering. En dan is het zeker niet aan de developer om op de stoel van de ontwerper te gaan zitten. Maar dat gaat vaak tegen onze natuur in; we willen immers herbruikbare code, toch? Als frontend developer ben je primair verantwoordelijk om de gebruikservaring te implementeren zoals bedacht. Altijd met de gebruiker en het bedachte ontwerp in het achterhoofd, en niet de techniek.

Daarnaast is het ook simpelweg een kwestie van voorkeur. Een uitgebreid frontend kan vergelijkbare uitdagingen bieden als een uitgebreid backend systeem, maar het zijn toch echte twee verschillende disciplines. Dan kan je maar beter je tijd besteden aan de dingen die je écht leuk vindt om te doen.

Frontend vereist tijd én ervaring

Wanneer je eenmaal in frontend development duikt, realiseer je pas hoe breed de discipline is. Met slechts kennis van HTML en CSS kom je niet zo ver. Er zijn tientallen aanverwante technieken en methodologiën die nodig zijn om een modern frontend te realiseren. Hoewel wij ook niet altijd in staat zijn om een Webpack configuratie te doorgronden, helpt de ervaring van eerder gemaakte fouten enorm. En die ervaring bouw je nu eenmaal minder snel op wanneer je vooral bezig bent met backend systemen.

Frontend development staat nog in de kinderschoenen. We zijn pas een jaar of 10 bezig om lekker werkende, interactieve systemen in de browser te bouwen. Dit verklaart precies waarom er nog zo veel ontwikkelingen zijn en waarom je zo veel tijd nodig hebt om “bij” te blijven. Tegelijkertijd wordt het vakgebied onderbelicht in veel formele opleidingstrajecten en is er onder nieuwe frontend developers weinig historisch besef waarom we dingen zo doen. Nu wens ik niemand de tijd van “spacer.gif” toe, maar juist omdat alles zo snel evolueert, is het goed om te weten waar het vakgebied vandaan komt.

Zelfs binnen de discipline zijn er verschillende accenten aan te brengen. Denk bijvoorbeeld aan animatie, waarbinnen we tenminste drie breed gebruikte technieken kennen. Of de focus op single-page applications, waarin we nog veel meer smaakjes kennen. Kortom, in frontend ontwikkeling hoef je je zeker niet te vervelen, maar zonder focus kan de snelle evolutie ook tot frustratie leiden.

En een full stack developer dan?

Wat als je nu echt heel veel plezier hebt in het bouwen van frontend én backend? Als je sterke kennis en ervaring hebt in beide disciplines is dat natuurlijk een waardevolle combinatie, maar het gezegde luidt niet voor niets: “Jack of all trades, master of none”. Een specialist zal het altijd winnen van een generalist wanneer je de diepte in moet binnen een vakgebied. In een klein team is het natuurlijk handig om van beide kaas gegeten te hebben, maar wanneer je de luxe hebt te kunnen kiezen, ga dan voor de specialist.. Want dat is niet alleen beter voor het eindresultaat, maar ook voor jullie team van backenders.