{
  "$type": "site.standard.document",
  "contributors": [
    {
      "did": "did:plc:n5zdxzzelmg7g22ebweczura",
      "displayName": "Saber Karmous",
      "role": "host"
    }
  ],
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiaefyaj4mrqr6gtgkhbxeyzrm5e5z5tuzgosjuvrvqpqolvxaumri"
    },
    "mimeType": "image/jpeg",
    "size": 62889
  },
  "description": "Met Ringo en Sander hebben we het over front-end development",
  "path": "/episodes/372",
  "publishedAt": "2023-10-16T03:00:00.000Z",
  "site": "at://did:plc:flhrheaiuteqoy65yixudwsv/site.standard.publication/self",
  "tags": [
    "Bun",
    "Front-end",
    "Storybook"
  ],
  "textContent": "Welkom bij een nieuwe aflevering van de CodeKlets podcast. De hosts van vandaag zijn Kishen en ik. Airhorn hebben we niet. Nee, nog steeds niet. Jammer hè. Na al die jaren. Is wel weer leuk met z'n tweeën. Ja. Nee, eigenlijk niet. Met z'n vierën. Ja, inderdaad. We zijn met z'n vierën. Daar zitten ze. Ik heb er weer zin in. Het is lang geleden dat we de vorige hebben opgenomen. Ja, het lijkt me wel leuk. En het onderwerp voor vandaag is ook een heel leuk onderwerp. Vind ik. Misschien andere niet, maar heb je mooi pech. Skip. En het gaat over front-end development. Dat is wel tof. Ja, zeker. En dat heb jij mooi geregeld. Ja, ik heb. Ja, dat was al denk een weekje of twee geleden. Toen zei hij van hee, wat een interessante podcast heb jij. En toen dacht ik hee, een luisteraar. Ze bestaan. Het is beter dan wat je had gezegd. Welke podcast? Hey, dat is leuk. Ringo zullen we straks even voorstellen. Maar ja, die ja, die liep dus langs. Ik denk nou begonnen het. Het deed dan natuurlijk te bespreken over. Waar heb je nou geluisterd dan? Welke aflevering dan? Maar ja, en uiteindelijk dachten we van hee, misschien is toch wel eens leuk om weer een keer een front-end development aflevering te doen. Want we hebben het alweer een tijdje geleden. Ja, we hebben wel vaker. Niet specifiek het niet het onderwerp front-end, maar we hebben het over. We hebben een keer over Engelen gehad. React ook. React hebben we gehad. En Next.js. Ja, zou kunnen. Ook ja, de lead developer die was dat toen geweest. Ja, dus we dachten van nou, we zijn toch opnames aan het doen. Dus om dan weer even een beetje weer leven in te blazen. We dachten van nou, dan maken we gelijk even gebruik van deze kans. En heel erg blij dat Ringo en Sander natuurlijk, die zullen we straks voorstellen, dat ze mee willen doen aan deze podcast. En zo is deze aflevering ontstaan vanuit front-end development. Ja, dat is ook wel logisch om te beginnen bij de front. En. Maar begrijp je nou eigenlijk goed dat Ringo zichzelf heeft uitgenodigd? Is dat nou eigenlijk? Dat is het eigenlijk. Ik dacht dat het andersom was, maar oké. Oh, kijk, kijk, zie je? Kijk, nu wordt het, ja, het wordt wat heet hier. Ja, precies, het wordt warm hier hoor. Nee, maar ja, dus ja, heel erg blij dat we nu weer een nieuwe aflevering weer kunnen opnemen. Ja, hier onze gasten voor vandaag, Ringo Blanken en Sander Schutten. Ja, welkom. Leuk om hier te zijn. Zeg het. Nou ja, we hebben altijd een standaardvraag voor al onze gasten om zichzelf te introduceren, zeg maar. Ja, hoe is het nou begonnen als programmeur? Waarom kwam het ineens vandaan en dat je nu ineens eindigde als een software engineer? Dus het leek ons wel leuk om jullie op die manier dan weer voor te stellen. Zullen we bij Ringo eens beginnen? Hoe heeft het zo mis kunnen gaan? Ringo, vertel. Ja, ik was een jaar of tien en het was eigenlijk het begin van de computers. En je had een Atari ST, mijn moeder had die van mij gekocht. Dat is wel een aankoop, een Atari ST. Dat was zeker een hele aankoop en klopt, ja. Mijn ouders waren nog niet echt heel erg rijk, dus ik weet ook niet precies hoe wat. Maar ze wisten eigenlijk al dat ik, ik was geloof ik een jaartje of twee, drie, dat ik voor de tv zat en ik vond alles op dat gebied, zeg maar, heel erg interessant. Dus ik denk dat ze heel lang heeft gespaard. Ging die dag zelfs vragen inderdaad. Maar daar is het al eigenlijk begonnen. En begon natuurlijk met spelletjes spelen. Alleen ik kon er ook op een gegeven moment heel achter dat ik ook zelf iets kon, daarmee kon doen. Maar ja, je had natuurlijk niet nul informatie. Zoals nu heb je natuurlijk heel veel informatie op internet staan. Kan je alles uitzoeken en zo, maar er was eigenlijk helemaal niks. Dus uiteindelijk een soort van, ik denk, ja, een soort van control c-achtig idee. En ik kwam in één keer bezig terecht en, nou, wat gaan we proberen? En op de ene manier, en ik weet ook zelf niet meer helemaal precies hoe, kwam mijn moeder op een gegeven moment naar me toe. En toen was ik dus bezig om een spelletje, een ski-spelletje te maken op die computer. En daar is eigenlijk de liefde ontstaan voor het programmeren. En, nou goed, later, een heleboel jaartjes later stond ik op de keuze om een bepaalde studie te gaan doen. Dat was elektrotechniek. Alleen, ja, ik vond het wel leuk, maar ik wilde eigenlijk al altijd iets met de computer doen. Op een gegeven moment belde een leraar op, die zei van joh, je zal het niet geloven. Maar het eerste jaar gaat beginnen van technische informatica opleiding. Zou je dat leuk vinden? Dus dat was voor mij echt iets van wow, oké, dat is echt geweldig. Dus ik zei ja, tuurlijk, dat wil ik heel graag doen. Dus ik ben daar eigenlijk mee begonnen en het heette dan technische informatica. Maar ja, uiteindelijk was het meer informatica dan dat technische gedeelte, zeg maar. Dus je leerde daar echt programmeren. Pascal Basic, een hele grote Unix-achtermachine had je staan. Bij wijze spreek ik een Kamergrote, zoals het was, zeg maar. En zo is dat eigenlijk begonnen. Dus ja, ik heb echt heel veel massen gehad met die studie destijds. En ja, dat is eigenlijk het begin geweest voor mij. Ja, dat is wel een vaker gehoord start. Dus dat je een game maakt en dat je op die manier... Ja. En ik hoorde jullie net iets zeggen over ST. Dat zegt mij nou echt helemaal niks. Waar staat die ST op? Het was eigenlijk de Atari XL800 aan mij. Ja, precies. ST die kwam later volgens mij. Daarom. 800 XL, dat was een van de... Ja, echt. Ik denk dat die in 82 of zo is uitgekomen. Je had zelfs de 400 XL. Die heb je ook nog gehad. Die is het kleinere voertje. 600 had je volgens mij. De 800 was vergelijkbaar met de Commodore 64. De 800 was 64 kb. Dat was wel heel wat. Tegang van de Commodore 64. Oh, dat is een mooi bruggetje. Dit is een heel mooi bruggetje. Want dan kan ik wat zeggen. Ik ben namelijk ooit begonnen op de Commodore 64. Ja, en dat was... Ik ging altijd magazines kopen in de computer of in de winkel. In de magazine winkel. En die kon je dan helemaal overtikken. Allemaal hexadecimale codes. Pagina's vol. En dan kwam er uiteindelijk een spelletje uit. Dat is een van mijn begin dingen geweest. En spelletjes verzamelen. Ik had echt bak vol met allemaal van die floppy disks. Nou ja, hartstikke leuk. Maar ja, uiteindelijk gaat de tijd vooruit. En dan schuif je steeds verder naar nieuwe computers. Wij hadden een computer omdat mijn vader had zijn eigen bedrijfje. Die deed heel veel textverwerking. En daar heb ik dus al een beetje mee op kunnen liften. Technische informatica heb ik ook nog gedaan. En NBO. En ik heb nog een HBO informatiekunde en informatica gedaan. Ja, altijd wel eigenlijk gewoon. Voor mij was het altijd een hele natuurlijke keuze eigenlijk. Ik vond het altijd heel interessant. Ik kon ook gaan oneindigen hoeveel tijd erin steken in de computers. Nou ja, en dan uiteindelijk roll je zo door. Wordt het je werk. En ja, dan zit je uiteindelijk hier zo in een opzolder ergens een podcast te houden over dit zinje. Het regent de gasten in en dan eruit. Nou, dankjewel voor degene die denken wie is deze stem nou? Sander Schutte. Sorry, dat was ik, Sander Schutte. Dankjewel. Ja, ik ben heel aan het schatten. Zijn er dan in het werk wat je nu vandaag doet, zie je daar overeenkomsten? Overheenkomstigheden met de beginjaar dat je programmeerde. En dan is het dus front-end development. Want kijk, een kenmerk zeg maar van waar je het over had op de Atari 800XL en de Conde 64 is dat je, ja, wat je programmeerde, zag je, het was visueel heel snel. Je kreeg die feedback heel snel terug. Zien jullie daar, heeft dat verwantheden of zie je daar, of is dat gewoon totale kul? Ja en nee. Wat ik zelf nu bemerk, en ik ben wel wat verder in mijn carrière en ik wil programmeren, is voorheen was het altijd dat ik een soort van dingetjes maakte en dan ging ik het meteen op het scherm doen. Dus dan deed ik er weer een regeltje bij en dan, oké, zit er een regeltje bij. En zo groeide het een soort van organisch, groeide eigenlijk mijn code. En wat ik nu eigenlijk de laatste tijd bemerk, is dat juist dat allemaal dat organische, dat probeer je eigenlijk zoveel mogelijk als laatste te doen, maar daarvoor zorg je dat je duidelijk hebt wat je nou eigenlijk moet doen, dat de prioriteit, de volgorde, eigenlijk meer allemaal een soort de voorbereidingen, dat dat zo belangrijk is. En op het moment dat je al die voorbereidingen hebt gedaan, dan is het meestal, het laatste stukje is allemaal wel duidelijk. Daar zie ik echt wel een verschil in ten opzichte van hoe ik het vroeger deed. Het was hartstikke leuk natuurlijk om een beetje organisch dingen te laten groeien, maar in mijn werk zie ik daar toch dat ik eigenlijk net veel meer tijd stop in de voorbereidingen. Ja, ontwerp misschien bedoel je? Ja, nou ja, kijken van wat moet er nou eigenlijk gedaan worden, wat zijn nou eigenlijk de varianten bijvoorbeeld van iets, waar moet ik wel rekening mee houden, waar moet ik niet rekening mee houden, allemaal dat soort dingen, in plaats van dat je dat achteraf iets maakt, en dan hoor je daarna van ja, het moet ook op dit moeten werken, of we hadden ook dit moeten doen. En dan kan je dat allemaal weer achteraf inbouwen, maar ik zie daar eigenlijk dat ik zelf nu heel erg ook de neiging heb om gewoon veel meer eigenlijk vooraf te vragen in plaats van dat ik maar begin en kijk, ja, en daarna een beetje gaan zitten bij schaven en bij werken. Dat is iets wat, volgens mij heeft het wel iets met ervaring te maken, hoop ik, denk ik. Oké. Ja. En geldt dat voor jou over het inzelf, zie je dat? Ja, als ik kijk zeg maar in het hele begin in ieder geval van het internet, daar praat je echt over, in 94, 95 of zo, begonnen met websites maken, dan had je natuurlijk HTML en CSS, en dat was front-end. Dat was het. Meer was er niet. Ja, JavaScript. Ja, één of twee regels JavaScript om een buttontje of zo, zeg maar, te doen. En later... Ja, zou je dat een keer onderbreken, want volgens mij werd er nog niet eens front-end development genoemd, zeg maar, toen nog HTML, CSS... Nee, je ging een website maken, zeg maar. Ja, precies, die designen of, ik weet niet hoe ze dat noemen, de HTML'en. Klopt. En op een gegeven moment kwam Flash om de hoek, zeg maar, en die gebruikte dan wat JavaScript om die Flashplay'en, zeg maar, te runnen. Ja, en daar kon je echt gigantisch mooie dingen met een soort van interactieve websites maken, zeg maar. Dus dat was weer een next level met Flash. Dan had je programmetaal, actionscript. Nou ja, er waren ook, zeg maar, designers die het ook geweldig vonden op het programma, want je kon animaties inmaken en je kon eigenlijk ook zonder code, kon je, ja, bijna alles aan elkaar knopen om een soort interactieve website te maken. En als je het dan, zeg maar, na deze tijden haalt, ja, wat stelt Hati Mellon C6 nog voor, zeg maar, in het geheel, zeg maar. Het is natuurlijk een heel belangrijk ding, omdat het visueel, zeg maar, een gedeelte is. Als je je front-end hebt, nou ja, dat is visueel. Maar als je kijkt ook naar frameworks die je moet gebruiken, testen, er komen zoveel accessibility, er komen zoveel facetten bij eigenlijk. Het is zo gegroeid. En ja, als je alleen al een project uitcheckt en je gaat hem installeren, als je kijkt hoeveel packages er bijvoorbeeld worden geïnstalleerd, dat zijn echt duizenden packages. Dat heb je allemaal nodig om uiteindelijk, zeg maar, die Hati Mellon C6 eruit te krijgen, zeg maar. Het is eigenlijk heel bizar. Maar het lijkt wel alsof we het ons zelf heel erg moeilijk hebben gemaakt of zo. Dat gevoel heb ik een beetje, ja. Ja, dat is wel interessant. Misschien kunnen we later op terugkomen. Dat is ook wel een leuk haakje. Oké. Ja, ja, ja. Ja, voor mijzelf, ik vind, dat vind ik aan front-end. Even kijken. Ik ben normaal gesproken dus gewoon een full-stack developer. Dus je doet eigenlijk alles. En dan zegt iedereen, je kunt alles niet goed. Best, vind ik ook, vind ik ook oké. Heerlijk. Dus als je meer back-end development doet, dan is er niet zoveel visueel, zeg maar. Ja, goed, misschien komt het JSON uit of een XML of whatever. Maar dat is wat minder interactief dan als je je Hati Mellon C6 in een browser hebt. Dus die feedback loop, zeg maar, die duurt wat langer, maar dan dat je dus direct gewoon HTML C6 in een browser hebt. Je savet en je ziet meteen het resultaat. En dat vind ik best wel vergelijkbaar met hoe ik vroeger programmeerde op, wat had ik, een MSX. Dat was ook al komende 64. Ja, je programmeerde iets en je zag meteen iets op je beeld. En dat is ook waardoor je, zeg maar, verliefd bent geworden op dat programmeren. Kijk, als ik tegenbij Kindle zou zeggen, hey, bouw even een JSON API aan. Maak een JSON API. Ja, dat boren ze denk ik niet zo heel gelukkig van. Je ziet wat JSON en laat ze aan hun vriendjes zien. Kijk, ik heb een stukje JSON aan. Dat is niet heel tof. Ik moet ineens aan die JavaScript meme denken. Die zal ik even in de tips delen. Dan zie je inderdaad een demo van een front-end developer. En dan zie je de hele club, inclusief developers en product owners, iedereen. Super enthousiast reageren. Tof, kijk, met één regel heb ik zoveel. En dan komt die backender. Dan hoor je alleen maar... Ja, dat. En die gozer heel enthousiast vertellen. Kijk, wat ik heb gebouwd. Rest API. Kijk, die JSON is helemaal simpel. Misschien is Saber wel een uitzondering. Maar ik denk dat de front-ends wat meer introvert zijn. Backends wat iets extraverter. Misschien ben jij een uitzondering in. Ja, dat kan. Ik ben sowieso meestal een uitzondering. Maar dat merk ik wel. Misschien omdat je dus volgestek bent heb je ook een stukje vond. Misschien is dat even daarmee te maken. Maar dat is een beetje hoe ik vaak mensen... Ja, dat zou best kunnen. Ja, kan. Maar dat is misschien wel voor laat. Wat ik altijd wel grappig vind is, als er wordt gesproken over front-end en back-end. Dat daar ook allemaal verschillende interpretaties in zitten. Want mijn interpretatie is dat front-end... Ja, dat heeft ergens met Javascript en de klant de ervaring te maken. Maar wat je dus ziet is dat bijvoorbeeld een website... Dat dat dan weer, hun CMS bijvoorbeeld, dat dat weer als een back-end wordt gezien. Maar als daar achter weer een of ander back-office-systeem zit... Dan heb je daar eigenlijk web-apis vaak weer omheen. Dat dan ook weer wordt gesproken als front-end. En een back-office-systeem wat dieper zit en weer een back-end is. Er zit best wel wat, merk ik, soms spraakverwarring in. In wat is nou eigenlijk echt front-end. Ja, dus je bedoelt eigenlijk meer vanuit the point of view. Het is toch vaak een black box wat we dan naar zitten te kijken. Maar wie weet wat er allemaal achter gebeurt. Dat is wat je bedoelt. Ja, nou ja, het is als je net één niveau dieper zit... Dan heb je bijvoorbeeld een web-apis dat ze dat dan weer als front-end noemen. Want dat is dan eigenlijk dan het aanspreekpunt. En daar zit er weer een of ander dieper database-systeem. En dat is dan weer back-end. Ja, dat is altijd wel grappig. Ik moet ook ineens denken aan... Ik was een keer in gesprek met een front-end developer en die zei van... Ja, dit waar je het nu over hebt, dit is de back-end van de front-end. Je zei dat op een gegeven moment. Ja, klopt. Oh, wow, wow. Ja, dat klopt. Maar die term wordt zo gebruikt nu, tegenwoordig. Want dan, ja, je hebt dus de back-end van de front-end. Voor de front-end. En die ontsluit dan weer allerlei APIs die je daarachter weer... Weet je wat ik toen dacht? Ik dacht, hou je back-end. Oké. Ja, precies. Die wist het ook. Ja, ja, ja. En toen werd je... Ik stond erop te wachten dat die mogen gebruiken. Toen werd je naar de deur begeleid. Ja, precies. Toen had ik geen carrière meer. Nee, maar die definitie is wel lastig, hoor. Daar heb je helemaal gelijk in. Want ik denk dat dat ook met de jaren best wel veranderd is. Misschien is dat ook... Want goed, één van de vragen is van, wat is nu front-end development? Ja. En ik denk dat dat zeker veranderd is. Want voorheen had je gewoon HTML, CSS... In de eerste instantie had je niet CSS, maar je HTML werd gewoon statisch geserveerd. Je ging met je browser naar een URL toe. En je kreeg gewoon HTML naar je toe met wat plaatjes. Dat was het. En op een gegeven moment kwamen er meer interactie in. Maar die interactie werd altijd wel voor jou uitgekoud, in eerste instantie, op de server. Dus je vulde wat in. Je ging naar de server toe. De server maakte iets nieuws voor je en die kreeg het terug. En dat was de interactie in eerste instantie. Maar later, omdat het wat rijker moest en luxer in je browser, die experience... Daar kwam JavaScript natuurlijk weer... Ja, misschien ook wel back-end of PHP, of zou dat je daarmee serveerde vaak? Dat klopt. Ja, dat ben ik ook inderdaad opgevoed. En het verhaal wat ik er een beetje uithaal van de laatste tijd is dat ook... Je wil ook zo min mogelijk de server belasten. Dat is ook wel wat ik vaak hoor. Dus dat front-end zo. Dus je wil eigenlijk de back-end heel... Ja, die discussie gaat er nu heen en weer heel erg. Sommigen zeggen van ja, je moet het helemaal op de server doen. Want op die mobile phones is het wat makkelijker, zeg maar. De anderen zeggen ja, nee, maar dan moeten onze servers in de cloud zijn weer duurder. Want die moeten meer processing doen, dus doen meer in je browser. Maar dat kan ook met security te maken hebben. Van ik wil meer dingen juist op mijn server. Dat is wel een grappige die je nu noemt. Ik heb samen gewerkt met Ringo. En Ringo die noemde op een gegeven moment webcomponents. En daar heb je ook dan weer... Toen die dat begonnen uit te leggen. Toen ook zoiets van ja, maar we doen het toch allemaal in JavaScript. En dan zitten we op dat niveau. En dan heb je weer webcomponents. Zit je daar weer eigenlijk gedeeltes te programmeren. Waarvan ik denk dat op eigenlijk server-site moet werken. Het is volgens mij ook wel eens iets wat een soort cyclisch is. Wat elke keer weer, dan weer front-end. Maar wat je denk ik nu ook wel ziet is dat je wilt eigenlijk... Zeker op een mobiel zeg maar. Maar ook op desktop wil je eigenlijk dat die website zo snel mogelijk iets teruggeeft zeg maar. En als je kijkt naar de meeste frameworks. Die gaan best wel wat over de lijn. Voordat je überhaupt een paar in kan tonen. En op moment dat je dat dus naar de server-site trekt. Kan je dat dus versnellen. Alhoewel je daar ook wel weer wat problemen hebt zeg maar. Maar uiteindelijk zeg maar kan je dat dan denk ik naar verleggen. Alleen kak kosten denk ik. Ja dat is weer een ander verhaal. En ook qua development kan je afvragen of het heel handig is. Maar ja je ziet er toch wel een verschuiving in ontstaan. En het ligt ook een beetje aan wat voor product je hebt denk ik. Ik bedoel als je het naar een particulier ofzo moet doen. Dan wil je het misschien zo snel mogelijk. Maar als het naar business is. Ja je zit dan zo erg als die twee seconden moet wachten. Voordat die respons krijgt. De eerste keer. Ja. En als het dan eenmaal een cash is. Dat er daar helemaal geen last van heeft. Ja dat is dan. Kosten, afweging en development afweging enzo. Nou dat is wel een goede ja. Want die business to business. Of het is een business-klant of bezoeker. Ja. Die heeft andere eisen. Want die discussie had ik misschien een paar weken geleden met iemand anders ook. Van ja. Een business gebruiker die kan niet anders. Die moet gewoon naar je site. Terwijl een consumer die zeggen. Ja tenminste dat wordt in Amerika. Als je twee seconden wacht gaat die naar de concurrent. Terwijl ik denk ja ik moet gewoon dat product hebben voor die prijs. Dus ik wacht soms wat langer. Maar daar is die wachttijd wel belangrijker zeg maar. Dan in business to business misschien. Dus dat is wel een goed punt. Maar het wordt ook wel de code die in je brouw. Om het even zo scherp te zetten misschien. De code die in je brouw draait is die is ook complexer geworden. Oh ja. Dan dat het was zeg maar. Dus als je zeg maar die knippoort meest voorheen. Ik als dotnet developer en full stacker werd front-end echt. Gedefineerd als alles wat in je browser dan draaide. Dus HTML, CSS, JavaScript, React, Angular. Noem het maar op. Wat allemaal in die browser draaide. Dat was front-end. Alleen ik weet niet of dat en dat heb ik niet per scherm. Maar ik merk gewoon dat er nu de laatste tijd dat er steeds meer. Ook server-side zeg maar. Met Node.js zeg maar. Aan de server-kant geprocessed wordt. En dat wordt dan ook zeg maar nog front-end genoemd. Dus die library of die framework zeg maar. Die doet ook iets op de server. Next.js doet dat bijvoorbeeld. Dus dan is het al wat vager om die front-end te definiëren. Want daar wordt zeg maar ook een deel. Je hebt dan van die hybride oplossingen. Een deel wordt in de browser gedaan. Een deel wordt door de server gegeneerde. En dat komt dan samen elkaar. Dus die definitie wordt gewoon steeds lastiger. En dat vind ik wel. Het is misschien niet moeilijk. Maar als je niet er zelf in zit dan weet je soms niet meer. Voor mij is dat ook nog steeds front-end zeg maar. Dat gedeelte. Ja ja precies. Dat begrijp ik wel. Ondanks dat het op de server gebeurt. Maar ja dat klinkt natuurlijk wel heel raar. Een beetje wat Sander net aangaf met front-end, back-end. Ja want net als bijvoorbeeld in React heb je nu. Misschien weet je dat. Heb je server components. Of zo. Niet server components. Ja er had thuis wel server components. Delen die gewoon op de server draaien. En dat is echt. Dat moet gewoon aan de server kan draaien. Dat kan niet in je browser. Ik bedoel dat heb je gewoon. Dus dat is al. En dat wordt nog steeds als front-end gedefineerd. En daarachter heb je dan wel weer andere back-end systeem. Om denk ik veel gegevens op te halen of whatever. Ja ik denk zodra het een beetje een visueel aspect heeft zeg maar. Dat je dan kan spreken van front-end. Dat er iets visueels uitkomt zeg maar. En of het nou op de server leeft of in de browser. Uiteindelijk het visuele gedeelte. Ik denk dat dat de definitie dan is van front-end. Dat is wel een goede denk ik wel ja. Ik denk dat als er een visueel eigenschap aan zit dan ja. Ja oké dan zijn we klaar. Ja op tijd. Oké bedankt voor het lijken. Wat vinden jullie nou echt gewoon echt leuk zeg maar aan front-end? Waarom is dat leuker dan dat je weet ik veel embedded development zou doen? Waarom niet iets anders? Ja voor mij heb ik ruim 10 jaar, 12 jaar bijna gedaan. Interactieve websites maken. Dat vond ik echt geweldig. Omdat je het visuele, de interactie zeg maar met de bezoekers die uiteindelijk zeg maar daar plaatsvindt. De uitdagingen. Ja ik vond zeg maar de interactieve websites maken echt geweldig. Ik heb heel veel in 3D gedaan. Ook een beetje in de begin tijd zeg maar van die 3D. Toen was het nog zo dat je de 3D gedeelte kun je alleen maar op de CPU doen. Niet op de GPU. En ik had een project van Coca Cola was dat. Die wilde graag dat Artic zeg maar met de polarbeers, met de ijsberen zeg maar. Daar wilde ze iets interactiefs mee maken. Dat mensen daar betrokken bij werden. En Coca Cola die sponsor door dat zeg maar ook de marketing et cetera. Dus die had mij gevraagd om een 3D omgeving te maken. Waarin ook ijsberen dan rondwippen. En ze hadden dus die ijsberen van die trackers gegeven. En die data kreeg ik als GPS binnen. En ze zeiden ja we willen ook graag dat het ook echt lijkt zeg maar. Dus moet je je voorstellen het is alleen maar op de CPU. Niet op de GPU. En dat moest ook echt lijken met trackers en dat soort dingetjes. Er was gewoon niet veel informatie. Als je nu kijkt op internet, je kan zoveel informatie vinden zeg maar. Ook zeker op 3D gebieden en dergelijke. Er was heel weinig informatie. En dat maakte voor mij echt een gigantische uitdaging om dat te maken zeg maar. Dat vond ik echt geweldig zeg maar. Dus die uitdaging, ik denk dat dat een beetje is uiteindelijk. Die uitdagingen opzoeken. Niet de geeikte dingen die je al een keer hebt gedaan zeg maar. Dat is altijd weer vernieuwend. Voor mij maakt dat in ieder geval front-end development. En voor jou Sander? Ik zit even na te denken. Vind ik het eigenlijk wel leuk. Ik denk dat ik het uiteindelijk... Ik ben juist van fullstacken toch? Misschien moet ik dat ook nog even zeggen. Ik ben een fullstack developer. Ik ben op een gegeven moment een soort van naar de front-end gerold. Maar ik denk dat ik het wel leuk vind. Wat ik namelijk er leuk aan vind is dat... Toen ik er uiteindelijk mee begon met front-end development... Was het altijd heel erg lastig. Er waren altijd heel veel issues. Het klikte niet zo goed als dat het met back-end. Met dotnet development was. Ik zie en zag dat er gewoon heel veel in te verbeteren was. Dat je net wat anders kon aanpakken. Net wat anders kon structureren. Dat vind ik eigenlijk wel gewoon... Dat klikt bij mij wel. Dat vind ik echt wel leuk om te doen. Om te kijken van hoe kan je nou dingen groeperen. Dingen hergebruiken. Dingen die je zelf custom hebt gebouwd. Te vervangen door iets wat erop staat. Ja, dat is eigenlijk wat ik daar leuk aan vind. Het is niet dat ik heel erg met het... Dat ik een klik heb met bijvoorbeeld het visuele. Dat heb ik eigenlijk niet. Het is meer de techniek inderdaad. Dat is wat meer mijn interesse. Ja, dat is het, denk ik. Zie je dan verschil, zeg maar. Tenzij je full stack developer ook bent. Er is verschil. Jazeker. Wat vind je fijner en wat vind je niet zo fijn? Een ding wat mij duidelijk is geworden. Is dat front-end development vind ik vele malen complexer dan back-end development. Dat heeft wel te maken, denk ik, dat de meeste front-end development tools... ...zit je dan aan de Node.js stack te werken. Ja, en daar komt gewoon zoveel bij kijken. Er zijn zoveel bewegende delen om ook maar de meest eenvoudige dingen te doen. En als je gaat afwijken, dan wordt het alleen maar steeds complexer en complexer. Terwijl back-end development, de back-end van de front-end... Dus had ik aan de CMS kant meestal te programmeren. Ja, dat was gewoon duidelijk. Ik heb veel met CMS-systemen gewerkt. Ja, de spelregels waren gewoon duidelijk. Je wist ook waar. Ja, je had weinige issues. En dat is met... Ja, dat vind ik met front-end development heb je heel veel keuzes. Je hebt heel veel smaken. Je kan heel veel dingen op een heleboel manieren uitvoeren. En uiteindelijk kom je er achter dat je toch niet de juiste keuzes hebt gemaakt. En dat vind ik wel leuk om daar dan... Ja, daar een beetje dat uit te vinden. Ja, precies. Ja, daar gevoel bij te kweken. Wat ik ook merk, het is ook echt wel veel volwassener dan dat het was. Ja, zeker. Want we kwamen uit een spaghetti JavaScript-wereld. Ja. JQuery was er een beetje. JQuery, ja. JQuery, zeg maar. Angular. Wat was de competitor ook alweer van JQuery? Er was er nog eentje, toch? Ik weet dat je zo iets van Bootstrap noemt. Ja, ja. Naar Bootstrap was er steeds meer. Er is wel iets geweest, maar JQuery was gewoon dominant. Overal. Iedereen zei ook van je... Op een gegeven moment leerde je JQuery en niet per JavaScript. Zijde, zijde, zeg maar. En dat heeft heel erg geholpen, terwijl tegenwoordig heb je niet veel JQuery meer nodig. Ook omdat die API... Volgens mij zag ik daar laatst iets over. Dat eigenlijk JQuery nog in zo verschrikkelijk veel dingen verwerkt zit. Ja. Volgens mij zit er ook nog een soort versie. Maar misschien ook wel in Angular. Dat weet ik niet. Nou ja, bij React zit het. Dat weet ik zeker. En View ook niet. Angular, volgens mij. Ja, het komt weleens voor. Volgens mij is de... Nou moet ik opletten. De popper JS, dat zijn pop-ups in Angular te maken. Die is volgens mij JQuery-based. Maar volgens mij Angular zelf is daar niks... Maar je hebt soms ook niet in de gaten. Dus afhankelijk van elkaar. Je installeert één package, maar die installeert weer tien packages. En die package installeert ook weer tien. Dus op een gegeven moment... De kans dat je JQuery ergens ziet in een project is vrij groot, denk ik. Op dit moment nog. Maar het wordt niet meer actief gebruikt, zeg maar. Ja, ik word er niet... Ik ben een beetje een asswipe op projecten. Ik kan er niet zo heel goed tegen als iemand in een react-project zit... Of een view-project. Dat ik in een keer JQuery langs zie komen. Dat kan ik me heel goed voorstellen. Waar ben jij aan het doen? Waarom, zeg maar. En dat volg ik dan niet. JQuery was vooral heel erg noodzakelijk... Op het moment dat we allemaal varianten hadden met browsers. Met Edge, 11, 10, 11, Internet Explorer. Firefox was toen ook nog helemaal populair. Ja, dat is helemaal waar. Dat werd iets eenvoudiger door het gebruik van JQuery. Ja, werd het glad gestreken. Dat klopt. Dat was ook wel fijn. En een ecosysteem wat er omheen... Allerlei plugins, StapBelle, Wtick, dat allemaal. Dat was echt heel erg rijk. Dus JQuery heeft zeker geholpen. Maar als we dan even snel vooruit spoelen... Vinden we dat we dat nog steeds hebben, die luxe? Dat we makkelijker zo'n plugin erin kan schuiven als het nodig is? Of wordt het alleen maar lastiger tegenwoordig? Als je kijkt waarom natuurlijk JQuery voor die browsers... Ik denk dat dat al redelijk is opgelost. Want de meeste browsers zitten allemaal een beetje op elkaar. Er zijn nog hier en daar een paar kleine uitzonderingen. Maar je hoeft niet meer zoals vroeger 5, 6, 7 verschillende browsers te testen. Als je de 1 of 2 pakt, dan heb je 90, 95 procent al binnen. En ik denk dat dat het verschil is met een aantal jaar geleden. En er zijn ook heel veel plugins voor Angular, heel veel plugins voor React, heel veel voor Vue. Ik ben meer... Er zijn heel veel opdrachtgevers die voorzichtiger in wat voor libraries ze erbij halen. Dus je begint met React en voor je het weet heb je 30... Phantasies of NPM packages erbij gehaald. De hele wereld binnengetrokken. Nu zijn mensen daar wat voorzichtiger in, omdat er ook wel rare dingen mee zijn gebeurd. Dus je let wel op wat je binnenhaalt. Of het een heel actief GitHub repo is. Er zijn een aantal dingen waar je naar kunt kijken om te zien of het wel slim is om die plugin te gebruiken. Of voor library. Dus dan eigenlijk wat ik hoor, als je ook kijkt naar alle browsers en mobiele devices en zo. Dus juist door die opkomst van al die verschillende frameworks, zou het wel het leven een stuk gemakkelijker kunnen maken voor een front-end developer. Om rekening te houden met al die verschillende devices en browsers die je moet ondersteunen. Volgens mij valt het... Om antwoord te geven, dat helpt. Maar het is ook wel dat... Wat is het? De laatste twee, drie jaar is er ook echt wel iets veranderd. Want het was natuurlijk Edge, die had zijn eigen versie. En je had Firefox en het zat allemaal een beetje op hetzelfde niveau. En wat ik nu zie gebeuren is dat Edge is natuurlijk overgegaan naar de Chromium engine. Nou, Chrome maakt er gebruik van, Brave maakt er gebruik van. Er zijn natuurlijk wel wat varianten nog. Dan heb je Firefox, maar Firefox is aan het wegzakken helaas. Safari, ja. Ja, en Safari is wel in opkomst. Maar Safari trekt steeds meer richting compatibiliteit met Chrome. En dat maakt het sowieso makkelijker al. Dus los van het framework. Dus het zijn twee componenten die dus van belang zijn dan? Ja, zeker. Dus de webbrowser engine en het framework die is. Ja, ja. Ja, maar ik weet niet of dat kijk niet meer zo goed. Heb er niet zoveel last meer van dat je in verschillende browsers moet draaien. Dat ligt ook een beetje aan wat de requirements zijn natuurlijk. Als je zegt van nee, ik wil Safari ondersteunen en ik wil Chrome ondersteunen. En allemaal mooie animaties en bewegende dingen. En je wilt het waarmaken, dan zul je het ook moeten testen. Nee, nee, dat klopt. Dat heb je gelijk. En dan in de API die je gebruikt, meestal. Ja, die zijn daarmee redelijk generiek. Dus daar heb je ook een framework eigenlijk niet meer. Als dat de vraag was, heb je daarvoor in ieder geval niet nodig. Dat is natuurlijk andere dingen waarom je die frameworks gebruikt. Maar voor dat gedeelte eigenlijk is dat echt niet meer nodig. Oké, nou mooi. En ja, je raakte, je zei het net eventjes, dan zul je het toch moeten testen. Nou weet ik ook wel, Ringo en ik werken samen. We hebben heel veel gesprekken over hoe je frontends het beste kunt testen. Zou je iets meer over kunnen vertellen, Ringo? Vanuit jouw kant, je ervaring. Hoe test je nou zo'n frontend? Ja, nu moet je inderdaad heel veel testen. Dat is wel een groot verschil, ja. Want vroeger, ik weet nog wel, toen ik begon, dan had ik echt nul testen wat dat betreft. En ja, we zijn al een beetje een doorslaan van mijn gevoel qua testen. Uiteindelijk wil je natuurlijk dat je alles afdekt. Er zijn verschillende soorten testen. Wat in ieder geval het laatste spreek dan wat we nu dan hebben bij Anva, zeg maar, een aantal dingen opgezet ook met Kishen erbij. Voor de code doen wij unit testen, wat redelijk gebruikelijk is. Er wordt heel veel bedrijven gedaan. Alleen minder unit testen dan voorheen. Dat heeft te maken dat we tegenwoordig ook iets kunnen gebruiken als component testen. En daar test je dus alleen het component mee. En dat kan met mockdata. Dan hebben we nog een feature test. Nou, feature test is eigenlijk wat groter. Dus je kan je ongeveer zien als een pagina die je dan aftest. Daar test je dus ook de integratie van verschillende componenten en zo af. En dan hebben we ook nog een end-to-end test. Nou, dat is eigenlijk dus dat je met de echte backend praat, zeg maar, en testen. Dus je hebt op zoveel verschillende, eigenlijk al vier niveaus heb je die testen. Daarbuiten hebben we ook nog een keer visuele testen. Dus om te kijken of je user interface en dergelijke nog klopt. Als je een team bijvoorbeeld gebruikt, ook als je verandert dat de kleurtje nog mal klopt. Dan heb je ook nog performance testen. Dat is de zesde test waar ik nu op zit. Nou goed, daar zijn we dan mee bezig om te kijken wat we daarvoor kunnen gebruiken. Maar dan zie je dus van dat het echt gigantisch is. En uiteindelijk wil je natuurlijk voorkomen dat je alles zou dubbel testen. Want ja, waarom zou je bijvoorbeeld je Engelen framework gaan testen als Engelen al getest is en dat soort dingen. Dus dat ga je niet doen, zeg maar. Dus we zijn wel een beetje aan het kijken van ja, hoe kan je ervoor zorgen dat je, je hebt natuurlijk de traditionele pyramide. Maar hoe kan je nou zorgen eigenlijk dat je qua kwaliteit, zeg maar, in use cases, zeg maar, kwaliteit, dat je daarvoor doet, met zo min mogelijk testen, waardoor je uiteindelijk bijvoorbeeld in die pipeline, als alles gedraaid door al die testen, dan wil je ook dat het zo snel mogelijk doorheen gaat. Maar je wilt wel alles afdekken. Je wilt wel die kwaliteit bouwen. Dan kies je verantwoordelijk voor om de kwaliteit te gaan weer. Oh jee, nou krijg ik allemaal boze e-mails. Maar ja, ik vind, qua testen is het een stuk professioneel geworden. En uiteindelijk wil je natuurlijk dat de klant gewoon geen problemen heeft. Maar mocht er dan een bug komen, zeg maar, ga dan kijken. Als ik zoveel testen heb, hoe kan het zijn dat die daar ingelipt is? Ga dat proberen op te lossen. Zorg dat hier een test is. Dan moet die test dus falen. Pas dat aan. Dan moet die test slagen. En dan heb je dat afgedekt, zeg maar. En ik denk dat als je dat, zeg maar, continu doet, dat je uiteindelijk voor zorgt dat je een collectieve, hele hoge garantie hebt qua software, zeg maar. Maar als je alles bij elkaar kijkt, vind ik het wel heel erg veel. Ja, zeker. Kijk, en daar ben ik helemaal met je eens. Dus we moeten heel goed kijken naar welke risico we innemen. Als we ook in het beginfase van een project zitten, ja, dan ga je misschien wat gemakkelijker mee om. Maar als je straks inderdaad gewoon live staat en er kunnen mensenlevens gered worden, ja, dan ga je toch wel even iets anders naar kijken. Je kan ernaartoe groeien. Niet dat het gaat gebeuren. Ik vind wel dat je toch al meteen die kwaliteit zo hoog mag, maar je kan ernaartoe groeien. Dus je bent toch niet allemaal benieuwd, zeg maar, inderdaad. Ja, daar ben ik mee eens. Weet je, ik werk een tijd bij het bedrijf waar ik nu werk. En wat ik daar bemerkt, is dat we eigenlijk in de chill het testen nooit echt goed voor elkaar kregen. We blijven bebouwen net op. We waren even aan het testen. En daarna viel het eigenlijk weer een soort van, ging het steeds verder stuk, een soort erosie noem ik het altijd, totdat je eigenlijk bijna weer niks had. En wat ik nu, wat mijn mening in ieder geval is, en dat is niet altijd even helemaal ook de praktijk, is dat als je aan het development bent, dat je gewoon daar het testen eigenlijk een soort essentieel onderdeel van is. Ik zei net ook van het voorbereiden, dat ik wat meer van het voorbereiden ben. En een van de voorbereidingen waar ik bijvoorbeeld heel erg van gechomeerd ben, is BDD. Schrijf in plaats van dat je gaat programmeren, schrijf in een soort vorm uit wat je verwacht. Als de klant dit doet, dan verwacht ik zus. Als de klant deze, dan verwacht ik. Als je dat uitschrijft, en daar geef je nog geen aanvulling in, dan ben je eigenlijk je requirements aan het vastleggen. En daar ben ik zelf heel erg van gecharmeerd, omdat dat zorgt ervoor dat je eigenlijk je requirements, je bent je documentatie aan het doen, je bent meteen ook je automatiseerde testen aan het doen, want die kan je, als je aan het programmeren bent, dan ga je die op een gegeven moment invullen met bepaalde checks of componenten, buttons kan je klikken en dergelijke. Je hebt er tijdens je ontwikkelproces, heb je er profijt van, want maak je fouten of doe je iets anders, dan ga je daar ook gewoon meteen profijt van hebben. Voorheen deden we dat soort dingen vaak achteraf, en ik zie gewoon dat daar heel veel winst te behalen valt, als je dat eigenlijk gewoon meteen daarmee begint, en gewoon meteen meeneemt in het verhaal. En het lijkt, zeker als je daar aan begint, dan lijkt het een soort van ja, maar nou ben ik met allemaal dingen bezig, wat eigenlijk nog niet heel belangrijk is, maar ik denk dat als je het naast elkaar houdt, dat je sneller je klusje klaar hebt, dan als je eerst je voorbereidingen doet, in plaats van dat je dingen nog moet gaan herschrijven, refactoren of achteraf gaat inbouwen. Doe jij dan ook al van tevoren ook de testen echt schrijven, dus van tevoren de testen schrijven en dan codeeren? Ik doe het tegelijkertijd. Ik probeer het tenminste niet altijd hoor, ik moet even eerlijk zijn, maar ik probeer inderdaad dan een soort van, wat is nou mijn klusje? Ja, het is inderdaad BDD, TDD. Ik weet eigenlijk niet eens welke kant ik nou helemaal precies zit, maar later ga ik het invullen. Dus de test-first-gedachte, dat komt er mee? Ja, maar het is een test. Je schrijft het in de vorm van test, maar het is eigenlijk het uitschrijven van de requirements. Ik denk dat de bewustwording ook de laatste paar jaren is. Ja, klopt. Je bouwt eigenlijk iets op en als je het achteraf doet, is het gewoon niet fijn om te doen. Dan raffel je het ook altijd een beetje af en dan ben je ook alweer de details vergeten. Terwijl als je als developer dat meteen doet, is dat een investering die zichzelf direct terugbetaalt, maar ook achteraf. Want op het moment dat je bijvoorbeeld met externe ontwikkelaars, dat er een nieuw iemand komt, ja, dan zijn die requirements, die zijn gewoon beschikbaar. En als zo'n nieuwe externe ontwikkelaar een wijziging doet, die eigenlijk niet zou moeten kunnen kloppen, ja, dan gaan dus je geautomatiseerde testen, gaan daar meteen melding van maken. Ja, ik ben daar zelf heel erg, ja, ik zie daar gewoon heel veel, heel veel winst in te behalen. Ja, wat ik ook wel mooi vind altijd, als teams dus een soort van, ja, noem het maar even, de test-first gedachte hebben, is dat ze ook meteen het ontwerp op testability natuurlijk ook even rekening mee gaan houden, want, ja, het is dus testability in de software, kwaliteit attribuut, ja? Ja, ja. Ja, daar staan zo, ja, achter ik natuurlijk kent zoveel kenmerk, ja, maintainability, hoe heet dat, performance natuurlijk. Nou, als je al die dingen dan meeneemt, dan is testability vaak hetgene wat jij dus net terecht zegt, vaak hetgene wat je dan achterlaat, weet je, achteraan. Ja, ja. Omdat je snel moet en je wil... Ja, ja. Je hebt je doel bereikt eigenlijk vaak. Zonder testen kan je ook je doel bereiken. Precies. Je hebt het opgeleverd. Alleen, ja, je hebt het korte versus lange termijn. Ja, ik ben trouwens altijd heel erg op de lange termijn gericht in mijn werk voor, nou ja, wie komt ernaar mee? Kan hij er dan ook mee uit de voeten? Of gaat dat allemaal wel of niet goed? Ik zit weleens te denken aan onze tijd, Saber, toen we bij Innofun heette. Ja, ja. Waar we toen met die... Wat was dat? Een multi-touch table. Waar we toen ook... Maar dat was echt niet dat we dachten van, we gaan eerst een paar testen bouwen. Ik zou niet eens weten hoe ik dat ding moet testen. Nee, maar zeg je, dat was een multi-touch tafel. Precies. Dat was wel een ding, zeg maar. Ja, maar misschien kwam het ook, omdat wij dachten van, ja, weet je, er zullen geen baby's dood gaan. Nee, nee, maar dat was precies. Dat is ook wel die... Hoe zeg je dat? Het risico, ja, wat je probeert af te dekken. Ja. En in dat geval, dat was misschien net een soort van prototype plus plus, zeg maar. Ja, dat was echt een prototype plus. Ja, we zouden iets bouwen als het werkte, dan waren we blij en dan zouden we het eventueel door ontwikkelen. Maar de testen van dat ding... Ja. Ik zou serieus nu, dat vandaag nog niet weten hoe ik die multi-touch tafel zou moeten testen, want we moeten een robot maken die dan multi-touch kan. Ja, we hadden wel wat unit-tests te kunnen schrijven toen. Ja, natuurlijk, voor de logica. Dat is een ander verhaal, maar echt een BDD of een N2N-test. N2N-test was wel heel moeilijk geweest. Iemand kan er creatief iets voor verzinnen. Ja, we hadden een robot kunnen laten aansturen op die tafel. En dan hadden we daar een test voor moeten schrijven. En dan een hele dure rekening sturen. Ja, maar wij doen wel BDD. Maar het is wel... Ja, ik werk zeg maar voor een bedrijf in een financieel sector en daar moet het... Dus wij moeten gewoon... Ja, je moet gewoon de kwaliteit kunnen garanderen. Dus je moet die risico's kunnen afdekken. Tegenwoordig moet alles traceerbaar zijn. En, weet ik veel, all the things. Dus waardoor je dat testen wel... Ja, dat moet gewoon. Dus dat is helemaal geen discussie meer. Wat jij zegt, wij gebruiken nog geen BDD. Dus het is niet dat we... Ik heb ooit eens een project, dat is al heel lang geleden, gestart. En mijn idee was om dan juist dus wel... Hoe heet het? Met die gurken, simpel is dat. Q-Qamber. De specifications, of de test slash specifications te beschrijven. En dan... Die falen dan allemaal. En dan geeft dat ook de voortgang aan van het project. Ja, precies. Dan weet je van, als je het allemaal uitschrijft en het is allemaal rood, dan zitten we nu op 0 procent. Nou, zijn er drie groen. Van de tien zitten we op 30 procent. Dus dan heb je gewoon een voortgang. Dan zie je ook... Ja, precies. Dat hebben we niet voor elkaar gekregen toen, helaas. Want er lag deels aan mij, maar ook de onervarenheid van ons allemaal als team van het schrijven. Dus we waren veel langzamer, waardoor we heel makkelijk teruggrepen op onze bekende manier van ontwikkelen. En het project stond gewoon redelijk onder druk. Of we moesten gewoon leven, als het ware. Dus dan neem je dat risico niet meer. In eerste instantie konden we dat nog, maar toen kwamen we in de squeeze. En toen was het ja oké, dit gaan we niet meer doen. We gaan gewoon weer terugvallen op onze normale manier. Maar dat is echt een hele... Lijkt me een hele fijne aanpak. Zeker met Edge at Development. Er wordt altijd gezegd, ja, hoe ver ben je nu met? Al weet je dus gewoon meteen. En, en dat weet je, ja, dat kun je waarschijnlijk ook beamen, is dat je geurkensyntax ook voor de leken te lezen is. Juist. En dat is ook wel heel erg fijn. Terwijl een unit test, een gemiddelde unit test, ja, we geven die soms wat wat wat fatsoenlijke namen, maar ja, dat is nog steeds een technisch ding. Daar kan een eind gebruik er niks mee. En wat het mooie is, want ik gebruik niet helemaal echt de geurkensyntax voor het schrijven van mijn testen, maar wat je voorkomt, is dat je het zorgt ervoor dat je eigenlijk je test langer kan houden, omdat je het niet technisch zou moeten doen. Dus dat je niet gaat uitschrijven van als ik op deze button klik, doe ik dit. Nee, want dan is het namelijk op het moment dat je naar een ander device gaat of een ander medium, dan kan je het allemaal weggooien als men de navigatieoverhoop gooit. Terwijl als je uitschrijft van onze klant, als onze klant dit doet, dan moet hij dit te zien krijgen. Ja, dat is iets wat altijd blijft. De dienst blijft je vermoedelijk wel houden. Ja, ook al is wat er eigenlijk achter zit, is anders. Ja, in de perfecte wereld hou iedereen het. Ja, ik denk dat dat je dat je wat op een gegeven moment wat mij opviel is dat er je kan heel snel naar een doel rennen en dan dat je heel snel programmeert. Maar daarna krijg je een soort echo effect met allemaal issues en dingetjes en oh en dit en zus en zo. En dat kost significant veel meer tijd, want er zit gewoon veel meer overhead in, want je hebt al iets wat live staat. Je hebt al eigenlijk iets wat je ook niet zomaar weer helemaal overhoop kan gooien, want dan introduceer je weer nieuwe issues. Terwijl als je dat gewoon, ja, wat gestructureerder aanpakt, dan heb je dat veel minder. Heb je ook gewoon die duidelijkheid, heb je die voorspelbaarheid. Ja, heb je ook minder regressieachtige issues. Kwaliteit ook, denk ik. Ja, het is zeker de kwaliteit. Nou ja, dan ga ik helemaal los. Want dit is, wij gebruiken dan, We hebben heel de tijd achter de feiten aangelopen met testen en applicaties. En wat ik nu zie, is dat we eigenlijk een soort die achterstand hebben ingewerkt bij het bedrijf waar ik voor werk. En dat we eigenlijk op heel veel vlakken nu aan het testen zijn, wat we voorheen niet deden. We doen nu ook edge case testen, omdat we dus gebruik maken van mocks bijvoorbeeld. We zitten niet aan speciale omgevingen vast, die dan soms wel werken, soms niet werken. We hebben gewoon heel duidelijk kunnen we continu alle onze testen doen. We gebruiken dan end-to-end testen op basis van Cypress. Dat gebruiken wij voor testen van onze functionaliteit. We gebruiken enkele unit tests omdat we weinig logica hebben in de front-end. Weel dingen met state en store. Maar voor de rest, de bulk zit toch wel ergens in componenten. Dan hebben we nog visueel testen. Daar ben ik helemaal, dat hebben we recent geïntroduceerd. Als je dat ook afdekt, dan kan je steeds meer naar iets toe werken wat gegarandeerd is. Als je zegt dat de functionaliteit goed is en dat het visueel goed is. Wat zou er nog meer fout kunnen gaan? Ja, er is er wel eentje. Ik zal het antwoord ook meteen geven. Dat is de integratietest die erna komt. Dus iets wat je oplevert om samen te werken met een ander systeem. Dat kan natuurlijk misgaan. Maar dat is goed om te weten. En dat is toch ook... Maar zo doe je het eigenlijk stap voor stap. In plaats van dat je zegt van ik ga in één keer... De illusie dat je vanaf nul, zeg maar, naar perfecte covertjes kan gaan, zeg maar, voor je testen. Theoretisch kan het, denk ik, wel om alles een soort aan elkaar te knopen. Maar ja, het geeft gewoon heel veel overheid en vertraging, denk ik. En ook weer risico. En een concessie is of een compromis, misschien moet ik het zo noemen, een compromis is dat je, nou ja, niet alles in één keer helemaal zeker weet, maar wel dat je van tussen de segmenten onderling weet wat het goed is. En als het dan niet goed integreert, dan weet je in ieder geval waar je het moet zoeken. Sander, interessant verhaal wat je vertelt. Dus wat ik hoor is dat jullie in het begin wat minder testen deden, en dan op dit moment nu veel meer. Maar wat was de beweegrede om dat te doen dan? Kan je daar iets mee over vertellen? Want natuurlijk, iedereen wil een topproduct, dat is wel duidelijk. Maar op een gegeven moment besluit je of je meer wilt testen of niet? Nou ja, ik weet eigenlijk niet eens wat nou de echte beweegrede is geweest. Het was eigenlijk dat we wel overtuigd waren dat we moesten testen en dat het er moest komen, maar we kregen het nooit echt voor elkaar. En daar hebben we op een gegeven moment wat dingen omgegooid en daardoor is het wel voor elkaar gekomen. En ik denk toch dat het in voorspelbaarheid, dat developers dat zien dat dat fijn is, dat je als je wijzigingen doet, nou ja, ik betrap mezelf regelmatig op dat ik denk van ja dit kan toch niet fout gaan, maar dat ik echt overtuigd ben dat het geen negatieve consequenties heeft en dan falen toch maar één van mijn testen erop en dan denk ik ja, die heb ik dus echt wel, die situatie heb ik gewoon gemist. Nou de kans was natuurlijk altijd aanwezig dat er weer handmatige testers die gingen handmatig testen en die gingen dat misschien wel of niet opvallen, maar ja dat voorkom je, dat je voorkomt door je testen gewoon goed zoveel mogelijk water dicht te doen en mee te nemen, dat voorkomt eigenlijk chaos, want achteraf dan heb je op productie het staan en dat is niet goed en dan gaat de product owner met een functioneel beheerder en de tester en die gaat het dan inpennen en dan gaat het via scrum en agile en dan komt het uiteindelijk bij de ontwikkelaar en ja dat is ook helemaal, het kost zoveel tijd en het is eigenlijk gewoon zonde. Ja, het is eigenlijk een investering vooraf eigenlijk, maar later ook een onderhoud, wijzigingen. Ik denk als developers heel fijn als je iets aanpast dat je bijna gewoon blind eigenlijk, dat is de ideale situatie, je blind kan release want als er iets fout gaat dan wordt het, als het goed is, een van je testen afgedekt. Maar dat is wel een route waar je bij heel veel bedrijven ziet. Het staat in het begin heel laag en men wil er naartoe werken en dan kost het veel tijd zeg maar. Dat is ook de reden waarom ik het vroeg, van wat zijn dan vaak de beweegredenen dat een bedrijf toch ervoor kiest. Ja, dat is misschien ook wel door issues die gekomen zijn of dat ze op een gegeven moment erachter komen van oh jee, als we hier nog een keer wat fout doen dan schaden we het bedrijf. Ja, ik denk ook dat bij heel veel bedrijven ook je regergeving, dat soort dingen allemaal verpakt worden. Oh ja, regergeving, precies. Dus jij moet er veel meer voorwaarden voor doen. Dus op een gegeven moment zie je bijvoorbeeld bij accessibility, dat is ook zo'n onderwerp. Als je kijkt, drie, vier jaar geleden was niemand daar heel erg geïnteresseerd in. Qua bedrijf, op bedrijfniveau iets hoger dan niet de frontenders, maar wat hoger zeg maar. Alleen nu is bijvoorbeeld, het is een verplichting vanuit de overheid, als je bijvoorbeeld een zorgkantoor hebt, dan moet je zorgen dat je een website accessible is voor iedereen eigenlijk. Dus ja, dan moet je er eigenlijk voor zorgen. Ik denk dat het een beetje hetzelfde met de testen zijn op een gegeven moment. Je wilt wat dingen afdekken, wat risico's afdekken. Dat bedrijf is steeds meer... Ja, maar je moet er ook een soort van naartoe groeien. Je moet er aan toe zijn, je moet er ruimte voor creëren eigenlijk. En op het moment dat je... Nou ja, eigenlijk testen is daar een onderdeel van, maar als je je code stack zo hebt, dan kan je er steeds een laagje boven doen. En steeds meer kan je meenemen, gecontroleerd. En is het niet dat je het met half-half doet, of dan stap je vanuit... En probeer je ook je test stack zo klein mogelijk te houden. Niet dat je zeven verschillende tools hebt, zeg maar, die allemaal anders zijn. Een moet je in Cypress, TypeScript, de ander moet in C-Shop. Dat soort dingen probeer je een beetje gelijk te houden. Precies, en daar was ik ook heel blij mee toen Ringo ons, ook binnen het project waar we zaten, even awareness van gaf, is dat we op een gegeven moment niet nog een derde tool moeten gaan introduceren, terwijl we Cypress al hebben, weet je wel, voor end-to-end testen. En toen kwam jij inderdaad met feature testen, bijvoorbeeld. Dat doen jullie. Ja, ik zit ook in de Cypress in principe. Ja, ja, ja. Component testen, dat het nieuw is. Dat hielp echt wel. Even een bruggetje naar een volgend onderwerp, want kijk, we hebben het nu veel over die front-end, maar ook een beetje vanuit een technische... Dus laten we even Testability even voor wat het is. Maar ik ben wel... Ja, jammer. Ik ben het ideale developer. Testen niet meer. Nee, nee, nee. Heel goed, heel goed. Maar we moeten door met de testen. Ik wilde graag even hebben over... Ringo en ik hebben ook vaak discussies over. Kijk, we hebben nog steeds met een back-end te maken, die wel eens qua api's natuurlijk veranderen en dat soort dingen. En als wij dus in de front-end de boel gaan mokken en stubben, ja, hebben jullie misschien wel tips voor hoe je dat een beetje goed kan streamlijnen? Hoe ga je om met front-end wijzigingen, back-end wijzigingen? Hoe zorg je ervoor dat alles met elkaar compatible blijft? Ja, als iemand het antwoord daarop heeft, dan hoor ik het graag. En zeg alsjeblieft geen BDD. Alsjeblieft niet. Nee, nee, nee. Daar kan ik geen BDD op toepassen, denk ik. Nee, nee. We mokken wel de api's. Dus eigenlijk de back-end van de front-end. Dat was hem toch? Ja, dat mokken wij inderdaad. En ja, daar zitten wel de nodige edge cases. Zitten er in bijvoorbeeld een foutmelding of iets wat niet gevonden kan worden. Daar kunnen we op testen. Dat is trouwens iets wat we voorheen nooit konden, omdat we dan aan een omgeving geknopt waren. En dat het ja, die omgeving die ja, die gaf geen foutmelding. Die die die testcase was er gewoon. Dus dat kunnen we doen. Dat is nog wel een handmatig iets. Dus je moet die mocks moet je handmatig onderhouden. En die kan je natuurlijk ook copypasten aan een of andere andere omgeving. Wat we alleen wel. Ik heb de neiging om van zorg dat alles. Dus heb je een productieverstoring gehad, maak daar een mok van. Zodat je daar volgende keer op kan die kan inrichten en kan testen. Alleen er zit op een gegeven moment gaat er een soort. Ja, noem je dat nou? Loop je tegen een beetje een soort tegen een plafond aan. Dat je dat het zo lastig te onderhouden is. En dat je eigenlijk dat niet alleen maar meer bij ontwikkelaars kan leggen. Maar is juist mok niet ingewikkelder dan echte data? Nou ja, het is een soort. Ik zie het ook weer hier als een soort compromis. Idealiter wil je natuurlijk alles aan elkaar knopen en meteen testen tegen de werkelijkheid. Alleen je moet er wel controle over hebben over alles. En dat is dus iets wat bij de organisatie waar ik voor werkte was dat niet zo. Die controle was er niet. Want daar werd één keer in het kwartaal of één keer in de maand. Ik weet het niet precies. Werden alle test cases gewist en werden er nieuwe test cases aangemaakt. En daar liepen we op remen erop terug dat onze testen eigenlijk niks anders deden. Van oké, kan ik doorklikken? Maar wat er op het scherm staat aan bedragen of gegevens of naam achter naam geboorte datum. Daar konden we niet op testen, want de volgende maand waren het weer andere leeftijden. Maar hoe zorg je er dan voor dat je wel in sync blijft? Want je hebt toch vaak te maken met integraties waar je geen controle op hebt. Zijn daar bepaalde technieken voor? Stel dat je de back-end aanpast en je hebt de front-end al staan. Je gaat vervolgens die back-end releasen. Dan sluit de front-end dus niet meer op de back-end aan. Dus dat is een probleem. Als je er dus niks mee doet, gooi je het gewoon naar productie toe. Je zegt van oké, de back-end is aangepast. Op de front-end doe ik niets. Ja, dan heb je dus een probleem. Het ligt een beetje aan de versioning gebruik van de back-end. Dan kan je er misschien nog maar wegkomen. Dan ga je eigenlijk op de integratie gedeelte gaat het fout. Wat je kan doen en dat is ook een beetje wat Kishen voor ons project hebben voorgesteld. Waar ik een beetje mixed feelings heb. Is om alle end-to-end testen te draaien op het moment dat je de back-end in de pipeline gooit. Dus je past iets aan. De back-end wordt aangepast en komt in de pipeline. Vervolgens draai je dus de end-to-end testen. Daar moet je natuurlijk wel voldoen in hebben staan. Dat het dan ook afdekt wat je wil. Dus dan ga je alle end-to-end testen draaien van de front-end op de back-end. En dan weet je of die slaagt. Als die slaagt dan is het oké. Mooi. Het is mooi. Naar dat is natuurlijk wel dat je alle testen elke keer moet draaien. Eigenlijk wil je gewoon veel eerder weten dat het niet goed is. Liefst wel, maar in dit geval is dat lastig omdat je de back-end. Ten eerste hebben we de back-end sowieso losgestaan van de front-end. Maar ik denk dat het grootste probleem is dat voor de front-end kunnen we echt goed traceren wat er is aangepast. We werken ook met NX Workspace, zoals jullie dat doen. Daar kun je heel goed met effecten weet je wat er is aangepast. Alleen... We kunnen straks nog even op inzoomen, daar ben ik wel nieuwsgierig naar. Uiteindelijk draai je dus wel alle end-to-end testen op dat moment extra. Dus als je de back-end aanpast. Ieder liter zou je willen weten op het moment dat je de back-end aanpast. Dat een effected systeem voor de back-ends eigenlijk ideaal zijn. Dan zou je het op elkaar kunnen aansluiten en dan draai je alleen maar de test op dat moment. Wat echt nodig is. Het probleem is op een gegeven moment dat die end-to-end testen kunnen best wel qua tijd oplopen. Dus ja, maar aan de andere kant hebben we best veel testen daarvoor. Ik ben wel benieuwd. Kunnen jullie je back-end dan een soort isoleren? Dat je die even de laatste versie hebt. Of is dat dan een omgeving eigenlijk? Ja, die gaat wel om een testomgeving. Wat je uiteindelijk doet, zeg maar. Je brengt alle wijsgingen die er zijn op een gegeven moment bij elkaar. En dan ga je nog een keer testen. Maar daar ben ik wel benieuwd naar. Dat klinkt heel goed. Maar dan moet je wel dus je vulling, je datavulling, die moet gewoon goed zijn. Want wij deden dit voorheen ook. Alleen de testomgeving, daar stonden dan weer andere testcases in. Maar dat is een beetje het bijhouden. Hoe zorg je nou voor dat dat op elkaar matcht? Stel dat je in zo'n omgeving vanaf 0 optuigt en de data ook kan werken. Maar je moet dat wel bijhouden natuurlijk. Dat is het grootste probleem. Stel met Mockdata, hoe zorg je ervoor dat je Mockdata heel actueel blijft? Iets waar we denk ik met een voorgaande aflevering misschien ook een keer bij hebben stilgestaan is contract testing. Dat kan ik niet meer hebben. Hoe komen we weer op testen eigenlijk? Dat komt altijd door mij. Ik weet niet wie dat was. Maar dat is misschien iets voor beide tips. Dat laden van die data is altijd het issue. Die API kun je wel afspraken over maken. Als die changes er zijn dat moet er door release management bla bla heen. Maar die data, dat is wel een ding. Wat wij volgens mij nu doen en ik zit daar een half in zeg maar. Dat is niet mijn capaciteit is dat we data in kunnen laden. Dus wij zeggen dat data in het andere systeem terecht komt. We maken die test case zoals het ware aan. Dus dan heb je al bij wijze van spreken zit er. Ja dit is compleet anders. Ik doe het bewust zeg maar dat het een ander domein is. Maar stel dat je 5000 orders hebt zitten in dat systeem. Dan maak je 100 test orders aan zeg maar. Dus die 5000. Doe je dat dan met de end-to-end test bijvoorbeeld? Dat zou wel grappig zijn. We doen het niet in de end-to-end test. Maar met de testen zeg maar. We gebruiken die 100 case waar wij van weten hoe ze eruitzien. Die orders zeg maar. Die worden dan gebruikt in die end-to-end test. Zodat je precies weet wat we gebruiken. Maar die schiet je dan gewoon in rechtstreeks ofzo? Ja precies. Dat is het interessante. Sommige zijn natuurlijk tussen aanstekens destructief zeg maar. Dus je kunt iets bijvoorbeeld als je een nieuwe order aan maakt. Als je nooit je test op, dan is dat al gewijzigd. Dus dat kan dus eigenlijk niet. Dus sommige dingen zijn lastig. Maar ieder kwartaal wordt dat spul helemaal weer leeggegooid. Dat andere team doet dat voor hun eigen systeem. En wij zeggen dan weer oké. Wij laden onze test cases later weer in. Omdat wij die API gewoon hebben op hun. Want dat is gewoon hoe wij ook gewoon werken. Maar hoe doe je dat dan? Even heel fysiek. Dus doe je dat dan via de end-to-end? Of doen we via de API's? Het aanmaken van de data doen we via de API's. Niet via de end-to-end test. Dat is gewoon een totaal andere applicatietool dingetje. Dat is op zich wel interessant. De uitdaging daarbij is als de API's veranderen van de andere partij, moet je die zorgen. Dat gebeurt nog weleens. Kijk, als de structuur een veldje bij komt, weet je, dat maakt niet uit. Maar soms zijn de relaties wel anders. Daarom dat ik als tip even erbij zet en dan zullen we het maar even later op testen. Maar contract testing zou daar een oplossing kunnen bieden. Het hele concept daarachter is dat je met elkaar een contract opstelt. Die sla je dan ergens op. Dus de afnemer en de producer. En die bespreek je met elkaar. Zodra dat dan iets wijzig, dan gaat van alles rood. Dat is natuurlijk de bedoeling. Zodat je inderdaad eerder erachter komt dan een end-to-end test. Misschien moeten we daar nog even inzoomen. En dan kom je sneller feedback. Ja, oké. Maar dan breekt het contract. En dan krijg je daar een signaal van. Maar dan kan het alsnog zo zijn dat die data anders is. Ja, data is wel een ander invul. Dus dat kan nog. En daar kan ook nog wel fout in zitten. Zeker, absoluut. Er zijn business rules veranderen. Dus dan kun je meer orders hebben per klant. Ja, precies. Dus daar zijn wel dingetjes die ook, los van de contract. Dat snap ik. Dus je maakt een contract over niet zozeer de inhoud, maar meer de structuur. Ja, precies. Dat geeft je. Dat is ook wel wat waard. Ik zal inderdaad de pacte noemen in de notes. Dat is goed. Nou, we zullen stoppen met de kwaliteit. Ik word er ook een beetje moe van nu. Ik besefte in één keer... Ah, gaat-ie weer. Nee, echt. Dit is de laatste. Ik besefte in één keer dat we met z'n allen hier ontwikkelaars om een tafel heen zitten en dat we zitten te praten over testen. Als ik me nog even een paar jaar terugdraai, dan was dat toch echt wel anders. Ja, zeker. En was dat meer uitzondering dan... Dat testen plakken we toch erbij. Dat doen we daarna wel. Ja, want het is nog steeds testen. Alleen de beweging die ik ook wel in bedrijf hoor, is dat... Dan zijn er testers in je team. Dus echt gewoon... Ja, die hebben we niet meer nodig. Dan moeten de developers zelf het doen. En ik vind ook dat de developers moeten kunnen testen. Alleen testen is echt een ander vakje. Ja, what the fuck. Het schrijven van de test, zeg maar. Of de manier waarop. Of hoe je... Nou ja, oké. Stel dat ik een user interface schrijf en maak. Dan heb ik daar tienduizend keer naar gekeken. En dan denk ik, oh, dan zit ik inmiddels gewoon eigenlijk de happy flow te bouwen. Oh zo. Ja, ja, ja. Maar dan moet ik die testcase moeten eruit voren maken. Ja, dat kan ik gewoon niet. Ja, het is, dat kan ik wel. Maar dat zit niet meer in mijn... Precies. Je hebt een hele andere flow. Ja precies. En het kan best zijn dat als ik zeg van oké, Kishen heeft iets gebouwd. En ik als developer kijk naar de scherm van Kishen, dan haal ik er waarschijnlijk ook dingen uit. Maar toch, de testen waar ik mee gewerkt heb, die halen dingen eruit. Dan denk ik, oké. Ja, ja. Dat ben je slim naar gedacht. Dus het is niet alleen maar... Ja, Saber, nou niet meer over testen. Testen we uit. Inderdaad, testen gaat niet uit. Volgende vraag die we wilden stellen. En ja, vul ze vooral in. What's the latest and greatest in front-end development? Ja, ik heb er eentje. AI. Ga je ervan? Nee, ik ga niet. AI, AI, AI. Nee, nee. Iets waar ik heel erg naar zit te kijken. Het kan ook nog wel NX noemen, maar dat is niet meer de latest. Maar dat is meer doorlopend. Nee, BUN. B-U-N. BUN-J-S. Ken ik. En dat vind ik wel heel erg interessant. En dat kan eigenlijk best wel een soort van, ik heb hem ook interne, heb ik nog genoemd, een game changer zijn voor development. Want voor front-end development. Want eigenlijk is het, ja, het hele hoe we pro... Kijk, stel dat je een storybook, als je een beeld storybook doet, dan zit je eigenlijk je code helemaal te beelden. En dan haal je hem door de TypeScript compiler in. Dan ga je linten. Dan haal je hem helemaal door de TypeScript compiler heen. Dan maak je een beeld om te kunnen releasen. Dan ga je hem helemaal door de TypeScript compiler heen. En zo verder. Unit testen, geldt hetzelfde voor. Ik weet niet of ik dat nou net zei. Maar BUN maakt het allemaal vele malen sneller. Met echt het package installeren, testen, gewoon heel je code base. En daar loop ik in de praktijk nog wel veel tegenaan met front-end development. Dat eigenlijk gewoon alles zo verschrikkelijk lang duurt. En dat je ook allemaal maatregelen zitten te treffen om dat zo snel mogelijk door de pipeline heen te doen. Bijvoorbeeld het end-to-end testen. Als dat in één keer veel sneller zou gaan, dan hoef je daar niet op te besparen. Dan kan je daarop doorpakken. Maar wat doet BUN.js dan? BUN is eigenlijk een drop-in replacement van Node.js. Alleen, volgens mij is het zo dat Node.js is geschreven op en in JavaScript. Volgens mij zit daar de Chromium engine ergens onder. Met de versie V8 of zo. Het heet de V8 engine, zo weet ik. Oké, praten niet helemaal onzin. Dat is mooi. Maar ja, daar hebben ze dus eigenlijk gewoon met volgens mij ZIC. En rust zijn ze daar allemaal dingen mee bezig. Ik denk dat het namelijk hier ZIC is. Maar dat is allemaal near-native code. Dus dat werkt gewoon veel sneller. Het filesysteem, dingen schrijven. Ja, dat gaat gewoon vele malen sneller dan... Het kan echt wel kane-changing zijn. Ja, dat kan. Er zitten nu heel veel dingen, merk ik, dat ik dingen tegen hou. Van ja, waarom zouden we niet op meerdere browsers testen? Waarom doen we dat niet continu? Bijvoorbeeld als je een git commit doet. Dat je een build, lint, test, allemaal op je eigen omgeving doet. Als dat in één keer wel mogelijk is. We zijn ook heel veel aan het kijken hoe kan je dingen optimaliseren. Ja, precies. En als je nou de core eigenlijk aanpast. Dat is in Node inderdaad. Ja, dat zou inderdaad echt zo goed werken. Dan zie ik daar echt zo. Ja, zeker. Dus ik heb daar ook verwachtingen van. Helaas is het zo dat het nog niet samenwerkt. Helemaal met NX Workspaces. Dus dat is jammer. Het draait toch niet op Windows? Nee, nog niet. Dat klopt. Dat klopt. Nee, sorry. Ik moet voorzichtig zijn. De Package Manager, dus als je MP en Package. Dus BunX ook bijvoorbeeld. Dus als je MPX doet. BunX is de tegenhanger. Die draait volgens mij wel. Maar het draaien van Node gewoon als applicatie. Dat draait volgens mij op Windows nog niet. Op Mac en dien ik wel. Maar ja, we doen niks op Windows toch? Ja, helaas wel. Ja, BSL. Daar heb je BSL voor. Heb ik ook. Maar BSL, daar zijn ook een haak en oog aan met BunX. Ik weet niet wat ze doen. BunX, ik sluit me heel erg aan. Het is heel erg interessant. Ze gebruikt als ik dat ze hebben hun eigen taal ontwikkeld. Om te versnellen. Dus dat is knap. Want iedereen dacht dat ze meteen rust houden. Maar dat doen ze volgens mij niet. Dus ze hebben een aantal concepten. Dus als jij je JavaScript code hebt. Sommige dingen, niet alles, die compileren ze naar ZIC. Zodat het daarna veel sneller draait. Dus dat is de grootste performance winst. Sommige dingen zijn niet sneller. Want ze hebben natuurlijk, er zijn nu al weer filmpjes van oké, maar dit gaat echt niet sneller. Maar ja, je weet, dat gaat misschien wel sneller worden. Maar sowieso een MPX install, zeg maar. Of een NPM install. En echt veel, veel sneller. Het is echt wel, in dat opzicht wel een gamechanger. Er ontstond een wedstrijd tussen Node en Deno. Deno ken je misschien ook wel. Node achtstevoren. Want de maker van Node, die is zeg maar voor zichzelf. Deno, ja. Die heeft een alternatief. Die heeft native, volgens mij typescript, et cetera. Alleen die hebben nooit gezegd, we zijn compatible met de API van Node. Daar heeft BUN wel gezegd. Oké, we gaan de API. En ze hebben een aantal dingen, die hebben ze gewoon naar BUN toegetrokken. Waardoor de schrijven-at-fas-systemen sneller. Een aantal dingen zijn echt wel heel stuk sneller. Waar het heen gaat, weet ik ook niet. Maar het is wel interessant om in de gaten te houden. Het brengt natuurlijk wel dit soort dingen, brengt iets in beweging. Want Node.js was natuurlijk best wel, dat was gewoon Node.js. En daar zaten allemaal nadelen aan. Maar nu wordt dat toch eigenlijk in beweging geduwd. Omdat er allemaal andere tools zijn. Misschien dat die tools nooit echt zo ver komen dat het helemaal afgerond wordt en bruikbaar. Maar het duwt wel weer de techniek vooruit. Oh ja, en de JavaScript Engine is die van Microsoft en Apple. Dus dat is wel een... En ik hoorde net Nginx Workspaces. Kan iemand daar iets over vertellen? Ik niet. Nginx Workspaces. Sorry, bedoelde NX. Ja, van Narwhal Technologies. Ja, wij gebruiken dat. We zijn daar een tijd geleden over gegaan. Volgens mij is het van origine en was het Angular Workspaces. Maar ze hebben op een gegeven moment ook allemaal andere plugins voorgeschreven. En een workspace is dat je meerdere apps, projecten, allemaal in één kan doen. Zodat je ze eigenlijk met elkaar kan verbinden. Dus stel dat je een component schrijft voor de ene programma. Kan je die ook hergebruiken in een andere programma. En alles zit in één versie beheerssystemen. Dat maakt het gewoon veel lastiger. En dat is echt wel een verschil ten opzichte van. Ik zeg nou lastiger. Dat bedoel ik eigenlijk niet. Makkelijker moet het juist zijn. Ja, ik zeg het niet goed. Nee, gaat helemaal mis. Misschien is de ervaring goed. Ja, misschien bedoel je dat. Het is een monorepo. Ja, het is inderdaad een monorepo. En je kan daar inderdaad volgens mij ook nog weer packages in gaan bouwen. Maar dat je toch weer iets anders. Dat je iets op kan leveren wat daaruit komt. Maar in de praktijk zagen wij best wel problemen met het opleveren van packages. En om al die versies dan goed te doen. Want je moet ze allemaal weer tegelijkertijd en allemaal compatible gaan releasen en onderhouden. Ja, het is gewoon een administratie op zich. Terwijl als je gewoon één werkelijkheid hebt, dan is dat gewoon een stuk makkelijker. Dus bij ons heeft dat echt wel heel veel opgeleverd. Maar geven we dan het gehele... Ja, dat is één vraag. Maar geven we dan het gehele één versie of zijn dat alsnog... Je hebt eigenlijk één versie weer systeem. Je hebt wel allemaal applicaties die je eigenlijk los kan releasen. Dus er komen allemaal losse artifacts uit. Eén of meer. En die hebben dus wel in losse. Dus stel dat je nu, als ik het goed begrijp. Dan zitten er twee applicaties in. En dan heeft applicatie één een versie en applicatie twee heeft zijn eigen versie. Nou ja, eigenlijk niet. Ik zit even na te denken hoe ik dat nou het beste kan zeggen. Je compilet mee, je krijgt een versie die je mee compilet. Oh zo, oké. Maar je kan wel uiteindelijk twee applicaties eruit krijgen. Dat het wel echt losse applicaties zijn inderdaad. Ja, zeker. Applicaties in libraries zeg maar. Die libraries kun je dan weer onderling uitwisselen met de verschillende applicaties. Dus ja, het is een heel uitwisselsysteem. Grote voordeel is dat je één keer alle packages, alles bij elkaar. En ik denk ook zeker als je kijkt naar bijvoorbeeld aspect wat ook de laatste 2, 3 jaar er gewoon boven is gekomen in de front-end is de security eigenlijk. Nou ja, het probleem was in het verleden had je bijvoorbeeld iets van 30 applicaties. En twee werden op een gegeven moment actief nog onderhouden zeg maar. En er werd er iets meer gedaan. Die andere 28 die bleven liggen. Die werden niet ge-updated. Maar er kwamen wel issues uit. En er was ook geen reden toe. Er was geen business case om die dingen te gaan updaten. Het mooie is natuurlijk als je NX Workspace hebt dat je die wel moet upgraden. En door het zogenaamde effected systeem dat je ook kan zien van oké, nu heb ik de package aangepast. Dit heeft dus invloed voor al die 30 applicaties. Ga ik al die 30 applicaties opnieuw bouwen, ga ik opnieuw testen. Dus hij zoekt uit van wat is er daadwerkelijk. Ik zei het woord testen. Ik hoorde het woord testen. Wat ik ook al van Ringo echt geleerd heb ook bij het project is dat effected. Dat is wel heel krachtig. Dat is eigenlijk een soort essentieel. En ik moet zeggen dat testen, daar kom je met NX Workspace niet mee weg. Want als je op de ene applicatie iets, een wijziging zit te doen voor de ene applicatie, kan het zomaar gevolgen hebben voor de andere applicatie. Met niet testen kom je niet mee. Je moet testen. Dat is een essentieel onderdeel ervan. Want je weet namelijk niet wat je in die andere applicatie voor schade brokend met je wijziging. En daar heb je dan voor het testen. Oké, gauw weer door naar het volgende onderwerp. We zitten inmiddels ook al bijna tegen de twee uur aan te tikken, of niet? Nou, ik dacht we hadden net begonnen. Ik denk dat we wel... We lopen warm hier. Ik denk dat we wel richting... Vanavond deet-ie, geen boelen. Nee, precies. Gauw door naar het volgende onderwerp. Wat is Storybook nou eigenlijk? Want we hebben het wel een paar keertjes genoemd, maar ja, wat is het nou? Storybook is mijn grote liefde. Oké, een lachstory. Ja, nee, ja. Kijk, Storybook. Ik zei net eigenlijk dat ik begon met BDD. En dat klopt. Want BDD zegt je je requirements mee en dan ga je beginnen. En dan kan je je... In Storybook kan je je componenten bouwen. Zonder de logica. Dat kan je eigenlijk allemaal parallel doen. En Storybook is eigenlijk een soort testbank of een werkbank waar je dan je componenten oplegt. En dan kan je zelf bepaalde situaties, de variaties kan je uitwerken. Bijvoorbeeld als je iets van een tabel moet laten zien, dan ga je hem ontwikkelen. Dat hij er goed uitziet in je Storybook story. Dat er bijvoorbeeld geen regels in zitten, geen items in je tabel. Of dat er één regel in je tabel zit, of twee. Of heel veel dat er paging moet plaatsvinden. Of dat er iets in getoond wordt wat heel lang is. En dat je misschien ook wel meteen met responsiveness, dat je wilt gaan kijken en controleren. Of het inderdaad goed responsive is. En dan zit je nog helemaal los van je state, store, logica. Want dat heb je eigenlijk allemaal... Dat zit eigenlijk daar dan buiten. Presentational Smart Components is ook wel iets wat heel erg met Storybook wel heel handig is om te doen. Maar al die variaties kan je eigenlijk al doen. Er kwamen zoveel issues in de praktijk langs met rare leestekens. Of dat mensen lange namen hadden en dat werd weer niet goed getoond. Met Storybook kan je dat eigenlijk meteen al. Kan je die variaties maken. En dat maakt je development, maakt ook weer veel voorspelbaarder. En dan gaat het mooie brugje nog heel even als laatste. Je kan ook visueel testen daarop doen. En daar gebruiken we de dienst Chromatic voor. Dat is een betaalde dienst. Maar ja, dat is... Je krijgt gewoon... In je pipeline kan je testen of er visueel of er verschillen optreden. En dan kan je dat accepteren of laten reviewen of andere mensen erbij halen. Dat is gewoon heel krachtig. Dat is eigenlijk een van die pijlers die je wilt kunnen testen. Dus het functioneel, visueel. Ja, een soort van alle... Dus die diensten bied je een storybook aan dan? Ja, storybook is eigenlijk... Je maakt ervan een soort website. Je kan dat dus opleveren, ook aan externe partijen als je dat wil. Kijk, dit zijn de componenten die wij hebben. Die gedragen zich zo. Als dat niet goed is, kun je dat aanpassen. Ook binnen bedrijven. Je ziet het als een soort van lego steentje. Dan kan je zeggen, als er iemand... Het hoeft niet speciaal een developer te zijn. Het kan ook iemand zijn die een analyse moet doen. Op te kijken van wat moet er gebouwd worden? Wat hebben we al in huis? Je gaat dan een soort cartologisch naar die website toe. Je ziet precies wat er binnen bedrijf allemaal gemaakt is. Sterker nog, je hebt ook de mogelijkheid om ook verschillende teams onderling te kunnen kijken. Wat is er allemaal gemaakt? Zo is het in de praktijk al voorgekomen. Sommige componenten worden soms twee, drie keer gemaakt door verschillende teams. Maar zelfs ook in hetzelfde team worden ze in verschillende variaties gemaakt. Het is een manier om ook dat te delen. Wat je al zei, in isolatie die componenten maken is een hele mooie punt. En de variaties dat je dat kan zien. In het verleden kun je iets programmeren. Dan wil je even kijken of dat werkt. Dan zet je wat extra code in je applicatie. Dan zet je een commentaar of vergeet de verwijdering. Dat werkt eenmalig. Maar de volgende keer als je iets aanpast, weet je niet of het allemaal gaat. Historiebook, echt een hele mooie aanvulling. Voor ons is het ook echt wel een systeem. We zijn bezig met het upgrade van Angular 16. We zitten voor te bereiden voor Angular 17. We gebruiken Angular Material. Op een gegeven moment hebben ze de huidige versie van de componenten Legacy genoemd. Dan moet je langzaam migreren naar de officiële versie. Met dat visueel testen, als je dan updates doet en je gaat wijzigingen doen, kan je visueel op alles wat je in Storybook hebt staan, kan je controleren of het goed is. Ik ben onderdeel van een platformteam. Dus ik ken al die applicaties, hoe die allemaal in elkaar zitten en hoe je er doorheen kan klikken. Ik weet het niet. Alleen wat ik wel kan doen, ik kan gewoon kijken in Storybook en ik kan gewoon zien of er verschillen of issues zijn geïntroduceerd. Maar dan moet je wel als developer in Storybook het een en ander vastleggen. Dus dat is wel de discipline die je dan wel overal moet hebben. Ja, eigenlijk wat je daar doet met Storybook, dat is die werkbank. Daar leg je je componenten op. Als je er niks in stopt, dan zie je niks. Je kan er in het ding instoppen. Dus daar ga je je datafulling eigenlijk doen. Wat normaal vanuit je applicatielogica komt, die kan je er zelf instoppen. En komen er bijvoorbeeld gebeurtenissen, bijvoorbeeld dat je op een button hebt geklikt, dan komt daar dus events uit en die kan je ook afvangen. En die dingen kan je met Storybook daar op controleren. Je kan het ook echt als development, tijdens de development, als je niks hebt, zeg maar, ga je beginnen. Dus het is niet zozeer dat die component helemaal klaar moet zijn. Je gebruikt het juist om het component ook te ontwikkelen. Dus per saldo is het eigenlijk niet heel veel extra. Alleen wat je dus vaak ziet gebeuren bij een bedrijf die dat nog niet heeft en zeggen, oké, de Storybook lijkt ons wel handig. Dan blijkt dus in een keer dat best wel veel werk is om dat allemaal eventjes te maken. En ja, terwijl als je er meteen mee begint, dan heb je eigenlijk niet heel veel extra werk aan. Dus in een bestaanproject Storybook kan gebruiken is wel... En zeker als je develops hebt die nog nooit iets meer gedaan dan kan er wel wat tegenkomen, zeg maar. Ja, snap ik. Zelfde ook dan met testing. Zelfde verhaal als je het achteraf doet. Oké. Nou, mooi. Ja, het lijkt me wel leuk om even naar onze laatste... Ja, naar de tips. Tips, tips, tips. Ik zal jullie al voorbereiden, ik heb geen tip. Wat? Ook geen geld. Ik denk, ik heb ook geen geld. Nee, nee, zeker geen geld meer. Maar, hoe heet dat? Nee, ik heb geen tip. Dat is volgens mij de eerste keer. Dat doe je elke keer. Ja, precies. Maar... Nee, nee, nee. Jullie mogen voor mij de tips geven. Dus ik weet niet wie wil beginnen. Ja, ik wil wel beginnen. Ja, tips. Als ik naar mezelf kijk, zeg maar, als je stelt dat je... Je begint net als met front-end development. Als ik naar mezelf kijk hoe ik... Buiten dan, ik heb natuurlijk al een studie gedaan, et cetera. Maar voor mij was eigenlijk open source de key. Daar is eigenlijk alles voor mij veranderd ook. Ik was op een gegeven moment in de gelukkige positie... Dat ik een hoop websites had gemaakt. Financieel niet al te veel problemen had. Dus ik kon eigenlijk allemaal prototypes maken. Dat ben ik heel veel gaan doen in desktop in flash, zeg maar. En toen leerde ik eigenlijk via de open source community... Leerde ik paper vision, paper vision 3D. Dat was een 3D-engine, zeg maar. Leerde ik kennen en ook de mensen, zeg maar, daarbij. Daar heb ik echt heel veel van geleerd, heel veel gezien. Op een gegeven moment zijn we ook naar away 3D, is dat gegaan. Nieuwe engine, zeg maar. En daar waren we met, laten we zeggen, twaalf mensen ongeveer. En daar heb ik zoveel van die mensen, heb ik zoveel geleerd eigenlijk. Dus ik zou zeggen, als je naar github gaat bijvoorbeeld... Er zijn zat open source projecten waar mensen zoeken. Probeer contacten te komen en bouwen gewoon een relatie mee op. Ik denk dat je daar heel veel kan leren van die mensen. Dus ja, die tips zouden zijn, open source projecten sluit je daarbij aan. Een goeie. Zijn er ook dingen die jij in je vrije tijd misschien met ons zou willen delen? Weet je al tips die je denkt van nou, ik heb dit boek gelezen of een film zien? Een soort jambers in het... Nou, als je het over een boek hebt. Ja, wat ik dus ook wel heel erg interessant vind is AI. Maar jullie vorige podcast, dat heb ik ook heel veel interesse in. Dus daarmee kan je ook uiteindelijk een boek schrijven. Dus ja, dat is een beetje een heel vervelend of lastig onderwerp, want op mijn vrouw is schrijfster. Dus ik had het over AI gehad en dat mensen, zeker developers, zeggen toch best wel of zoiets van moet dat nou allemaal? Zeg maar niet iedereen, ze staan heel erg happy mee met AI. Dus dat vertelde ik ook tegen mijn vrouw. En die zei ja, knijpte ja, die begreep het allemaal natuurlijk. Tot dat ik begon. Ik ga iets schrijven waarmee ik dus een boek, waar ik een boek uiteindelijk mee kan laten genereren. En dan kom je op haar gebied. En toen sliep je op de bank. Maar ja, ik vind dat super interessant. En wat ik ook heel erg interessant vind, is eigenlijk het creeren van code. Dus ik creer niet verkozen, maar het creeren van kunst eigenlijk via code. En toen kreeg ik dat ook heel veel doen. Maar daarvoor heb ik, ongeveer 20 jaar geleden was Joshua Davis, die had een conference, dan was ik helemaal echt flabbergasted bij. Ik vond kunst heel leuk, maar ik was er niet zo heel goed in. Iemand zit naast me, ik weet wel goed wat het is. Daar zal ik straks wat meer over vertellen. Dus ja, dat was een beetje mijn mankoop. Maar mijn moeder is wel heel erg, die schildert ook en dat soort dingetjes. Dus ik had dat helaas niet meegegeven, maar ik vind het wel heel erg leuk. En ik vind ook fotografiebewoed heel leuk. En uiteindelijk, ja, met code kan je dus ook hele leuke dingen doen. En eigenlijk Joshua Davis was iemand die mij daar heel erg in geïnspireerd. En dat is bijna twintig jaar geleden ofzo, dat hij talk had, ergens in Amsterdam. Dus eigenlijk ben ik altijd mee bezig geweest, maar in vrije tijd inderdaad. Dus ja, dat soort dingen vind ik heel erg leuk te doen. En gaming. Games maken. Oh, ook nog recentelijk of niet? Laat ik zo zeggen, we hebben een stuk of 15 prototypes gemaakt. Uiteindelijk is er volgens mij eentje uitgekomen. Maar ik werk met iemand samen die meer een kunstenaar is. Ook designer eigenlijk. En dat is een paar weken ben je met het project bezig en een paar weken daarna dan is het iets anders. Maar ik vind het niet erg, ik vind het gewoon leuk om te doen. En daar leer je ook wel heel erg veel van om dat soort dingen op te pakken. Opnieuw voor de nieuwsgierigheid, hebben jullie nog ergens iets live staan waar we kunnen kijken? Als het goed is, moet er wel iets live staan inderdaad. Dat moet ik even denken. Dat mag ook in de show notes straks. Ik weet eigenlijk niet, want het is echt wel een jaar geleden. Ik weet niet of het nog steeds in die stores staat. Altijd leuk om het even te delen. Nou, dankjewel Alingo. Sander? Ik heb er ook nog eentje. Ik volg de nodige mensen op YouTube. Gewoon omdat het gratis is. Maar daar heb je Dave Farley. En die heeft een kanaal. Volgens mij is dat kanaal van hem. Dave Farley. Ja, goed zo. Ja, die heeft een kanaal Continuous Delivery. En op een of andere manier, als ik zijn kanaal volg, zijn aflevering. Dan heb ik elke keer van. Hey, ja, dat ben ik gister ook. Heb ik dat tegenkomen? Oh, dat is ja allemaal. En dat is prettig. Dat is echt wel die bevestiging ofzo. Ja, het is van ook. Het is dat dat klopt. Maar hij gaat ook dingen daarover zeggen. Van oh, dan kun je beter dit doen. En waarom je dit nou eigenlijk aan het doen bent en waarom het nou ook. Hij zit dan ook een soort eigenlijk voor mezelf. Zit ik van ja, maar waarom ben ik hier nou mee bezig en vind ik dit erg? En ben ik? Probeer ik dit nu eigenlijk op te lossen? En dan benoemt hij eigenlijk voor mij van ja, dat zit je op te lossen vanwege dit soort situaties. En dat heb ik elke keer. Hij heeft behandeld. Wel steeds allemaal verschillende onderwerpen. Maar het is elke keer dat ik denk van het lijkt wel net of die zit af te luisteren. Wat ik op mijn werk, waar ik mee bezig ben. Dat gevoel geeft hij wel meer. Dat doet hij ook. Ik wil het niet verklappen, maar ja. Ja, dat is er. Weet dat deze podcast aankomt? Ik vind dat echt wel een kerel die ja. Wat de volgende gast wordt dat? I wish. En Engels ook. Ja, Engels. Maar wel een goede tip. Ja, zeker. Het is echt wel interessant. Als je verder wil komen, dan proficineeler dan. Ja, heel fijn. Luisteren naar hem. En heb je nog een recentele tv serie die je zou willen aanraden aan ons? Nee, eigenlijk niet. Film ook niet? Kijk in films. Films zijn stom. Stom. Als we een beetje niet werk gerelateerd. Ik ben heel erg wel bezig met huis automatisering. Dat vind ik ook wel. Home Assistant. Volgende aflevering. Dat hebben we niet gedaan, volgens mij. Jawel, één keertje toch? Oh ja, Pauline. Pauline, ja. En er was iemand die dat zelf deed. Dat klopt. Ja, dat is leuk. Daar gebruik ik mijn vrije tijd voor. En mijn kinderen. En je kinderen, wauw. Oké, we gaan naar de volgende. Jij tips, Kishen? Ik? Ja, zeker. Ik kan sowieso iedereen aanraden om naar onze CodeKlets Slack kanaal te gaan. Daar hebben we alle props naar Leon Berenschot. Die had monodrawhealthtone.com gedeeld. En dan kon je volgens mij vrij snel een hele coole ASCII... Echt? Ja. Zullen we even klikken? Ik zie een robot. Oh, dat is cool. Dat is een powerful ASCII art editor. Designed for the Mac. Oh ja, voor de Mac ook exquisiet dan. Kan die ook praten? Ja, dat zou wel cool zijn. Het staat erbij. Hello friends. Ja, precies. Ga je weg? Ja, deze aflevering is bijzonder voor mij in ieder geval. Mijn broertje is vandaag ook meegekomen. Die zit op de achtergrond hier. Die heeft een mooie... Zit er echt mee te tekenen en mee te schilderen ook. Hij heeft niks met idee, maar wel een nerd wat dat betreft. Ja, net als wij. En ik zou jullie willen vragen om eens naar zijn Instagram te gaan. Hij is de opkomend artiest, kunstenaar, Deep Spandee. Ik zal ook even in de show notes... Zal ik eventjes... En de A's zijn met 3'tjes. Zijn 3'tjes, ja ja ja. Hoe nerd kan je zijn, hè? Nee, helemaal goed. Ja, toch? Dus ja, ga kijken. Wat voor kunst maakt hij dan? Ik geef even het telefoon. Mag dat... Ik krijg ineens een extra gast. Ja, horen jullie mij? Zo krijg ik een zware stem, toch? Ja. Wat kunst maak je? Ja, street art. Ik gebruik voornamelijk aquarel, dus waterverf. Dus totaal niet vergevend. Maar het is gewoon heel fijn voor mij. Ik ben nu momenteel ook heel veel bezig met India Inked. Dus daar ben ik nu een beetje mezelf op aan het, ja, moet ik zeggen... Maar ik weet niet zoveel van street art. Street art, waar doe je dat dan op? Doe je dat gewoon, ja, niet op de muur? Ik kan illustraties denken, portretten alleen in een bepaalde stijl. En dat is ja, toch heel erg onbeheerst. Cool. Onbeheerst. Je wilt eigenlijk, hoe heet die bekende uit Londen? Engeland? Banksy? Ja. Banksy? Ja. Oh die? Je wilt gewoon de next Banksy? Nou ja, dat weet ik niet. Nee, nee. I wish. Maar ja, ik durf te dromen. Maar ik heb nog veel meer ideeën. Maar ik start eerst met schilderen omdat daar gewoon heel veel passie in zit. Maar uiteindelijk wil ik nog veel meer dingen. Maar dat is wat jij hebt gemaakt? Ja. In mijn ooghoek zie ik wat. Oh, cool. Ja, zeker. Nou. Gaan we kijken? Ja, inderdaad. Volgens mij doe je ook nog wel wat exposities hier en daar. Maar goed, dat zullen we ook wel laten zien. Ja, nu momenteel zitten we in een stop. Dus even voorbereiden voor het volgende seizoen. Oké. Ja, dat is ook belangrijk. Ja, even. Ik geef de mic over. Ja. In elke bank. Ja, cool man. Thanks. Hartstikke tof. Ja. Ik zou ook sowieso die JavaScript meme even delen met die back-ends en die front-ends. Dus dat doe ik straks wel eventjes. Ik moet even opzoeken welke het ook weer was. En ja, Pact heeft een stukje over contract testing. Zal ik ook wel even met jullie delen waarmee je dus contracten kan opstellen. Ook tussen back-ends. Want als back-ends moeten we met elkaar wat communiceren. Ja, dat is wel een interessante. Dus wat Ringo en ik vaak bij onze huidige opdracht over hebben is, joh, waarom wisten we dit nou niet eerder? Waarom moeten we die gruwelijke end-to-end-test, weet je wel, aan het einde pas achterkomen? Dus ik denk dat contract testing best wel zou kunnen helpen. Ik denk ook wel wat. En wat ook wel een interessante beweging was, maar ik weet niet of dat nog steeds leeft, is om de front-end ook te zien als een, en tuurlijk, je moet hem zien als een consumer, maar dat je dan ook een contract zou kunnen opstellen tussen een echte back-end en een front-end. Ja, daar heb ik het wel over gehad met een aantal back-ends, maar uiteindelijk gelijkt het erop dat dat toch niet helemaal daarvoor bedoeld is. Ja, precies, dat dacht ik al. Helaas, maar het was wel echt een hele mooie oplossing geweest. Dat wou ik net zeggen, want dan kom je er echt achter van, hey, dit is echt sneller dan dat we hadden verwacht. Maar goed, ik denk ook dat het daar niet voor gemaakt is. Oké. Nou, Saber nog wat binnengekomen. Loki. Loki? Ja, die is net uit. Seizoen 2. Ja, ja, ja. Dat is gewoon. Ja, ik heb het nog niet afgekeken. Ik kon het niet afkijken, want mijn kinderen die kwamen binnenlopen. Maar anyway. Ja, ja, ja. Ja, dat is ook eens wat. Dat had ik gekund. Dus, maar dat seizoen is net begonnen. Dus dat was een van de Marvel series die me heel positief heeft verrast. Ik ben ook wel best wel een Marvel geek, zeg maar, qua comics. En ik heb. Ik had juist de Thor en Loki comics nooit gelezen. Dus dat is eigenlijk misschien wel handig. Misschien wel of niet, weet ik niet. Maar ik vind in deze serie wordt hij best wel. Ja, het is echt gewoon leuk. Ja. Ik had ook Luffy gezien. Nee. Oké. Welke is die nog eens? Luffy heet dat. Luffy. Ja, kijk mooi. Zet die er ook bij. Hoe schrijf je dat? One Piece. One Piece. Ja, de One Piece. Dank je wel. Hoe schrijf je dat? De One Piece. De One Piece. Ja, zo heet de serie inderdaad. Maar het is Luffy. Oké. Ja. Ik ook even kijken. Het zegt me helemaal niks. Heel interessant. En voordat ik hier naartoe reed, keken wij op de bank. Hoe heet die? Gen V. Oh ja. Ja. Dat was echt best wel een ranzige. Ja. Ik weet niet. Is dat die ene die de lucht in vliegt? Nee, ik zou niet anders in de lucht vliegen. Je moet gewoon die serie zelf gaan kijken. Je moet dan niet beschrijven wat er gebeurt. Nee, het is echt nes. Ik ga het ook niet doen. Zeker niet. Maar echt, oh man. Ik weet nog wel dat ik het gezien had. Zeg ik tegen mijn broertje net ook van. Waar heb ik nou naar gekeken? Dat. Wie bedenkt dit? Ja, ik denk dat die in die writers' room, zeg maar, van die serie, dat het echt wel... Dat is echt interessant. Oké. Nou, dat was hem dan. Dankjewel voor de tips. Dankjewel dat jullie hierbij wilden zijn. Ja, super leuk. Dankjewel. In de show note zetten we altijd, zeg maar, hoe we jullie kunnen vinden via LinkedIn, eventueel via social media. Ik weet niet of jullie die hebben of niet. Dus dat zetten we sowieso in de show note. Zeker. Dus dan kunnen luisteraarsen jullie op die manier vinden. En ja, dat was hem weer. Ja, en vergeet vooral niet, ik zei het net ook al, kom gezamenlijk bij elkaar bij de CodeKlets pod, of sorry, de Slack. Ja. En ja, kijk ook even op onze website, codeklets.nl. Is dat dan ook zo van like en subscribe? Wat zeggen ze er altijd op al die dingen? Vergeet niet te liken en te subscriben. Die tekst hebben wij niet in. Nee, die hebben we overgeslagen. Of gelukkig. Nou ja. Nou, dankjewel. Dankjewel. Dankjewel. Doei doei.",
  "title": "Front-end development met Ringo Blanken en Sander Schutten",
  "updatedAt": "2026-02-12T12:09:51.156Z"
}