Tim Neutkens over Next.js

Welkom bij aflevering veertien van CodeKlets. Zoals jullie van ons wel gewend zijn dat we iedere keer wel een beetje iets een beetje anders doen. En dat is dit keer ook zo. En vandaag hebben we een gast co-host, compleet nieuw concept hebben we eigenlijk nog nooit gedaan. Dus een co-host die te gast is en waarom doen we dat? Hebben de rest van de host ruzie met mij? Dat is sowieso niet aan de orde. Maar we vinden het vooral belangrijk dat we de tweewekelijke publicatie vasthouden van de podcast. Dat is een tip van Randall. Randall is de host van de prijs winnende podcast met Nerds op tafel. En die heeft een motto, the show must go on. Dus kost wat kost moet je gewoon, zij doen iedere week, doen ze een opname, moet altijd doorgaan. Dus ze zorgen altijd wel dat er genoeg hosts zijn die de show door kunnen laten gaan. Nou, dat advies lijkt mij wel handig om dat op te volgen. Dus vandaar dat wij dat ik vandaag in ieder geval heb gevraagd aan mijn collega Joost Mijles om mede host te zijn is voor mij geen onbekende voor jullie misschien wel. Maar hij is mijn directe collega bij Aviva Solutions. Maar dat is niet de belangrijkste reden. De belangrijkste reden is dat hij zelf ook ervaring heeft met Next.js. Dat is vandaag voor de gast die we vandaag hebben, is dat eigenlijk komt dat we heel goed van pas. Dan kunnen we met jou ook wat hele goede inhoudelijke vragen stellen. Want ja, ik stel soms niet zo heel slimme vragen of ja, nou, dat is misschien wel goed. Want niet alle luisteraars die hebben ervaring met Next.js, dus dan ben ik de vertegenwoordiger van de luisteraars. Dus dat lijkt me een goede rolverdeling. Maar goed, welkom Joost. Ja, dank je wel Saber. Ja, niemand, tenminste, er zullen zeker wel links en rechts luisteraars zijn die jou kennen. Maar zou je zelf kunnen introduceren? Wat doe jij in het dagelijkse leven als developer? Ja, we zijn nu drie en een half jaar collega's, denk ik. In die afgelopen drie en een half jaar heb ik een heel stuk sitecore en commerce gedaan. Dat heb ik eigenlijk sinds ik bij Aviva ben gekomen en gespecialiseerd. Met sitecore, commerce, je kent onze accelerator die we gebouwd hebben met React, bovenop sitecommerce. Maar de laatste jaar ben ik steeds meer enthousiast geworden over Jamstack. En daar komt ook mijn interesse van Next.js vandaan. Als je dan nog iets verder naar het heden gaat, dan de laatste half jaar, dan worden we echt diep ingedoken met een nieuw initiatief binnen Aviva, een platform noemen we dat. En dat is eigenlijk de tegenhanger van DXP, wat sitecore is. Als je helemaal alles uit de box krijgt, is een platform de manier om een modeware DXP te hebben. Bij hem een SaaS-based aanpak, service naar wensen combineert, om daar je oplossingen uit te kiezen, om daar je platformen modeware samen te stellen. En in context daarvan zou je op zoek gaan naar wat past nou goed bij ons. Met het achterhoofd react-stuk kennis wat we hebben. En toen zijn we uitgekomen bij Next.js, nadat we verschillende dingen vergeleken hebben, bijvoorbeeld Gatsby. Daar komen we straks nog wel even op, denk ik. En dat is in heel kort wat ik doe. In de laatste tijd ben ik dan naast de Next.js bezig met bezigheden, ben ik met Create React heb bezig. Dat is nog een stukje sitecore werk wat ik doe. Oh, cool. Nou, dan die kennis komt denk ik al van pas voor vandaag, dus ik verwacht wel heel goede vragen van je. Ja, precies. Maar goed, we hebben vandaag ook een gewone gast die niet helemaal gewoon is, het is Tim Neutkens. Tim is de hoofdmaintener van Next.js. Hij heeft een passie voor het maken van schaalbare applicaties en het verbeteren van de ontwikkelaarservaring. Tim was al een bekend gezicht binnen de Versel community voordat hij bij Versel zelf ging werken. Verder draagt hij een steentje bij aan Next.js, Micro en MDX. Tim heeft een sterke achtergrond in e-commerce en CMS oplossingen. En welkom, Tim. Hoi. Dat was ze. Ik ben stiekem wel trots dat we je te pakken hebben gekregen. Want andere hosts weten ook dat ik hoop dat ik die jongen van Next.js te pakken krijg, want ik wil ook echt een keer in de show hebben. Twee redenen, want onze site is inmiddels met Next.js gemaakt. Dus ik dacht, dat lijkt wel een goede reden om jou uit te nodigen. Dus welkom. Ja, zeker. En ook Nederland, wat een keer anders is dan anders. Normaal spreek ik altijd in het Engels op podcasts en zo. Oh ja. Ja, ja. Dan is het normaal een dubbele eer. Dus ja, wel een internationaal werkveld heb je natuurlijk. Dus dat gaan we denk ik zo ook wel over hebben. Ja, de ijsbreker is misschien een groot woord, maar wat we heel vaak vragen aan onze gasten is van, hoe ben je nou echt begonnen met software ontwikkelingen? En van welke leeftijd? Want dat verschilt nog best wel bij mensen. De ene is echt, Wanderen was echt begonnen vanaf zijn zesde jaar en sommigen zijn echt, nou weet ik veel, 30's of 35's, dat zijn wat later rollen ze erin. Maar hoe ben jij begonnen met software ontwikkelingen? Ja, goede vraag. Ik ben begonnen met programmeren op mijn 14e, 15e zoiets. Misschien 16e. Ik kan het me niet helemaal meer herinneren. Ik zat in ieder geval op de middelbare school. En ik was gewoon in vrije tijd dingen aan het lezen over software engineering. En toen kwam ik uiteindelijk, deed een site teken die heette CodeAcademy. Daar kon je cursus op doen. Dat was in, ik denk het eerste of tweede jaar dat CodeAcademy bestond. Daarvoor waren er niet echt van die hele interactieve platforms waar je kon leren eigenlijk. Je had zeg maar geen CodeSandbox of Rapelit of wat dan ook zeg maar. Dus toen kwam CodeAcademy uit. En CodeAcademy was eigenlijk interactief leren van programmeertalen. Dus je kon er JavaScript leren of PHP of Python en Java enzovoort. En ik begon toen met JavaScript. Dat vond ik zelf heel erg lastig op dat moment. Het was toen 15 weken ofzo. En dat kwam ook omdat ik niet direct de resultaten kon zien van de code die je schreef. En toen kwamen ze met de nieuwe cursus PHP. Daar had ik al heel erg snel bij van oh wacht. Als ik hier iets in schrijf kan ik ook meteen in mijn browser zien wat het resultaat is. En dat hield heel erg met het visueel leren van dingen. Zeg maar als je iets veranderde dan hoef je alleen met refreshen. En dan zag je de aanpassing die je had gemaakt live of op een website. En dat was toen ook heel makkelijk om het live te zetten op een website enzovoort. Omdat je gewoon het FTP, gewoon een bestandje over sleet en het staat online zeg maar. Dus zo ben ik eigenlijk begonnen. En toen eigenlijk steeds verder erin gegaan. Dus steeds meer persoonlijke websites gaan maken enzovoort. Gewoon om het te proberen. Niet eerst met heel veel druk erachter van oké ik wil dit persoonlijk. Of wat dan ook. Ik vond het gewoon leuk om te doen. En toen uiteindelijk ook een paar websites voor het bedrijf van mijn ouders. Meegeholpen met maken enzovoort. Mijn ouders hebben een tuincentrum. En die gingen steeds meer online. Dus hadden niet eens een webshop op dat moment. Dat was in, ik kan me niet eens meer herinneren welk jaar. Maar echt heel lang geleden, tien jaar geleden ofzo. En ze hadden eigenlijk zeg maar. Een paar websites en die websites waren echt super lang geleden gemaakt. Dat is een grote table zeg maar. Table layout en alles stond daarin. En dat was gewoon plat HTML met een klein beetje PHP. En die gingen toen update enzovoort. Soms stonden de prijzen van producten. Ja, dan moest je die even aanpassen en dat soort dingen. Dus dat begon ik steeds meer te doen. Dat was wel grappig. En toen uiteindelijk zijn ze ook begonnen met het bouwen van een webshop. Met Gentoo op dat moment. Daar hebben ze een webshop op gezet. Timeplantenwinkel.nl. Als je ooit planten zoekt, keer daar terecht. Shout out. En die webshop was gebouwd met Gentoo. Super ingewikkeld. PHP framework. Zeker voor een zestienjarige. En dat ging allemaal wel goed op zich. Toen... Ik studeerde op dat moment. Want ik had mijn VMBO afgemaakt. En toen ging ik naar de MBO toe. MBO-ICT-beheer. ICT-beheer is helemaal geen programmeren. Dat is alleen maar netwerken aanleggen. Software installeren. Geautomiseerd uitrollen van complete netwerken. Dat soort dingen. Alles wat niet programmeren is. Maar gewoon DevOps-achtige dingen. Alleen dan interne netwerken. En terwijl ik op die opleiding zat. Toen werd ik ook heel erg motiveerd door mijn mentor. Die... Maar ook omdat ik had gezegd dat ik programmeren wel interessant vond. Enzovoort. Van hey, je kunt ook dit en dit proberen. Enzovoort. Dus die hield me daar heel erg mee. Met van oké, dit kun je nog meer leren. Binnen software engineering en software development. Enzovoort. Zelfs... Ook al was dat niet een onderdeel van de opleiding zelf. Ik kreeg er geen punten voor. Ik kreeg eigenlijk helemaal... Daar had ik helemaal geen nut aan eigenlijk voor die opleiding. Maar het was heel interessant. En ik had eigenlijk heel veel geluk dat die mentor toen... Dat ook gewoon, zeg maar, motiveerde eigenlijk. En daardoor begon ik steeds mijn websites te maken. We hadden ook een soort vak. Dat heette Service Desk. Waarin je eigenlijk het bestaande bedrijfsleven... Of zeg maar, goede doelen enzovoort. Die dus een website willen en alleen gewoon geen geld hebben... Om die websites te laten maken. Die kwamen dan bij de school aan. Bijvoorbeeld van, hey, we willen eigenlijk wel een website. En dan konden wij dat doen met WordPress enzovoort. Nou, studenten kunnen op zich heel simpel met WordPress doen. Dus dan leer je meer over hoe STP werkt en dat soort dingen. Dat had ik al een keertje gedaan. Dus daar... Dat hielp heel erg met ontwikkelen enzovoort. En dan in het tweede jaar van die MBO-opleiding, dat was twee jaar lang... Was het, zeg maar, vier periode stage lopen en één periode nog naar school. En die vier periode was gewoon en één stuk doorwerken bij een bedrijf. En toen had ik eigenlijk het geluk dat mijn vader heel toevallig bij een of andere event van de punk iemand anders tegenkwam. Die toevallig heel vlakbij woonde en een klant van het bedrijf was. Van de tuincentrum dus. Alleen heel toevallig. En die was aan het vertellen tegen mijn vader. Ja, ik heb een agency waar dus een aantal developers hebben zitten die elke dag bezig zijn met het bouwen van websites. En toen zei mijn vader dus van oh ja, dat vindt mijn zoon vast interessant enzovoort. En die is nog op zoek naar een stageplek. Is dat misschien iets? En ik zat natuurlijk op een ECT wereldopleiding. Dus dat is eigenlijk niet echt, dat matcht niet helemaal met een website die websites bouwt. Maar uiteindelijk na heel veel aandringen enzovoort had ik uiteindelijk toch een sollicitatiegesprek voor die stage zeg maar. Dus daarheen gegaan, verteld wat ik allemaal gedaan had. Die webshop gebouwd enzovoort. Heel veel met WordPress enzovoort. En ja, dus ik had wel de verwachting van ja, dat gaat gewoon niet lukken enzovoort. En toen een paar dagen later, toen belde de leidegevende van die club toen op van hey, we willen het wel proberen met je. En zeg maar, de eigenaar van die agency had ook nog een ECT-beheerbedrijf daarnaast. Dus die had uiteindelijk al zo'n bedacht van ja, als het niet lukt, dan kan je altijd nog daar gaan proberen zeg maar. Als ECT-beheerder. Maar uiteindelijk is dat niet gebeurd gelukkig. Dus ik was daar gewoon begonnen en ja, gewoon zes maanden lang stage gelopen. Superleuke tijd met iedereen daar. Gewoon superveel leren van al die mensen die gewoon in de praktijk werken. Ja. Waardoor dat je gewoon heel veel dingen leert die je daarvoor nog niet kende of wel vanweest alleen het niet gebruikt had enzovoort. Bijvoorbeeld ja, source control, git bijvoorbeeld. En een heleboel andere dingen, ticket systemen enzovoort. En toen ik denk een maand na dat ik gestart was daar, toen kwam die eigenaar van de agency naar mijn desk toe. En die zei van hey, heb je een momentje? En die nam me toen mee naar een conference room. En die zei van hey, heel veel mensen binnen het bedrijf die zeggen dat we je aan moeten nemen, want je doet het heel erg goed schijnbaar. Dus en ik dacht dat ik iets verkeerd had gedaan ofzo, want ik werd dus even apart genomen, zeg maar. En dus zei die ja, heel veel mensen die vinden dat ze je aan moeten nemen als je klaar bent met school enzovoort. Na die stage was ik klaar met school, zeg maar. Met MBO in ieder geval. En ik had eigenlijk het doel dus om dan door te gaan studeren en gewoon software engineering ofzo te gaan doen. Die opties had ik toen ook nog allemaal, zeg maar. Dus ik had eigenlijk de optie tussen, want dan zeg je ja, denk er maar over. Je kunt ook zeggen ik ga door studeren nog vier jaar en dan ben je op je twintigste klaar en that's it. Dat kan natuurlijk ook. En toen heb ik met mijn ouders overlegd enzovoort. En mijn ouders zijn ondernemers, dus die vinden het ook heel erg dat zeg maar je leert heel erg veel door te werken en gewoon daar heel erg op te focussen. Het is een heel erg goed overleg met ouders enzovoort. Want toen was ik nog zeventien overigens om het in een context te plaatsen. En toen zei ik eigenlijk van ja, oké, ik heb nu dus een keuze tussen. Ik ga werken en ik ga heel veel ervaring opdoen. Of ik ga nog vier jaar naar een software engineering of media design opleiding of wat dan ook. En dan krijg ik waarschijnlijk heel veel van de dingen die ik al heb geleerd door te werken. En dan ga je er eigenlijk alleen maar heen voor het papiertje oké je hebt hbo niveau zeg maar. Wat ook mogelijk te bepalen is door gewoon heel veel werkervaring te hebben en te laten zien van oké dit zijn alle projecten die ik heb gedaan. En deze mensen die die vinden dat ik dit niveau heb zeg maar. Dus uiteindelijk koos ik ervoor om dat aanbod aan te nemen. Dus dan ga ik daar gaan werken bij die agency voor ongeveer 2,5 jaar ofzo. En terwijl ik daar werkte, kom ik meer aan aanraken met open source. Dus ik had veel, niet eens veel contact met mensen in open source of wat dan ook. Ik had gewoon in mijn vrije tijd veel tijd over en ik vond programmeren heel erg leuk. Dus ik was naast mijn baan die al veertig uur per week programmeren was. In principe was ik ook nog aan het programmeren. En toen kwam ik dus uiteindelijk uit bij een project dat binnen de Magento community relatief populair was voor front-end tooling. Dat was een soort package over gulp en nog wat andere tooling heen om eigenlijk het makkelijker te maken om front-ends te bouwen met Magento. Dus daar ben ik toen mee kunnen helpen. Heel veel PR's gedaan enzovoort. Omdat we dat ook gebruikten bij de agency waar ik werkte. En toen daarna kwam ik op Hacker News, dus nieuwspunt Y Combinator. Daar kwam ik een project tegen dat heette Hyper. Hyper is een terminal die gebouwd is op werktechniek. Die is gebouwd door Vercel. Dus dat was eigenlijk de eerste aanreking die ik had met Vercel. Ik had toen nog site, dat mocht je dat kennen. En toen kwam ik in aanraking met T-Community. Dus ik kwam in een Slack. Ik was een van de eerste 100 mensen die in die Slack zat van Vercel. En dat was op het moment dat ze echt nog maar met z'n vier of vijven waren binnen Vercel. Dus toen begon ik eigenlijk... Ik vond het wel een interessant project. Er was dus een terminal gebouwd met webtechnieken. Dus met Electron. Alle regels waren HTML enzovoort. Styling was gewoon CSS. En het gebruikte React. Wat ik op dat moment nog niet echt gebruikt had. En Redux voor de state management. Dus elke karakter dat je typte was een Redux action die getriggerd werd. En als je dan op Enter drukte, dan werd er een hoop states doorgepast naar een terminal emulator. En dat was allemaal interessant. Die approach die we hadden op dat moment, dat was niet de beste approach voor een terminal. Dus later is dat allemaal gefixt door een andere soort library te gebruiken. Die eigenlijk alles in canvas doet. Dus als je typen dan is het gewoon een canvas waar dingen op gerendeld worden. Dat veel meer performant is. Dat hele stukje techniek zit ook in VS Code bijvoorbeeld. VS Code is een terminal. En VS Code is ook een Electron app. Dus dat was wel interessant. Dus daar had ik heel veel aan gecontribuut. Ik zat in die Slack. Ik praatte heel veel met verschillende mensen. Heel de community die ze op dat moment hadden. En dat was gewoon heel interessant voor mij. Omdat ik heel veel aan het leren was van die mensen. Dus dat was wel gaaf. En toen uiteindelijk kreeg ik wat contact met de CEO van Versel. Kishen Marouche. Op dat moment ken ik hem nog niet helemaal goed. Dus toen zorgde ik hem een keer op. Toen bleek dat hij sokken-taillouden had gemaakt. Monkoes enzovoort. Monkoes is toch die ORM voor... Ja, voor MongoDB. En dat soort dingen. Dus hele grote open source projecten enzovoort. Was een van de early adopters van Node, zeg maar. Dus heel veel van de packages in de ecosystem waren gebouwd. Vanuit het bedrijf dat hij geco-founded had. LearnBoost. En toen leerde ik hem een beetje beter kennen enzovoort. En toen zei hij eigenlijk van... Oké, ik heb gezien dat je heel veel contribueert aan Hyper. We zijn bezig met een nieuw project, Next.js. En we zouden er best wel wat hulp bij kunnen gebruiken in open source, zeg maar. Dus ik zei oké, kijk wel een keer naar. En toen bleek dat dat heel erg zoals PHP was. Dus je maakt eigenlijk een pages directory. En in die pages directory kun je dus JavaScript files gooien. En dat is eigenlijk net zoals met PHP. Waar je eigenlijk dus een index punt PHP maakt. En dan begin je het code te schrijven in PHP. En dan zie je meteen wat er eigenlijk gebeurt op het scherm enzovoort. Dat was met Next ook zo. Maar dan voor Node.js en React. Dus je maakt een index.js. Daar exploiteer je een React component. En dat React component is meteen gerenderd op je scherm. Maar zelfs op dat moment al. Dus zeg maar, voordat ze Next 1.0 had uitgebracht. Was het al met HotModule Replacement. Dus in plaats van dat je moet refreshen. Kon je dus een aanpassing maken. Opslaan en dan zag je meteen op je scherm. Zonder dat je moet refreshen. Of hoeft te refreshen. Dus dat was wel interessant. Dus dat was wel best wel een goede developer experience. Alles stond wel nog in de kinderschoenen op dat moment. Zeg maar, als je nu terugkijkt. Dat is wel vier jaar geleden voor context. Maar er was dus wel veel potentie. In ieder geval dat is wat ik erin zag. Dus heel veel potentie voor oké. Als je met React werkt. Dan is dit wel echt een goede oplossing voor het. Zeg maar niet hoeven nadenken over oké. Welke routing oplossing ga ik gebruiken. Of welke compiler ga ik gebruiken. Hoe moet ik Webpack installeren. En opzetten enzovoort. Dat is wat toen nog echt iedereen was handmatig aan het doen. Dus iedereen zette handmatig zijn Webpackconfig op. En dan moesten ze daarna nog Babel configureren. Je moest uitzien te vogelen welke transforms nodig waren. Om een React Compiler goed te compileren. En als je dat dan uitgevogeld had. Dan bleek negen van de tien keer dat je toch niet alle transforms goed had staan. Waardoor je in productie niet gecompileerde code kreeg. Dus dat die niet geminefied was enzovoort. Dus ik zag dat Next daar heel erg mee hielp. Door eigenlijk alles te standardiseren. Dus alles dat er al in. Als je gewoon een app wilt gaan bouwen. Wat is het voor. Want dat had ik bijvoorbeeld in die tijd bij die agency gezien. Als er geen standaard is. Over dit is de manier waarop iedereen het gaat doen binnen het bedrijf. Dan heb je dus elk project een andere soort config. En over de lange termijn geeft dat heel grote problemen. Omdat ze dan elke keer of net gaat er iemand weg. Dus iemand die gaat bij een ander bedrijf werken. En die heeft dan net alles gemaakt binnen het bedrijf. Of ze zijn vergeten hoe dat de config werkt. Omdat er bijna geen documentatie is. En dat soort dingen. Dat is puur, dat is niets. Omdat, zeg maar, dat is niet dat het zo is alleen bij die agency. Dat is bij elk bedrijf dat ik tegenkwam. Op conferences, bij meetups enzovoort. Die vertelden allemaal hetzelfde verhaal. Oké, ja, we zijn niet blij met onze config. We gaan migreren naar deze applicatie en deze compiler. En dan gaat het misschien wel opgelost zijn of wat dan ook. Alleen, het kan er eigenlijk altijd op neer dat ze gewoon, zeg maar, te weinig tijd hadden om dit allemaal uit te bouwen, zeg maar. Zeker bij agencies waar je, zeg maar, projecten aan het bouwen bent. Voor, zeg maar, de eindgebruikers of de eindklanten. Die veelal, zeg maar, onderschatten hoeveel werk dat dan is, zeg maar. En dat documenteren dan eigenlijk zeggen van oké, jullie bouwen die applicatie. Jullie moeten ervoor zorgen dat die schaalbaar blijft enzovoort. En dat stukje documenteren is voor jullie rekening, zeg maar. Ja, precies. Maar dit was ook een beetje, even kijken. Ik was niet per se helemaal in het begin met React betrokken, maar toen ik daar een beetje bij inrolde, dat was ook vanuit Aviva, vanwege ons commerce platform. Ik deed toen daarvoor Angular. Ja goed, ik ben geen Angular fan, dat weten mensen wel. Toen ben ik React gedaan. Het was de eerste als je van, hey, wat is React nou? Doe die zo raar, een beetje gekke JSX. Het kwartje viel niet meteen. Toen het eenmaal viel, toen ik er een beetje mee ging spelen, toen je merkte, toen was het nog dat je starter kits had, zeg maar. Dus dat je echt gewoon iemand had dan nagedacht over een bundel van configs voor, wat was het toen, gulp, krunt soms ook nog. En als je geluk had ook een goede config voor webpack. En dan kon je dan een GitHub klonen, daar kwam het blijkop neer. En dan kon je mee starten. En dat was ook in die tijd, Joe Man was ook volgens mij al een beetje, dat moest het er ook zijn geweest. Dus dat was eigenlijk de beginfase. Ja, precies. Dat is vier jaar geleden of zo, denk ik toch, Saber? Ja, zoiets. Ja, net als vier jaar geleden. Ja, klopt. Ja, maar het is echt bizar, want eigenlijk is vier jaar geleden niet eens zo heel lang geleden. Ja, dat lijkt echt heel lang geleden. Er is echt veel gebeurd. Maar toen hoorde, ik denk dat ik, en dat durf ik echt niet te zeggen, dat ik Next.js zo half heb gezien liggen, zo van oké, één van de vijf, zes opties, dat ik dacht van oké, wat is nou de goede? Ja, ik weet, ik kan hier niet uit kiezen. Ja, ik had er wel echt tijd voor om daar echt helemaal in te duiken. Ik ben in principe niet de front-end developer, maar gewoon full-stack. En dan is het, het moet meteen werken, als het ware. Ja, dat hielp dan, zou dan helpen. Dus op dat moment was het, er was best veel reurings. Laat ik het zo zeggen. We hadden volgens mij Next.js, Gatsby, en zo nog tien Starter Kids en Create ReactApp. Was het toen al wel of niet? Dat weet ik niet eens. Ja, in 2016 was een interessante tijd. Er waren eigenlijk, zeg maar, Create ReactApp was toen net aangekondigd ofzo, voor als ik me kan herinneren. Webpack was Webpack 1, Webpack 1.0, dus nu Webpack 5. De bebel was bebel 6 of 5 zelfs nog. En er waren gewoon heel veel losse boilerplates, zoals je zei. Heel veel mensen die het zelf instelden omdat ze die boilerplates niet konden vinden. Ik was daar onder andere schuldig aan. Er waren gewoon heel weinig, er waren heel veel keuze. Alleen het was heel lastig om die keuzes te maken. Gatsby op dat moment was nog niet zoals je het vandaag kent. Next was nog niet zoals je het vandaag kent. Wat wel handig is bij Next is dat heel veel van de core primitives, dus de dingen die we vanaf het begin in het framework hebben gezet, zijn nog steeds hetzelfde. Dus vrijwel alle top-level APIs, dus de pages map, de link API, de router, alles is nog ongeveer hetzelfde als het was in Next 1. En het meeste wat we hebben gedaan is eigenlijk de onderliggende implementaties verbeterd en nieuwe features erbij gezet. Dus heel veel dingen om schaalderheid van je applicatie te vergroten, om je code te optimaliseren. Dus te zorgen dat de code die je schrijft minder, zeg maar, bundlesize oplevert dan, zeg maar, vier jaar geleden. En tijdens dat alles proberen om zoveel mogelijk backwards compatibility te hebben. Dus, zeg maar, apps die in Next 1 zijn geschreven, die zijn grotendeels compatible met Next 10. Next 10 is wat we vorige maand hebben gereleased. Ja, precies. Daar komen we zo op. Niet dat ik je helemaal wil afremmen, maar voordat we dan naar Next.js gaan, had ik nog wel... Vind je dat je vooral in front-end of back-end of ben je full-stack? Ja, dat is natuurlijk een beetje een populaire term, maar waar opereer je en wat vind je zelf? Want volgens mij, voor mij, als je nu aan iemand vraagt, ja, dat kom ik toch op, Next.js, maar hoe positioneer je Next.js? Dat is niet alleen maar front-end. Dat is ook eigenlijk het back-end-deel. Maar waar word je heel enthousiast van? Juist van de front-end of van de back-end? Ja, het is voor mezelf, zeg maar, ik kan mezelf niet goed classificeren en dat zou dan full-stack-ish moeten zijn of zo. Ja, precies. Want ik trouwens, ja, er is er veel over te zeggen. Ja precies, dat weet ik, ja. Zeg maar, het hele full-stack gebeuren is, zeg maar, als je Next gebruikt, dus als je applicaties aan het bouwen bent met Next, dan heb je een beetje, het enige wat je moet weten is eigenlijk hoe je React-components schrijft, hoe dat JavaScript werkt, en een beetje Node.js. Maar dat stukje is niet eens per se nodig om het te kunnen gebruiken, behalve dat je moet weten hoe package managers werken en hoe dat je de terminal gebruikt, omdat je het commando uit moet voeren enzovoort. Ja precies, maar dat is eigenlijk een beetje common, dat moet je altijd kunnen eigenlijk. Ja, het is sowieso, als je developer bent tegenwoordig, dan is command-line-knowledge gewoon nodig op een bepaald moment, omdat ze bijna geen graphical user interfaces hebben voor het overgrote deel van alles wat je doet in de JavaScript community op z'n minst. En wat je dus hebt is als je een next app aan het bouwen bent, ben je voor het grootste deel front-end code aan het schrijven. Je kunt ook API's toevoegen, API routes, en daarmee kun je in veel gevallen heel veel van je logica kwijt. Wat we ook even zien is dat grotere applicaties hebben een losse API die gebouwd is in of een andere taal, of in Node, of wat dan ook. En die staat dan helemaal los van de next application, zeg maar. Daarmee dus echt front-end developer. Of in ieder geval front-end developer. Tussen aandachtstekens, ja. Omdat je, zeg maar, dus vooral bezig bent met de front-end van de applicatie. Dat betekent niet dat je full-time CSS aan het schrijven bent, of wat dan ook. Het betekent gewoon dat je de logica voor de front-end van bouwen bent. Dat is in ieder geval mijn definitie daarvan. Onder andere omdat nu ook steeds meer, zeg maar, CSS frameworks uitkomen, zoals Tailwind, waar je steeds minder CSS zelf schrijft, maar je classes gebruikt om components te maken. Voor mijzelf, als iemand die aan Next werkt en contributor is, zeg maar, ben je eigenlijk een soort van full-stack developer, maar het neigt meer richting back-end developer. Maar nog steeds heel erg in touch met front-end, zeg maar, omdat je je maakt tools om front-end developers te helpen en daardoor moet je wel weten hoe alles in elkaar zit. Maar daarentegen ben je ook met heel erg verbonden dingen bezig die met back-end te maken hebben. Dus je bent bezig met het optimaliseren van code die alleen maar in Node.js draait. Je bent bezig met contributor aan Webpack, aan Babel, je bent bezig met het schrijven van plugins voor Webpack en dat soort dingen. En dat zijn dingen die je als front-end developer tegenwoordig vrijwel niet hoeft te doen. Wat heel goed is overigens, want dat soort dingen zijn meestal als je een applicatie aan het bouwen bent, niet de dingen waar je aan zou moeten werken. Voor het overgrote deel is het ding waar je als front-end developer mee bezig zou moeten zijn het maken van dingen voor je klant en niet voor de build tool chain, zeg maar. En dat is waar Dextus mee helpt. Want je hebt dus geen build tooling die je zelf moet onderhouden en dan steeds moet upgrade of moet bij je houden enzovoort. Dus je hebt bijvoorbeeld, je hoeft niet Webpack te upgrade, dat hebben wij al gedaan bijvoorbeeld. Dus als je Webpack 5 wil gebruiken, dan kun je nu in Next zeggen, oké, ik ga Webpack 5 installeren op een bepaalde manier. Op dit moment nog in beta vandaar. En dan kun je het meteen gebruiken, omdat wij al die tijd gestoken hebben in het upgrade van Webpack. En dat kan soms heel makkelijk zijn. Het kan zijn van oké, we upgrade in dependency and that's it. Maar major upgrades van compilers, zoals Webpack, dus compilers zijn fundlers, is over het algemeen heel erg ingewikkeld, omdat je al je plugins compatible moet maken enzovoort. En dat kan soms weken duren bijvoorbeeld, omdat ze helemaal goed krijgen. Ja, dat zijn dingen die uit je handen worden gehaald. Die ervaring hebben wij ook wel, ja. Dat klopt, ja. Ja, soms komen mensen gewoon vast te zitten, zeg maar. Dus vast te zitten, als in je komt een project binnen en dat project gebruikt nog steeds Webpack 3, omdat ze nooit naar Webpack 4 hebben kunnen upgraden. Dat was zeker, zeg maar, Webpack 3 naar 4 was bijvoorbeeld een heel erg groot update. Was bijna niet te doen als je zeg maar, dus bij een agency werkte ofzo. Omdat je dan tegen een klant moet zeggen, hey, we gaan even 40 uur investeren in het upgraden van de compiler die 18 websites zit. En dan zegt de klant van, wat is een compiler? Waarom is dat nodig? En dan zeg maar ook niet eens van waarom is het nodig van, oké, het is belangrijk omdat je nog up to date bent, maar ook van, wat is de business metric, waarmee dat we gaan kijken of die 40 uur het eigenlijk wel bepaard zijn, zeg maar. En dat is heel lastig om dat weer uit te halen, zeg maar. Dus dan kun je langer termijn kijken, oké, over zoveel jaar heb je dan meer geoptimaliseerde bundels, bijvoorbeeld. Wat je nu in Webpack 5 krijgt. Maar het is nog steeds niet makkelijk te verantwoorden, zeg maar. Oké. Ja, eigenlijk hebben we we hebben niet eens een segue nodig. We zitten allemaal gewoon midden in Next.js. Ik heb, ja, dat is eigenlijk wel een goede, want je zegt bijvoorbeeld ook in je in je bio zeg je ook wel dat je de ontwikkelaars ervaring wil verbeteren, dus dat omschrijf je ook van dat je eigenlijk met die tussen aanhalingstekens back-end tooling bezig bent om te zorgen dat het front-end development process soepeler en makkelijker gaat. Dus dat was wel een vraag, zeg maar, die ik haalde, maar dat heb je al beantwoord. Ik ben trouwens wel nieuwsgierig, want je hebt naast dat je een steentje hebt bijgedragen aan Next.js en heb je ook aan Micro. Dat zei mij helemaal niks. En MDX, MDX wel, maar Micro niet. Kun je vertellen wat Micro en MDX, ja, wat dat zijn? Ja, Micro is een heel kleine HTTP-server. Je moet eigenlijk denken, express, maar dan compleet uitgekleed zit alleen maar de request-response handler in. Dus dat betekent dat je geen express .get, of app.get, app.post enzovoort hebt. Je hebt pure module.export en dan een functie. En die functie is dan een request and response parameter en dan kun je dus zeggen response .end en dan data bijvoorbeeld. Of je kunt een return doen en dan daar data returnen. Je kunt het vergelijken. Micro is ook vier jaar geleden gemaakt. Dat is eigenlijk een soort serverless functions, een type API. Wat later kwam, zeg maar, die je dan in een container kon hosten. Dus je hostte dan een hele kleine container met micro erin. En dat was dan geoptimaliseerd voor het maken van APIs. Dus echt niet front-end gerelateerde code, maar puur back-ends. En dan denk je natuurlijk waarom heb je dat gemaakt enzovoort enzovoort. Maar dat was ook een project van Vercell en dat gebruikten we op dat moment voor het bouwen van die Vercell APIs voor het platform, zeg maar. En dan, ja, en dan naast is MDX. Dat is een project wat ik samen met Kishen, de CEO van Vercell, ben gestart. Toen we eigenlijk bezig waren om de, ja, we noemden het zelf de block-outturning experience. Wat is eigenlijk, we waren op dat moment heel veel blogs aan het schrijven. Headless CMS'ers waren nog niet helemaal, zeg maar, de hot and happening thing dat ze dit jaar zijn geworden. In het vorig jaar. Dit was in 2018. Dus we hadden eigenlijk zoiets van, oké, je wil eigenlijk alles in Markdown schrijven, want we schreven toen op dat moment alle blogposts met JSX. Dus letterlijk als je als je ooit JSX hebt gebruikt om gewoon components te maken, werkt helemaal perfect, maar voor het schrijven van blogs is het niet het meest ideale. Zeker omdat je heel veel dingen die je vaak gebruikt, dus bijvoorbeeld linkjes, niet heel snel kan maken. Je moet dan helemaal een component importeren, dat component dan gaan gebruiken, om dat linkje te maken, en dan de hitchwrap er nog in te zetten, enzovoort. Dus, en het zag er dan daarna heel moeilijk leesbaar uit. Dus als je dan moest gaan reviewen van die textstack maar die geschreven was, dan moest je door de text heen kijken, zeg maar, zelf. En hetzelfde met editen enzovoort. Zoiets van, ja, oké, we willen wel Markdown gebruiken, maar al onze blogposts hebben hele interactieve components in het midden van de content zitten. Dus hoe lossen we dat dan op? En terwijl we dus het idee, Kishen had op dat moment het idee van, ja, oké, wat nou als we mensen dus die import, dus JSX imports, laten schrijven in de Markdown, aan de bovenkant van de Markdown file, en dan die JSX laten gebruiken in de Markdown. Omdat Markdown ook support heeft voor HTML-text. Je kunt ook gewoon HTML schrijven in Markdown. En dat is bijna altijd valid, zolang je de juiste spacing houdt. Dus toen begonnen we eigenlijk met een soort spec. Die spec die de specificatie van hoe dat alles rijdt zou zien in de meest ideale situatie. Dus oké, hier zijn we bezig geweest. En toen had Kishen het idee van, oké, we gaan er niet meteen zelf aan werken, maar we gaan kijken wat de hele community erover denkt. Want het is misschien wel een interessant idee voor meer mensen. En toen op dat moment was Spectrum nog een ding. Spectrum is zeg maar een forum software die is overgenomen door GitHub. Ik denk ook anderhalf jaar geleden, of een jaar geleden. dat is recent. Ze zijn daarmee gestopt omdat ze nu GitHub Discussions hebben. En GitHub Discussions is zeg maar in GitHub ingebouwd. Dus dat is iets makkelijker om te gebruiken. En dat gebruiken wij nu ook voor Next.js. En dus wat wij eigenlijk deden was we posten daar op het forum voor zeg maar je had meerdere spaces en er was een space voor Frontend Café, denk ik, dat het is. En Frontend Café was zeg maar heel veel verschillende programmeurs. Niet eens alleen maar mensen die React gebruikt of alleen maar mensen die View of Angular gebruikte. Maar gewoon iedereen die in die spectrum zat, die was gewoon aan het programmeren in JavaScript de meeste. Dus Kishen had die gepost en en daarover getweet enzovoort. Die tweet ging best wel viral-ish in de Frontend community op Twitter. Dus heel veel mensen kwamen in dat forum en in dat forum begonnen ze ook allemaal ideeën te delen enzovoort. Weet je het standaard open source verhaal? zeg maar twee dagen later dus na het weekend want ze hadden het op vrijdag of zo gepost er kwam een post van iemand die zei van ik had dit weekend tijd en bleef me in mijn hoofd rondspoken ik heb het helemaal geïmplementeerd die had zeg maar een proof of concept gemaakt en op github gezet dus toen zei wij oké dat is mooi interessant enzovoort want we hadden wel wat ideeën Over hoe dat die implementatie zou moeten zijn, zeg maar. Een van de voornaamste dingen was we kunnen niet compileren in de browser. Dus die GSX-syntha of die MDX-syntha, die moet dus gecompiled worden in iets als Webpack of zoiets. Pure om ervoor te zorgen dat je niet in de browser zeg maar een hele babble moet draaien om dat allemaal goed te krijgen. Want dat is zeg maar 700 kb aan code en dan ben je sowieso al over je site-budget heen. Dus dat ging niet worden en die initiële implementatie door John O'Tender, een gast uit Amerika, die zag best goed uit en die deed dus dat exacte wat ik net uitlegde die en compilde het in de browser via 2 dingen, via Remark, dat is eigenlijk een parser voor Markdown. Daar zat dan een custom plugin op die eigenlijk de EST, want het is misschien heel technisch, een abstract syntax tree krijg je door eigenlijk de code te parsen en dan krijg je eigenlijk een soort JavaScript object terug met elke regel die jij in je Markdown hebt gezet en dan daar alle metadata van die dan de compiler eigenlijk voor die taal, dus in dit geval Markdown heeft gepakt en met Remark had je dus, dan parser je dat dus eigenlijk en dan kun je daarna plugins over de EST draaien, dat is hetzelfde als de manier waarop dat bevel werkt bijvoorbeeld en wat ze toen, wat ze daar dus deden was, we passten die HTML tags, dus die HTML tags die waren al geparsed, want de JSX was dus HTML in principe, daar parsen we nog die JSX uit en maakten daar dus een, in plaats van HTML node, maakten daar een JSX node van en wat we daarna deden was, het was niet eens, implementatie wise maakt het niet zoveel uit alleen we hadden ook een spec die we wilden maken voor dit is wat een MDX document eruit ziet in de EST, dus hebben we ook een MDX EST format zegmaar gemaakt, om het zo duidelijk mogelijk te krijgen voor mensen die een eigen parser zouden willen implementeren enzovoort, dus die MDX EST die werd daarna dus weer terug omgezet in iets anders, dus in HTML of JSX of wat dan ook, in die initiële implementatie werd het dus omgezet in React Components en dan heb je dus meteen React Components die je kunt renderen met React, enig probleem was, dan moest je die parser dus in je bruisel draaien, omdat je anders de MDX niet kon draaien in de bruisel, waardoor dat je dus je interactieve components niet interactief waren, die kon je dan alleen maar server renderen en dan was je klaar zegmaar, dus dan kon je geen interactie toevoegen, geen clicks, geen states, geen effects enzovoort, dus dat kon dan op dat moment niet, dus toen had ik het redelijk rare idee, als we weer terugkijken, om zegmaar je schrijft dus Markdown en in die Markdown plaats je JSX, maar wat nou als we die EST van die MDX output zegmaar dan weer omzetten in JSX, dus in plaats van dat je dus de input is Markdown met JSX erin, maar de output is dus JSX en daardoor krijg je dan zegmaar dus gewoon een JSX tree, dus elke regel, elke paragraph enzovoort, die werd dus een JSX node, dus er werd gewoon een P JSX node en daarna werd dat dus in Babel gegooid om dat dan weer om te zetten in normale JavaScript die je dan uitvoert in de browser of in andere environments, dus dat was eigenlijk het idee dat ik toen had en wat toen hebben gedaan is, dat is geïmplementeerd, dus ik en John samen binnen een paar weken tijd en dat is in productie gekregen op Vercellet.com in de blog en de documentatie, dus de documentatie en de blog waren beide gedreven door MDX zegmaar op dat moment, dus dat was het interne gebouwd enzovoort, niemand gebruikte het in open source enzovoort en toen hadden we onze eerste of onze tweede user conference dat jaar in 2018 en dat heette toen nog site day, dat was een conference in San Francisco, waar dan heel veel sprekers kwamen die met over Vercellet platform gingen praten of over Next of over andere topics die ze hadden die heel interessant waren en in de keynote hadden we dan een plan om dan MDX aan te kondigen, dus toen, ik had toen nog nooit gepresenteerd in het wagen in ieder geval, dus buiten zegmaar presentaties op school, dat soort dingen en toen moest ik dus gaan presenteren in de keynote als eerste na Nikeshemo aan het begin en dan meteen de nieuwe versie van Next aankondigen, nieuwe MDX format aankondigen en nieuwe website enzovoort en dat was dan voor 350-300 mensen ofzo en bij de Palace of Fine Arts wat echt heel mooi is in San Francisco, dan wordt ook bijvoorbeeld Get Up Universe gehouden, dat soort dingen, dus dat is wel zo gaaf bijna twee en een half jaar geleden of twee jaar geleden, ja eigenlijk is dat lang geleden, het lijkt wel heel lang geleden, ik zat nu te denken dat ik pas voor de eerste keer op bij NextConf geweest, dat was afgelopen oktober was dat denk ik, ja vorige maand en het was natuurlijk helemaal online maar het was vele malen groter nu natuurlijk, ja zeker ja zeg maar na die eerste keer presenteren heb ik ook echt op conferences gesproken die vele malen groter zijn, echt tot aan volgens mij was React Europe was 1500 mensen ofzo in een ruimte wat je nu helemaal niet meer kan voorstellen zeg maar, maar ja dus dat was wel apart ja inderdaad, vorig jaar bij Dodges voor 2000 mensen ofzo, heel heel raar om voor zoveel mensen te staan, als je ooit denkt over oké ik durf niet op het podium te staan en ik ben bang dat heel mensen naar me kijken, het is niet zo eng als je zou verwachten omdat ze de hele ruimte dimmen en altijd licht op jou staat en je half verblind wordt door het licht waardoor je niet iedereen ziet in de ruimte, ik ben nog niet verder gekomen dan 100, dat ligt er ook nog aan wat voor ruimte want als je 100 zeg maar ja gewoon een hoe zeg je dat een grote, niet heel groot maar een redelijke conference en je kunt eigenlijk iedereen zien dat is ook al best wel ja overweldigend. Was het dit keer live Tim in oktober? De next best comes was niet live keynote nee we hebben dat voorgeproduceerd omdat we dat risico niet zouden nemen dat het zeg maar niet zou werken of dat je verbindingsproblemen hebt enzovoort ik heb geen stabiel internet of ik had geen stabiel internet rond die tijd dus dat zou je in een Zoom meeting hebben waar je half weg valt enzovoort dat weet je niet en ja dus dat was zeg maar allemaal voorgeproduceerd maar opgenomen in een soort professionele setting dus Het is met een cameraman enzovoort, en dan ook nog in drie verschillende landen en vier verschillende mensen, dus je had zeg maar, ik in Nederland hier dus, vlakbij Eindhoven opgenomen. De andere waren, twee waren in San Francisco en de laatste was in Buenos Aires. In Argentinië. Dus ja, dat was wel interessant. We moesten alles aan elkaar plakken zeg maar, al die stukken, en dat moest dan ook allemaal goed overlopen. En uiteindelijk, ik ben heel positief over het resultaat en heel veel mensen die feedback gaven ook. Dus ja, dat was wel gaaf. Ja, dat was leuk. Ja. Ja, ik had het er met je hoofd ook even over. Het stomme is, ik heb de clean-out toen gezien en ik dacht, wow, die ziet er echt wel, ja dat is een compliment denk ik wel, een beetje Apple-esque uit zeg maar. Ja, het zag er gewoon goed uit zeg maar. Dus dat vond ik echt wel indrukwekkend. Alleen er gebeurden dingen, over mijn kinderen, dat zei ik net ook al, over mijn kinderen of over werk, want het was aan het einde van de dag voor ons toch Joost? Ja, klopt. Ja, uiteindelijk. Het begon om vijf uur smiddag inderdaad. Ja, precies. Ja. Ja, dat is voor mij wel een overgang. Dus dat is precies van de etenstijd enzovoort. Ja, op zich was het etenstijd, ja, op zich kun je natuurlijk ruim tijd voor maken, maar dat was ook het idee, maar dat gebeurde, ja, kinderen gebeuren en dan heb je in één keer een andere planning. Dus dat was jammer en volgens mij staan nu een aantal talks online als ik het goed heb gezien. Ja, klopt. Dus de clean-out kun je al terugkijken en een aantal talks ook, dus talks van mensen van Lift, van Ashicorp, Tencent, Tencent is een heel groot Chinees bedrijf dat WeChat zit, bijvoorbeeld, en ook de grootste nieuwsite van China, de host, zegmaar, die dat zijn, die zitten achter de grootste nieuwsite van China, die ook op Nexus gebouwd overigens. Dus dat is wel tof. Ja, zegmaar, de vierde of vijfde grootste website van de wereld, op basis van een X-ranking. Draaien ze op Vercell, dan? Nee, nee, die met self-hosting, ja. We hebben ook klanten van Vercell die echt gigantisch groot zijn, zegmaar. Dus het is niet zo dat, zegmaar, die allergrootste site, zegmaar, alleen maar Ik was meer benieuwd hoe het in China werkt, want ik weet, in China is het natuurlijk een vroeg ding om in Amerika te draaien, bijvoorbeeld. Ja, de meeste, de manier waarop dat in China werkt is dat je dus een Chinezen region moet hebben, waarin je dus bijvoorbeeld AWS heeft regio's in Mainland China en Hong Kong. En dat is waar je je service op draait voor die specifieke groep van klanten, zegmaar, eigenlijk. Oké, eens even zien. Vragen, vragen, vragen. Heel lijst van vragen. Ja, we hebben zeker een lijst van vragen. Ehm, eens even kijken. Ja, het voortrekt heb ik nou wel, ik denk dat daar hebben we een aantal dingen wel besproken. We zitten gewoon midden in Next.js, lekker gezellig. En bij de Next.js 10, ik ga niet de hele historie bedoel, laten we het gewoon even over 10 hebben, want bij die conferentie is natuurlijk redelijk recent die versie gereleased. Ik zag dat er een aantal grote features ook onder zijn, ik ga ze niet allemaal opnoemen. Een aantal waren er onder andere. Image component, dat was een hele grote. Ja, image component, internationalization voor de routing, next analytics, next commerce. Misschien is het handig dat we die gewoon, ja dat wij even bij stilstaan, maar het image component, nou dat spreekt misschien wel, dat spreekt meteen mensen ook wel aan. Waarom heb je die gebouwd? Laten we het zo, laten we het dan maar meteen zo. Ja, dat heeft eigenlijk meerdere redenen. Een van die redenen is dat we er eigenlijk achter kwamen dat een heel groot gedeelte van alle bytes die in een pagina zitten, images zijn. Meer dan 50 procent in veel gevallen. En dat heeft zeg maar een best wel groot effect op je performance van je pagina's. Dat heeft meerdere redenen. Een van die redenen is dat je het networkrequest opneemt. Dus die plokken eigenlijk andere resources die geladen moeten worden om je pagina interactief te maken. Dus bijvoorbeeld JavaScript die nodig is om de pagina interactief te maken. En daarnaast kwamen erachter dat, of ja dat wisten we eigenlijk al, dat heel veel sites niet hun images lazy loaden. Dat staat eigenlijk in dat die alle images laden voor de hele pagina. Terwijl je alleen maar zeg maar 30 procent van die images ziet in het initiële viewport zeg maar. Dus als je een site opent dan zie je een aantal images. Maar alle images eronder die zijn niet nodig om jou te laten starten met het lezen van de pagina. En als je die dus niet lazy loadt dan heb je dus het probleem dat die dus langer doet over het laden van de pagina. Terwijl dat niet nodig is zeg maar. Dus wilde dat eigenlijk dat probleem oplossen. Dus performance wise het beter maken van het niet laden van images die uit de viewport zijn. En daarnaast ook het preloaden van images die heel belangrijk zijn. Dus als je bijvoorbeeld kijkt Google die gaat hun search engine ranking aanpassen volgend jaar naar Core Web Vitals. En dat is een nieuwe factor zeg maar. In Core Web Vitals zijn eigenlijk drie verschillende metrics. En daar kunnen er later nog meer bij komen. En de eerste drie zijn eigenlijk First Contentful Paint. Dat eigenlijk hoe snel dat de pagina geredeld is met content. Largest Contentful Paint. Dat betekent eigenlijk wanneer het grootste element op die initiële viewport geladen is. En Cumulative Layout Shift. En dat betekent eigenlijk de beste manier om dat uit te leggen is eigenlijk je gaat naar een pagina toe. En terwijl de pagina aan het laden is, zie je allemaal elementen op en neerspringen. Totdat je uiteindelijk het juiste resultaat ziet. En vrijwel iedereen die het web ooit gebruikt heeft, heeft dat ooit ergens gezien. Zeker op je mobiele apparaten enzovoort. Of op je telefoon. Als je daar op een website zit. En die website heeft advertenties of afbeeldingen of wat dan ook. En je opent de pagina. Dan is de kans heel groot dat je begint te scrollen. Omdat je die teksten zelfs naar ingeladen en de afbeeldingen bijvoorbeeld niet. Zeker op 3G verbindingen of 4G verbindingen. En dan begint de scroll. En ineens is de tekst waar je was naar beneden geslagen. Door een afbeelding die hoger zit. Zelfs die afbeelding zie je niet op je telefoon. Of je desktop zie je die wel. Dus je ziet alles op en neerspringen. Dus dat heet Cumulative Layout Shift. Daar hebben ze nu een metric voor gemaakt. Een manier om het bij te houden in Chrome. En dat wordt ook uitgerolde naar andere browsers. Voordat je kunt meten hoeveel Cumulative Layout Shift jij hebt in je pagina. Of Layout Shift in je pagina. En dat mag niet hoger zijn dan een bepaald percentage. Want als het hoger is dan een bepaald percentage betekent eigenlijk dat heel je pagina op en neerspringen is. Totdat de hele pagina geladen is. En afbeeldingen zijn een heel groot factor in dat hele verhaal. Afbeeldingen en assertenties. Nou, afbeeldingen. Daar waren we al naar aan het kijken natuurlijk. Zoals ik zei. En de manier om dat eigenlijk op te lossen, dus dat Layout Shift gedeelte, is om ervoor te zorgen dat developers eigenlijk zeggen dit is het aspect ratio van de afbeelding die hier gerenderd gaat worden. Dat hoeft niet eens de width en de height te zijn. Maar puur het aspect ratio. En nu is het natuurlijk zo dat je het aspect ratio kan berekenen door de width en height te weten. Dus wat we eigenlijk gedaan hebben is we hebben een React Component gemaakt die width en height nodig heeft. Dus je moet een SRC toevoegen. Dat is gewoon de soort van image. En daar moet je dan width en height aan toevoegen. Dat hoeft niet per se de width en height te zijn van de afbeelding zelf. Dat hoeft alleen maar de width en height te zijn om de aspect ratio te berekenen. En dan kun je dus meerdere layouts toevoegen. Dat is een layout property die bestaat voor meerdere soorten layouts. Omdat we erachter kwamen dat er meerdere... Afbeeldingen worden op veel verschillende manieren gebruikt in verschillende layouts, bijvoorbeeld in een flexbox, in een grid enzovoort. En die moeten op een andere manier gestaald worden om dan die layout shift te voorkomen. Dus er zit ook een layout property bij. En dan is eigenlijk het laatste stukje wat je eigenlijk helemaal niet ziet als je aan het gebruiken bent. Je gebruikt de image component en daardoor kun je automatisch het lazy loaden. En als je dan een afbeelding hebt die in de viewport zit, dan kun je hem ook nog priority geven. En priority betekent eigenlijk... Deze afbeelding is heel erg nodig voor de largest contentful paint. De largest contentful paint wordt meestal gemeten op een hele grote afbeelding die op de homepage staat, op de initiale viewport. Dus wat je heel vaak ziet op websites, dus... Zeg, je gaat naar bol.com of Coolblue, of wat dan ook, dan is de eerste afbeelding die je ziet in je viewport is vaak een hele grote afbeelding die bijvoorbeeld een actie laat zien, of zoiets. En die afbeelding moet er heel snel zijn, want die largest contentful paint wordt daarop gemeten. Dus wat priority dan doet, is eigenlijk... Dan zeg jij tegen Next, van oké, preload deze afbeelding en zorg ervoor dat die zo snel mogelijk geladen is, zeg maar. En dat kunnen wij dan weer doorzetten naar de browser door die linker op preload toe te voegen. Wat gewoon een webstandard is voor oké, deze resource is nodig om een afbeelding snel te kunnen laden. En daardoor laat hij dan ook sneller. En daardoor gaat de largest contentful paint, hebben we ook gezien dat die soms verbeterd wordt met meer dan 15 procent. Dus dan heb je 15 procent sneller je largest contentful paint. En largest contentful paint, je moet het eigenlijk een keer opzoeken, web.dev, een site van Google. Daar wordt alles uitgelegd over al die correct files. En daar wordt ook uitgelegd dat bijvoorbeeld largest contentful paint gemeten wordt, omdat ze dus research hebben gedaan, de sphecologische research binnen, zeg maar, tegen users bijvoorbeeld. Waarin dat blijkt dat heel veel mensen wachten totdat die grootste afbeelding geladen is voordat ze überhaupt aan de pagina beginnen te scrollen. Oh. Oh wow, ja. En dat is natuurlijk niet handig als je dan dus mensen laat zitten wachten op dat hele grote afbeelding ding dat er nog niet is, zeg maar. Als je kijkt naar de concurrenten, Gatsby, die hadden natuurlijk al een tijdje image support. Zie je dit als laatste dingetje wat jullie nog niet hadden bij Next.js en Gatsby wel? Mag ik het zo oorschrijven? Nou, je kon dit natuurlijk al zelf doen door zeg maar een image component te gebruiken van een zeg maar die op NPM stond bijvoorbeeld. En daardoor kun je dus zeg maar het lazy loaden in ieder geval krijgen en het optimaliseren van images kun je doen door bijvoorbeeld, daar hebben we nog niet eens over gehad, stel je wilt images optimaliseren dan moet je dan een CDN gebruiken dus een image CDN zoals Cloudinary of ImageX of Fastly Image Optimizer of zeg maar er zijn een heleboel van deze soort services en die moet je dan zelf configureren en instellen en dan zorgen dat het allemaal werkt samen met je component en dan was je nog steeds niet, want dan moet je nog steeds SSC sets toevoegen en sizes en van alles zeg maar allemaal om images zo klein mogelijk te krijgen en dus zeg maar Next kun je gebruiken als tegen dat hele stuk over Gatsby bijvoorbeeld Gatsby is a Static Site Generator en Next is niet per se a Static Site Generator het is een Hybrid framework, zoals we dat noemen. En dat houdt eigenlijk in dat je dus kunt zeggen, ik wil bepaalde pagina's statically generated hebben. Dus als, hetzelfde principe als een static site generator, maar alleen maar voor bepaalde pagina's. Dus je kan zeggen van oké, de homepage kan static zijn, dus we maken hem static. De blog kan static zijn, dus we maken hem static. En dashboard bijvoorbeeld kan, heeft heel veel dynamische data. Dus we maken deze, server-site render. En toen Next geïntroduceerd werd, dus vier jaar geleden, hadden we alleen maar server-site renderings. Alle pagina's werden altijd server-site rendered. Zelfs als het niet nodig was om ze te server-site renderen, zeg maar voor elke request. Dus het verschil tussen static generation en server-site rendering is eigenlijk dat je bij static generation zegt, oké tijdens de build voor productie, gaan we hem exporteren naar html en die html die stuur dan naar users toe. En die kunnen, dat betekent niet eens dat het niet meer geupdate kan worden. Dus in Next kun je ook zeggen oké, ik wil de pagina opnieuw genereren na een bepaalde tijd. Dus kun je zeggen revalidate 1 of revalidate 10 en dan kun je zeggen oké na 10 seconden render hem opnieuw in de achtergrond. Zonder dat je daar je end-user performance mee schaadt, zeg maar. Met server-site rendering, ik denk net iets anders, daar heb je elke request die binnenkomt, ga je dan een specifieke react-pagina renderen voor die gebruiker. Daarvoor heb je meer resources nodig, of een caching-laag voor je server-rendered pagina's. En dan kun je dus zeggen oké, we renderen voor elke gebruiker deze specifieke content. En daar zitten voor- en nadelen aan. Eentje is dus dat je meer resources nodig hebt. Omdat je dus voor elke user iets aan het renderen bent, aan de server, op de server, zeg maar. Bij Static Generation heb je gewoon een statische HTML file die de CDN dan serves. Dus zeg maar, stel, ik request versatile.com, wat dus dan een beetje static is, vanuit Amsterdam, dan krijg ik hem ook vanuit Amsterdam binnen, als er al iemand anders in Amsterdam is geweest naar de website. Oh, zelfs dat ja. Direct via een CDN. En dan heb je de server-rendered. Zou dan zijn, we hebben deze functie gehost in San Francisco, dus je moet helemaal van Amsterdam naar San Francisco gaan, om die pagina te laten renderen door een server daar, en dan terug te krijgen, zeg maar. En dat kun je dan oplossen met ook nog caching voor je server-rendered pagina's. En dat kan ook op Vercell bijvoorbeeld. En dat is eigenlijk de twee verschillen. Dus je hebt static generation, server rendering, en dat is anders dan alleen maar static generation. Wat dus zeg maar, oké, ik ga een statische pagina maken, en that's it, zeg maar. Oké, dus Next.js is een beetje best of both worlds, is dat goed om te omschrijven? Die hybride situatie, dat je dus de keuze hebt om? Ja, anders dan, het is geen static site generator, het is ook geen, het is een soort van static site generator, maar ook een server-rendered framework. Dus het zorgt eigenlijk voor dat jij als developer de trade-offs kan kiezen die handig zijn voor de pagina die je aan het bouwen bent. Ja, ik vind dat... Ik zou nog niet zeggen van oké, we gaan, zeg maar, we kiezen er nu voor om alles static te doen. En over twee jaar kan het zijn dat je applicatie zo gegroeid is of zo'n andere requirements heeft. Dus stel je gaat A-B testing doen of andere dingen, user personalisation is een andere groting. Zorg er dat elke gebruiker een ander soort resultaat ziet. Dat kun je dan doen door gewoon te zeggen oké, ik ga van static generation naar server-rendering. En dat is gewoon een functie aanpassen in plaats van oké, nu moeten we een nieuw framework uitkiezen en dan alles om gaan bouwen. Waarschijnlijk heel veel geld kost, heel veel tijd en heel veel moeite. En dat voorkom je dan eigenlijk door tot zeg maar oké, we bouwen hybrid application, dus een hybride applicatie die het allebei kan, zeg maar. En de nadruk is natuurlijk op kan, want je hoeft dus niet te zeggen van oké, ik ga per se alles static doen of alles dynamic. Of een van de twee, je kan ook zeggen ik ga gewoon een hele applicatie server-rendered maken of een hele applicatie static generated. Ja, al die keuzes dat maakt denk ik echt uniek Next.js. Want bijvoorbeeld naar de commerce case toe die ik in het begin een beetje noemde al. Ik bedoel als je dan kijkt naar Gatsby, dat is natuurlijk leuk als je maar een beperkt aantal pagina's hebt die je tijdstatisch kan genereren. Maar op het moment dat je echt veel producten krijgt, dan kan je dat natuurlijk niet allemaal meer build time doen. En met Next.js heb je dan de keus om dat of server-side te doen of statisch of incrementeel statisch? Ja, dus wat je eigenlijk kan doen is dan zeggen van oké, ik ga de belangrijkste pagina statisch genereren. En de rest van de pagina's ga ik dynamisch renderen en dan ook cache, zeg maar. Dus zeggen van oké, ik heb zoveel pagina's die gewoon zeg maar, ik heb tienduizenden pagina's. En niet alles hoeft statisch genereerd te worden. Maar het is wel handig als ze allemaal gecached worden. Als de eerste request binnenkomt dan cacheen we ze bijvoorbeeld. En dat kun je dus ook doen met Next. Waardoor je duidelijk zegt van oké, we hebben een server-side rendered backend met caching laag ervoor, zeg maar. Oh zo, ja. Oké, cool. Nou, dat ben ik vergeten. Ik had een vraag, want jij had het er altijd over. Oh ja, dat incrementeel updaten. Daar heb je mij, Joost, heb je mij een keer uitgelegd. Incremental Static Regeneration, toch Tims? Ja, dat. Wat is dat? Dat vinden luisteraars denk ik wel interessant om te horen. Maar hoe werkt dat? Ja, dit is ongeveer wat ik net verteld heb. Dus je kan zeggen, het is eigenlijk dat stukje. Dus het zeggen van oké, ik ga een paar pagina's statisch genereren. Als helemaal geen pagina's statisch genereren. Maar ik weet dat deze pagina's gecached kunnen worden. Ze hebben geen user-specific data. En dat kunnen we garanderen doordat je Catastatic Props gebruikt. Wat dus minder toegang heeft tot bijvoorbeeld de request en response. Krijg je daar niet mee en dat soort dingen. En daardoor kun je eigenlijk zeggen van oké, deze pagina kan statisch genererend worden tijdens de request. Dus als jij een request doet naar de pagina, dan wordt die gegenererd en daarna gecached. En dan requests die daarna komen, die gaan dan in de achtergrond. Dus buiten jouw request om, gaat die ook hergenereren. En wat dat eigenlijk verzorgt is dat je een hele simpele API hebt als eindgebruiker. Dus als de programmeur die een next step aan het bouwen is. Waar je eigenlijk zegt van oké, deze pagina moet elke 5 seconden gehergeneerd worden. Met zo'n request binnenkomen enzovoort. En dan doet die dat ook automatisch. Dus dan hoef je daar niet over na te denken van oké, stel je hebt een CMS bijvoorbeeld. En je hebt mensen die in de CMS aanpassingen maken. Dan hoef je niet te zeggen van oké, ik sla het op en dan moet ik een next build draaien bijvoorbeeld. Ja precies. Wat meestal niet het beste idee is. Omdat je dan ook heel veel caches weggooit van data en JavaScript die gegeneerd is en dat soort dingen. Ja oké, dat snap ik wel. Maar dit is wel een feature die wel erg vast zit aan de CDN waar je op zit. Dus je moet wel die Stale Revalidate functionaliteit hebben. Dus bijvoorbeeld dit, dan kun je het ook prima op FirstSale doen. Maar als je dan NetRefi wil, dan kun je deze even niet gebruiken. Het zit zeg maar zo dat je dus als je een CDN hebt, de meeste CDN's ondersteunen Stale Revalidate ook. Dus CloudFront en Festly, CloudFlare ook bijvoorbeeld. Die supporten dat allemaal. NetRefi is een ander verhaal omdat die niet echt, die zijn meer gefocust op statische hosting. Dus die gebruiken meestal NextExport. En NextExport die genereta ex statische HTML. En dat is dan ook het enige wat je kan hosten zeg maar. Ik heb toevallig een uitbreiding gebouwd voor ze op hun plugin voor Next.js. Dus om dit te doen, die statische site generation. Maar omdat ze die capability niet hebben voor Stale Revalidate. Kunnen ze net het laatste stapje niet maken. Ja precies. Dus omdat ze dus geen, zeg maar niet die andere CDN's gebruiken bijvoorbeeld. Of Vercell CDN heeft ook support voor Stale Revalidate. Kan het dan niet werken op die manier zeg maar. Tegenover wat je bijvoorbeeld bij Vercell hebt. Waar we het nog niet over hebben gehad overigens. Vercell is eigenlijk een bedrijf achter Next en verschillende andere open source projecten. En Vercell is een hosting platform. Een cloud platform voor eigenlijk een workflow. Die heet Develop Preview Ship. En het begint eigenlijk bij het developpen van je applicatie. Dus je bouwt een Next applicatie of een Gatsby applicatie. Of een van de andere static generators. Dus Ugo of Eleventy of Angular of Create React App. Wat dan ook. En dan geef je eigenlijk ons een GitHub repository. En met de GitHub repository detecteren wij dan oké. Dit is de applicatie die je hebt draaien in die repository. Dus je zegt van oké. Je hoeft niet eens te zeggen van oké ik heb een Angular applicatie. We zeggen gewoon van oké je hebt een Angular applicatie waarschijnlijk. Als het niet zo is dan kun je het aanpassen. Maar dit zijn de settings die je wil hebben. En dan gaat hij dus automatisch met zero configuration. Kun je dan deployments krijgen. En deployments zijn eigenlijk losse unieke URLs. Voor elke commit die je doet. Inclusief pull requests. Dus als je een pull request maakt dan krijg je automatisch een URL. Waarmee dat je dus die wijzingen kan zien. Dat is voor de preview. De preview stop van de develop preview ship. En dan het laatste stukje is natuurlijk hoe gaan we dit in productie krijgen. En dat kun je dus ook met voorstel doen door dan te merge naar de main branch. En dan krijg je eigenlijk een productiedeployment. Die dan gelinkt wordt aan je domain dat je al hebt. Dat is eigenlijk de develop preview ship methodologie. En dat werkt heel mooi samen met Next. Omdat je dus met Next heel makkelijk wijzingen kan maken in je applicatie. In je front-end zeg maar. En dat dan ook meteen kan deployen naar het platform. En dat is zeg maar een vercel platform is geïntegreerd met Next. Dus eigenlijk alle features die je in Next hebt werken uit de box automatisch op het vercel platform. Omdat ze die dus allebei bouwen. Dus ze bouwen en het vercel platform en Next. Jullie doen volgens mij ook wel iets. Mijn ervaring is alleen voor onze website. Dus ik ben echt geen enorme ervaringdeskundige. Er zit wel magie achter. Maar volgens mij doe je ook als er een commit is. Het is niet dat je alles altijd helemaal beeld of wel? Of heb ik dat niet helemaal goed begrepen? Dat je daar wat slimmigheid in doet. Ja, we proberen natuurlijk zo slecht mogelijk te zijn in hoe dat dingen optimiseerd worden. Een ding dat we doen is dat we voor alle frameworks die we ondersteunen automatisch de caching goed zetten. Wat je normaal bijvoorbeeld als je zelf je CI instelt. Dan moet je bijvoorbeeld uitzoeken waar staan de cache folders. Bij Next is dat .next slash cache. En dan moet je die opslaren ergens met die CI config. En dan weer terug zetten. En dan gaat je veel sneller naar de eerste keer. En op voor zelf heb je dat niet te doen. Dat gaat allemaal automatisch. Daarnaast hebben we heel erg geoptimiseerd voor workloads van Next bijvoorbeeld. En andere frameworks die we veel op ons platform hosten. Oké, ja. Ik was positief verrast. Ik dacht, cool, dit werkt wel heel erg nice qua developer experience. Heb jij nog vragen over Next 10, Joost? Next 10 en commerce. Dat heb ik wel benieuwd. Ja, tijdens de keynote over Next is 10. Dus in Next 10 hebben we eigenlijk nog twee dingen aangekondigd. Eentje is internationalized routing. Dat is dus het vertalen van goud. En het hele afhandelen van oké, hoe kan ik mijn applicatie vertalen. Wat heel belangrijk is in Europa natuurlijk. Omdat we heel veel verschillende talen hebben. In een relatief kleine... Zeg maar, de grenzen zijn heel dichtbij. Ja, klopt. Veel bedrijven, zeker ook in Nederland, die gaan heel vaak naar het buitenland toe. Om toch te groeien, zeg maar. Zeker e-commerce. En dat brengt ons natuurlijk bij e-commerce. E-commerce is natuurlijk een hele grote markt op dit moment. Waar je eigenlijk... Wat we eigenlijk zagen was... Er zijn heel veel bedrijven die e-commerce sites aan het bouwen zijn op Next. Ze willen eigenlijk heel graag een soort startpunt. Van oké, waar beginnen we als we het gaan bouwen? En daar hebben we samen gewerkt met BigCommerce. Dat is een SaaS provider voor e-commerce. En daarmee hebben we samen eigenlijk een starterkit gemaakt. Voor het bouwen van webshops. Dus die automatisch integreert met BigCommerce. Straks ook met andere providers. En daar kun je eigenlijk heel makkelijk e-commerce sites mee bouwen. Dus je hebt de ingebouwde componenten al. Om productpagina's te maken, om homepages te maken, enzovoort. En het fijne, of het handige met Next is natuurlijk ook... Dat je nu door die hybrid approach, waar we het straks over hadden... Hoef je niet meer te zeggen van oké, we gaan nu ook het CMS in BigCommerce doen. Je kunt ook zeggen van oké, we gaan naar een andere CMS provider. Die helemaal gespecialiseerd is op het bouwen van CMS's. En het beheren van content en niet e-commerce producten. En daar ga je dan je content neerzetten. Omdat het makkelijker is voor de editors. Om daarin te werken dan in de BigCommerce-medule bijvoorbeeld. En daarom is het steeds vaker dat bedrijven in die headless approach gaan. Waarin dat ze zeggen van oké, we gaan een applicatie bouwen die verschillende providers bij elkaar kan brengen. Dus verschillende providers. We hebben ook een e-commerce provider. Dat kan ook een legacy applicatie zijn. Dus bijvoorbeeld een Outer Magenta instance. Of een custom-built achterkant. En die brengen we samen met die NextJet applicatie in één grote applicatie. Die je dan aan het bouwen bent op basis van Next. Voor de front-end. Dus de front-end is dan helemaal gebouwd in Next. Maar de achterkant is dan nog steeds of die legacy applicatie of een nieuwe applicatie. Of een cloud provider zoals een CMS bijvoorbeeld. Oké. Mag je jou iets zeggen over wat andere providers gaan worden voor commerce? Weet ik niet zeker. De meeste cloud providers die in de e-commerce space zitten. Die zijn geïnteresseerd in dit project. Ik weet niet hoeveel ik erover kan zeggen. Nee, nee. Dat moet je vooral niet doen. Nee, nee, nee. Dat moet je niet doen. Maar er zijn wel feature requests. En als je naar giddap.com slash for sale slash commerce gaat. Dan kun je ook zien wat de feature requests zijn. De pull requests enzovoort. Het is helemaal open source. Dus daar kun je ook feature requests indienen als je een bepaalde provider zou willen zien. Je hebt zelf iets gebouwd met commerce tools. Eigenlijk in een beetje hetzelfde trend als Lexus, commerce en big commerce. Dat is heel interessant. Ja, cool, cool. Ja, we zien ook heel veel. Zeker voordat we commerce dus aangekondigd hadden. Hebben we ook gewoon heel veel e-commerce platforms gezien. Die gewoon zelf gebouwd zijn, zeg maar. Dus hele grote namen in Amerika, zelfs in Nederland trouwens. Die dus next gebruiken voor de frontends van een applicatie. Maar is Nederland, ja dat is misschien, nou goed. Is Nederland niet een beetje een bijzondere, die idee heb ik altijd met e-commerce. Omdat wij best wel, hoe zeg je dat, heel goede payment hebben door Ideal. Blijkbaar is het zeg maar, de kosten van transacties liggen heel erg laag. En e-commerce is volgens mij enorm hard gegroeid in Nederland. En harder dan in de rest van Europa, lijkt het zeg maar. Ik weet niet of je iets mee hebt gekregen. Ik weet niet precies de data erover. Ik weet wel dat het steeds makkelijker wordt om te betalen. Zeker met dingen als Apple Pay, dat je nu ook in Amerika hebt. Dat is nog makkelijker dan Ideal, zeg maar. Ja, dat is waar. Dat je alleen maar je gezicht nog voor je iPhone heeft te houden. En dat het dan gewoon werkt, zeg maar. En dan ben je al klaar met betalen. De e-commerce space in Nederland is niet super groot, natuurlijk. Je hebt niet heel veel verschillende spelers. Vooral heel veel, zeg maar, de distributie van spelers. Zeker in, zeg maar, de categorieën. Als in, zeg maar, Bobcom bijvoorbeeld is steeds meer een platform aan het worden. Dus die trekken eigenlijk data van kleinere webshops samen. En dan is het eigenlijk een soort marktplaats. Alleen dan met een soort... Ja, dat je het gewoon kan zien als een soort marktplaats voor spullen. Die andere echte bedrijven. Dus niet mensen die gewoon zeggen van oké, ik ga mijn boeken verkopen ofzo. Maar gewoon bedrijven die dus hun producten willen verkopen op Bobcom, die daar dan verkopen. Dan heb je natuurlijk andere spelers zoals Coolblue die zeggen van oké, we gaan alles zelf doen. We hebben een heel groot magazijn staan. Meerdere zelfs. En daar vandaan wordt alles geleverd. Ze hebben zelf bezorgers. Ze hebben schijnbaar meer dan duizend, heb ik laatst gehoord. En bijvoorbeeld Blokker doet nu ook dat platform ding, wat Bobcom ook doet. Waar ze dus gewoon daten van kleinere webshops samenbrengen. Dus dat zie je steeds meer. Dus kleinere spelers die hebben zelf wel een webshop, maar dan een hele kleine webshop. En dan halen ze heel veel van hun omzet uit platformen. Bobcom, Blokker, Ensvoort. En wat je daarnaast ziet is dat je nog steeds heel veel... Er zijn wel veel grote bedrijven die ook gewoon in Nederland zitten. Maar bijvoorbeeld de multinational zijn of wat dan ook, zeg maar. Dus die kunnen bijvoorbeeld ook hun sites laten bouwen in Nederland. En dan door heel de wereld verspreiden, bijvoorbeeld. Ook andersom natuurlijk Amerikaanse bedrijven die in Nederland komen. Ja, tuurlijk. Bedrijven uit Londen, Deliveroo bijvoorbeeld. Dat is daar een voorbeeld van. Het drijft ook op Next voor een webplatform. En ja, je ziet zo redelijk veel... Zeg maar, e-commerce ziet nog steeds heel veel groeien. Heel veel nieuwe websites, heel veel redevelopment, redesigns enzovoort. Dus dat is zeker nog een... Als developer is daar zeker werking te vinden in de meeste gevallen. En daarnaast zijn er natuurlijk ook nog altijd mensen die gewoon websites willen. Websites als in de bakker op de hoek met een openingstijde enzovoort. Die worden ook gebouwd op Next in sommige gevallen. Tevallig had ik laatst... We kunnen soms zien dat er nieuwe sites bij zijn gekomen door bepaalde webcrawlers die weten hoe ze een bepaalde technologie moeten vinden. Er kwam ook de website tegen van een bepaald winkelcentrum waar ik vlakbij woon. Die ook op Next was gebouwd bijvoorbeeld. Maar we zien het eigenlijk van kleine websites. Dus het winkelcentrum dat vlakbij mij ligt. Tot aan de rest van Nederland. Volgens mij iWish en Pearl. En nog dichterbij een site die iedereen wel kent. Ondertussen Corona Dashboard van de Rijkse overheid. Dat is ook op Next. Dat is compleet open source. Dus die kun je ook vinden op GitHub overigens. Daar heb ik niet aan meegewerkt. Dat draait alleen op code die ik geschreven heb. Via Next. Dat zal het grappig zijn om te zien. Dus je ziet heel veel verschillende soorten applicaties. Die gebouwd worden op Next. Omdat je dus zo flexibel bent. Je kunt zeggen van oké, ik ga nu de kleinste website bouwen. Waar niemand op gaat kijken. Mijn eigen website bijvoorbeeld. Daar kijkt niemand op. Tot aan de top 5 van de hele wereld. Zoals QQ van Tencent. Dat is ook wel waar de kracht ligt. Want als je dus weet wie een next.js applicatie bouwt. Dan kun je dus van die kleinere websites doorgroeien naar oké. Ik ga iets grotere websites bouwen. Het schaalt dus gewoon heel erg goed. Maar dat is op zich wel knap. Als je binnen vier jaar, dat is het eigenlijk. Dat je dan toch bij de top 5 terechtkomt. Dan gaat er iets goed. Het lijkt mij. Dus dat is wel mooi om te zien. Wauw, man. Ik moet zelf gaan zoeken of ik nog vragen heb die niet langs zijn gekomen. Heb jij iets? Ja, ik heb het altijd aangezet. TypeScript of JavaScript. We hebben het een hele tijd over gedaan om het om te zetten naar TypeScript. En dat hebben we incrementaal gedaan. Incremental adoption is een ding waar ik best wel gepassioneerd over ben. Daarom zijn er ook heel veel features van Next. Niet zo van oké, je moet het nu gaan gebruiken. Het is meer van hier is het en ga het gebruiken. Kan het zijn dat we het deprecaten, maar de kans is niet heel groot. Van oudere features dan. We vervangen dan features. Bijvoorbeeld get initial props. Can you get server-side props, get static props. En de reden dat we dat doen is dat we die upgradability willen houden. En TypeScript is een heel goed voorbeeld daarvan. Je kunt zeggen, ik ga TypeScript gebruiken. En dat betekent niet dat je je applicatie niet eens moet ombouwen in TypeScript. Er zijn mensen die dat doen. Kan in sommige gevallen, in veel gevallen ook niet. Voor Next zou dat betekenen dat we maandenlang, of niet maandenlang, maar dat we een halve maand bezig zouden moeten zijn met het omzetten van alle JavaScript-files naar TypeScript-files. En dat is niet heel logisch als je een startup bent. Met heel weinig mensen als in resources. Dus wat het deden was, we hadden het eigenlijk zo gedaan dat we gewoon met één bestand begonnen zijn en één voor één, elke keer als we aan een bestand werken, zetten we het om naar TypeScript. En op die manier ben je dus niet resources aan het weggooien, doordat je gewoon elke keer net iets anders, zeg maar, omzet. Dus elke keer als je een pull request maakt, verander je een verhaal naar TypeScript. Conturbius hoefde dat natuurlijk niet te doen, maar wij interne deden dat wel. En daardoor heeft het iets langer geduurd, maar hebben we er zelf geen last van gehad in hoeveel features we aan het bouwen zijn enzovoort. Of waren in dat geval. Nu is alles TypeScript. Ja, 99% TypeScript. Als je naar de repository statistics kijkt, die kloppen niet helemaal, omdat de examples in JavaScript zijn, by design. Maar de core is in TypeScript. Het interessante met TypeScript is dat je in een bepaalde manier, omdat je types hebt, moet je nadenken over hoe dat bepaalde function calls gaan en bepaalde flows in de applicatie. Die kun je niet maken met TypeScript per se. Het kan wel door any te gebruiken en andere dingen te doen, maar het is niet zo handig als het kan zijn. Daardoor word je heel erg gedwongen om iets meer functional programming te doen, wat geen slecht ding is, zeker niet in een framework zoals Next. En daardoor kun je ook bijvoorbeeld bugs vinden of sneller refactoring, omdat je dan zegt van oké, ik wil een referentie veranderen in elk bestand tot deze functie aanwoordt, bijvoorbeeld. Maar ook bijvoorbeeld als je iets wilt refactoring en je wilt die argumenten aanpassen. Stel dat je een argument weghaalt ergens, of een object een key weghaalt, dan krijg je warnings van de rest van de applicatie van oké, die property bestaat niet meer en je bent hem hier aan het gebruiken. Of die property bestaat niet meer, maar je zet hem hier. Het is niet eens het gebruiken stuk, het is ook het zetten van die property op dat moment. Daardoor kun je dus efficiënter werken, omdat je dus als je dingen wilt refactoring sneller klaar bent. En als je nu front-end applicaties zou maken, Tim, zou je dan ook altijd TypeScript kiezen, of zeg je daarna, is JavaScript misschien ook wel een goede optie? Want je ook zei over die examples, die zijn nu bij design in JavaScript. Ja, het ligt er aan. Als je helemaal van scratch aan begint, zou ik TypeScript wel gebruiken, omdat je het ook kan, zeg maar, de type checks kun je ook ignoren in bepaalde stukken, waardoor je kunt zeggen, oké, dit stukje is niet superbelangrijk voor nu in ieder geval, laten we het later fixen. Doe dat ook in de Next.js-codebase. Dat is niet iets waarvan je moet denken, oké, ik laat alles vallen, we gaan nu alleen maar types fixen, zeg maar, dat soort dingen. Want uiteindelijk, die types zijn er niet om die checks altijd goed te laten gaan, bijvoorbeeld, die types zijn er om jou te helpen, beter te programmeren of spelletree factoren en dat soort dingen. Dus ze zijn niet een blokker voor jou als developer, ze zijn meer als een hulpder, natuurlijk. Ja, ja, dat is denk ik ook wel de kracht van TypeScript, dat is volgens mij, oh man, ik moet me schaamelijk niet even zo de maker, want ik develop nu normaal gesproken in .net, en hij heeft ook C-sharp, zeg maar, gemaakt en toen TypeScript. Maar hij heeft toen altijd gezegd, oké, het is iets waar je in, ja, hoe zeg je dat, je ease in, zeg maar, dus je loopt er stap voor stap, kun je daar in gaan, je hoeft niet in één keer big bang over te gaan, dus dat is een optie, precies. Dus dat is wel heel sterk. Ja, en dat is ook hoe bijvoorbeeld binnen Microsoft TypeScript gebruikt wordt, ze hebben het steeds een stukje meer geïmplementeerd, en dat helpt dus ook gewoon als je als programmer bezig bent, moet je niet erover nadenken van oké, we gaan de hele applicatie in TypeScript schrijven, het is meer van, kunnen we deze feature in TypeScript schrijven, of kunnen we dit stuk van de code dat heel erg buggy is, omzetten in TypeScript, zodat we de input en output altijd hetzelfde houden, en daardoor niet de rest van de applicatie crashen en dat soort dingen. Ja, precies. Ja, ik vind dat wel, het heeft me positief verrast zeg maar, ook dat het zo goed opgepakt is, want dat was vroeger natuurlijk altijd van oh, Microsoft, nee, slecht, en dan moeten we niks mee doen, maar dat is toch best wel populair gebleken. Ja, ik denk dat we nu eigenlijk wel heel veel next besproken hebben, zijn er nog wel, nee, ik denk dat we verder moeten gaan, laten we het laatste deel inleiden, nog wat kletsen over wat losvast dingetjes. Een onderwerp wat we altijd terug laten komen, of een onderdeel, zijn de developer dilemmas. Dat zijn gewoon dilemmas, en je moet kiezen. We hadden eerst gebruikt door de developer dilemmas site, maar die hebben we een beetje uitgeput, dus die gebruiken we nu niet meer, dus nu verzinnen we zelf gewoon dilemmas. Ik heb het geluk gehad dat mijn co-host, of mijn andere host Bernard, dat die er twee voor mij heeft verzonnen, dus ik heb er gelukkig reden om te verzinnen. Dus laten we gewoon beginnen. De eerste is, je moet een feestdag afschaffen. Eigenlijk is het niet eens dilemma, dat is wel grappig. Welke kies je? Black Friday, Cyber Monday, Valentine's Day, Singles Day, of Kerstmis? Dit is echt wel... Dat is eigenlijk best wel makkelijk, want Black Friday en Cyber Monday zijn eigenlijk al afgeschaft dit jaar volgens mij, want ze zijn al weken van tevoren bezig met acties en zo. Dus het is meer Cyber Monday of zo. Ja, precies. Het is echt niet normaal, ja. Maar je wordt er ook niet rustiger van. Je krijgt de hele tijd van, oh, hier heb je nog een aanbieding, hier nog een aanbieding. En je weet echt niet meer. Het is niet meer zo speciaal of zo. Hoe zeg je dat? Het lijkt er ook op alsof bedrijven denken van, weet je wat? Als wij nu als eerste beginnen, dan geven ze als eerste bij ons het geld uit. En dan hebben we de boel binnen. En dan heeft de concurrentie pech gehad. Maar die singles was volgens mij in China ook bizar groot. Of heftig, dat was wel... Dat was volgens mij de beste dag voor Alibaba of zo. Vorig jaar of zo was het echt niet normaal qua inkomsten en dat soort dingen. De volgende, dat is wel meer een keus. Altijd jQuery of altijd COBOL? En ik denk dat Bernard ook bedoelt dat je mag ook kiezen uit Lisp, Haskell of Assembler. JQuery. Bij het bedrijf waar ik gewerkt heb, hadden we een COBOL applicatie. Die is nog steeds maintained. Na dertig jaar. Voor... Ik ga de naam niet noemen. Nee, precies. Maar voor een heel groot bekende naam in Nederland. Dus als ik die naam niet zou noemen, dan zou je weten welke bedrijf dat is. Je bent er waarschijnlijk als je kinderen hebt ooit geweest. Maar dat is eigenlijk het enige wat ik kan hinten. Oké. Ja. Hilarisch, hadden we een COBOL applicatie in productie draaien voor meer dan dertig jaar. En nog steeds maintain. Dus er was nog steeds iemand die die applicatie geschreven had, die was nog steeds daarmee bezig. En misschien nog steeds nu zelfs, want ik heb het niet meer bijgehouden en zo. Maar, ja. Dat is ook wel iets moois. Ik weet ook gewoon, iets moois hebben. Ja. Ja, het is wel gaaf dat je een systeem bouwt dat zo stabiel is, dat is eigenlijk wat het is, dat je het gewoon dertig jaar lang kan laten draaien zonder dat je een nieuw framework nodig hebt om alles te hebben bouwen, zeg maar. Ja, dat is natuurlijk aan de andere kant van het spectrum, zeg maar. Nu is dat wel minder. Maar in JavaScript was het op een gegeven moment, iedere week had je wel een nieuwe framework of een library of weet ik wat. Ja, dat is natuurlijk wel compleet anders dan hoe het met COBOL is. COBOL staat in principe gewoon stil. Ja, dat zijn volgens mij wel wat dingetjes. XML, internet, ja. Ja, het is ook als je... Ik was vorig jaar bij de Computer History Museum geweest in Mountain View. En daar hadden ze een soort plaats hangen aan de muur. Met alle programeertalen en wanneer dat ze bedacht zijn, zeg maar, en publiek gemaakt zijn enzovoort. En COBOL wordt ook echt een van de eerste programeertalen die daarbij stond, zeg maar. Dus dat is wel grappig om te zien. Ja, ja. Ja, dat is wel... Dat wordt nog steeds. Volgens mij is de vraag naar COBOL ontwikkelaar. Dat was op een gegeven moment, ik weet niet of het nu nog steeds is. Die was in één keer zo hoog dat heel veel mensen met pensioen gingen. En je werd gewoon heel goed betaald, zeg maar, als je dat kon. Dus er is nog wel wat in te verdienen. Volgens mij de volgende vraag die daar staat, die heb jij meegenomen, Joost. Ja, ik heb de vrijheid genomen om daar iets toe te voegen, Saber. Ja, het is niet echt een dilemma. Toch, of wel? Van sommige mensen wel. Ja, nou. Theowind of SCSS? Theowind. En dat zeg ik niet omdat ik goede vrienden ben met Adam, de creator van Theowind. Maar het hele idee van Theowind is om SCSS schaalbaar te maken. Schaalbaar als in scalable. En dat heb ik zo goed zien werken in grote applicaties de afgelopen tijd met Theowind. Dat ik al overtuigd ben dat het een goede keuze is voor applicaties die je bouwt in je dagelijkse leven, zeg maar. Dus e-commerce enzovoort. Zeg maar, dingen waar je components bouwt die hergebruikt gaan worden. Wat dus in de meeste gevallen vrijwel elke applicaties die je bouwt of hergebruikt gaan worden binnen andere applicaties. Dus een probleem met je bijvoorbeeld, wat ik bij agencies heb gezien, is dat ze voor elke klant een nieuw componentsystem bouwden, bijvoorbeeld. En dat was puur op designbasis. Dus een compleet ander design, want de klant wil niet dat het eruit ziet als elke andere e-commerce site. Maar het mooie aan Tailwind is dat je door het aanpassen van een paar parameters eigenlijk kan zeggen van oké, de spacing is nu anders, de kleuren zijn anders, dus het thema eigenlijk, de font sizes zijn anders. En daardoor ziet een component er niet hetzelfde uit tussen de twee websites. Ook al zijn het exact dezelfde components. En daarnaast kun je dan ook nog met klassen natuurlijk een paar dingen aanpassen enzovoort. Maar dat is wel interessant om te zien in ieder geval. Ja, dat is wel... Het is ook best wel hard. Hoe oud is Tailwind? Ik heb er wel... 1,5 jaar. Ik vind het ook heel fijn. 1,5 jaar volgens mij. In 2019 hoorde je er net iets van. Een jaar geleden heb ik een talk gezien van iemand die bij Alkolia werkt. Die bij .js. Ik kan haar naam even niet herinneren. Maar als je dat opzoekt, er is een talk over utility-based CSS. Wat Tailwind dus eigenlijk implementeert. En ook standaard geeft eigenlijk aan dat. Want het moeilijkste in CSS is eigenlijk het namen geven van dingen. En het stylen van dingen. Dat klinkt natuurlijk heel cliché-achtig. Maar het is natuurlijk het bepalen van welke classes, welke styling hebben. En hoe die samenwerken om een component te maken. En uiteindelijk wat je noemt als developer of front-end developer in 2020 en 2021, is vooral components maken. Je maakt de kans dat je puur en alleen maar HTML aan het genereren bent. In een bepaalde vorm. Maar zelfs HTML in de meeste gevallen zijn een soort van components. Maar de meeste mensen die gebruiken frameworks als React, Angular, Vue, Svelte. En die hebben een component model in het framework gebouwd. Waardoor je echt componenten aan het bouwen bent. Buttons enzovoort. En componenten zijn dan ook weer opgemaakt uit andere componenten. Waardoor je dus gewoon een systeem moet hebben dat je dat eigenlijk kan schalen met al die verschillende componenten. Zonder dat je voor elke component dus een klas aan het schrijven bent. Want het goede, of eigenlijk het ding wat mij het meest aansprak aan Tailwind was niet dat oké nu hoef ik geen CSS meer te schrijven. Want je bent nog steeds CSS clusters aan het toevoegen. Het was meer het performance stukje waarin dat je begin met een bundle van 70 kb. Maar uiteindelijk als je naar mijn website toe gaat bijvoorbeeld dan ben je maar 3 kb aan het CSS downloaden. En dat kan ik als ik het handmatig schrijf niet beter doen. Ja dat kan ik wel voor mijn eigen website. Maar als je naar een grote website van een bekend Nederlands merk gaat bijvoorbeeld dan is het nooit een site die je handmatig hebt kunnen optimaliseren in CSS basis zeg maar. En dat kun je dus met Tailwind door Perch CSS dat ze gebruiken heel goed te doen zeg maar. Ja ja cool. Ja dat waren de dilemma's. We hebben er drie gehad. Tips. Ik weet niet of je, nou goed we behandelen tips. Ja dat kan van alles zijn. Tools, conferenties, boeken. Best practices, alles mag. Ja ik zal aftrappen maar ik heb er maar één. Dat is een luistertip. Ik heb een podcast zeg maar. Ik tip vaker ChangeLog, de ChangeLog podcast. En dit keer ging het over de toekomst van de Mac. Want er is natuurlijk een nieuwe chip zeg maar ja uitgebracht. En drie Mac's die daarmee uitgerust zijn. En Tim Dreamstra. Ik weet niet of hij Nederlands is. Hij klonk volledig Amerikaans. Maar goed die naam klinkt Nederlands. Misschien is het van de oorsprong. Maar hij is de product marketing manager voor developer technologies bij Apple. Hij is dus niet de hardware engineer maar gewoon een developer. Toevingen, technologie op Mac. Managed, nou dat zegt de naam natuurlijk al. Maar er zat heel veel enthousiasme in. Ze waren echt heel blij dat die M1'er was. Tuurlijk is dat wel een beetje op Amerikaans. Maar je merkt echt wel dat ze heel blij waren dat die M1-chipper was. En die zal ook echt wel een hele poos. Het idee om zeg maar op arm over te gaan hebben ze niet zeg maar voor gaven zonder. Daar zijn ze al een poosje mee bezig. En daar gaat die podcast over. Dus wel een luistertip. Ik vind het wel mooi. Ik vind het sowieso heel stoer wat Apple gedaan heeft. Als je mij drie jaar geleden had gezegd dat er een arm-chip in een desktop gaat komen die echt gewoon op sommige punten gewoon echt een stuk sneller is dan een Intel-chip. Een CPU. Ja, dan had ik je wel een beetje voor gek verklaard. We zagen het dan wel aankomen. Maar ik vind het wel stoer. Ik vind het wel interessant hoe dat zich verder gaat ontwikkelen. Zeker ook voor developers. Ja, kan het wel relevant zijn. Maar dat was mijn tip. Ik weet niet of jullie tips hebben. Of ja, noem iets. Maakt niet uit wat. Ja, sowieso die M1-chip. Die initiële resultaten over developer-work-gerelateerde dingen. Dus compiler van code enzovoort. Zelfs de compiler van V8, blijkbaar, is echt gigantisch veel sneller. Met ook meer battery savings. Dus meer batterij voor je laptop is niet leeg als je klaar bent met V8 compiler en dat soort dingen. Dat is dus blijkbaar met de Intel processors wel zo. Dus dat is wel interessant. Dat zag ik de laatste keer een tweet over. En verder, als je dus meer wilt weten over Next, kun je naar nextjess.org slash learn gaan. Waar je eigenlijk een soort interactive tutorial, dus een interactieve tutorial, kan doen. Die je helemaal door het bouwen van een Next.js app heen loopt. En ook hoe je Verstel gebruikt en dat soort dingen. Wat niet per se nodig is als je Next gebruikt, overigens. Maar daar kun je doorheen gaan als je nog nooit van Next hebt gehoord enzovoort. Het enige wat je nodig hebt is een beetje kennis van React. En dan kun je aan de slag. En ja, dat is het verder wel. De tip waar veel mensen een vraag om vragen is, zeg maar, hoe je aan contributen in open source begint. En het antwoord dat ik meestal geef is redelijk simpel. Het antwoord dat ik meestal geef is redelijk simpel. Het is gewoon, doe het. Maar het meest nuttige is als je naar een repository gaat. Het maakt niet uit welke repositories. Maar meestal de meest populaire frameworks enzovoort, die hebben een Good First Issues label in Issues. En als je daarheen gaat, dan kun je dus Issues vinden die relatief makkelijk zijn. Soms zelfs zo makkelijk dat je denkt van, waarom zou ik dit zelfs doen? Maar het helpt vaak met het, zeg maar, jezelf meer kennis geven over de codebase, voordat je echt aan het contributen van features of bug fixes of wat dan ook begint. Stel docs changes, A moet naar B veranderd worden of wat dan ook. Simpele dingen zoals dat. Is ook hoe ik ben begonnen met het contributen aan Next bijvoorbeeld. Was gewoon documentatie toevoegen, een beetje bug fixen, bugs die relatief gezien heel erg simpel zijn, die als je JavaScript kennis hebt, gewoon zou kunnen doen. Ik deed het ook zonder dat ik altijd veel JavaScript kennis had. En het helpt op lange termijn op medere manieren. Maar hij heeft het natuurlijk op een manier geholpen die niet heel normaal is. In zoverre dat ik dus, doordat ik heel veel contributen heb aan Next, uiteindelijk een baan heb gekregen om aan Next te werken fulltime. Wat je natuurlijk niet kunt verwachten voor iedereen. Maar het heeft me vooral heel erg geholpen met het doorgroeien naar oké, ik heb heel veel meer kennis over JavaScript, Node.js. Contributen bij een open source project. Dat staat altijd goed op je survey ook overigend. Vooral iedereen die ik gesproken heb die mensen zoekt of developers zoekt die bijvoorbeeld aan next year's projecten kunnen werken. Vragen meestal om oké, heb je ook een GitHub of wat dan ook. Zodat we daar al een keer naar kunnen kijken enzovoort. En als er dan grotere projecten opstaan, of niet eens grotere projecten zijn, maar gewoon projecten die je vaker hebt gezien of die in de ecosystem bestaan enzovoort. Dan is dat meestal een plus tegenover andere mensen die ook solliciteren voor eenzelfde slotbaan. Ja, dat geloof ik al. Ik had zo'n vrije chips, die wil ik eigenlijk steeds wel stellen. Maar goed, Joost, heb jij nog tips toevallig? Dat is bijna niet benodigd naar Tims betoog net over tailwind. Iedereen aanraden tailwind een keer uit te proberen. Ja, dat is wel waar. Ja, ik ben ook echt positief verrast door tailwind. Ik had in eerste instantie zoiets van, oké, laat maar even zien. En toen dacht ik, oké, ja, gaat makkelijk, zeg maar. It makes sense, zeg maar. Vond ik wel interessant. Kom op, kom op, ik wil die vraag. Ja, ik had nog, er is natuurlijk best wel een, heb je dat de kapitaalinjectie geweest voor development van Next.js? Maar de druk, ontstaat er een druk, verandert er dan iets, zeg maar? Je hoeft daar niet te zeggen van, ja, dat gaat af en toe. Ik moet wel zeggen over wat issues. Maar ik kan me voorstellen dat er wat dynamiek verandert, zeg maar. Maakt het, maakt het alles, is alles makkelijker of is alles, ja? Ja, om het, om het even in de context te geven. De vercel, het is een bedrijf achter Next, die heeft een 3D gedaan. Eerder in het jaar is dat aangekondigd. En daar is toen 21 miljoen dollar opgehaald. En dat is eigenlijk voor het uitbouwen van de platform, het uitbouwen van Next, zeg maar, het groeien van vercel, zeg maar. Daar is het voor. In zoverre verschil tussen voor het raisen van het geld tegenover nu, is dat daarvoor we met z'n tweeën aan Next werkte, fulltime, en nu met z'n vijven fulltime in Next werken. Qua projectleiding, enzovoort, heb ik nog steeds de leiding over het project. Dus er is relatief gezien daar niks veranderd. Ik kan nog steeds zelf de prioriteiten stellen over oké, dit is wat we gaan bouwen, dit is wat er aankomt in Next, zeg maar, enzovoort. Ik heb natuurlijk verantwoording die ik af moet leggen aan Qashirmo, en een andere e-staff binnen vercel. Eigenlijk het hele ding natuurlijk, als je naar vercel kijkt, wij zijn erbij gebaatd dat NextVS groeit, niet alleen op vercel, maar ook in open source. Hoe groter de community is, hoe beter het is voor iedereen. Dus voor de community zelf, want er zijn meer mensen, dus er zijn meer banen, dus je kunt ook eerder als een NextVS developer aan de slag. Er is meer interesse van andere bedrijven om te continuëren aan Next. Een vraag over vorig jaar, zelfs voor de Series A announcement, kwam Google, Google Chrome, een specifiek team, dat de studio's bericht van hey, we zijn bezig met een soort nieuw initiatief binnen Google Chrome, om samen te werken met frameworks. En we zien dat Next een van de frameworks is waar we het grootste impact kunnen hebben op het web zelf, zeg maar, als in dat frameworks gebruikt. Wat houdt dat nu in? We zijn naast mijn team, wat dus vijf mensen is. Er zijn nu ook een aantal mensen van de Google Chrome team, relatief gezien heel veel tijd bezig aan Next zelf. Dus het verbeteren van performance, het verbeteren van de developer experience in bepaalde delen. Next Image bijvoorbeeld is in samenwerking met het Chrome team gemaakt, om dus al die core web files beter te maken voor een heel groot deel van de Next Applications die dus al bestaan, maar ook alle nieuwe applicaties die gebouwd worden. En in die samenwerking, die is nu ongeveer anderhalf jaar bezig, hebben dus ook heel veel nieuwe features en nieuwe optimalisaties gemaakt. En dan denk je misschien van ja, oké, leuk dat jullie dat allemaal met Next aan het doen zijn, maar wat heeft dat voor nut voor mij als ik Create Reacts heb gebruikt, of web Excel, ik heb zelf iets gebouwd enzovoort. Maar een hele hoop van deze wijzigingen die kunnen dus eerst gevalideerd worden tegen echte applicaties, NextJet applicaties in productie die miljoenen gebruikers hebben. En daar kunnen we zien van oké, het werkt wat we hebben uitgevoerd en het heeft een heel goed effect. Een voorbeeld ervan is een nieuwe bundelsplitting algoritme dat we hebben gemaakt samen met Chrome Team. En wat je daar eigenlijk ziet is dat nieuwe algoritme wat we hebben gemaakt voor bundelsplitting, is nu een default in Webhack 5. Dus iedereen die Webhack 5 gebruikt, die heeft automatisch die optimalisatie, zelfs als je geen Next gebruikt, als je een Next gebruikt zit die er al in als je gewoon Next installeert. Alle nieuwe visies hebben die optimalisatie al. En zo zijn we nog een hele hoop optimalisaties aan het maken die ook overgenomen worden in andere frameworks. En daarnaast doen we dus ook, zeg maar bijvoorbeeld, wat is het nut dat Vercell bijvoorbeeld in Next investeert, ook dat ik bijvoorbeeld vorig jaar een memory leak in Webhack heb gevonden samen met een collega en die gefixt heb en daar ook een pullercaster heb gestuurd waarmee dat memory utilization van Webhack, voor alle Webhack applicaties, met iets van 70% verminderd werd tijdens het beelden. Waardoor je eerst, je draait Webhack en hij raakt out of memory en dat wordt later dus gewoon, je draait Webhack en je krijgt gewoon een output uiteindelijk. Dus we hebben nog meer dingen gevonden, bijvoorbeeld een bug in de file watcher die Webhack gebruikt, ChokeyDar, op Mac. Ik had toen ik Nexus applicaties aan het bouwen was, kwam ik erachter dat als ik een bepaalde error maakte, dus ik maakte een deep file en ik sla hem op, ik zag de error overlay enzovoort en ik maakte daarna nog een weiseling, dan ging die error overlay niet meer weg. En dat kwam niet omdat de error overlay kapot was, of wat dan ook, alleen dat kwam gewoon omdat de watcher die Webhack gebruikte stopte met watchen van dat bestand, nadat die een crash had gehad. Daar ben ik toen anderhalve week mee bezig geweest, omdat ik er zo, ik snapte maar niet dat dat gebeurde, want het was niet heel standaard. En toen ben ik dus tot Rabbit Hole eigenlijk doorgegaan om een bug te vinden in ChokeyDar, wat is gebruikt tot voor elke developer die een Mac heeft, die node code schrijft en Webhack gebruikt of andere tools, en daar die bug gefixt. En dat zorgde er eigenlijk voor dat je nu dus als er iets crashed in Webhack, dat je niet nog een error hebt, die error die blijft dan niet meer staan, die hoeft niet te rebooten en dat soort dingen. Wat dus eerst wel nodig was. En je zag het niet, dus dat was ook een beetje het raar. Ja, maar dat is wel nice, ja. Dat is dus, ja, hoe open source bedoeld was, zeg maar. Volgens mij hebben wij het wel eens hier in de podcast wel eens over gehad, van ja, misschien moeten bedrijven er eens over nadenken om dan, weet ik veel, 5 procent van de tijd, ja, niet geforceerd, maar wat te spenderen, terug te geven aan open source. Ja, zeker bij bepaalde agencies. Ja, goed, je zei dat eerder wel, van ja, je wilt bouwen aan je code, maar soms wil je ook iets terug kunnen geven, denk ik. Ja, dat zou misschien wel mooi zijn. Ja, cool. Ja, daar zijn we wel door de tips heen. We delen altijd Twitter Rants. Ik heb geen Twitter Rants, weer niet. Want als er geen is, dan gaan we die ook niet bespreken. Goed, dit was het weer. Zoals altijd, zorg dat je geabonneerd bent op ons. Dat zul je vast misschien al zijn als je zo ver bent gekomen als nu. Maar als je dat niet bent, ga je naar je favoriete podcastspeler, zoek op CodeKlets. Wil je met ons babbelen, want wij zijn natuurlijk super leuk en onze community wordt steeds leuker, ga naar onze Slack. Die kun je vinden via codeklets.nl. Die link die is gewoon, die staat daar gewoon. Dus dat is niet moeilijk te vinden. Alle interessante links, die komen in de show notes. Dus dat kun je daar naar toe. Door, linken, klikken, whatever. We hebben een Twitter account, dat is at codeklets. Hou die in de gaten, dan hoor je links en rechts nog wat nieuwtjes. En dan zie je misschien ook wel onze nieuwsbrief langskomen. Daar moet nog wat werk voor verzetten. En dat was het eigenlijk wel. Ik wil jou bedanken Tim. Graag gedaan. Bedankt voor je tijd. Dat is echt heel fijn dat je even gast wilde zijn. Ik ga jou ook bedanken Joost. Dank je wel, het was leuk. Zeker. Nou, dank je wel. En laters. Doei.