Jeffrey Bosch en Sander Elias vertellen ons alles over Angular development

Welkom bij een nieuwe aflevering van CodeKlets podcast. We zitten alweer in aflevering veertien. Het is gelukkig weer een aflevering in real life. Dat is al lang geleden dat ik één heb gedaan in real life. Het was allemaal online en online is op zich handig. Want ja, je kunt eigenlijk in je eigen habitat, zeg maar, in je eigen thuis, zeg maar, kun je gewoon rustig een opname maken. Maar ja, daardoor is het menselijke contact, zeg maar, van de gasten en de host is wat minder. En dan krijg je in mijn ogen toch een minder goede podcast. Dat wil niet zeggen dat al die opnames die we online hebben gedaan, dat die slecht waren. Maar het is toch anders. Dus ik ben heel blij om dit vandaag zo in real life te kunnen doen. Ik ben vandaag ook de enige host, de enige host. En vorige keer heeft Kishen het gedaan. Die heeft het ook alleen gedaan. Dat vond ik ook heel goed gegaan. Dus dat wil niet zeggen dat we straks alles weer met één host doen. Maar het kan heel goed gaan met één host. Maar, vandaar dat we ook vandaag twee gasten hebben. Twee heel interessante gasten. Ja, die hebben een onderwerp. Ik ga het niet meteen verklappen, wat ik zelf, ja, waar ik een mening over heb. Maar ik vind het zeker een heel interessant onderwerp. Ik wil vandaag de luisteraar heel erg... Ik hoop dat de gasten de luisteraar vooral bekend gaan maken met het onderwerp waar wij het vandaag over gaan hebben. Goed, de eerste gast is Sander. Sander is een ervaren ontwikkelaar met meer dan vier decennia aan praktijkervaring onder zijn riem. Hij werkt sinds 2010 met Angular en is ook Google Developer Expert voor het web, gespecialiseerd in Angular. Dat verklaapt meteen het onderwerp voor vandaag. De organisator van bijeenkomsten en congressen. Anderen helpen hem daarbij natuurlijk, want hij doet natuurlijk niet in zijn eentje, zeg maar, de bijeenkomsten organiseren. Dus dat lijkt me dat dat wel handig is. Maar hij ademt code. Hij friemelt wat met IoT, doet fotografie, wetenschap. En wat meer vage gadgetachtige dingen. En Sander is verder de oprichter van Scully. Daar mag hij mij heel veel over gaan vertellen. Maar welkom Sander. Hoi. Leuk om hier te zijn. Het is ook weer voor het eerst dat we in person ergens zijn. Sinds al twee en een half jaar zo'n beetje. Dus ook wel weer eens een keer leuk. Ja, ik mocht buiten spelen vandaag. Ja, dat klopt. Dat is wel grappig. We zijn vandaag in Eindhoven bij Aviva. En jij komt ook uit Breda volgens mij? Prinsenbeek, ja. Dus ja, Prinsenbeek. Ja, ik zeg al heel snel Breda. Ja, het is officieel Breda. Maar niemand in Prinsenbeek zegt dat het Breda is. Net zoals iemand die in Bravel woont niet zegt dat die in Breda woont. Die woont in Bravel. Klopt. Maar goed. Ja, welkom. En ik ben blij dat je de tijd hebt genomen om er bij te zijn. Verder hebben we Jeffrey. Jeffrey is de auteur van de NGX AWS Deploy. Medeorganisator van de Dutch Angular Group. En lid van het X-layers kernteam en medewerker van Scully. Gaan we het over hebben. Momenteel werkt hij bij Stiply als senior software ontwikkelaar. En hij heeft een passie voor alles wat met internet te maken heeft. En draagt bij aan verschillende open source projecten, zoals NGRX. En de Angular CLI. Dat is ook heel stoer. Welkom Jeffrey. Dankjewel, leuk om hier te zijn. Ja, jij moest een langere reis maken. Ik denk al ietsjes langer dan vanuit Breda. Ik kom uit Ede, dus dat is ongeveer een uurtje rijden. Ja, dat vind ik heel tof dat je de tijd hebt genomen om deze kant op te komen. En naar het mooie Eindhoven hebt mogen afreizen. Ja, zoals je nu gemerkt hebt, we gaan het vandaag hebben over Angular. Een framework, moet ik zeggen. Want het is altijd een discussie, is het library van frameworks. Er zit wel een nuance in, maar het is wel een framework, toch? Ja, ja, voor en dan zeg ik meestal front-end development. Dat zal ook wel kloppen, toch? Ja, ja, wij zitten hier heel erg te knikken. Wat niet erg werk bij een podcast. Ja, ja, dat is waar. Ja, ik moet ja, nee, zeg, ja, ja, ja, nee, dat klopt. Dus dat, dat wil nog wel eens gevoelig zijn. Maar sommige mensen staan heel erg op een streep. Als je zegt framework tegen library of library tegen framework, dan krijg je daar weer een discussie. Maar goed, dat zit hier toch voor een discussie? Ja, dat is wel waar. En om een beetje erover te kletsen. Dus dat komt wel helemaal goed. Ja, jullie zijn al twee software ontwikkelaar. Hoe zijn jullie daar ingegrold? Sander, kun jij daar eens op beginnen? Nou ja, ik was nog enigszins jong, een jaar of 7. En mijn vader, die droeg een computer binnen voor zijn werk. En ik vond dat wel een interessant ding en ik wou er eigenlijk spelletjes op doen. Eén probleem, rond die tijd waren er nog geen andere computers of spelletjes of wat dan ook. Dus die moest ik zelf gaan schrijven. En ik kwam er eigenlijk heel snel achter dat ik het schrijven van de spelletjes leuker vond dan het spelen van de spelletjes. En zo ben ik er ingerold. Ik ben bij een computerclub gegaan. Ik heb aan mijn elfde mijn eerste commerciële programma verkocht. Ik heb op mijn zestiende een bedrijf gestart, wat ik op mijn achttiende helemaal officieel heb gemaakt. Want toen moest je nog wachten tot je volwassen was. Echter was dat pas bij 21. Zolang wou ik niet wachten. Dus toen heb ik mijn eigen. Toen moest ik bij de rechter volwassen verklaard worden, wat nog een heel ding was. Dus daarna ben ik mijn bedrijf gestart, waar ik nu nog steeds voor werk. Oh, echt? Ja, grappig. Dat is wel, dat is al een pose, of niet? Dat is al een pose. Ja, ja, ja. Mijn bedrijf bestaat 36 jaar nu. Nou, er zijn niet heel veel IT-bedrijven die dat na kunnen vertellen. Dus dat is wel heel indrukwekkend, ja. Ja, cool. Maar goed, dat heeft je dus eigenlijk gepakt vanaf je zevende. Eerst ben je gewoon eigenlijk nooit meer. Ik heb nooit meer wat anders gedaan. Nou ja, in ieder geval ontwikkeling. Niet alleen, niet alleen software, ook hardware. Maar ja, de laatste paar TV-scenia is het eigenlijk voornamelijk software geweest. En ik doe wel wat hardware, maar dit is eigenlijk alleen maar een hobby. Ja, precies. Voor de fun. Tegenwoordig is het met die IoT-spullen zo leuk om er thuis mee te spelen. Ja, ja, ja. Het is ook veel toegankelijker geworden, zeg maar. Ja, nou ja, weet ik niet of het dat nou juist leuk vindt. Het is juist leuk om je ergens in te diepen en echt iets te bouwen van niks af aan. In plaats van een kantenklaar bordje te kopen in je USB te pluggen. Hey, ik heb iets gebouwd. Ja, ja. Ja, goed, het is wel zo dat heel veel kinderen, zeg maar, dus die manier heel makkelijk erin stappen. Dus dat is wel, ja, dat is anders dan vroeger. Nou ja, de ontwikkeld blokken zijn tegenwoordig anders als dit. Ja, ja, ja. Toen. Toen, ja. Ja, ik vind dat een positieve ontwikkeling. Ik bedoel, want het is denk ik maar voor een happy view. Laten we zeggen, de happy view die dat konden doen, zeg maar. Of via ouders of via school toevallig. En nu is het, ja, hoe makkelijker en het is wat goedkoper. Nu is het heel breed te verkrijgen en dat is een goede zaak. De insteek van mijn bedrijf was ook om mensen bekend te laten worden met computers. Oh ja. Een aantal jaar geleden zat ik terug in de trein en ik zat eigenlijk niet lekker in mijn vel, al een tijdje niet. En toen kwam ik tot de realisatie van ja, oh, wacht even. Mijn doel is ondertussen wel bereikt. Ik zat in een trein waar iedereen op een laptop of op een telefoon of op een tablet zat werken. Nou weet ik waar mijn jeuk vandaan komt. Ik moet iets nieuwsgijven zinnen, want dit is al klaar. Ja, dat klopt. Ja, dat is wel, ja, het is overal, zeg maar. Je hoeft niet meer te bewijzen, zeg maar, dat. Nee, je hoeft niet meer te bewijzen dat de computer een handig ding is en dat daar de toekomst ligt. Dat station zijn we ondertussen al ruim schood gepasseerd. Een aantal jaar geleden al. Toen had ik zoiets van oké. Ja, dat is zeker grappig, want mijn DK geloofde tegen dat toen ik op Haarvoest zat. Zeg ik van ja, ik wil of piloot worden of ik wil iets met computers gaan doen of programmeren. En mijn DK zei toen van ja, maar weet je dat wel zeker? Want ik weet niet of dat wel iets te verdienen is. Het zit aan mijn toekomst, denk ik. Ja, precies. Toen zei ik, oké, maar ik wil het toch, zeg maar. Ik ga het gewoon doen. Ja, precies. En dat is echt heel bijzonder als je achteraf dat bekijkt. En het zal misschien zijn dat er, dat ben ik helemaal niet bewust, zeg maar. Of toen was ik me toen helemaal niet van bewust dat er misschien een crisis was of zo. En dat er heel weinig, dat er heel veel mensen, zeg maar, thuis zaten om een of andere reden. Weet ik niet. Dat die daarom zei van, dat moet je maar niet doen. Maar ja, achteraf gezien dacht ik ook zo. Dat is alleen maar gegroeid en harder gegaan. Dus dat was wel een bijzonder, bijzonder advies. Ik heb nog een blauwe maandag mij gezitten te vervelen op een MTS. En een van de dingen die ik daar gedaan heb, is het hele computerlokaal ingericht. En aangesloten en gezorgd dat alles werkte. De computerdocent uitgelegd, hoe een computer werkte. En toen ben ik daar bij die school maar weg gegaan. Toen was het wel klaar. Ja, ja. Het was niet heel compatible met de school. Nee, nee, dat snap ik. Jeffrey, hoe ben jij begonnen met... Ja, dat zat ik me net even af te vragen, want je gaf dit al aan in de aankondiging. Ik weet niet meer precies hoe. Ik weet alleen dat ik, denk ik, naar de middelbare school ging. En ik weet nog dat ik daar elektrotechniek als deelfak had. Dus dacht ik, wat ga ik hierna nou nog doen? En toen eigenlijk, ja, ik vind computers eigenlijk wel leuk gewoon. Het gamen aanzeggen, wat ik niet overigens heel intensief doe. Dat is niet mijn ding. Ja, en ik ben er gewoon een beetje ingerold of zo. Ja, niet echt een hele bewuste keus. Dus toen ben ik gewoon gaan studeren om software ontwikkelaar te worden. Ja, ja, wel die kant op. En toen kon je daar weer een deelfak. Dus ik heb ook echt computers in en uit elkaar gehaald. En softwarevakken gehad. En steeds verder daarin doorgegroeid eigenlijk gewoon. Dus het was niet echt een bewuste keus. Ik wilde gewoon iets met computers doen. Wat ik dat leuk vond, maar nog niet echt een richting. En nou ja, langzaamaan kwam het zover. En ik denk de eerste programmeeropdracht was denk ik op mijn, tijdens mijn studie. Volgens mij moesten we een examen doen of zo ervoor. Met een stoplicht hier. En je snapt natuurlijk wel dat stoplicht hier was wel vrij snel gemaakt. Dus hadden we ook gewoon een soort backdoor gemaakt. Met z'n allen in dat lokaal, om dan maar te chatten met elkaar. Dat was dan in ieder geval nog leuker, want het stoplichten was iets te eenvoudig. Dus dat was wel, ja dat was denk ik ook rond de MZ-tijd en zo. Een beetje die hoek. Oh ja. Oh ja, dat is iets later dan denk ik. Ja, ik ben iets jonger in dat gezicht. En ja, zo eigenlijk doorgegaan gewoon in dat germijn. En nou ja, tot de dag van vandaag gewoon lekker software ontwikkelen. Ja, nu is het gewoon niet weg te denken. Dat is een beetje raar om nog te kunnen zeggen, er zijn geen softwareontwikkelaars meer nodig. Dat kan gewoon niet meer. Ik denk dat toen ik studeerde was het nog, de mobiele telefoon was natuurlijk wel niet in dezelfde vorm als dat die nu is. Dus echt apps op telefoon was misschien net, zeg maar. Echt net net, maar niet zoals het hedendaag is met alle technieken die we tegen de dag kennen. Ik had toen denk ik in één van de eerste telefoons Java applets of ja, wat is het? JMSE, Java Mobile Standard Edition ofzo kan dat. Ja, draaide op een Siemens-telefoon. Echt gewoon een zwarte schermpje. Ja, dat ga ik software nooit gedaan trouwens. Nooit in doorgebroken? Nee, nee. Maar dat was ook wel bijzonder, dat was wel een beperking natuurlijk, maar goed, je kon als Java opdraaien. Dat vond ik op zich wel stoer, zeg maar. Maar goed, maar dat software ontwikkeling dat blijft, dat gaat niet meer weg, zeg ik nu, totdat de machines komen. Dan is het afgelopen. Maar goed, dat duurt nog even. Die draaien ook op software. Ja, maar dan hebben ze ons niet meer nodig misschien. Maar goed, dat komt wel goed. Ja, we gingen het over Angular hebben en ja, we kunnen het op allerlei manieren aanvliegen. Angular is er al best wel lang. Ik denk dat als de luisteraar die zal altijd wel, zou gek zijn als je Angular niet kent. Dus bijna iedereen kent inmiddels Angular. Het is ook al best wel lang in een andere vorm, zeg maar, natuurlijk, sowieso. Angular.js is vanaf 2009 beschikbaar. Ja, precies. En dat is ook eigenlijk waar ik wilde beginnen, zeg maar. Kijk, we gaan niet de hele geschiedenis van web development toe, maar op een bepaalde moment is er een noodzaak geweest om wat betere software, laten we het maar even noemen, te gebruiken om front-end applicaties te maken. Want er kwam een wens dat het wat rijker werd en wat complexer, zeg maar. JQA is toen heel populair in de hele tijd geweest. Dat leidde tot heel vaak tot spaghetti, zeg maar. Dus dat was mijn ervaring. Laagdrempelig, maar goed, of dat nou betere software veroorzaakt. Ja, dan moest je wel heel gedisciplineerd. Ja, voor die tijd was het een hele grote evolutie, denk ik. Ja, ja, het was ook, zeg maar, JavaScript was voor me heel veel mensen best wel eng. En JQA heeft dat wat toegankelijk. Toegankelijker gemaakt, ja, zeker. Nou, wat JQA deed was de verschillen tussen browsers eigenlijk wegkoepsen, zodat je in een uniforme API had. En dat is eigenlijk nog maar een paar jaren overbodig. Nog niet zo heel lang. Maar dat was de verdiensten van JQA. JQA was een API-layer eigenlijk op toppen van de browsers. En het was net van nooit een daadwerkelijk library. Het was geen framework. Het was nooit bedoeld voor de dingen die er naderhand mee gebouwd zijn. En dat bleek ook uit de software die eruit voortkwam. Ja, klopt. Dat zien we op de dag van vandaag nog wel eens. Ja, ja. Ja, maar ook gewoon wat lastig is soms is dat dan mensen, ja, dat is niet per se erg omdat je dan gewoon gewend bent, dat mensen op een, ik noem het even, een JQA-manier met Angular of React of whatever, en op die manier gaan programmeren. Dat is best wel lastig, zeg maar. Als je dat soort code tegenkomt, dan denk ik, oh crap, dan moet dat heel veel, moet dat best wel... Ja, dat gaat weer veel tijd in zitten. Ja, ja, dat moet best wel gereffecteerd worden. Soms weet je niet wat er gebeurt, heeft iemand op een andere manier iets geïnpermenteerd. Maar goed, dat was allemaal nog tot Angular, zeg maar, de originele Angular.js, zei je al. Ja, in die tijd was er volgens mij ook Ember, kan dat? Ja, volgens mij kwam die net ietsjes later. Ik denk net iets later. Je zat toen in de fase waar je knock-out en backbone... Ja, backbone en knock-out. Die kwamen toen een beetje in opkomst en die losten een deel van het probleem op, maar niet het hele probleem. En Angular was eigenlijk het eerste framework wat met een echt complete oplossing kwam, zodat je in de browser gewoon een applicatie vrij makkelijk op kon zetten met een paar, met twee of drie geregels code. En dan had je gewoon een werkende applicatie. Maar dat was een hele simpele applicatie. Maar het werkte. The Hello World werkte. Ja, The Hello World was daardoor eigenlijk zonder code zelfs te doen. Je kon een klein stukje HTML met dingen erin. En dat werkte. En dat was in alle andere frameworks had je daar gewoon tientallen lijnen code voor nodig, minimaal. En niet de meest leesbare code. Nee, dat klopt. Ja, goed, dat was de originele Angular. En dat is ontwikkeld door... Bij Google, toch? Of is dat... Het is volledig binnen Google ontwikkeld. Ja, in eerste instantie als een site-project, maar al heel snel zei de baas van het team van hey, dit is wel heel handig dat we hier echt iets van maken. Ja, in eerste instantie door Minko en Mishko, zeg maar, die zijn dat begonnen. Of Mishko was degene die het begonnen had. Chaos hadden door elkaar, maar die was volgens mij begonnen. En dat is steeds meer geëvalueerd. En toen kwam er ook een team omheen, binnen Google, omdat de waarde ervan gezien werd, in ieder geval binnen het Google-team. Ja, ja, ondertussen draaien er ruim 3000 Angular-applicaties alleen al binnen Google. Ja, ja, precies. Ja, ja, ja. Ja, dan is het wel een serieus verhaal. Dan test je ook je eigen software ook. Ja, ja, dat doen ze continu ook. Als er iets mis is, dan voel je de pijn zelf tenminste ook. Ja, dat is leuk dat je dat zegt, want ik weet niet of je weet hoe het Angular-team werkt. Het Angular-team, als ze een release gaan doen, dan moeten ze het eerst testen op alle interne software van Google. Alles. En als er binnen Google iets breekt, kunnen ze het niet releaseen. Sterker nog, ze moeten het ook zelf weer oplossen. Ja, ja. Dus het Angular-team, dat er hedendaars zit, is gewoon verantwoordelijk voor heel Google in dat opzicht, waar alle Angular-componenten in zitten. Dus als zij een change doen, en ze maken een breaking-change, en er valt iets om, dan zegt Google, los het dan ook maar op voor iedereen. Want anders moet iedereen aan het werk. Ja, sowieso. En je voelt die pijn. En je gaat ook zorgen dat je beter kwaliteitcontrole doet, zeg maar, voordat je een release zomaar de wereld in hoort. Nou, en ik denk dat dat een van de sterke punten is van Angular. Dat je, als je met Angular gaat werken, weet je zeker dat je een goed getest, enterprise-ready framework tot je beschikking hebt, waar je eigenlijk geen zorgen hoeft te maken over het framework of dat daar rare bugs in zitten. Ja, dat is echt belangrijk. Daar wil je wel aardig van uit kunnen gaan. En dan moet je nog steeds zeggen, het is gratis, zeg maar. Dus dat is wel een ding, zeg maar. Ja, nou, tegenwoordig vind ik dat zo vanzelfsprekend dat ik dat niet eens meer... Nee, dat begrijp ik, want inmiddels zijn heel veel... Eigenlijk alle libraries die een beetje te grote, zeg maar, die zijn allemaal wel gratis. Alleen, het was niet vanzelfsprekend. Het was nooit vanzelfsprekend, nee. Maar ik ben zelf... In het verleden heb ik altijd met closed source gewerkt en ik werd er op een gegeven moment zo voorzienlijk moe en ziek van dat ik gezegd heb, dat gaat me niet meer gebeuren. En toen ben ik overgestapt naar alles wat ik bouw, gaat volledig met open source. En die beslissing had ik al genomen voordat Angular een ding was. Ja, ja, precies. Omdat, ja, als je afhankelijk bent van een leverancier van een bepaalde tool om je werk te kunnen doen en die leverancier laat je in de kou staan met wat dan ook, dan heb je een probleem, want dan kan je het niet zelf oplossen. Bij open source kan je zeggen van, hey, ik heb dit probleem. En als het echt nodig is, dan kan je het zelf oplossen en eventueel een pierre doen van, hey, dit is toch een probleem. Ja, precies. Ja, of desno's huur je iemand in, weet ik veel, die dan voor jou het oplost. Maar dan weet je in ieder geval dat je erbij kunt, zeg maar. Zet er niet een andere agenda op in belang van whatever. Dus dat is wel een pluspunt. En het is ook wel, ik moet wel, denk ik wel weer, zeggen dat het helpt wel dat er een groot bedrijf achter een library of een framework staat. Want dat helpt. Ja, dat zijn dus wat je net ook zei, die kwaliteit. Google kan dat makkelijker doen dan dat, stel dat ik nu een start-up begin en geen library X, zeg maar. Saber framework. Maar dat is voor je naam trouwens. Ja, precies. Die is waarschijnlijk al bezet. Ja, maar dat is toch niet helemaal, kijk, de grootste frameworks die we kennen zijn React en Angular en die komen allebei van grote bedrijven naar. Maar er is ook nog zoiets als Vue, dat door iemand is gemaakt op zijn zolderkamer in zijn vrije tijd. Ja, dat klopt. Het kan wel. Ja, ja, zeker. Nou, daar ben ik ook blij om, zeg maar. Dus dat dat wel die innovatie of dat die mogelijkheid er is, want het is een beetje jammer dat alles uit grote bedrijven moet komen, want ik kan niet zeggen dat is altijd vanuit hun belang, maar het is misschien ook fijn dat er ook buiten iets gebeurt. Ik dacht ook trouwens dat Vue ook iets met Angular of Google ofzo. Ja, volgens mij de originele oprichter van Vue of de bedenker die heeft een, nou ja, en hoe lang de periode, weet ik niet, maar een soort van blauwe maandag in het Angular team gezeten en die was het in bepaalde manieren niet eens met iets. Geen idee wat, exact. En toen is die Vue begonnen. Ja, oké. Ja. Was dat niet dat andere Vreemdborg van... Ja, dat is een andere, dat klopt. Die, god, nou mag ik die nou vergeten. Dat is niet heel erg succesvol geworden. Er zaten best wel hele mooie uitgangspunten in. Hoe heet dat nou? Die heeft toen aan de Vue rennering, zeg maar, van Angular 2, dus de opvolger heeft die toen... Is dat niet Cycle geworden? Is dat niet Cycle? Nee. Nee. Maar goed, die heeft toen aan die rennering gewerkt. Ik kan er ook niet op komen. Niet opeens gekomen, of ja, de binding, of weet ik veel, of 2-way binding, whatever, niet uitgekomen. Toen is hij, zeg maar... Ja, die library was hij al begonnen, volgens mij, maar toen is hij eruit gestopt en heeft hij dat... Hij kon er niet over eens worden. Nou, dat kan gewoon gebeuren. Dat kan dus in open source of Teams. Zoals dat. Dus op zich... Ik ben... Dat is irritant. Ik kijk of ik er zo meteen op kom. Dat doen we gewoon in die show note. Ja, precies. Ja, alles erbij zetten. Ik kan het er nog in knippen, maar dat ga ik niet doen. Even kijken. Maar goed, dat is Angular. Dat is vanuit... De historie. De historie, ja. Vanuit Google is dat begonnen. Groter en groter. Heel veel, ja, steeds meer applicatie waarschijnlijk binnen Google die het opgingen pakken. En het is wel... Voor mij ging het in één keer heel hard, zeg maar. Want in één keer alles van Angular leek het. In de AngularJS-tijd? Ja, ja, precies. Ja, sorry. Ja, dat is goed om even voor de luisteraar te refereren. Ja, dat zeker. Klopt. Ja, op een gegeven moment aan het eind van de AngularJS-periode ging het heel hard. En toen was alles zo'n beetje AngularJS. En daar kwam wat weer op stuiten op. En toen zijn wat andere mensen andere dingen gaan doen. Onder andere het Angular-team. Die zijn Angular begonnen in plaats van AngularJS. Ik denk dat het goed is. Want op dat moment groeide we ook uit wat AngularJS kon bieden. Ja, oké. Met die structuur die er toen lag, zeg maar. Ja, je moet natuurlijk een library of een framework worden altijd gebouwd met de tools die op dat moment beschikbaar zijn. En met de kennis die op dat moment beschikbaar is. En de principes in het AngularJS verhaal waren heel goed. De uitvoering ervan. Daar zaten wat haken in ogen aan. Er zijn mensen die nog gillen nachts wakker worden over een digit cycle. Ik zal verder niet in details gaan. Maar de mensen die weten waar het over gaat. Daar zaten wat inherente problemen aan hoe het framework gestructureerd was. Dat heeft het Angular-team ook gezien en onderkende. Ze zeiden van ja, dit moeten we oplossen. Dat kunnen we niet doen met een simpele upgrade. We gaan iets nieuws maken. Dat is Angular geworden. Of dat nou een gelukkige keus van naam is. Misschien moeten ze een andere naam geven. Ik weet het niet. Na de rand is dat koffiede kijken. Je weet het niet. Ik snap het wel. Dat is heel anders. Bij Microsoft hebben ze ook een handje van om namgeving niet heel goed te doen. Bij Microsoft hebben ze ook een handje van om een compleet nieuw framework uit te zetten en onder dezelfde naam. Dat is hetzelfde. Visual Basic 4 is hetzelfde als Visual Basic 5. Alleen moet je wel alles herschrijven. Van 4 naar 5 vroeger waren die versies best wel heel heftig van 4 naar 5. Je had nog niet echt een cementige versie, maar je wist wel als je van 4 naar 5... Dat is echt wel iets anders. Bijna een ander framework. Met .NET viel dat heel erg mee. .NET Framework. Dus 1, 2, 3, 4 was allemaal een beetje evolutionair. Het idee van .NET Framework dat het alleen maar uit zou breiden. Dat er nooit iets uit zou gaan. Dat is weer het andere. Ja, precies. En toen zijn ze .NET Core begonnen. Dat was het in de nieuwe. We zien nu nieuwe ontwikkelingen. We laten er met de tijd mee gaan. Dat was op zich heel goed uitgespund. Dat heeft Microsoft heel vaak. Dat ze door legacy code en vanuit de community feedback krijgen. Wacht even, nu ga je te hard. Dit moet je terugdraaien. En nu hebben ze .NET Core Samen met .NET Framework is er een nieuwe standaard gekomen. En ze noemen dat nu weer .NET. Dat is echt zwaar irritant. Het was heel fijn om te kunnen googlen op .NET Core. Zodat je weer het onderscheid hebt. En nu is het allemaal weer nieuw. Dat is een beetje vergelijkbaar met wat er met Angular gebeurde. Als je dan geen googlede was, was het niet heel fijn. Dat is inderdaad het grootste probleem. Bijna dezelfde naam. AngularJS versus Angular. Dat is nu niet echt een enorme change. Dat is als je nou iets wil weten over AngularJS, als je toevallig in een project zit wat er dan nog draait, dan zit je nu met het omgekeerde probleem. In het begin was het inderdaad andersom. Je zocht iets over Angular en je vond allerlei inhoud over AngularJS. Maar dat is in de rentinking aan onze business. Ja. Dat wordt misschien makkelijk gedaan. Of ja, makkelijk niet. De consequenties van die naamgeving wordt dan misschien niet altijd ingezien. Maar dat is nu helemaal zo. Het is wat het is. Ja, dat is waar. Maar dat Google is wel belangrijk. Dotnet, zeg maar, als naam, was ook niet fijn op de Google, zeg maar. Dus daar hadden we vroeger altijd, of C-Sharp, zeg maar, dat is ook niet altijd. Dan moest je het of uitschrijven. Je kwam er uiteindelijk wel, maar het was niet de meest handige naamgeving. Nee, dat is heel lastig. Copy-paste-code als je het niet kan vinden. Ja, ja, precies. Dat is wel een ding. Ja, goed. Toen zijn ze dus overgaan naar de nieuwe, de nieuwere versie. Hoe noemden ze het in het begin? Engeler. Wel gewoon Engeler. Ik had het gevoel dat het Engeler 2.0 of zo, maar dat was toch ergens... Engeler 2 is denk ik de meest publiek beschikbare geweest in het begin der tijden, zeg maar, van Engeler. 3 is bewust overgeslagen. Ik weet niet zo meer wat de reden daarvan was. Als je dat wilt weten, kan ik het je wel vertellen. Nou, doe eens. Engeler 2 heeft een redelijk onstabliege start. Engeler 2 heeft een redelijk onstabliege start gehaald. Er waren een aantal beta-versies, waarvan beta op beta gewoon complete breaking changes in zaten. Dus daar waren developers die helemaal op de edge zaten, waren daar niet blij mee, want die wilden gewoon hun werk opnieuw doen. Op een gegeven moment was dat klaar, en toen werd het als Engeler 2, want we hadden natuurlijk Engeler JS, dat was dan 1, en Engeler 2 werd Engeler 2, en dat werd dan verkocht als Just Engeler, maar we begonnen met 2. Toen dat EMAG gereleased was, toen waren er nog wat problemen met de router. En toen kwam de router eigenlijk op een versie 3. Ik snap hem nu, ja. Dus er was een router van versie 3, maar toen kwam er een disquatantie, die zei nou, oké, we gaan naar versie 4 en dan trekken we het recht. En dan lopen we vanaf daar met de semantic versing gewoon lekker door. En toen was denk ik ook het hele Just Engeler helemaal klaar, en was het gewoon weer Engeler zonder Engeler 2, of elke andere bewoording eromheen. Ja, en dit klinkt als een hele lange periode, maar dat valt op zich reuze mee, want ze zit op een release cadence van een half jaar. Dus dat is Engeler 2 als, ik noem het iets erger, in januari en juni was Engeler 3. Dus nu 4 aan de beurt en weer een jaar later, maar Engeler 5 zit ondertussen aan Engeler 13. Ja, klopt, ja, dat zal ik langskomen. Nee, dat is goed, maar dat is wel fijn als je die cadence hebt, want dat helpt ook wel om een beetje te kunnen verwachten wat er nou... Ja, het enige is ze volgen niet echt helemaal als semantic versing, want echte breaking changes zijn er niet tot nauwelijks geweest tussen die versies. Nee, dat klopt, maar ze hebben gewoon eigenlijk een hoofdversie nummer, dus ja, dat zal onder water natuurlijk wel misschien, weet ik veel... Ja, als je heel neurotisch op semantic versioning gaat, dan zeg je weer ja, we releasen deze versie en pas als er breaking changes zijn, dan gaan we naar de volgende versie. Dat is niet een cycle die helemaal precies gevolgd wordt. Nee, klopt. Over het algemeen blijven ze wel vrij strikt aan semantic versioning, alleen die breaking changes ja, als er breaking changes zijn, zijn ze bij een volgende versie, maar er zijn een heleboel versies geweest waar ook geen echte breaking changes in zitten. Ja, dat klopt. Opeens, dat is mijn ervaring dan ook. Er waren ook wel een paar waar ik wel even doorheen gevloekt heb, zeg maar, omdat ik moest upgraden. Leg niet alleen aan Engel, omdat je dan libraries die dan niet geupgraded zijn, blijven hangen. Maar dat hou je met alles. Ja, dat hou je met alles. Ik moet zeggen, ik heb een heleboel projecten door allerlei versies ingetrokken. De meeste breaking changes waren geen breaking changes in Engel, maar in TypeScript of in RxJS, maar voornamelijk in TypeScript. TypeScript doet ook iets van cementingverziening en daar doen ze iets heel bijzonders met cementingverziening. Die kan ik niet helemaal volgen. Ja, ik snap... Ja, goed, dat weet ik ook niet. Andere discussie. Ja, nou ja, goed. Dat is wel interessant, omdat je baseert je wel. TypeScript is harder gegaan dan ik verwacht had, zeg maar. Omarmt, zo moet ik het zeggen. Want omdat je nog meer had coffee script, zeg maar, dat is al een poosje geleden, dat hoor je niet heel veel meer. Vooral aan de noodkant, zeg maar, in Node.js. Was dat eventjes populair? Nooit gesnapt. Ja, nou ja, dat was binnen nood de community. Daar was best wel veel discussie over, zeg maar. Dat weet ik, maar ik heb nooit gesnapt. Waarom maak je een language wide space depending? Ja, maar Python, ja. Ja, dat, ja. Ja, nou ja, goed. Het is weer populair geworden. Dus er zijn mensen die vinden het fijn en anderen niet, ja. Dus daar snap ik, zeg maar, maar goed. Het is... Controvers, zeg maar, binnen de... Dus nog niet eens in de fronten, zeg maar, maar in de noodcommunity van, ja, moet je dat wel doen? Mag je libraries aanbieden met coffee script of niet? Dat ontstond, zeg maar. Maar met TypeScript is dat anders gegaan. Ik bedoel, het is toch... Het komt uit de Microsoft koker. Dus ik had vanuit mezelf zoiets van, oké, dat wordt lastig, want mensen hebben meteen een vooroordeel of een oordeel over wat Microsoft ontwikkelt. Want dan denken ze, oké, het is wel open source, maar wat is jullie agenda nu? Wat ga je ermee doen? Gelukkig is dat goed gegaan. En steeds meer drijvers en bedrijvers... Daar heeft het Angular-team ook een behoorlijk betekenis in gehad. Op de eerste instantie gingen ze volgens mij ook een eigen TypeScript-achtige language maken. ActScript, inderdaad. Allemaal rond die Angular 2 periode en daarvoor, om een eigen TypeScript te doen. En parallel daar aan was Microsoft bezig. Uiteindelijk zijn ze tot de conclusie hier ook komen. Dan kan Microsoft beter dat doorontwikkelen. En dan ontwikkelen wij Angular gewoon op basis daarvan. Met alle gemak daarvan. En zo is het geëvolueerd. En toen zag je ook de adoptie van TypeScript in andere frameworks of libraries. Zoals React of Vue. Waar het in eerste fase, zeg maar, niet echt aan de orde was. Klopt, ja. Kijk, bij Angular was het echt een keuze. Ja, het was een hele directe keuze. Ja, je gebruikt gewoon TypeScript. En bij React was dat nog niet. Want React had toen, oh, ik wilde Dart zetten, maar dat is het helemaal niet. Tuurlijk. Die had een andere library, zeg maar, Flow. Zeg maar, dat is niet totaal, maar om te kijken over type checking en null references. Die checks konden ze met Flow doen. Daar hebben ze het best lang voor gehouden. En uiteindelijk hebben ze het best lang voor gehouden. Ja, dat was het. Ja. Ja. Ja. Ja. Ja. Ja. Ja, het was zoekende. Ja. Dus dat is wel volwassener geworden. Het blijft ontwikkelen. Dat is op zich wel positief. Ze nemen het serieus. Dat is fijn. Het is niet uit Band-Away. Ik weet niet of je Silverlight kent. Ja, goed. Iedereen kent Flash, Silverlight. Laten we over de schutting gooien. Dat stoppen we mee. En zo heeft Microsoft er wel een handje van om een aantal technologieën heel erg als Silver Bullet, zeg maar, neer te zetten. En dan uiteindelijk na een jaar of 4 of 5, geen succes, overboorten. Dat is toch wel jammer. Maar dat is met dit meegevallen. Maar goed, die keuze is binnen Angular gemaakt. Wat voor keuze zijn er nog meer, zeg maar, geweest bij Angular 2, die echt het onderscheid van de AngularJS hebben gemaakt. Zijn er meer, typescript is één daarvan, zeg maar. Nou, ik denk dat er niet zozeer andere keuzes zijn gemaakt. Ze zijn alleen bewuster en beter gemaakt. In AngularJS had je ook een soort van modules. En je had een soort van dependency injection. Maar dat was een soort van. In Angular had je echt dependency injection. Wat in AngularJS had je Rootscope. En dat was eigenlijk gewoon een enorme global waar iedereen van alles aan ophing. Wat dus voor geen meter werkte. Want we weten allemaal dat global's moet je niet gebruiken. Maar als er zijn, dan plakken we er alles aan vast, want dan kan het. Daar hebben ze in Angular echt heel erg afscheid van genomen. Daar is gewoon geen mogelijkheid meer toe. Om dat soort code te schrijven. Ze hebben beter de barrières geforceerd tussen de componenten, tussen de directives. Dus alles is veel meer op zichzelf staand geworden. Dat is de ontwikkeling. En dat gaat langzamerzegend door. Ik denk dat je als je iets met Angular hebt gedaan, heb je vast wel iets van Ivy gehoord. Dat is zeg maar weer de doorontwikkeling van hetzelfde principe. Ja, klopt. En ik denk ook dat het ecosysteem Angular aan zich ook gewoon een stuk geëvolueerd is. Waar je voorheen upgrade guides had in AngularJS fase van ga deze stap door en dat soort dingen te maken. Dat hebben ze in de eerste fase ook wel een beetje gehad. Maar ze hebben nu ook echt CLI tooling die gewoon je helpt bij upgrade situaties. En dat noemen ze binnen Angular bijvoorbeeld schematics. Hoe je dat een beetje kan zien is een soort van blauwdruk van deze changes moet je gaan doen binnen je code. En die kan je gewoon uitvoeren. Dus een upgrade is niks anders dan een paar commando's in je CLI. De meeste edge cases zijn wel al uit zeg maar. En dat in het begin was dat natuurlijk wat vaker dat dat niet per definitie goed ging. Maar ik kan je nu vertellen dat als er een nieuwe release is dat je gewoon de volgende dag eigenlijk ook kan upgraden. Alle changes die onder water er al in hebben gezeten. En dat is niet alleen een package update. Dat is ook gewoon fysieke code die ergens staat in je project. En dat is denk ik ook wel een groot verschil ten opzichte van nou ja in ieder geval andere frameworks dat je dus zo'n relatief eenvoudig upgrade scenario hebt. Dus dat je gewoon kan zeggen oké ja ik upgrade het en ik ga ook nog kijken of dat mijn third party dependencies dan ook nog gecompatibel ermee zijn. Want dat is altijd lastig natuurlijk. Daar hebben we het net eigenlijk al over gehad. En als dat zo is dan ben je al gewoon in die nieuwe versie. Dan kan je gewoon meteen al door met de latest release of de release waar je heen wil natuurlijk. En alle stappen om code changes te doen hoef je niet meer handmatig te doen. Dat is gewoon weg geautomatiseerd in basis. En dat is wel heel erg nifty denk ik voor developers. Ik denk dat Angular inderdaad het is niet alleen een framework. Het is niet alleen iets wat je in de browser stopt. Het is echt een ecosysteem. Het is een ecosysteem maar ook vanuit het team is er een enorme focus op tooling en developer experience. En dat merk je ik ken geen andere library of framework wat een dermate versie van tooling heeft. Dat als jij een upgrade doet en ze hebben iets veranderd zodat je het links moet zetten in plaats van rechts dat je zegt doe een upgrade en die gaat door jouw code heen en maakt die upgrade. En dat is wat schematics voor je kunnen doen. En dat is als het Angular een breaking change heeft dan maken ze dus een schematic erbij die automatisch jouw code update. En daar wordt wel eens overeen geklansed van ja, Angular heeft goede tooling. Ja, dat klopt. Ze hebben goede tooling. Maar dat komt ook van datzelfde verhaal vandaan van hey, we hebben die 3000 projecten die we up to date moeten houden. Dat is met Hans niet te doen. Nee, precies, ja. Dus daar hebben ze echt wel goed over nagedacht. Je ziet ook dat doordat ze dat doen, de adoptie bij populaire third parties, ik noem er even een paar, Angerix, deels ook Scully, daar zie je dat ook gebeuren. Toevoegen van een nieuw project, hoe je dat moet opzetten met een third party is ook weer een commando. En als daar bepaalde schematics in zitten dan heb je meteen al de blauwdruk van dat onderdeel wat je nodig gaat hebben, dat het dan misschien net even iets anders moet in jouw situatie. Natuurlijk, ik denk dat we dat allemaal herkennen. Maar een update, je ziet gewoon welke update je moet doen van al je third parties. En die voelt je ook uit. En omdat iedereen weer leunt op het ecosysteem, zeg maar, wat ze gecreëerd hebben, worden die migraties steeds eenvoudiger. Een typescript migratie, een jest tooling migratie, als dat nodig is omdat de configuratie parameters veranderd zijn, wat nog wel eens gebeurt. Het wordt allemaal een stuk eenvoudiger. Nee, klopt. Maar goed, die code analysis, zeg maar, die zit daar ook dus bij. En zeg maar, is het ook zo dat als je eigen code, zeg maar, is dat omdat je je code op een bepaalde manier structureert? Of je houdt je aan bepaalde guidelines? Je hebt niet zo heel veel keuze. Als je Engels schrijft, dan gaat je code automatisch in een bepaald stramien en je gebruikt dependency in Jax en je gebruikt component in directives. En dat staat allemaal redelijk strak vastgelegd hoe je dat gaat gebruiken. De restrictie, Engel komt met een aantal restricties en restricties zijn niet een slecht ding. Restricties zijn een goed ding. En dat houdt in dat als ze iets gaan veranderen in dat systeem, dat ze weten van oké, het komt van dit en het gaat naar dat. En dat kan je met een AST-analyse kan je dat zien. Oké, dan analyseren we de AST en schrijven de update terug. En dat is ook precies wat ze doen. Ja, vandaar precies, want dan kun je die analyseren en dan kun je ook zeggen oké, deze upgrade heeft deze impact of hier moet je dit is. Precies. En een aantal van die schematics waar we nu over hebben doen zelfs updates voor third-party libraries. Ja, wat jij net ook zei. Ja, klopt. RxDS wordt gebruikt door Engeler en er zijn breaking changes geweest van 5c5 naar versie 6, van versie 6 naar versie 7. Een Engeler developer heeft daar geen boodschap aan, want die doet gewoon ng-update. Tada! En dan is het klaar. Ja, precies. En dan kan het zijn dat je hier en daar nog eens een kleinigheidje aan moet passen, maar over het algemeen als ik bij een oud project aan kom en ik moet het gaan upgraden naar iets nieuws, ben ik met een paar uur klaar. Ja, ja, precies. En dat is dus, dan ga ik oké, ik kom hier nu bij een Engeler versie 7. Oeh, dat is wel heel oud. Misschien wel anderhalf 2 jaar. Heel oud. En dan, ja, eigenlijk een uur later heb ik hem op versie 13 zitten. Nou heb ik het al een paar keer gedaan, dus ik weet waar ik op moet letten. De truc is wel, je gaat van 7 naar 8, van 8 naar 9. Je gaat stap voor stap. Je kan in één keer, maar als je van stap tot stap gaat, weet je zeker dat al die upgrades ook gewoon correct gebeuren. Een goede tip voor de luisteraar, dat, om dat inderdaad te doen. Als je dat niet doet, dan zie je gewoon wel eens net even wat gekke dingen. Dus doe het stap voor stap. Ga van versie naar versie. Major version, overigens, niet de minors en echt de major versions, goed om even te benoemen. En dan loads de schematics, het ecosysteem engelen hier wel doorheen. Ja, want versie 7 weet van versie 6 hoe die eruit ziet. En versie 8 weet van versie 7 hoe die eruit ziet. Dus dan gaan al die upgrades gaan ook goed. Het zal een beetje pushen zijn dat 14 ook nog eens weet van 6, zeg maar. Nee, die kenners supporten maximaal min 2 versies. Engelen zeggen van supporten de huidige versie min 2. Wat ik nog steeds een hele vreemde keuze vind. Het is ook wel lastig als je libraryhouder bent, maar goed, dat is de keuze die ze gemaakt hebben. En ja, er valt wat voor. Ja, maar er kan misschien zijn om de flexibiliteit aan te bieden aan bedrijven, zeg maar, om dan een keer niet een versie mee te gaan ofzo. Ik weet het niet en misschien is dat de reden. Nee, dat is inderdaad ook de reden. Maar wat support is, is de huidige versie en de versie daarvoor en de versie daarna. Dus de laatste 3 versies zijn de actuele. Alles wat daarvoor zit, is compleet unsupported. Als jij nog op een versie, we zitten nu op 13, als jij nog op versie 10 zit, dan als je een probleem hebt, ja, zoek het maar uit. En daar valt iets over te zeggen. Ja, maar ik zit op 10. Ja, dan moet je upgraden naar 11. Ja, maar dat kan niet, want ik heb een third party. Sorry, ga naar die third party en zeg dat ze de boel moeten updaten. Ja, dat zie je heel vaak in libraries, in issues zeg maar van libraries op github. Deze versie is nog niet geupgraded. Oké, natuurlijk is het lastig. Het blijft nog steeds. Kijk, voor grote bedrijven, bedrijven die achter een open source project zitten, die kunnen dat misschien tijd voor brengen. Maar als jij een wat kleinere team hebt, misschien een eentje, is het soms lastiger, kan ik me voorstellen. Soms kan ik me voorstellen, ja, dat krijg je. Heel veel mensen die open source hebben gewerkt, die hebben wel eens een niet slapeloze nachtroom, die ergeren zich daar best wel aan, dat mensen eisen dat zeg maar. Dat kun je bijna niet, je kunt niet eisen. Je moet blij zijn dat die library er is. En mensen, soms is het gewoon best effort. Je kunt niet altijd... 24 uur in de dag? Er zitten maar 24 uur in de dag. Als ik zo iemand krijg die een eist, dan zeg ik van oh, doe maar een PR. Ja, dat doen tegenwoordig mensen wel. Dat was niet zo standaard. Nee, maar ontwikkelaars zijn niet per se communicatief of hebben niet per se altijd de voelsprieten, zeg maar, om te weten wat voor impact iets is. Dus als je zegt, ik wil morgen dat hebben, dat iemand anders dat niet per se goed oppakt, dat merk je gewoon. En het is hetzelfde dat als jij boos bent op iemand en je stuurt een mail, is het anders dan dat je erheen loopt en gewoon even praat met iemand. Dus dat is natuurlijk met zo'n issue, ja, je bent misschien heel je woede zeg maar, in die issue aan het pompen. Dan dat als jij die persoon in het echt ziet, ja, dan zou je waarschijnlijk anders zeggen. Dan moet ik zeggen, we hadden het eerder al over community. Ga eens in de Angular issues kijken. Als iemand daar inderdaad, niet alleen Angular, maar ook in alle libraries die eraan verbonden zitten, ga eens in de issues kijken. Daar is iedereen over het algemeen behoorlijk beleefd. En als er iemand zit van ja, maar ik wil zo ASAP, een oplossing, dan wordt er wel gezegd van nou ja, is prima, jongen, we zijn te huur. Ja, ja, precies. Nee, nee, natuurlijk, maar dat is bij Angular zelf maar goed, in het algemeen gebeurt dat nog wel. Er zijn echt wel mensen die... Ja, ja, je ziet het heel veel bij libraries als je in de GitHub issues zit, dat er gewoon echt, nou, er nog net niet gescholden of zelfs wel gescholden wordt. En dan denk ik van ja, jongens, hallo, je gebruikt deze software gratis. Ja, helemaal goed. En niemand staat je in de weg om een PR te maken? Nee, en niemand staat je in de weg om zelf het proberen. Ja, tuurlijk. Dat is wat de normale, zeg maar, dat is een goede reactie, zeg maar, erop. Of dat had je kunnen verwachten, maar heel veel mensen zijn gewoon gebruikers. Ja, die zoeken gewoon de oplossing op dat moment. Ja, en dan gaan ze schelden, want ja, misschien staat ze op zo'n onderdruk, of weet ik veel wat, er moet een release morgen doen. En ja, je krijgt zo'n... Ja, dat. En dat kun je niet verwachten. Er zijn dus best wel wat mensen die open source libraries of frameworks hebben gemaakt, die afgehaakt zijn, van ja, oké, dit is gewoon niet leuk meer. Weet je wat, ik doe dit gewoon omdat ik het leuk vind. Ik krijg daar best veel waardering voor, maar af en toe die negatieve dingen, die hoef ik niet per se te hebben. Dat is dan, ja. Ja, dat is niet alleen in open source. Ik denk dat het overal is waar mensen met elkaar iets moeten doen. Eens, klopt, klopt, klopt. Open source zegt het al, het is open. Dus het is ook in het open, zeg maar, en het zal best wel bij een, weet ik veel, noem maar eens iets, een Facebook of een ander bedrijf zal het intern misschien ook gebeuren, weet ik niet. Ja, er zijn wel Facebookpagina's waar het gewoon ook op gebeurt. Ja, ja, ja. Nee, het gebeurt gewoon overal in de samenleving. Wat ik eigenlijk probeerde te zeggen is dat als je in de Engel community gaat kijken, dat dit soort uitwassen, daadwerkelijk uitwassen zijn. Dat ze er bijna niet zijn. De Engel community is enorm vriendelijk en enorm verwelkomend en ze zullen je altijd proberen te helpen als dat mogelijk is. Ja, ja, precies. Dat lijkt me, dat is gewoon de beste manier om dat te doen. Je zei, RxJS, dat is een van de onderdelen die gebruikt worden door Angular. Kunnen jullie dat beschrijven wat het doet of is dat... RxJS is een library, en het is daadwerkelijk wel een library, die ervoor is om event streams te managen. En dan oversimplificeer ik het een beetje. Het doet meer, maar je hebt eigenlijk een... Er is zo'n fraai vierkant van, oké, ik heb één instans wat ik synchroon wil behandelen, ik heb één instans wat ik A-synchroon wil behandelen, ik heb een stream events. Wat is... Ik mis er één. En je hebt dan een event dat meerdere veren voor kan komen en wat je op een andere manier kan behandelen. Ik mis één kant. Ja, die komt wel weer. En RxJS is precies voor die omissie, want voor de één heb je een promise, voor de ander heb je gewoon een callback. Maar RxJS voorziet in die vierde, waar je een stream hebt van meerdere omissies en waar je de heleboel kan composeen. Dat is eigenlijk de sterke kant. RxJS is voor iemand die graag functioneel wil programmeren, een uitkomst, omdat het eigenlijk volledig functioneel programmeren is. Ja, ja, precies. Oké, en dat heeft geholpen, zeg maar, ja, ten eerste dat ik mee maak, dat die keuze niet zomaar gemaakt is, zeg maar. Die keuze is niet zomaar gemaakt. Ik heb daar behoorlijk vermoedde stechelen om het erin te krijgen. Er is een behoorlijke discussie aan vooraf gegaan voordat het erin ging en het kwam er naar mate in, voornamelijk in op dat je weet wat een promise is. Een promise was niet cancelable tot voor kort. Maar als je een HTTP request wilt doen en je wilt dat cancelen, de HTTP ik weet niet eens meer hoe het heet. Die kan je daadwerkelijk cancelen. Maar als je dat in een promise word hebt, dan kan je hem opeens niet meer cancelen, dan gaat die er altijd uit. En dat is bij één request meestal niet zo'n probleem. Maar als je tientallen requesters uitgooit en je zegt van oh, maar ik heb die hele informatie niet meer nodig, dan wil je die kunnen cancelen. Je wilt niet al dat verkeer op het netwerk hebben. En observables, RxJS, die kan je cancelen. Als je dan zegt van oh, ik unsubscrib, ik heb die niet meer nodig, dan wordt het keurig netjes opgeruimd en alle uitgaande requests worden gewoon afgestopt. En dat is de reden dat het in HTTP is gekomen en dat is de reden dat het bijvoorbeeld in de router wordt gebruikt, want de router is ook ongoing. En als je niet meer geïnteresseerd bent, dan sluit gewoon je ding af en dan wordt dat allemaal keurig afgehandeld. RxJS is event streams on steroids. Ja, precies. Je zei al dat ze composable zijn. Maar goed, er zit een learning toetjes. Mijn ervaring, dat is los nog van Angular, maar ook met Angular natuurlijk, want dan kom je er gewoon niet naar. Er zit wel een learning curve aan. Die learning curve heeft is gewoon omdat je echt moet weten hoe asynchroniteit werkt. En dat terwijl RxJS niet eens asynchron is, want het werkt prima synchron. Maar je moet het hele concept van asynchroniteit en synchroniteit goed begrijpen. En dan nog de library zelf begrijpen. Welke delen je eruit moet halen. RxJS leunt natuurlijk op operators om bepaalde onderdelen te doen in zo'n stream. Dus als er een stream plaatsvindt, het pakketje komt voorbij, ja, wat gaan we dan doen? Oh, nee, ik wil van pakketje A moeten de naam veranderen. Daar hebben ze allemaal operators voor. En die moet je ook nog eens weten. Dus ja, je moet het concept weten inderdaad, maar je moet ook nog weten hoe de library en welke onderdelen er dan echt inzitten om de toepassing die je wilt gaan programmeren goed te gebruiken. Ja, precies. Maar goed, daar zijn heel veel voorbeelden voor. Nee, neem ik aan. Ja, meer dan genoeg. En de documentatie is tegenwoordig van ArcGIS ook heel erg goed op orde. Dus de meeste mensen komen daar wel vrij goed uit. Ja, je moet er wel goed, maar het is niet effe, ik rush er even in en ik ga het effe... Nou, ik denk niet, de meeste mensen zullen het niet in een uurtje herkennen. Nee, daarom. Het kwartje moet erin zitten, dat is mijn ervaring. Het duurt effe voor dat het kwartje goed valt. Het kwartje moet vallen en je moet ook de use case hebben. Ik was op het moment dat ik Rx ontdekte, wat overigens ver voor Engeler zelf was, had ik zoiets van, oh, maar dit lost voor mij een use case op. Dit is een probleem waar ik regelmatig tegen aanloop en dat wordt door deze library opgelost. En het principe van de observable, en dan heb ik het niet eens over RxJaspen, gewoon het pattern, het observable pattern, dat lost een probleem voor mij op. En vandaar dat ik het gelijk kon plaatsen en ik geloof dat ik mijn eerste RxJ in 2013 heb gedaan. Oké. Of iets later, maar in ieder geval lang geleden. Ja, ja, precies, want het is even kijken, want Rx staat voor reactive programming, zeg maar. Het is niet react program, maar reactive, zeg maar, dat is wel een heel belangrijke. Want volgens mij is er, ik weet niet eens, in dotnet heb je dus ieder platform het. Ja, dat meen ik wel, want volgens mij is het door Bart Smet. Erik Meijer of Bart Smet? Ja, Bart Smet is in België. Erik Meijer klopt, ja. Met de funky shirt. Ik weet niet of je wel eens gezien hebt. Het is door Erik Meijer is het bedacht. Volgens mij is er als eerste een Proof of Concept gemaakt in JavaScript. Daarna geïmplementeerd in dotnet, volgens mij, of een andere Microsoft taal. En laterhand is het opnieuw geschreven in JavaScript en overigens naar TypeScript. Ja, klopt. Ik heb er vanaf het begin al van al meegespeeld. Ja, precies. Dat is wel heel lang geleden. Een oud collega van mij die had toen een keer laten zien dat ze de muis, de stream en de mouse bewegen. En dan kun je het eventueel laten vertragen. Of laten skippen. Dus al die operators die liet hij toen zien. Dat is wel impressive, zeg maar. En dat was trouwens wel JavaScript toen. En aan de .net kant zijn ook mensen die er helemaal weg van zijn. Ik moet eerlijk zeggen dat er minder... Het gebeurt niet zo veel meer in de backend, zeg maar. In de .net kant, denk ik. Ik denk dat het volgens mij is E-Link er ook op gebaseerd. Maar ik weet niet genoeg van E-Link. Ja, ja, ja. Ik heb daar één talk van. Dat is wel Bartersmet, zeg maar. Die leggen er toen uit, zeg maar, dat het eigenlijk ook reactive was. Supergaaf. Als je dan sessies hebt van Microsoft, dan was het heel vaak dat je 9 van de 10 sessies bij zo'n conference... Soms is het 30% marketing. Soms is het wel kennis. Maar dan is het best wel starter, zeg maar. Level 100. Ja, precies. En toen kwam er één keer die van Bartersmet. Oh, wacht, nu moet ik even opletten. Dit is 400. Ja, precies. En dat was echt een hele dikke 400. Toen dacht ik wel, op het moment dat ik het niet verwacht, dat is niet irritant. Toen dat ik me ingesteld op iets anders, ik denk, ja, dat komt wel goed. Het kan niet moeilijk zijn. Maar dat was echt wel een hele goede sessie. Toen lag wel die link, zeg maar, met reactive programming. Maar ik heb daar verder toen niet mee verdiepen. Ik ben pas weer echt in gaan verdiepen, zeg maar. Toen ik met Angular, nee, niet twee, vijf, weer in aanraken kwam. Toen moest ik wel... Het is een mooi model, zeg maar, even heel simpel gezegd. Het is inderdaad RxJS en Dobserver. Het model is vrij lastig te begrijpen. Ik kwam daarachter op het moment dat ik mijn eerste RxJS-stalk deed voor een zaal met AngularJS developers, want Angular was nog geen ding. En ik in twee minuten een complete blanke zaal had. En ik had zoiets van, oh, ik ben net begonnen en ik ga al zo langzaam. Ze hebben nu tegenwoordig die grafische, hoe heet die, charts? Dus dan kun je zien. Die marble, ja, precies. Ja, dat is wel echt wel nice. Ook wel logisch dat dat kan, maar goed, je moet er maar even op komen. Dus dat is wel een toevoerde waarde. De CLI van de HarderGnet, ook al over, dat is best wel een sterk iets, zeg maar, vanuit Angular. Zijn het dingen die echt gewoon eruit springen, of zijn er nog nieuwe ontwikkelingen in dat gebied? Of is dat gewoon steeds evolutie, er komt af en toe eens een keer iets bij? Of? Het laatste wat ze hebben gedaan, ze leunen heel erg op Webpack natuurlijk onder water nog, en daar zijn ze nu bezig om dat open te zetten naar ES Build. Oké, wel ja. Ja, dus daar zijn ze al aan begonnen. En dan moet ik even goed zeggen, het is volgens mij op het, ja, zo noemen we dat de Build Optimizer, dus eigenlijk de optimalisatie van de code zelf, dat werd voorheen door een bepaalde Webpack Tool Link gedaan, ik weet niet meer precies hoe die heet, en dat doen ze nu met ES Build. En volgens mij de CS6 zeg ik uit mijn hoofd ook, dat het nu inmiddels door ES Build gaat. De CLI zit nog best vast aan Webpack, maar ze zijn daar langzamer of zeker inderdaad wel afscheid aan het nemen. Maar als een gebruiker merk je daar eigenlijk niks van, behalve dan dat het steeds sneller wordt. Ja, ja, precies. Performance wise is het nu volgens mij 20% sneller sinds 2013, want 2013 is dan de officiële versie waar dat dan echt in gemaakt is, en daar zitten nu ook concepten in als caching, dus dat je een build gecached wordt en dat die begrijpt dat als je in component B iets aanpast, dat die niet component A opnieuw hoeft te rebuilden. Overigens is het een Webpack cache. Ja, dat klopt, dat klopt. Maar die adoptie is er wel en je ziet ook dat de mensen die zoals een ES Build graag willen gebruiken, dat die adoptie er ook is. En overigens, als je dat echt zou willen, je kan ook gewoon de hele Webpack stream er uit gooien, maar dan moet je je eigen builders maken, want dat is nog weer een ander concept. En daar zie ik ook wel de eerste Proof of Concepts voorbij komen om dat te doen. Dus dat ze alleen maar ES Builden gaan doen, maar dat zijn gewoon open source projecten, is nog niet specifiek iets door Angular zelf gemaakt. Hoe heet dat? Wat was er niet? Een Java iets? Wat was dat nou? Dat is een component dat niet persé in JavaScript draaide, maar taal X, die ook iets zo optimaliseren. Dat is ES Build. ES Build is in Go geschreven. Is het ES Build, nee, Go. Een van de toelings is inderdaad in Go of in Rust geschreven, en die compileert TypeScript sneller als TypeScript. Ja, dat zie je steeds meer gebeuren, want in het eerst om ons te vragen, moeten we dat wel doen, want compatibility, dat weet ik veel te allemaal, maar je ziet dat Go en Rust steeds vaker voorkomen in dat build, omdat de build soms best lang kan duren. Dat is met alle JavaScript, TypeScript, JavaScript. Dus dat zijn wel goede ontwikkelingen. Dan is er ook iets als Angular Core. Wat zit daarin? Het is de kern, maar wat betekent dat dan? Dat betekent eigenlijk alleen dat dat de basislibrary, daar heb ik het inderdaad over, een library van Angular is, waar niet een compiler meer in zit, want die zit ondertussen niet meer in de Core, maar waar de basis onderdelen van Angular in zitten, die je nodig hebt in de browser. Nou, klinkt Core als dat is één groot ding wat ik altijd moet deliveren. Dat is niet zo. Angular is zo gebuilt dat alles wat je gebruikt geinclude wordt en de rest wordt getrishaked. Daar wordt heel erg strikt aangekeken. Als er iets toegevoegd wordt, is het reshakable, kan het door de tooling verwijderd worden. En als jij de router niet gebruikt, nou is de router een eigen package, maar zou die erin zitten? Zou je die niet gebruiken? Nee, gebruik een eigen, dan is dat prima, ook al heb je hem als dependency ergens in je packagefaal zitten, dan wordt die gewoon eruit gehaald. Maar Core is niet iets waar een Angular developer mee bezig is, die importeren gewoon de dingen die ze nodig hebben en de tooling zorgt er eigenlijk voor dat je niet meer shipt als wat je nodig hebt. Dat wil niet zeggen dat je maar blindfoldert alles, moet gaan lopen en included wat je ook maar nodig denkt te hebben. Maar dat is altijd wel zo. Ja, dat is altijd wel zo. Helaas gebeurt het ook nog weleens zo hier en daar. Ik kom zo hier en daar weleens een enterpriseprojectje tegen. Hey, wat is het payload? Oh, 20 megabyte aan scripts. Ja, ja, dat klopt. En dat is volgens mij nou, daar schrik ik nog niet eens om, want dat zijn we soms echt wel. Ja, ze zijn soms nog wat groter, zeg maar. Het was niet de tree shaker. Ik had nu iets waar ik dacht, ja, dat haak er al op in, maar goed, dat maakt niet uit. Maar goed, dat is core, dat is gewoon een given, zeg maar. Ja, dat is de bundle, zeg maar, waar de de basis noodzakelijden voor Engel in zitten. En je hebt er een paar, maar core zit er echt de basis, basis noodzakelijden in. Je hebt natuurlijk ook een package zoals de router, je hebt een package zoals HTTP. De common heb je ook nog. Ja, de common, daar zitten dan de standaard, voornamelijk de standaard componenten en directives. De NGA of de NG4. Maar als je ze niet gebruikt heb je, ja, dan kan je ze er ook uit laten. We konden het zeggen, ja, dat lijkt me... Als je iets bouwt, heb je altijd zoiets van ja, is dit core? Ja, oké. Je moet het ergens, op een gegeven moment moet je ergens een beslissing maken. Eh, even kijken. Ja, qua beelden, het wordt gebuilt, dus uiteindelijk omdat het JavaScript is. Sorry, TypeScript. Je build het en dan komt uiteindelijk JavaScript uit wat dan draait in een browser. Zijn daar nog speciale dingen voor? Of is dat bijvoorbeeld om te zorgen dat, ja, dat zal waarschijnlijk in je tuning zitten om te zorgen dat het zo compatible mogelijk is met zoveel mogelijk browsers of of is dat een uitbesteed iets wat door AS build eigenlijk gebeurt? Nee, daar wordt met het bouwen van Angular, wordt daar terdegerekening mee gehouden. Angular 13 is een maand, twee maanden, uit denk ik? Ja, ik denk twee maanden is ongeveer. Twee maanden en de grootste verdienste van Angular 13 is NoMoreEA. Oh ja, ja, dat is wel dus die ligt er uiteindelijk uit. Er wordt nu eigenlijk alleen alle Ladies Greatest. Ja, Ladies Greatest, min 2. Min 2, ja. Oké, dus de, hoe heet dat? De browsers, de laatste twee versies afslaren? Ja, de laatste twee Chrome's, de laatste twee Firefox, de laatste twee Safari's, de laatste twee Edge's, ja, wat hetzelfde is als Chrome, nog. Ja, het gebeurt nu wel ja, ik weet niet waarom dat gebeurt, want ik dacht ook van die engine is in principe hetzelfde, maar soms zijn er toch dingetjes die dan niet werken in Edge. Ik weet niet hoe ik dat voor elkaar heb gekregen. Maar, nee, maar die snap ik ja, dus het is een beetje Evergreen, min 2. Ja, dat is ook wel logisch. En dat kun je mogelijk ook instellen, of niet? Want dat is volgens mij... Er is een instelling voor, er is, je kan dat natuurlijk niet instellen voor Angular, Angular Support, al die dingen, maar je hebt de browser RC file en daar kan je zeggen van nou, ik wil alleen maar de laatste van Chrome of ik wil alleen maar Chrome. Of een hele specifieke versie van Firefox, omdat je dat zo graag wil. Ja, precies. Ja, omdat in een bepaalde enterprise zitten ze daarop vast. Overigens wordt dat door de tooling wel herkend en dan zal Angular de tooling daarop aanpassen. Ja, onder water wordt dat aangepast. Dat is nice. Dus als jij zegt, ik bouw alleen maar voor Firefox, dan wordt alleen Firefox dingen gedaan. Alleen de Firefox dingen gedaan. In zover dat dat kan. Bij het compileren bedoel je dus. Ja, ja, ja. Oké, ik snap hem. Ja, dat is wel heel erg, dat is trouwens wel heel fijn. Ja, en de jaarschap wordt misschien iets kleiner soms. Dat is het voornamelijk. Ja, nou ja, nou we geen IA meer hebben. Schilt het niet zo heel veel meer. Mijn eerste vraag toen ze met versie 2 uitkwamen was, gaan we dan geen IA meer supporten? Dat hebben ze wel gedaan. Dat hebben ze wel gedaan, tegen mijn wil in. Soms krijg ik niet meer zin. Soms wel, maar niet altijd. Ja, dat is waar. Dat is heel irritant. Ja, IA is wel... Ik wil niet heel lang over... Nee, laten we niet te lang over IA praten. Het is wel een interessant gegeven. IA was volgens mij de eerste serieuze browser voor Mac. Dat is heel raar, want dat is toen IA... 580, ik bedoel, met 5X, volgens mij 55 ofzo. Dat is een versie die op Mac beter zichzelf verhield aan standaarden, CSS-standaarden, dan de IA op een Microsoft, op Windows, zeg maar. Omdat dat 10 was anders. Oh ja, laten we ons wel een beetje aan de regels houden, zeg maar. Terwijl dat andere IA-10, dat was berucht. We hebben veel gevloekt, zeg maar. Toen voor IA... 5 was het al, en 6 was... Die versie is er heel lang geweest, zeg maar. Was niet leuk, zeg maar. Dat is echt... De selectboxen, de drop-downs, die waren echt... hell, zeg maar. Ik was echt blij als het toen. Toen was Chrome volgens mij nog niet eens heel erg aan de orde. Firefox had je toen als alternatief, daar was ik heel blij mee. En toen Chrome kwam was ik heel erg blij, want dat het een beetje... dat er een beetje concurrentie was aan een goede browser als alternatief. Nou, er waren in die tijd wel meer goede browsers, hoor. Ik heb toen een heleboel, in die tijd maakte ik ook al applicaties, maar dan zei ik meestal tegen mijn klanten van ik gebruik deze browser. Ja, ja, ja. Ik heb een hele tijd Firefox geïnstalleerd voor mijn klanten. Zeg, oké, deze applicatie werkt bij Firefox, of deze applicatie werkt met Opera. Opera was ook heel lang een van de betere browsers. Ja, ja, dat klopt. Je had ook Opera Mobile, dat was best wel een sterkte. Je had ook nog Mini, volgens mij. Ja, dat was Opera Mini. Die heb ik nog wel eens op Setupboxen gezet voor je tv. Was Mini degene die rennen de server ergens anders? Ja, ja. Ja, dat voelde ik op zich een mooi concept. Ik denk privacy-technisch dat het tegenwoordig lastiger wordt. Ja, ik weet niet wat ze tegenwoordig doen. Volgens mij werkt het nog steeds. Ja, dat gaat zeker nog ergens werken, absoluut. Ja, ze hebben volgens mij een shift gemaakt dat ze een andere engine zijn gaan gebruiken. Volgens mij niet meer die van zichzelf. Nee, ze zijn overgestapt naar de engine die Chrom ook gebruikt. Chromium. Dat is een beetje jammer. Ze hadden hun eigen engine en die was gewoon echt heel erg goed. Maar ja, Opera was natuurlijk niet een heel groot team en die zijn toen aangesloten bij het Blink team. Volgens mij Blink is dat van jou? Ja, nu wel. Ja, klopt. Ja, dat klopt. Het was ooit KDE. De browser van KDE is degene die toen met Apple volgens mij ontwikkeld is. Dat is een beetje de engine die waar Chrom, zeg maar, toen nog gebaseerd had. Nu zijn ze uit elkaar en dat is helemaal uit elkaar gegroeid. Dus dat vond ik op zich stoer dat het uit KDE kwam. Dat vond ik alweer. Hoe heette dat ding? Nou, ik ben even die naam vergeten. Maar ik voelde het sowieso moedig dat iemand zei oké, ik maak een andere browser. Want het was omdat er vroeger was het echt closed-door. Je had Netscape, InterXplore, Opera en wat had je nou meer? Er waren er niet heel persoonlijk heel veel. Nee, er waren er niet veel in muziek. Ja, dat was er daarvoor nog. En dat het gratis was, was al een ding. Bij Netscape was het altijd een beetje van ja, dat is een soort van trial-achtig. Ik weet niet, dat licentiemodel was altijd zo vaag. Iedereen had gewoon Netscape. Daar zitten we aan vast. Daar krijgen we nog de rekening van. Dat was echt wel bijzonder. Ja, Netscape was volgens mij de eerste versies was het shareware. Ja, precies, dat ja. Dat was toen nog een concept. En dan kon je het proberen voor het tijdje. En als je het dan echt leuk vond dan werd je geacht ervoor te gaan betalen. Volgens mij deed helemaal niemand dat. Maar volgens mij is het altijd shareware gebleven. Wel, oké. Maar waren er dan niet enterprise-versies ooit geweest? Dat dachten we dat er wel was. Dat je dan wel een versie kon hebben waar dan daar zat een scriptaal in of zoiets. Iets met Java. Script. Ja, dat is wel een goed idee. Toen bewust als marketing technisch was het toch de naam gekozen. Ja, Java-spoorplet heeft helemaal niks met Java te maken. Java staat tot Javascript als car staat tot Carpet. Ja, precies, ja. Ja, nee, dat is wel gaaf. Mooi, man, dat mijn laptop dan even zegt, hey, weet je wat, ik ga lekker. Gewoon, waarom je dat doet? Dat is een mech, he? Een mech denkt voor zichzelf. De DevTools zie ik je staan. DevTools, wat moet ik aan het denken? De Angular DevTools voor in je browser. Oh, wel. AngularJS, die had dit ook al. Veel mensen weten niet zo goed, eigenlijk, dat er ook gewoon een nieuwe versie is van de Angular DevTools. Dus de AngularJS had een DevTools voor in je browser ingeromen, Firefox en al die dingen, om gewoon te zien development time, hoe bepaalde components gerendert waren, welke properties erop zaten, welke values erin zaten, nou ja, et cetera, et cetera. Die kunnen ook on the fly aanpassen. Die is er ook een hele tijd niet geweest voor de nieuwe Angular versie, zeg maar. En ik denk, versie acht, twijfel ik even? Nou, rond, in ieder geval rond acht of tien. Iets in die in die zaken is het weer geïntroduceerd. Ook door volgens mij hetzelfde team wat toen de tijd ook voor AngularJS developte. Voor Angular 3 was er al een package, maar dat was van een externe team. En die hebben dat toen ontwikkeld en die hadden het op een gegeven moment, denk ik, niet zo heel veel tijd meer voor. Dus toen is dat verwaterd en bij de nieuwe versies van Angular werkte dat niet meer. En met versie 12 hebben ze volgens mij de band, heeft het Angular team de banden aangehaald met dat team. En hebben ze samen verder ontwikkeld en hebben ze gezorgd dat de devtools nu weer helemaal up-to-date en specifisch zijn en dan kan je gewoon je Angular applicatie, als die in dev mode draait, kan je gewoon al je componenten openen, je kan je properties of je componenten, je kan de input zien, je kan er ook dingen tegenaan gooien, je kan zeggen als ik hier nou een boelje in gooi in plaats van een nummer, wat gebeurt er dan? Dat soort dingen, dat vind ik wel, ik moet eerlijk zeggen dat ik niet per se, soms doe ik nog steeds Angular, mist ik het in eerste instantie niet, maar toen ik weer met Vue werkte, dacht ik oh ja daar zit die in, reactor heeft er zeg maar een, dus ik dacht oké, nou goed het zal wel, maar dat hij dan weer terug is gekocht, devtools. Is dat niet alleen reduxting? Nee, het zijn wel devtools ja. Je kunt de state zien zeg maar, en de componenten die onder elkaar, de vader-kind-relatie als het ware, en dan zie je de state. Dus dat doet, ja, reactor ook, maar in principe is dat best logisch zeg maar. Nou, de ene vindt dat fijner dan de andere, want de andere in de console kan je nog best al weer wat dingen, dus dat is natuurlijk ook nog maar de ervaring. Dat ligt ook wel van je ervaring. Ik gebruik een enkele keer de devtools van Angular, maar meestal ga ik gewoon gelijk naar de console. Soms is het nog handiger als je echt profiles wil draaien, dus performance dingen, want die zitten standaard in. Oh, oké. Performance profiling is veel beter, veel makkelijker in de devtools van Angular, omdat je alleen kijkt naar die gooi je zeg maar alle bulk die uit de browser komt, en uit het framework zelf gooi je ze weg. Die laten zien, nou dit kost dit componenten tijd. Dus dat is inderdaad wel heel prettig. Ja, dus dat is ook wel, daarom is het ook goed om even te benoemen, denk ik, dat de mensen ook gewoon die tool gebruiken, op het moment dat performance problemen bijvoorbeeld een rol spelen. Ja, dan is het heel helpvol. Ja, of je even wat wilt testen, ik bedoel gewoon inderdaad een string, een boelie, wat gebeurt er dan allemaal precies, als voorbeeld. Dan zijn dit soort tools gewoon heel handig om even in je browser te hebben. Ja, ik schrijf nooit bugs, dus ik heb die dingen nooit nodig. Oh, heel gek. Haha, want dan ben jij. Dan moet je zometeen inleisten, dit is de bugvrije developer. Dat is wel cool, ja. Uh, uh, statement, sorry? Ik wou dat het een vraag was. Ja, nee, ik bedoel, één regel is het voor mij al moeilijk. Nee, nee, nee. Iedereen schrijft bugs. Dat is los van, misschien is de use case veranderd, dan ontstaat er gewoon een bug, of je hebt ergens niet aan aangetijden. Dus dat is verder geen rare iets, dus je moet... Was dat een hondje? Ja, ik hoorde ook een hond ergens. Ik dacht dat... Je eerste kantoor aan de linkerkant. Echt waar? Oké. Ja, nou toch, zeg maar een... hoe noemen we dat? Sideway. Sideway, ja, niet de segway. In het Nederlands twalem af. Heel veel mensen zeggen, ja, je moet je hond gewoon uitwerken. Snap ik dat jij dat wil, maar sommige andere mensen die hebben zoiets van, ik vind honden niet fijn. Dus dat... Ik ben niet helemaal over uit of je nou je hond altijd mee naar je werk moet nemen. Ik had een oude collega van, misschien een verhaal een keer eerder verteld, zal wel, dan moet je het maar mee doen. Dat hondje voelt mij gewoon heel erg leuk. En ik heb niks tegen. Ik ben niet bang of zo van honden of zo. Maar ik was uit werk en dat hondje zat heel... Kev, kev, kev. Oké. Niet nu, zeg maar. In mijn pauze vind ik het op zich ook... Ik ben net m'n buk aan het maken. Ja precies, het is gewoon een extra afleiding. Dat hoeft niet, zeg maar. Ik kan nog genoeg bugs van mezelf schrijven. Ik heb geen hulp benodigd. Dus iedereen van, oh, dat is zo'n lieve hondje. Dat snap ik. Maar niet in deze kamer. Ja precies, in mijn vrije tijd. Ik ben uit werk. Dat is een beetje doorgegaan. Dat zie je hier ook wel, dat de werkomgeving moet heel leuk zijn, snap ik. Je moet ook werken, zeg maar. Op een gegeven moment was er een trend dat overal stonden flippenkasten, pingpongtafels, alles was maar leuk. Kijk, glijbanen, noem maar maar op. Ja, ik snap dat het leuk moet zijn. Maar aan de andere kant denk ik ook van ja, het moet een environment zijn waar je goed kunt ontwikkelen en dat je ook af en toe even pauseert en even iets anders doet. Maar het is niet alleen maar een speeltuin. Maar je had het volgens mij over state management. Daar begin je... Nou, dat wilde ik over gaan beginnen. Ja, ik kan twee maanden hier wat doen. De staat van werkplaatsen. Te veel afleiding werkt niet. Ja, side effects. Dat is niet heel handig. Ik kan het op twee manieren doen. We hebben over Skully en Jamstack of eerst over state management. Dan mogen jullie kiezen. Misschien kunnen we even kort state management aantippen. Want binnen de Engelijk community is state management altijd best wel een ding. Je ziet daar een aantal verschillende open source projecten voor die heel goed zijn denk ik voor bepaalde toepassingen. Maar je ziet ook dat die vrij snel geadopteerd worden. Ja, binnen Engelijk projecten. En wat bedoel ik daarmee? We beginnen een project en we moeten daar meteen een state management library in hangen. En dat is denk ik wel iets wat niet zo is. En daar zijn wij beide wel redelijk sterk in. Dus dat je dat eigenlijk helemaal niet per definitie hebt in Angular zelf. Want Angular heeft gewoon services. En services kunnen gewoon je state manager in welke vorm dan ook. En dat verschilt natuurlijk. En wanneer heb je het wel nodig is waarschijnlijk een hele grote enterprise applicatie over meerdere teams die allemaal een klein stukje hebben van een domeinmodel dergelijke. En misschien ook dan nog wel websockets hebben die alle data als het ware pushen. Maar in andere cases zien wij het in ieder geval redelijk dat je met een paar services in de basis er gewoon wel uitkomt. En als je daar goed naar kijkt dan kan je het concept subject as a services is vrij bekend binnen Angular. Ik weet niet hoe dat in een andere community is. Maar dan leun je weer op RxCS, observable pattern om eigenlijk je state te manageren. Dat kan je allemaal namelijk gewoon in een service. Oké, ja. Dat is de manier eigenlijk. Dat is de standaardmanier. Nou, dat zou de standaardmanier moeten zijn. Helaas wordt er heel vaak al direct naar een management library gegrepen. En dat is heel vaak inderdaad gewoon, oké, laten we een klom gaan halen, want we hebben een mug. Ja, oké. Ik snap hem. Die discussie die is... Ik weet niet hoe die is. Jij komt meer uit de React. Ik weet niet hoe die discussie daar is. Nu moet ik eerlijk zijn. Kijk, als je mij vraagt de laatste ja, wat ik gedaan heb. Ja, dan is het viewer Angular. Nu iets meer view dan Angular. Daarvoor React. Die discussie is bij alle drie een beetje. React werd ook heel snel gezegd, oké, doe maar Redux of MobX. Terwijl die hebben we ook te gast gehad, de MobX-man, die zei ook, dat hoeft niet. Zeker met de nieuwe APIs, zeg maar. Zou je dat niet hoeven? Anders moet je die state iedere keer doorgeven naar kinderen. Dat hoeft nu niet, want je hebt nu een context library. Ik heb daar een itch bij, omdat ik dan eindelijk een soort van global state ga creëren. En dan denk ik, oké, maar er is geen contract tussen de vader-kind. Dus je weet niet wat je kunt verwachten. Je moet dan maar weten, er zit iets in die context. Die kan ik op een bepaalde manier ophalen. Ja, maar dat is, de meeste state libraries, die maken één globaal groot ding, wat meestal store heet. Ja, precies. En alles wordt in een globaal ding gegooid. En dat is mijn grote bezwaar ook. Je mist de koppeling tussen je business logic en je localiteit. Je bent hier bezig met een tabel te maken van het een of het ander. En daar zal een service bij horen. En die service zal de business logic moeten bepalen. Maar state management krijg je heel vaak dat je business logic niet meer in je component zit en zelfs niet meer in je service zit, maar die zit in allerlei stukjes verdeeld door je hele applicatie. En er zit een stukje van je business logic in de effects. Er zit een stukje van je business logic in de reducers. Er zit een stukje van je business logic in... Iets anders. En de hele logica kan je niet meer gewoon van boven naar beneden lezen. Je moet op jacht naar alle stukjes. Ja, precies dat. Plus een extra complexiteit voor, nou ja, ik noem het maar even juniors of medias of mensen die gewoon niet deze concepten goed kennen en dus ook niet weten waar ze in een project naar moeten kijken. Ik denk iemand die al dertig keer zo'n project heeft gedaan, die zal meteen snappen waar al de onderdelen zijn, zeg maar. Maar dat is helemaal niet nodig. Ja, maar dat is dan wel op basis van kijk, dan kijk je... Dat is een basis van ervaring. Ja, maar in een conventie zeg maar. Stel dat je bijvoorbeeld, nou goed, dan spreek ik even over React en dan Redux. Dan, er zijn er ergens best practices afgesproken ofzo, en dan verwacht je dingen daar in, dan op die manier georganiseerd en dan weet je op die manier, oké, zo moet je dat doen, maar dat is niet ergens iets... Ja, dat kan wel. Je code analyzers kun je dan waarschijnlijk nog wel iets bovenwaard krijgen, maar daar zit geen tooling achter ofzo, of er wordt door typering van TypeScript wordt iets afgedwongen. En dat is toch, ja, ik weet niet of dat... Bij MobX heb ik veel te weinig ervaring mee. Volgens mij is bij MobX dat iets beter in elkaar. Dus dat vind ik een nadeel, zeg maar, van die manier hoe dat bijvoorbeeld in React zit. View heeft hoe heet dat, in ViewX is eigenlijk een beetje het vergelijkbaar met Redux en eigenlijk al die... Ja, trouwens, het is, hoe heet dat, de architectuurstijl was toen bij Facebook ooit een keer zo'n soort van... Ja, daar komt het vandaan. Ja. En daar is ViewX een beetje op gebaseerd. Dus het lijkt een beetje op Redux en ook een beetje weer niet. Dus daar zit... Sommige dingen denk je, oké, ja, dit snap ik, het is handig, maar ja, waarom? Bij ViewX... Bij ViewX was er hier redelijk snel naar ViewX gewezen, dus niet zozeer Het probleem met dit soort oplossingen is heel vaak dat er wordt naar geweest, heb je dat probleem, of heb je een probleem wat daar ook maar vakelijk op lijkt, dat is de oplossing. Ja, precies. En het grote probleem met heel veel van deze oplossingen is dat ze de kennis, de business logic die je nodig hebt om een probleem op te lossen, dispersen door een heel aantal verhaals heen. Ja. Als ik over iets daarna wil denken, wil ik eigenlijk alles bij elkaar hebben. Ja, ja. Dan is mijn mentale overheid veel meer geconcentreerd op het probleem. Als ik een service schrijf en ik doe business logic, dan heb ik het allemaal bij elkaar. Ja, oké. Als ik mijn business logic moet oplossen in een redux of in een wat van ook, dan, oké, dan moet ik erover nadenken, oké, dit stukje, dit hoort een reduzer te zijn en dit stukje, dit hoort een action te zijn en dit stukje hoort een dingetje te zijn en een action hoort daar en een reduzer hoort daar en dat ding. En alle kennis die je nodig hebt om dat probleem op te lossen, die wordt verspreid, uit elkaar getrokken en allerlei verschillende stukjes gestopt. En dat weet je op het moment dat je er aan het doen bent. Kom je twee maanden later terug bij hetzelfde probleem en dan ga je al die stukjes moet je weer bij elkaar gaan harken en dan moet je er weer één geheel van maken mentaal en dat is zo'n enorme mentale overheid. Dat is niet te onderschatten. Dat kost je gewoon een uur minstens extra. Dus ik denk Angular State equals service. Ik denk dat dat een beetje de samenhang is van dit. Dat is sowieso vanuit jullie zeg maar. Er zijn libraries die een andere manier... Er zijn een heleboel mensen die daar compleet anders over denken. En ik heb altijd zoiets van die komen wel bij. Als ze lang genoeg hiermee gewerkt hebben dan valt niet zoveel anders als tot een vergelijkbare conclusie te komen. Je moet over code nadenken op een manier dat maintainable is. En hoe hou je iets maintainable? Door alle kennis te concentreren op één plek. En op het moment dat jij een global gaat... Dat is ook de reden dat we geen globals moeten gebruiken. Op het moment dat je globals gaat gebruiken, verlaat je dat principe. Ja, ja, eens. Het is een technisch aspect. Wat bedoel ik daarmee? Dit zegt niet meteen iets hoe iets functioneel opgelost wordt. Het zegt meer over hoe we gaan technisch state-managemen. En hoe dat dan in verschillende libraries... De ene library zal misschien wel hebben van hier moet je al je business lopen elkaar en dat is dan wat gestructureerder. Je kan dat natuurlijk altijd. Je kan al die dingen in één file stoppen en dan heb je het alsnog bij elkaar. Maar dat is dan meestal niet de best practice voor dat dergetreffende framework. En dan worden de best practices weer gevolgd. Met als gevolg dat je de kennis die je nodig hebt om een probleem aan te pakken of om iets op te lossen dat die gedisperst wordt door je hele applicatie in plaats van dat het centraal bij elkaar staat. En dat is het grote probleem dat ik zie met vrijwel alle state-managements. Oplossingen. En dat is niet specifiek naar één toe. Dat hebben ze bijna allemaal. Ja, nee. Als je kleine applicaties hebt, heb je het niet nodig. Het groeit een keer en het wordt groot. Dan zou je het mogelijk nodig hebben. Ja, dat is tot een bepaalde hoogte waar. Je kan ook zeggen van nou, op het moment dat het groeit, moeten we er eens een keer gaan over praten hoe we hiermee gaan werken en moeten we daar een structuur, een structurele oplossing aan bieden. Een structurele oplossing is niet een library of een je kan ook gewoon interne afspraken maken. Kijk, als wij iets schrijven, als wij een rest functionaliteit hebben, dan maken we daar een basis van onze services zien er zo en zo uit. Ja, ja, ja. Natuurlijk, dat zijn convencies weer. Je kan een convencie binnen je team afspreken. Je hoeft niet convencies te importeren van iemand anders. En dat wordt heel vaak veel te snel gedaan. Ja, nee, kijk, hoe zeg je dit? Makkelijk om te zeggen. It depends, dat wordt al heel vaak gebruikt. Kijk, er is bestaansrecht voor die libraries. Alleen, het is meer zo, je moet de keuze heel goed en je moet ook weten, wat zijn de consequenties daarvan? Dat is vooral en die vind ik lastig, want er wordt gezegd, als een applicatie groter wordt, bijvoorbeeld, of het is wat ik net ook al zei, dan ga je een keer zo'n library erbij halen, maar wat zijn de consequenties? Daar gaat me om. En als die consequenties goed zijn, dan kun je leven. Er wordt veel te weinig gekeken naar de kosten van extra software introduceren in het system. Third parties worden heel makkelijk geïnclude en tot een bepaalde hoogte is dat ook prima. Kijk, als je een third party hebt die één dingetje doet en er zijn vijf third parties die hetzelfde dingetje doen, dan is dat prima, als dat een component is, want dan kan je zeggen, ok, die component weet ik, ik pak een ander component. Maar als dat een third party is die door heel jouw code heen invloed gaat hebben, dan zoals een state management library, dan moet je daar toch echt wel even een stevige discussie over hebben, of in ieder geval over nadenken. En dat stukje even over nadenken, wordt helaas veel te vaak overgeslagen. Nee, dat eens, dat is misschien een ervaring, dat je deels maakt, oh ja, dit componentje doet dat, en misschien trekken al heel veel binnen, mpm install of yarnhead, whatever je gebruikt. Ja, ja, we hebben inderdaad ook nodig, we introduceren moment.js, dat is een goed plan. Hey, waarom is mijn runtime nou ineens drie keer zo groot? Juist, dat soort dingen, dat is echt een heel goed voorbeeld ervan. Dus daar moet je altijd een afweging maken. Ja, en hoe zwaar is zo'n nieuwe library? Goed, Scully, en ik zie hier Jamstack erbij staan, ik weet helemaal niet wat Scully is, en dat ga je mij ook vertellen. Maar je weet wel wat de Jamstack is? Ja. En wat is dat volgend jaar? Oh ja, het is gaan met de headless development, bedoel je dat? Ja? Ja, precies. Nee, dat weet ik. Dat was zal het zo, ik heb één keer bij een intake, kreeg ik de vraag van, hey, kun je me vertellen wat een deadlock is in een database? Oh ja, leuk. Wat het zo'n verplas wedstrijd. Dus toen heb ik het maar heel uitgebreid uitgelegd, en toen dacht ik, oh ja, shit. Nou was ik er verder aan. Ja, precies had ik die moeten doen. Dus dat. Nee, maar Jamstack, ja, dat. Ik wist dus niet dat Scully, zeg maar, R1 is, zeg maar. Kun je dat zo zeggen? Een middel is. Ja, precies, ja. Maar wat doet het, zeg maar, voor de luisteraars? Nou, eerst moeten we, denk ik, een klein beetje uitleggen wat Jamstack is. Jamstack is een manier om je applicatie te distribueren, voornamelijk. En dat maakt, in plaats van dat je één index.js hebt, waar alles, alle pagina's vandaan komen. Ik noem het even pagina's. Je kan het de grouds noemen, je kan het viertjes noemen, wat je wil, maar dat al jouw pagina's komen uit. Eén index.js met de één set JavaScript. Jamstack zegt van, nou, dat is misschien niet zo'n goed idee, want als je iets als SEO wil doen, of je wil andere optomanisaties hebben, of je wil een klant een snelle oplossing bieden, dan is dat misschien niet zo ideaal. We hebben zoiets als wat heet HTML, met alles al netjes ingevuld. En als je dat naar je browser stuurt, dan ziet je gebruiker direct waar het over gaat. En dan hoeft er niet eerst nog JavaScript op te starten en een framework te starten en allerlei andere dingen. En dat is eigenlijk Jamstack. Jamstack pakt een applicatie en maakt een index HTML voor elke pagina die je daarin hebt. Dat houdt in dat je voor SEO een enorme optomanisatie hebt, omdat alle pagina's... Ja, het is gewoon een static site geworden in plaats van een... Indexatie is beter daardoor. Ja, de indexatie is veel beter daardoor. Maar ook de opstarttijd wordt veel sneller, want de gebruiker landt op een pagina en krijgt direct de informatie van de HTML van die pagina, inclusief de CSS, als je het goed opgezet hebt. En dan staat het direct een plaatje en de mensen kunnen dan direct beginnen met lezen en in de achtergrond start dan de applicatie op. Ja. En dat is eigenlijk wat Jamstack is. En dat klinkt heel simpel, maar dat heeft over het algemeen ver vrijstrekkende gevolgen voor hoe je een applicatie beeldt. Ja, klopt. Tenzij je een Angular applicatie hebt en je gaat Scuddy gebruiken, dan krijg je het... Je krijgt het niet helemaal cadeau, maar het is eenvoudig. Het is behoorlijk eenvoudig om dan inderdaad van je applicatie een Jamstack sollicie te maken. Oké. En het werkt dan hoe? Moet ik er iets voor doen? Ik moet Scuddy, zeg maar, include of installeer? We hebben een Scuddy schematic. Je installeert Scuddy. Je doet ng-add scuddio-slash-init. En dan wordt Scuddy voor je geïnstalleerd in je Angular project. En dan kan je in principe npx-scuddy draaien en dan analyseren we jouw applicatie. We extracten al de routers en gaan al die routers omzetten in je dist-folder. Eindetje met een heleboel. Dat zijn pagina's. Static pagina's. Ja. Cool. En als die static pagina opraakt, dus dan gaat die, zeg maar, vanaf wat gebeurt er, zeg maar, als die eenmaal in de brouwer draait, dan gaat die dan? Ja, je krijgt gewoon, het is lastig om dit in het Nederlands te zeggen. Je praat iets te vaak in het Engels. Ja, iets te vaak in het Engels gedaan. De browser komt op de index.html. De gebruiker ziet direct de inhoud van de pagina, want die hebben we al gerenderd, want we wisten wat er kwam te staan. Dus die ziet hij. Die gebruiker begint met lezen. Ondertussen start gewoon je normale spa framework op in de achtergrond. En tegen de tijd dat de gebruiker zover is dat die ergens op gaat klikken, is die applicatie opgestart en is die ready to go en gaat die verder als een normale spa. Ja, precies. Oké, cool. Ja, dat is herkenbaar. Dat is Jamstack wat je net deed. Ja, dat is het wel. Maar goed, dat is wel een goed principe. Maar ik zie je ook dat er een... Wat is het verschil, zeg maar, tussen SSR server-side rendering en Scudy? Er gebeurt iets meer, zeg maar. SSR is server-side rendering, voor de mensen die niet weten wat het is. Dat houdt eigenlijk in dat je hebt een eigen server nodig. Die server hangt aan het internet met alle veiligheidsrisico's van dien. Jouw gebruiker gaat naar jouw server toe. Zegt van nou, ik wil die pagina erbij. Die server gaat die pagina voor jou bouwen en stuurt dan de HTML naar de gebruiker. Ja, precies. Daar heb je dus een server bij nodig. Je moet betalen voor de server. Je moet betalen voor de beveiliging van de server. Je moet die server bouwen. Je moet die server onderhouden. Bij Jamstack maak je... Je rendert de hele groep tijdens de development tijd, of eigenlijk op het moment dat je gaat deployen render je al je pagina's uit. Je upload naar je S3 bucket. het werkt. Klaar. Je hebt geen eigen server nodig. En dat heeft behoorlijke voordelen. Het gaat zelfs nog iets verder. Want je zegt van ja, maar op een gegeven moment is mijn applicatie gestart en dan heb ik waarschijnlijk iets nodig wat heet data. Ik probeer producten te verkopen. Dat zal data voor nodig zijn. Scully geeft je de mogelijkheid om die data te embedden in je HTML. Dat houdt in dat je voor een product pagina alle data die je nodig hebt voor de product kan je embedden in die desbetreffende pagina, zodat je niet naar de product database hoeft als je die pagina start. Dat heeft als bijkomend voordeel dat omdat het geembed is in de pagina is het synchron beschikbaar. Dus als je spa start krijg je niet een enorme flash, maar het staat er meteen. Ja, dat is wel cool. Ja, mooi. En dat hebben jullie gebouwd? Ik heb dat samen met een aantal anderen gebouwd. Ik ben de hoofdengineerde architect, om het zomaar te zeggen. Ik denk dat ik 80 procent van de code geschreven heb. Het is een open source project. Jeffrey werkt er ook aan mee. Het zou grappig zijn geweest dat je denkt, ja, dit is closed source. Dat heb je de hele podcast. Nee, deze doe ik liever niet. Ja, uiteraard. Je kan geen open source doen zonder een stukje closed source. Er zitten een paar ontwikkelingen aan te komen waar wij services gaan bieden voor scully gebruikers in de cloud. En daar zullen stukjes closed source Dus de tool aan zich, die blijft gewoon publiek beschikbaar, maar er zijn een paar enterprise features die het gewoon met name aan de enterprise kant makkelijker maken, sneller maken, eenvoudiger maken, waardoor daar zit een stukje funding is daar gewoon direct voor nodig. Ja, daar zit wel... Maar daar komt ook al het gemak bij, zeg maar. Ja, tuurlijk. Je moet natuurlijk al een... Hoe heet dat? Ik werk voor een bedrijf Herotefs en die sponsoren scully eigenlijk. Het is ook gesponsord door Google, door het Engelerteam zelfs. Dat is wel heel fijn, ja. Dan heb je in ieder geval de goede support. Nou, ja, het is niet een hobbyprojectje, want dit is niet iets wat je als een hobbyprojectje kan maken. Er zit hier van mij zelf al meer dan een jaar werk in. Het is... Maar je hebt de kans dat ze dat, zeg maar, Engel erin trekken, of is dat een beetje raar? Blijft het altijd los van? Het Engelerteam voelt er steeds meer voor om dingen af te stoten in plaats van te interniseren. Tenzij het echt iets is wat heel erg close to de dingen is. Ik weet niet of de concept Rehydration je iets zegt. Dat is iets waar het Engelerteam naar wil gaan kijken. En als ze dat doen, dan ga ik toch eventjes serieus met ze aan tafel zitten. Oh zo, oké. En dan, daar is een enorme overlap in wat we willen. En dan gaan we even kijken hoe dat verder gaat. In Engel er... Nee, ik weet niet. Ik weet niet vanaf ergens. We zitten nu op 14. We gaan nu naar 14. Als 14 is eind dat jaar. Het zal geen 14 worden. Maar volgend jaar. Ik hoop volgend jaar. Maar goed, dat is goed om te weten. En wat nog wel interessant is, want dat is vaak onderbelicht, er is een heel krachtig pluginsystem in. Dus stel dat jij... Engel er zit ook een pluginsystem in. Maar dat is... En wat je daar bijvoorbeeld mee kan is dat je heel specifiek zegt, dat je een bepaalde route hebt. En dat je daar een plugin die je zelf kan maken, maar ook een aantal die gewoon standaard geleverd worden met Skully, kan gebruiken om die pagina's te genereren. De meest simpele vorm is natuurlijk gewoon een blog waar je gewoon een markdown files bijvoorbeeld hebt. En dan zeg je oké, ik heb daar mijn folder. Daar staan markdown files in. Genereren mijn blog daar maar voor. En dat moet op die route. Maar dat kan je natuurlijk ook gewoon met iets doen dat ergens naar een database gaat kijken en daar de informatie vandaan haalt en dan nog een andere database ook aanspreekt om dan daar ook informatie vandaan te halen zonder dat je daadwerkelijk echt die API calls nog moet doen in de spa als het ware. En ja, het maakt niet uit wat het dan meer is, want het is gewoon runtime. Het is gewoon op je machine development time of deployment time hoe je dat ook wil zeggen. En veel mensen weten dat niet. Ja, de blog weten ze omdat het op de website staat en ze weten vaak omdat dan ja, ik wil meer experimenteren. Dat is makkelijk. Maar je kan er veel meer mee dan alleen maar even gewoon blogjes genereren als het ware. Je kan dat gewoon als je e-commerce hebt als het ware gewoon gebruiken om bepaalde onderdelen te automatiseren, dat het gewoon gerenderd wordt. Standard HTML, standard CR6 en dat er een heel klein stukje JavaScript nodig is om die webshop als het ware te gebruiken, noem ik het maar even. Ja, plug-ins zijn de kracht van Scully. We hebben het net over routes ontdekt. Als je een route hebt waar een product ID in zit, dan hebben we een route product slash ID. Als we die gaan renderen, dan hebben we één route. Dat is niet echt heel erg hulpvol. Scully komt bijvoorbeeld met een JSON plug-in. Hier is het endpoint waar mijn product database staat. Dit is de naam van het ID dat je eruit moet halen. Scully gaat voor jou naar die database. Die trekt de hele boel binnen. Die extract ID's en die maakt product ID 1, product ID 2, product 3, product 6.844. En dan maakt hij al die dingen voor. En bedt die data weer in de HTML. Dan wordt het meteen weer... Ja, precies, dat je snel die... Hoe heet dat? Je krijgt snel resultaten... Geen flesjes. Je hebt geen server meer nodig. Je hoeft je product database niet meer aan je openbaar open te stellen. Nee, dat sowieso wel. Dat scheelt of dat je een interne in-house catalog warehouse systeem moet hebben met een of andere API. Op een bepaald moment stel dat ik... Ik weet het niet, hoor. Stel dat ik een miljoen miljard producten in mijn catalog heb gezet. Ergens stopt het met... Je gaat niet alles erin zetten, laat ik het zo zeggen. Dat ligt aan je gebruikscase. Kijk, als je naar bol.com wil, dan wil je toch dat al jouw miljard producten bezoekbaar zijn. Dus dan zul je ze moeten genereren. Maar dit is... Hier hebben we nog geen directe oplossing voor binnen gekomen. Dat is wel een van de volgende dingen. Dat is geen SSHR, maar een Just-In-Time-server. Dat is eigenlijk die zegt van... Ik krijg een URL die ik niet ken. Dan gaan we naar de server. En die doudt die pagina en de CDN. En dan kun je ze nu ook... Dat is even een andere... On the Edge, zeg maar. Dat is op een Edge-computing van... Dat is ook een van de volgende stappen die we in de planning hebben om het op Edge-computing te gaan doen. Maar dat is toch even... Niet direct aan de hoelade. Nee, dat begrijp ik. Maar dat zijn wel dingetjes die je dan... Daar heb ik met het bouwen van security eigenlijk al rekening mee gehouden dat we daar naartoe gaan. Dat we naar Edge-computing gaan. Ja, dat scheelt gewoon. Geld, zeg maar. Even simpel gezegd. Want die bulky servers en performance kan ook nog heel veel uitmaken. Edge-computing kost ook geld. Ja, dit is waar. De hoefte is gewoon echt een statische generatie. En volledig statisch. Daar kan je op elke domme server dat wegknallen en er een CDN voor zetten. En dan kom je in heel land voor heel weinig geld. Maar als je al Edge-functies nodig gaat hebben, dan moet je toch een abonnementje afsluiten bij AWS of... Ja, Cloudflare. AWS is Cloudflare. Nee, nee, dat weet ik. Maar Cloudflare is bovenop AWS. Er zijn er een aantal. Er zijn verschillende spelers die dit soort diensten aanbieden. Netlify. Ja, precies. Ja, ook. Netlify heeft nog geen Edge. Nee, dat is waar. Nee, ze hebben nog geen echte Edge. Vercell begint ermee te komen. Ja, die hebben we... Toen was ik al schattig... Ja, we zijn dan nu... Volgens mij een van onze libraries bij Aviva is zeg maar met Vercell gebouwd. Ze gaan redelijk hardlaken. Ik zou zo zeggen, want er zit nog wel best wel wat funding achter. Ze hebben volgens mij die jongen van... Goh, nou moet de library echt... Nee, dit is niet degene die we eerder hadden. Next.js. Ja, Next.js is gewoon hun core library. Het is niet een Reacting... Hoe heet dat ding? Up-and-coming library. Remix. Nee, nee, nee. Een front-end... God. Quick. Nee. Die wilde ik ook gaan noemen. Geen View, geen React, geen Angular. Maar... Het is een veld. Ja, precies. De lead maintainer, zeg maar, die is nu in dienst bij Versel. Dus dat is wel interessant. Want in principe is de rest gewoon allemaal React. En wat daar gaat gebeuren. Dus op zich doen ze wel interessante dingen. Dat is wel mooi, zeg maar. Dat is door iedere elkaar... Nou ja, goed, er zijn wel eens van die talks. Dat vind ik heel gaaf. Dat er dan iemand van Angular, iemand van een React, Ember en ja, whatever dat was. En dat ze dan ook wel zeggen, oké, we kijken gewoon echt wel naar elkaar. Of oké, er is iets van... Iedereen kijkt naar elkaar. Ja, precies. Overigens, Cully werkt prima samen met Versel en met Netlify. Ik heb twee weken terug, drie weken terug heb ik een sample applicatie op Netlify gezet. Met een 2500 product pagina. Dus niet echt een heel klein voorbeeldje. En dat draait gewoon helemaal in de Netlify server. Nee, nee, precies. Dus dat soort dingen. Dat is gewoon goed dat je dat ook mogelijk maakt. Maar wat ik wil zeggen is, ze kijken ook echt wel naar elkaar. Dat vind ik mooi, zeg maar. Want het is niet alleen maar... Dan kijk ik naar de reacteur. Den Abram of die ken je denk ik. Ja precies. Ja, daar heb ik wel eens... Ja, maar een open... Weet je, best een open vent, zeg maar. Dus die zegt echt wel... Nee, die heeft natuurlijk Redux ooit gemaakt. En die zegt ook in ieder geval, ja, je hoeft niet over Redux te gebruiken. Hij gaat zelfs nog iets verder dan dat. Ja, eens. Other discussion. Ja, precies, dat is een andere discussie. Maar goed, die jongen is wel... Ja, hij staat open voor dingen, zeg maar. Dus dat vind ik echt wel gaaf. En dat is positief, zeg maar, in de... überhaupt in de brede zin van de front-end JavaScript, TypeScript community. Dat het allemaal niet zo heel... Ja, in een hele oorlog is. Natuurlijk is het altijd van, oké, de mijne is beter dan de andere. Of weet je wel, die krijg je altijd wel een keer krijgen. Maar ze kijken echt wel naar elkaar. Ze weten echt wel, de use-case werkt met React misschien iets beter dan met Angular. Dus dat weten ze. Er zijn een aantal dingetjes die voor... Daar leren ze ook van elkaar van, denk ik. Ja, ja, geoptimaliseerd op zijn. En als, mocht er in ieder geval een ontwikkeling zijn, die door, noem eens niet, sveilt, zeg maar, beter werk dan bij de andere, dan zal het misschien mogelijk zijn dat de andere daarop, ja, zich aangepast. Dus... Ik denk dat we in de komende jaren steeds meer naar de Edge gaan. Ja, ja, dat zie je. Nee, dat is zeker klopt. Naar de Edge computer. Dat is de next big thing. En als frameworks zich daar niet... Ready. Ready voor zijn. Als ze daar niet in die omgeving niet voortzienlijk kunnen werken, dan gaan ze dat verliezen. Ja, nee, die beweging, dat zie je zeker. Nee, ik hoopte al dat dat wat sneller, maar goed, dat is even... Ja, ik hoop ook dat dat wat sneller gaat, maar ik heb toevallig gisteren met Alex van het Angular team daar een enige discussie over gehad. Maar die discussie stemde mij hoopvol, had ik het zo gezegd. Ja, oké. Tuurlijk. Dus, ja, dat loopt. Ik denk dat e-commerce, wat je net ook zei, dat is wel een heel sterke driver daarvoor. Dat is althans vanuit ons ook, merk je ook dat dat echt wel helpt. Omdat wij traditioneel, e-commerce vanuit de .net applicatie, gebruiken we nog steeds een CMS, zeg maar. En dan doe je e-commerce erop en het is echt niet per se snel, zeg maar, laat ik het zo zeggen. Ik heb wel eens in dat soort omgevingen gewerkt, ja, het is echt per se niet snel. Juist. En hosten is ook niet goedkoop. Want als je zegt van ja, het maakt niet uit, de Netlify's, de Cloudflare's of AWS kost je geld. Nou, dit is echt even in een paar orders van groot en meer, zeg maar. Dus ik had altijd zo'n onopbijk gevoel aan, van nee, hier moet je vanaf. En Jamstack is natuurlijk al een tijdje, dus ik dacht oké, dit is gewoon de way to go, sowieso. Maar goed, als je een angular applicatie hebt in e-commerce, dan kan je met Scully de Jamstack embracen, en voor het groot gedeelte van je servers af. Je kan natuurlijk nooit 100% van je servers af, want op een gegeven moment moet er ergens een order ingeschoten worden. Dat is de idee van e-commerce. Maar dat zijn sites die met Scully gigantisch goed te maken zijn. Je maakt de keuze mogelijk, even voor jou, want je kunt zeggen van je moet hem ergens inschieten, maar dan kun je nog zeggen, ja, ik ga dat serverless doen met functions, of ik doe dat niet. Ik heb wel een built-in server in de house, dus je krijgt de keuze, terwijl voorheen... Dan zat je vast aan een CMS en de hele rand er omheen. Dat was gewoon één, noem het eigenlijk een monolith, en alles was voor jou gekozen. Je kon er niet vanaf. Dat is met Jamstack heb je de keuze. Ik wil niet zeggen dat je dan niet iets kunt bouwen wat lijkt op de oude manier te zijn aan het steken. Ja, ik zeg dan, je hebt een server nodig, maar je hebt een back-end nodig. Ja, precies. Die kan op de edge leven. Die kan in een serverless functie leven. Of die kan gewoon op een conventionele server ergens. Maar die keuze heb je dus. Ja, precies. Dat zijn goede ontwikkelingen. Laten we eens even kijken. We zijn trouwens best wel aardig onderweg. Een uur en drie kwartier zie ik hier. Volgens mij zijn we ook door het hele lijstje al bijna heen. Nee, maar ik weet nog niet of ik alles ga raken. Want ja, dan kunnen we gewoon nog een uurtje doorgaan. Ja, nou ja, er staat hier een onderwerp Standalone Components. Ik weet niet of we daar heel lang over hoeven te zeggen. Nou, ik denk wel dat het goed is om even aan te tippen. Ja, dat denk ik ook. Want dat is denk ik de nieuwste ontwikkeling, zou je kunnen zeggen, binnen Angular. Kijk, ik denk voor... Jij komt van React. En ik denk dat het altijd toch vreemd is geweest dat je die module moet maken. Want React kent dat helemaal niet. En ook een Vue en alle andere kennen dat eigenlijk niet. Angular is eigenlijk meer gescoopt in dat opzicht dat zo'n module zegt, oké, dit zit er allemaal in, deze components zijn er. En verder kan je ook niet. Dit zijn de restricties. Deze hele module is zo gescoopt op deze manier. Standalone Components is eigenlijk de volgende stap dat je eigenlijk geen modules meer nodig hebt. Dus dat je echt, zoals je dat een beetje kent ook vanuit je React zeg maar, gewoon components kan maken en een component-hierarchie als het ware kan maken in je Angular applicatie. Daar is een hele lange discussie aan vooraf gegaan. Die is ook redelijk publiek gewoon te volgen. En nou, is het een maand of drie, vier geleden dat echt de kogel door de kerk is? Ja, denk ik wel. Ongeveer vier maanden geleden is echt besloten van oké, we gaan dit doen. En dit gaat in een van de aankomende versies komen. En wat betekent dat voor de Angular developer eigenlijk niet zo heel veel wat je nu doet. Kan je gewoon blijven gebruiken, maar je moet gewoon geadopteer. Dus je kan zo dadelijk gewoon een component maken met eventuele services en alles wat je nodig hebt. Zonder dat je daar nog specifiek die modules voor nodig hebt in je project en suite. Dat maakt het ook makkelijker om vooraf van React bijvoorbeeld Angular te gaan doen. Want de manier hoe components zijn, de structuren die daar in frontend framework klanten zijn, die komen dan ook steeds meer overeen. Oké, dat is een interessante ontwikkeling. Ik wil nog even een klein beetje doorgaan over de modules. Want modules zijn een ding in Angular en die doen eigenlijk iets heel vreemds. Want in jouw module bepaal je welke directives en componenten beschikbaar zijn voor jouw component. Dat is heel vreemd. Ik verander hier iets en ik krijg daar iets beschikbaar. En ik zit nou met mijn handen te gebaren, dat is niemand die dat ziet. Maar dat is een probleem van modules. Ze keren, het is een inverse, er is een mooi woord voor wat ik nou niet op kan komen. Maar je moet op een andere manier daarover denken. Je gaat iets in een component gebruiken en je weet eigenlijk niet zo goed waar het vandaan komt. Dat kan uit de common module komen of dat kan uit jouw eigen library komen. Inversion of control, doe je dat toch niet? Nee, geen version of control. Nee, inversion of control. Ja, inversion of control. De module is in controle over wat er binnenkomt inderdaad. En jouw component kan alleen maar gebruiken wat er in jouw module geinclude is. En dat is een beetje een mismatch. En dat is, ook hier geldt weer, dat is een mentale overheid waar je echt zonder kan. En vanaf het begin af aan is dit mijn probleem geweest met modules. En niet dat ik nou een probleem heb met modules. Maar dit is waarom ik van het begin af aan tegen het teamgroep heb. We moeten hier vanaf. Want dit is geen goed systeem. Ja, maar bla bla bla. En in het begin kon het niet anders. Ze zijn ontstaan vanuit tooling. Want er was geen mogelijkheid om dit te doen. Oh zo. De eerste Angular 2 alpha die had geen modules. Maar wat gebeurde daar? Als je dan een NG4 nodig had, dan moest je de NG4 importeren. En als je een NGIF nodig had, dan moest je de NGIF importeren. Dus wat gebeurde er? Bij elk component of wat je schreef, had je zonglides met imports. En daar werd niemand blij van. Want er was geen manier om dat te bundelen of te doen. In een manier die ook compileerbaar was en verteerbaar was voor Angular. En dat gaat nu meer omdat je dan... En daarom zijn modules gemaakt. Om die slag te maken. Dat je een klustertje van dingen hebt die beschikbaar zijn voor je componenten. Maar standalone componenten draait dat weer terug. En die gaat niet meer alles los importeren. Want ondertussen is de tooling zoveel verder dat daar betere oplossingen voor zijn. Die tooling was er toen niet, nu wel. En dat is een belangrijk punt. En die kijken vooral naar de imports of niet? Of is dat de manier... Hoe dat het er precies uit kan zien is nog niet helemaal uitgekristalliseerd. Maar waarschijnlijk kan je gewoon zeggen... Ik maak een barrelfile waar ik mijn imports in doe. En ik importeer die barrel en ik heb whatever. Maar pin me hier niet op vast. Het kan ook iets anders worden. Maar een barrel is gewoon een simpele Java scriptfile die iedereen begrijpt. En dat is geen module. Die nog allerlei andere verantwoordelijkheden heeft in betrekking met DI. En met het opstarten van componenten. En met het exporteren of het importeren van onderdelen. Dat zit er allemaal niet in. Dus dat is eigenlijk waar we naartoe gaan. En ik ben er heel blij mee dat we nu eindelijk weer standalone components krijgen zoals het nu gaat heten. Omdat dat het veel makkelijker maakt om over engelere applicaties te redeneren. Ja, dat was niet mijn bezwaar. Het matcht er niet in je hoofd. Ja, je krijgt er een onderbuikgevoel bij. Waarom moet ik dit maar goed? Het antwoord is, de tooling was toen nooit niet op een niveau dat het zonder modules kon. Maar we gaan dat onderbuikgevoel weer wegnemen. Dat hebben we net gedaan. Ja, ik hoop dat het snel komt. En dat we de applicatie waar ik aan het bouwen ge-upgrade komen, dat we dat kunnen doen. Dus dat is een heel goede ontwikkeling. Want ik had zoiets van, het is zo. Je bedoelt het toch. Dus je gaat er niks aan veranderen. Althans, ik had geen zin in een PR schrijven en een propositie van oké, zo zou het beter kunnen. Daar zat ik even zo, zat ik hier de race. Maar dat is in ieder geval een heel positieve ontwikkeling. Dat het een beetje vergelijkbaar is met de andere, zeg maar. Ja, oké. Ja, maar dit is ook een van de verdiensters van Ivy. Ivy heeft het idee localiteit een stuk verder gebracht in Engeland. Maar Ivy was Ivy vanaf het begin al, of niet? Nee, Ivy is geïntroduceerd in versie negen. Oh, negen zelfs? Ja, in negen. In acht was het optioneel. In negen zat het in. Was het opt in en in versie dertien is het de enige mogelijkheid. Ja, oké. Dus vanaf versie dertien is er geen mogelijkheid meer voor view engine, zoals de vorige oplossing heette. Oké. En ik denk dat het een goed idee is. Absoluut, absoluut. Ja, en als jullie tevreden zijn, dan geloof ik dat ook. Dat lijkt me wel... Ja, van jou hoor, we hebben het gewoon nog een keer. Ja, ik weet niet, ik moet upgraden, zeg maar. Ik moet niet, we moeten gaan upgraden. Ja, ik niet. De applicatie die we gebouwd hebben, die is drie jaar geleden ongeveer begonnen. Twee jaar ben ik weggewezen, maar nu weer teruggekomen. Een aantal dingen zijn beter. Een aantal dingen denk ik van, wow, hij is echt vroeger gebarsen, dus dat moet iets aan gebeuren. Maar ja, dat betekent gewoon dat we nu even stil moeten staan en dat ding upgraden. Want ik denk dat we op negen zitten, meen ik zo uit mijn hoofd. Dus dat moet even geupgrade worden. En het leuke van Engeler is, het is ook even upgraden. Ik zeg niet heel veel meer. Ja en nee, want we gebruiken libraries, zeg maar. Ik ben van vijf naar zes een keer geweest. Dat was toen die redelijke RXJS-upgrade. Dat ging, want dat is ook die tips die ik kreeg. Dus dat fik ik en ik denk, maar mooi, je kan weer verder. Dan kan ik wel testen en zo. Misschien een of twee dingetjes die hem omvielen. Maar goed, dat was allemaal niet... Uiteindelijk viel dat mee, maar het was een upgrade, zeg maar. Niet zomaar even één updateje en dan gaan we verder. Daarna viel het mee. Alleen ik vermoed dat wij echt wel wat dingetjes gaan krijgen die omvallen. Dat hoeft niet aan Angular zelf te liggen. Maar het zijn libraries die ook nog niet per se Angular, dus met Schematix, zeg maar, van Angular werken. Dat we daar ergens issues gaan krijgen. Nou ja, kijk, als het een library is die je zelf geïmplementeerd hebt, dan verandert er heel erg weinig. Nee, precies, dat klopt. Dus dan zal het op zich niet op omvallen als je naar een nieuwe versie gaat. Het enige dat zou kunnen is als je die library, als die... Nee, want die library is gecompleerd naar JavaScript. Nee, volgens mij is er geen probleem. Als je andere libraries hebt je op zich weinig last van. Nee, dat klopt. Daar heb je nog nooit... Het is als je zeg maar een Angular library van het internet geplukt hebt voor een datumding en die autor heeft die library laten schieten. Die heeft het niet meer nodig. Kijk, wij gebruiken Leaflet, zeg maar. Ergens in Nederland wordt er Leaflet gebruikt. Op een geheim plekje. Ja, op een heel geheim plekje. Nee, die kun je gewoon nativ gebruiken. Dat hadden we ook kunnen doen. Een rapper. Een rapper gebruikt, zeg maar. En daar kan best wel iets... Dat is een keer gebeurd. Het viel uiteindelijk mee. Dus dat soort libraries, daar heb ik soms... We denken, oké, gaat het wel goed. Dus we gaan het zien. Misschien ben ik over een paar weken aan het vloeken. Misschien niet. Dus als het meevalt, dan hoor je het. Als het tegenvalt, hoor je het nog veel harder. Ah, dat is goed. Nee, maar dat is op zich... Ja, goed. En als die modules er komen, of die... Hoe heet dat? Standalone components? Ja, standalone... Ja, precies. Juist niet. De module, de standalone components. Dat is echt wel een toegevoegde waarde. Dat vind ik voor mij dan een toegevoegde waarde. Ja, zonder meer. Ja. Dus dat is een goede kant. Ja, ik denk dat je niet bang hoeft te zijn voor een update. En inderdaad, als je een unsupported Angular library hebt, dan heb je misschien een punt. Maar overdag bijeen zijn die ook allemaal open source. Kan je ze gewoon binnentrekken en dan die libraries even updaten. Kost je een uur of twee en dan... Ja, het is nu vooral omdat er na een tijdje ontstaat een wildgroei. Je moet even opscholen. Het leek vroeger makkelijk om even moment binnen te halen. Misschien moet dat niet doen. Nou, is het alleen qua functionaliteit, zal het wel. Qua grootte is het een ding. Maar zo zijn er wel meer libraries waar je denkt, ja, misschien hadden we dat net goed zelf kunnen doen of op een andere manier zelf implementeren. Ja, dat is een van de dingen dat Jeffrey weet ook dat ik daar van heb. Hebben we die library echt nodig? Ja. Want ik zal niet zomaar een turpa die je binnen trekken. Kijk, als je iets binnen trekt en het is voor een geïsoleerd dingetje ergens in één onderdeel van je applicatie, dan maakt het niet zo heel veel uit. Maar als je iets binnen trekt wat je overal in je applicatie gaat gebruiken, check even of het een goede library is, of je goed gesupport is, of er een actief team achter zit. Dat is toch het minste? Ja, dat klopt, dat klopt. En kijk even naar de code-kwaliteit. Ik heb heel vaak dat ik iets nodig had dat ik ging kijken en dan kwam ik op een library en dan open ik de code. Ik ga eerst een paar stukken van de code lezen en denk van, dit gaat er niet worden. Nee, dat is waar. Ja, dat is precies. Soms denk ik, oké, je doet het te makkelijk, maar je kijkt wel precies wat je zegt. Is het actief? Wat voor issues zijn er? Dus je kijkt, je moet wel evalueren. En ook de NPM audit helpt ook nog wel. Wat gebeurt nog wel is dat ik denk, oké, waar heb ik hier nu binnen gehaald? Dat er echt heel veel issues zijn en dan blijven hangen. En dat ligt niet per se altijd aan de library zelf. Nee, maar soms ligt het gewoon aan de dependencies van de dependencies. En helaas is er niet altijd een weg omheen. Juist. Met Skully hebben we daar af en toe ook last van. Maar ja, aan de andere kant, je kan ook niet alles zelf schrijven. Nee, daarom. Ik kan het wel, maar niemand heeft genoeg tijd om daarop te wachten. Juist. Dat is het. Dat is de afweging die je moet maken. Die moet je gewoon bewust maken. Maar dat is eigenlijk een no-brainer, maar ik zeg het toch nog maar een keer. Als laatste, zeg maar, en dan gaan we door naar de volgende, het einde, zeg maar. Community platforms. Er worden een aantal hier opgenoemd worden. Waar moet je aan denken? Want ik zie hier Angular Nation, Angular Discord en Angular Air. Dat zijn plekken waar je... Ja, ik denk als je, sorry, als je gewoon zoekt naar een community waar je gewoon vrij kan praten of Angular developers kan ontmoeten of spreken, dan zijn dat de plekken waar je moet zijn. Angular Air is echt een videocast, noem je dat? Oké. Ja, het is gewoon een YouTube-stream. Elke vrijdag volgens mij proberen ze een gaspreker te hebben over een bepaald onderwerp. En dat kan zijn een bepaalde library. Maar dat kan ook zijn een pattern of net wat voorbij komt en interessant is. Daar komen sprekers. Dus daar kan je gewoon informatie op doen. Angular Discord, dat zeg ik al genoeg, dat is het Discord kanaal waar heel veel angular mensen zijn, waar je gewoon vragen kan stellen, antwoorden kan krijgen. Scully is daar een onderdeel van. Maar zo heb je ook over RISJS of hoe je routes, hoe je dat nog beter kan optimaliseren. Allemaal onderdelen om te doen. En Angular Nation, dat is echt meer een community om mensen te ontmoeten. Daar doen ze ook events organiseren met bijvoorbeeld het Angular team, maar ook met Storybook team of AG Grid of dat soort zaken. Sander is daar regelmatig te vinden in een thema wat ze noemen Ask a GDE, waar je gewoon je vraag kan stellen. Dus ben jij Angular developer en heb je gewoon is deze keuze wel zo slim bijvoorbeeld, dan zijn dat de plekken waar je gewoon heen kan gaan om gewoon je vraag te stellen. En toevallig heeft Angular Nation ook courses vrij beschikbaar over schematics, maar ook over andere zaken. Hoe je directives goed inzet en dat soort zaken. Dus dit zijn gewoon helpvolle tips, denk ik, voor de luisteraars of voor de mensen die net starten met Angular of gewoon jaren Angular achter zich hebben gelaten en er eens even willen opfrissen. Kijk eens naar die plekken, meld je aan en stel gewoon ook de vraag die je wil. Ik mis er een hele belangrijk. Er is iets zoals een Engelere lunch. Ja, die hebben we ook nog. Maar die doen wij. Die doen wij. En die hebben we niet op het laatst. Ja, precies. Dan moet je die wel toevoegen. Ja, erg, hè. Sander en ik doen natuurlijk de Dutch Engelic Group. De oudste Engelic Group ongeveer in Nederland, want er zijn er een aantal. En we doen maandelijks Engelic Lunch, echt voor de Nederlandse community. Dat wil niet zeggen dat we alleen maar Nederlands moeten spreken, maar dat proberen we wel. Dat heeft meer te maken omdat we zelf veel in het Engels bezig zijn. Maar ook gewoon kan aanhaken tijdens je broodje om vragen te stellen of gewoon of gewoon, ja, dit te zijn en gewoon een beetje te kletsen, zoals we hier hebben. Precies in dezelfde vorm, maar wel met wat mensen die kennis hebben van Engeler en ervaringen hebben en ook je gewoon kunnen helpen om een stapje verder te komen met je probleem of het project waar je mee zit. En dat was wat was de frequenties zijn je? Een keer per maand. Per maand. Ja. Oké. En dan meestal zeggen we de laatste donderdag van de maand. De laatste donderdag van de maand, zeg ik even. Maar dat staat op onze Meetup pagina, dus daar kan je gewoon voor aanmelden. Dus die moet gewoon ook in de show notes? Ja, dat komt omdat je dan niet aan jezelf denkt. Dan denk je wel aan alle anderen, maar niet aan jezelf. Dat is ook heel erg. We proberen ook nog wel wat sessies te organiseren online om voor de Dutch Engelgroep in dezelfde vorm als jij, wat jij doet met jouw podcast, alleen dan wij doen het gewoon via een livestream, waar we gastsprekers ook uitmaken. Heel specifiek Engelen natuurlijk, want dat is de Dutch Engelgroep. En dat kunnen mensen zijn die geen ervaring hebben en die gewoon een keer een talk willen geven. Dus ik nodig ook iedereen uit die hier in Nederland is van heb je een talk of wil je eens een keer een talk geven? En vind het gewoon spannend. Laat het weten, wij gaan je helpen, we geven je feedback op en ja, we gaan het gewoon samen doen. En dat doe je nu online, dus dat is die stream. Ja, dat hebben we jarenlang hebben dat gewoon in real life gedaan. Toen gebeurde er iets, toen gebeurde er iets waar ik het hier niet over wil hebben. En nu doen we het online en ja, als alles weer een beetje rustig is, dan gaan we weer in real life gaan weer organiseren en misschien in de toekomst zie ik ook nog een congresje gebeuren. Ja, ja, precies. Ik denk dat mensen dat ook wel. Ik kijk online dingen, online congres of een conference of hoe je het ook noemt. Het is zeker wel van waarde zeg maar, maar de commitment zeg maar, dat is minstens mijn ervaring, de mensen die dan gaan kijken naar zo'n online. De commitment is anders. Je zit gewoon thuis, gewoon lekker en iedereen stuit en stuilt rond. Het is anders dan dat je echt fysiek ergens bent. En een real life conference is ook gewoon leuk. Ik ben afgelopen december nog bij onze Zuidervrienden in België geweest. En vervolgens zit ik een uur aan tafel met Minko. Gewoon te kletsen over koetjes, kalfjes en ook engelen natuurlijk. Maar gewoon de mensen gewoon zien zeg maar. En dat is wat je denk in een conferentie met name hebt. En Sanne en ik hebben daar heel erg de mening in dat als we dat gaan doen, dan gaan we het niet online doen, maar dan willen we echt fysiek of op z'n minst hybride met een selectieve club mensen zeg maar. Maar ja, dat ligt aan de toekomst. Wat daar precies allemaal gaat gebeuren. Maar dat die er een keer gaat komen, dat gaat komen. En dan willen we gewoon wat mensen hebben in een zaal. En waar je gewoon daarna met z'n allen een borreltje kan drinken of even kan kletsen. Gewoon de social talk hebben. Ja, dat is wel belangrijk. Die is waardevol. Ik denk toch dat ik neig naar hybride. Ja, ik neig er ook een beetje naar. We gaan het zien wat dit jaar gaat brengen. Ja, ik weet niet. Ik zie al dat best wel wat conferenties alweer gepland zijn. Het is natuurlijk een risico dat het niet doorgaat. Maar anders kun je ook gewoon niks doen zeg maar. Je kunt ook zeggen van oké, ik ga het gewoon plannen en we zien wel. En als het dan niet doorgaat, ja dan jammer dan. Het probleem is, als je een conferentie gaat plannen, je moet een locatie, je moet meer dan een jaar van funding vastleggen. En daar zit een kostenplaatje aan. Ja, dat wil ik dus net zeggen. Dus als je die klap kunt hebben zeg maar. Dus als het niet doorgaat, dan kun je dat doen. Anders is het tricky. Niet toevallig vanuit ons, niet vanuit ons, dat is voor interne mini-conferenties als het ware met alleen onze personeelsleden. Ja, dit is gewoon van oké, laten we het gewoon plannen. En als het niet doorgaat, ja. Ja, maar dan heb je het vanuit je bedrijf. Ja, precies. En dan zit het natuurlijk als een soort van bedrijfsrisico. Ja, we moeten sponsors zoeken, kaarten verkopen, goodie bags, nu moet het maar even. En alle merchandise eromheen. Nou ja, mensen moeten komen, sprekers moeten komen. Iemand vanuit het buitenland die moet laten invliegen. Nou ja, met alle regels. Zegt dat wat? Het is ook een droom zeg maar voor ons zeg maar. Ja, voor mij vooral dat er een CodeKlets-conferentie komt, ooit. Maar dat is niet zo snel gebeuren zeg maar, want het moet eerst veilig zijn. Ja, precies. En dan hebben we precies hetzelfde. Hetzelfde rijden wat jij aangeeft, van oké, je moet sponsor hebben, locatie, je moet de juiste sprekers hebben. Ja, in ons geval is het het soort Nederlandse sprekers zijn. Niet zo zeggen dat we niet Engelstalig, dat we die buiten willen sluiten. Die discussie hebben we trouwens heel vaak van, oké, je doet het in Nederland, je sluit een groep mensen uit, buiten, zeg maar, hier in Nederland. Ja, dat is waar, maar ja. Dat is gewoon een keuze. Ja, dat is een keuze zeg maar. En dat willen we dan wel een keer gaan doen zeg maar. Maar ja, kan dat? Waar ga je dat doen? En ja, dus dat is... Herkenbaar, herkenbaar. Ja, en online hebben we wel zo vandaag. Ja, dat is, ik geloof er wel in, maar ik denk dat dat, stel dat wij nu al tien jaar bestaan en we hadden vier of vijf keer zo'n conferentie gegeven en we zouden dan online gaan. Denk je dat er best wel wat dan... Ja, dan was het dan duizend, dat er dan 500 of 300 mensen zijn. Dan is dat anders dan dat je vomskrijt begint met een online conferentie. Ik geloof niet dat je dan zoveel mensen strikt, zeg maar. Dus dat lijkt me lastig. Nee, en dan moet je nog afvragen. Ga je het kaartje verkopen of niet? Ja. Online. Ja, ja, precies. Dat is ook een... Dat zijn heel veel van die conferenties die dan gratis zijn. Oké, dat was het rondom Engelen. Ik weet niet of jullie nog dingen kwijt willen over. Nee, ik zit even te denken. Nee, ik denk dat we al genoeg gezegd denk ik. Alle onderwerpen we al gehad hebben. Mooi, mooi, mooi. Ik wil je eigenlijk nog even bedanken om ons te ontvangen en het is het is erg leuk. Ik kan me eigenlijk niet heugen dat ik zo lang over mijn vak heb gesproken in het Nederlands. Ja, dat is echt lang geleden. Ja, ja. Dat kan ik me ook... Ja, ik kan een interne sessie kan ik me herinneren, maar dat was ook een half uur, zeg maar. Maar gewoon lekker praten over Engelen en alles wat erbij komt kijken. Ja, precies. En gezelligheid. Ja, in het Holland. Ja, precies. Ik praat heel veel over Engelen. Ik praat heel veel over mijn vak, maar het is altijd in het Engels. Ja, dat scheelt ook als je voor een Amerikaans bedrijf werkt. Ja, dat is waar. Voornamelijk dan. Zullen ze het niet in het Nederlands gaan doen? Ja. Dan wordt het een feestje voor mij. Maar we zijn nog niet helemaal klaar. We hebben... Nou, dat is een developers dilemma's. Die doen we alle tijd niet meer, omdat ik daarmee stop want we hadden op een gegeven moment niet echt interessante dilemma's meer. En we hebben wel tips. Ik weet niet of ik daar niet gevraagd heb. Jullie hebben misschien een kindertje voor mij, maar normaal gesproken zeggen we ja, het maakt niet uit wat voor tip je hebt. Een conferentie, een type computer, een serie, een film, whatever. Alle tips zijn welkom. Dan komen die gewoon in de show notes tegen. Dus dan mag iedereen gewoon een tip geven of meerdere. En ik weet niet of jullie iets weten te verzinnen. Nou, ik denk dat we een behoorlijke tip al hebben gehad. De Engeler devtools voor in de browser. Dat is een leuke tip. Ik denk dat een andere leuke tip, als je het over series hebt, is het The Witcher en op Netflix. En op Prime hebben we The Wheel of Time. Ja, heb ik ook gezien. Die is vrieselijk goed. Ja, ik vond, ik heb hem helemaal gezien. Ik ken de boeken niet, dus heel veel mensen kennen de boeken van je. Ja, ik heb de boeken gelezen. En ik vond hem in het begin traag op gang komen. Heel veel karakters. Ja. Het wordt nog verwerkt. Ja, dat geloofde ik al. En die jongen, ja, dat moet niet spoileren natuurlijk. Hoe heet hij nou? Het zijn vier, ja, vijf personen, wat dan in het geval in de film opdraait. En de jongen, zeg maar, die, ja, een beetje rood, blond haarige jongen. Nederlander. Ja, echt waar. Hoe heet hij in de serie? Rand. Rand, ja, Rand. He, ik vind zijn karakter, nee, nee, nee, niet zozeer. Kijk, dat zal met de boek, je moet het boek lezen. Iemand die het boek leest, die zegt van ja, dat is een lastige verhaal. Ik vind het altijd zo irritant dat iemand heel dom is, heel tijd rond. Ja, niet dat hij dom is, maar heel tijd van oh, alles overkomt me. Oh, oh, gebeurt dit? Oh, en dan heb ik deze, oh, ik wist niet dat ik dit... Dus ik dacht, oké, net als altijd twee stappen achterlopen. Dat heb ik met die Rand heel erg. Terwijl die andere, die hebben ze, ja, weet je wat, die ene vrouw met die gestaard. Die krijg je? Ja, precies. Ja, ik krijg heel veel krachten. Dus dat vond ik wel cool. Dus, nee, ik vond het heel mooi. Het einde, zeg maar, vond ik echt gaver. In het begin vond ik het nog een beetje lastig, maar gelukkig ben ik er doorheen gekomen. Ja, maar het is, ja, je hebt de boeken niet gelezen, maar in de boeken heb je nog veel meer karakterontwikkeling en karakterontwikkeling is heel lastig. Ja, ja, eens, ja, ja. Maar goed, dat komt als het goed is een tweede en een derde seizoen al. Dat komt sowieso een tweede en een derde seizoen. Ja, ja, dus dat is fijn, ja. Mooi, dat is ook een tip. Andere tips? Een scully. Ja, dat is, ja, die komt sowieso wel. Een poefje bij je hebben of een tafeltje voor je laptop als je een podcast doet. Ja, dat is waar, of gewoon een hele studio inrichten. Ja, of een studio inrichten, dat is een lastige. Ja, ja, ja, dat is een tip. Wat heb ik nog aan het tip? Een boekje dan. Ik ben twee weken geleden of zo, drie weken. Drie weken geleden denk ik een boek begonnen. Ja, oké. Nu of Nooit heet dat. Dat gaat over eigenlijk mentale zelfbewustzaamheid. Oké. Maar dan vanuit de commando's. Ik ben pas anderhalf hoofdstuk verder. Ik weet er nog niet exact alles van. Maar het is wel interessant hoe dat kan. Hoe de commando dat ziet. Misschien gewoon voor degene die denkt, dat vind ik interessant. Zoek het eens op en er zijn een tal trouwens van dat soort boeken. Maar deze kwam op mijn pad. Ja, oké. En die moet je... Wat is jouw tip? Ik heb geen tips. Ik heb heel vaak tips. Ik heb de Wheel of Time gekeken, vond het gaaf. Ik heb soms antitips van koop dat niet of doe dat niet. Ik zit midden in een verhuizing. Dat is echt één grote stresspartij, zeg maar. Ik stress echt helemaal niet snel. En de laatste drie maanden zitten we een beetje in die heisa, zeg maar. En wij hebben geen overlap, zeg maar. Normaal sproken verkoop je je huis. Dan zit je daar nog drie maanden in, als het ware. En voordat je dan over gaat naar je andere huis. Of je verkoopt het en je zegt van, oké, die datum kan eruit. Sleutel, et cetera. Juist. Dan heb je een overlap en dan kun je rustig gewoon in je huis blijven wonen. Je verbouwt je nieuwe huis, je zet je spultjes er langzaam in en dan verhuis je gewoon een keer klaar. Dat hadden wij dus niet, want het bouw liep uit en zo. Shit happens. En ik dacht, ja, dat valt nogal mee. Dan zit je wel een keer in een vakantiepark. Maar nee, dat is echt... Ik ga niet in een kookleer zitten. En ik ben op dit moment geen vrienden met stucadoors. Stucadoors zijn echt niet mijn... Niet je vrienden? Nee, echt niet. Zo'n stucen niet? Nee. Ik probeer een analogie te vinden in development, zeg maar, wie dan de stucadoors zijn. Want we worden heel vaak als bouwvakkers gezien. Vind ik ook best wel. De metselaren en iemand die maakt het design van een huis of een website. En de architectuur, dat is allemaal heel erg analoog. Maar de stucadoor weet ik nog niet helemaal wie dat is bij de development. Maar die gasten, die weten dat ze heel erg gewild zijn. Iedereen in de bouw op dit moment. Maar goed, dat gaat altijd... Ze kosten tegenwoordig ook meer als een developer. Ja, dat is best zuur. Die jongens zijn echt... Alles is duur nu. Oh, ik wil een tuinhuis. Ja, duurder het hout, dus twee keer zo duur. Oké, dus dat is twee keer zo duur. Kan die ook van plastic? Ja, precies, ja. Ja, maar dat is ook duur. Ja, tegenwoordig is alles... Ja, goed, containerprijzen blijkbaar zijn echt to the roof gegaan. Dus als je iets vanuit China hierheen moet halen. Ja, niet ik persoonlijk, maar dat is voor bedrijven heel duur. Dus het is echt een heel bijzondere tijd, zeg maar. Dus dat is de enige tip die ik heb als je hebt gewruisd. Zorg dat je een flinke overlappen hebt, zeg maar. En een goede stukken door. En een goede stukken door, met heel veel referenties. Ik weet niet hoe je dat... Ik dacht dat die van mij ook goede referenties had, maar die kwam in één keer niet meer op dagen, maar dat is even een andere ding. Goed, ik nogmaals, ik wil je nog een keer bedanken. Jij bedankt. En jullie hebben best wel een reis gemaakt, zeg maar, om hierheen te komen. Dus dat vind ik echt wel een eer dat jullie dat gedaan hebben voor ons. Dus ja, dat. Iedereen gaat natuurlijk in zijn podcasts spelen te zien krijgen, wanneer deze online staat. Dat hoef ik nu niet te vertellen, maar dat gaat automatisch gebeuren. Is dat een ding? Ja, dat is heel bijzonder, ja. Dat gaat allemaal heel automatisch. Ja, verder ga gewoon naar codeklets.nl. Daar zie je alle informatie over onze podcast. Daar kun je ook zien hoe je bij ons op de Slack komt. Er staat nog een link naar een nieuwsbrief. Dat vraag ik me nog af of ik die nog daar ga laten staan, maar daar kun je naar kijken. We zijn op Twitter te volgen. Alle gasten die bij ons zijn gekomen, die volgen we ook op Twitter. Dus dan kun je vanuit ons Twitteraccount zien wie er allemaal zijn geweest. En dat zijn ook de enige mensen die we volgen. Dus als je denkt, waarom volgen jullie zo weinig mensen? Zijn die zo arrogant? Nee, dat was eigenlijk het principe. En dan kun je ook meteen mensen daar, als je ons volgt, kun je ook die andere mensen volgen en die zullen meestal wel interessant zijn. Dus dat is handig om te doen. We hebben een Instagram account, maar daar doen we heel weinig mee. Dus dat hoef je verder. Mag je even acht weken laten. Dus dat was het weer. Nou, doei doei. Dag. Doei doei.