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.
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, 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.