Designsysteem Blauwdruk helpt development bij de politie te stroomlijnen

Voor veel organisaties is het lastig om alle changes bij te houden, zowel op technisch vlak als op UX-gebied. Frontend-developer Ryan Kool en UX-designer Chris van Schayk van de Landelijke Eenheid vertellen tijdens de Developers Summit (2 t/m 5 juni) over Blauwdruk. Dit is een designsysteem dat het werk van developers en UX-designers in hun organisatie op één lijn houdt en versnelt.

Ryan Kool is als frontend-developer verantwoordelijk voor de software-architectuur van Blauwdruk, een nieuw technisch designsysteem voor de politie. In een team van zes mensen is hij zowel lead developer als architect. Sinds een jaar is hij bij de politie gedetacheerd. Aanvankelijk werkte hij volledig aan RAPP, een systeem waarmee politieagenten met een mobiele applicatie tijdens hun dienst meldingen kunnen doorgeven. In dit project trof hij UX-designer Chris van Schayk. “Hij vertelde dat binnen de politieorganisatie grote behoefte bestond aan stroomlijning van de gebruikservaring en het gebruiksgemak.”

UX als doelstelling, maar ook technische efficiëntie

Behalve een gebruikersgerichte doelstelling (UX) zagen Chris en Ryan mogelijkheden om zaken technisch efficiënter aan te pakken. “Wat dat betreft sloot het verhaal van Chris goed aan bij wat ik zelf ook had gemerkt”, vertelt Ryan. “We hebben bij de politie meer dan tachtig ontwikkelteams waarvan er zo’n vijftien betrokken zijn bij het RAPP-project. De onderlinge communicatie is best goed, maar je kunt niet uitsluiten dat er dubbel werk wordt verricht of dat iets er nét even anders uit komt te zien dan eigenlijk de bedoeling was. Chris was daarom al begonnen met de aanzet tot een designsysteem, met een library voor herbruikbare componenten.”

Blauwdruk is ontstaan vanuit het idee om alle technische changes bij te houden op één plek waar ook de ontwikkelingen rond UX staan. Dit zorgt voor consistentie in het ontwikkelproces, met componenten die generiek toepasbaar zijn. “Je hoeft hierdoor maar één keer de kwaliteit te waarborgen en één keer te distribueren, waarna alle teams het systeem kunnen afnemen.” Deze centrale plek is ingericht met Nexus als private repository.

Inner sourced opensource-project

Inmiddels is Ryan als lead developer het grootste deel van zijn tijd bezig met het ontwikkelen van componenten voor project Blauwdruk. “Tegelijkertijd ben ik ook betrokken bij het RAPP-project en andere teams, vooral om te testen of de componenten werken zoals bedoeld.” Hij ziet dat steeds meer teams nieuwe componenten aan de library toevoegen en ook gebruiken. “Wanneer een team iets nodig heeft dat nog niet in de library staat, denk bijvoorbeeld aan een dropdown-menu, kan het dat in principe zelf bouwen. Dit is een soort distributed way of working waarbij ons team zorgt voor de kwaliteitscontrole en het publiceren in de library. Zo groeit Blauwdruk steeds meer uit tot een inner sourced opensource-project waarmee iedereen in de organisatie wel iets kan.”

Na ongeveer een jaar is het project al ver gevorderd. In dat jaar moest het team her en der lastige keuzes maken. Ryan: “We zijn begonnen met bouwen in Angular Material, omdat het RAPP-project - waar de focus op lag - daarmee werkte. We moesten snel componenten opleveren en zorgen dat het project werd versneld. De eerste driekwart jaar hebben we daar heel intensief aan gewerkt, met als resultaat een volwaardige library.” Bij het bouwen in Angular kwam het team ook een technische bottleneck tegen, vertelt hij. “Niet alle projecten bij de politie die met Angular zijn geschreven maken gebruik van dezelfde versie. Ze werken daardoor niet allemaal goed samen met de Angular-versie die we in de library gebruiken.”

Van Angular naar StencilJS

Om het incompatibiliteitsprobleem op te lossen, besloot het team over te stappen op het ontwikkelen van webcomponenten met StencilJS. “Daarmee ben je niet afhankelijk van het Angular-framework en kun je gemakkelijk werken met html en Javascript. Het maakt daardoor niet uit als de politie in de toekomst met bijvoorbeeld React of een andere taal wil werken; de libary is er compatibel mee. Een nadeel is dat de library minder compleet is dan wat al in Angular is te vinden, dus we moeten zelf meer bijbouwen. Daar zijn we inmiddels mee begonnen.”

De reacties die het Blauwdruk-team uit de rest van de organisatie krijgt zijn positief, vertelt Ryan. “Wat ons helpt is dat we de volledige support van het management hebben gekregen. Daardoor kunnen we dit fulltime doen en hebben we in ons team een tester, een scrum-master en behalve onszelf nog twee developers. Veel teams zijn inmiddels actief aangehaakt en zijn er heel blij mee, want het neemt ze veel werk uit handen. Projecten lopen makkelijker door Blauwdruk en daarvoor is het echt een soort kickstart, helemaal nu de bottleneck met Angular er niet meer in zit en er minder afhankelijkheden zijn. De library is daardoor een stuk makkelijker te gebruiken. Van politieagenten krijgen we inmiddels te horen dat de UX van hun apps een stuk consistenter is.”

Tweakers Developers Summit

In bijna elke organisatie kan het niveau van development groeien door goed na te denken over een designsysteem. Een van de inspirators van Ryan is de Amerikaan Brad Frost, die een boek schreef over atomic design. “Hij legt uit hoe je development in stukjes kunt knippen en hoe dat op de lange termijn veel tijdbesparing en kwaliteit oplevert. Niet alleen zorgt een goed designsysteem ervoor dat de hoeveelheid frustratie afneemt, het leidt ook tot minder fouten en zorgt voor meer consistentie in je projecten. Dat is precies waar we naartoe willen voor onze eindgebruikers: een standaardmanier van werken aanbieden die onze operatie zo goed mogelijk ondersteunt.”

In de frontend-track van de Tweakers Developers Summit zullen Ryan en Chris verschillende aspecten van het project toelichten. “We zullen natuurlijk vertellen waar de noodzaak voor Blauwdruk vandaan kwam en hoe het project is ontstaan. Verder willen we de voor- en nadelen van onze keuzes op technisch gebied uitleggen, waaronder die voor Angular, StencilJS en Storybook. Daarbij vertellen we over onze ervaringen, wat we zijn tegengekomen en waarover we enthousiast of juist minder enthousiast zijn.”

Meer weten over de Developers Summit? Kijk hier voor alle informatie over het event.

Meer informatie over de politie vind je hier.

Dit artikel is geen redactioneel artikel, maar een advertorial en tot stand gekomen dankzij de politie en Tweakers Partners. Dit is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers-events zoals Meet-ups, Developers Summit, Testfest en meer. Kijk hier voor een overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (49)

Ik heb 4 jaar geleden een project gedaan met StencilJS. Dat ging niet om een applicatie, maar om het bouwen van een 'component library'. Deze componenten moesten overal gebruikt kunnen worden (vanilla js, Angular, React, Vue, etc..) dus we wilden graag gestandaardiseerde web components maken. Dat kun je natuurlijk met het handje te doen, maar een goede toolchain die je het nodige werkt bespaart is wel net zo prettig. Het grootste probleem destijds was dat de ontwikkeling van Stencil niet zo vlot liep en dat sommige features gewoon (te) lang op zich lieten wachten. Als ik nu op hun Github kijk ziet het er nog steeds niet zo actief uit. Hetzelfde geldt voor het vergelijkbare lit-element. Architectureel gezien vond ik het altijd een aantrekkelijk idee om standalone web components te bouwen die overal werken, maar het lijkt erop alsof de grote JS frameworks te veel aantrekkingskracht hebben en dat kan ik ergens ook wel begrijpen.

Mijn ervaring is dat lit erg actief is!

Als de ontwikkeling van een framework afhankelijk is van de community dan lijkt het me ook redelijk dat de community van gebruikers en ontwikkelaars op zijn minst bijdrage probeert te leveren.

Lit 2.0 is pas geleden ge-released. https://lit.dev. Er is juist veel bedrijvigheid. Veel van het werk dat ze doen is niet perse zichtbaar op Github. Overigens wordt er ook volop ge-commit op github.

[Reactie gewijzigd door hakog2 op 25 mei 2021 14:32]

Inmiddels wordt in de overheid ook gewerkt aan een design system voor de hele overheid, waarbij verschillende huisstijlen (waaronder de Rijkshuisstijl) kunnen werken op een gemeenschappelijke basis. Toegankelijkheid voor blinden etc. volgens de Digitoegankelijk.nl / WCAG standaarden krijgt daarbij bijzondere aandacht. Zie https://designsystem.gebruikercentraal.nl/. Alles is open source uiteraard. 5-11 juli is dit ook een track in een hackathon https://www.meetup.com/nl-NL/Code-For-NL/events/278262253/ waarschijnlijk, bericht me even voor meer info.

Ik heb een artikel geschreven over hoe NL Design System een codebase is waar veel mensen mee kunnen werken, of ze nu Angular of StencilJS of gewoon een CMS gebuiken:

Jouw project inrichten op de NL Design System architectuur

Nu maar hopen dat de focus zo veel mogelijk op HTML en CSS native ligt, en dat de Google Light House test en Mozilla Observatory test beide maximale scores kunnen hebben bij gebruik van alle componenten.

Het zou mooi zijn als ze naast WCAG ook PWA - incl. automatisch pre-load van next navigation steps - compatible zijn. En het liefst ARM-template compatibele EN dat de gebruikte scripts WebASM gecompileerd kunnen worden.

Dan resulteert deze style - eindelijk - in een ultra snelle goed interactieve website. Die ook bij een hapering in je verbinding vrolijk blijft doorgaan én hoog scoort in de zoekmachines en social ranking engines.

[Reactie gewijzigd door djwice op 25 mei 2021 23:37]

StencilJS? Dapper. 145.000 google-hits, 500 stackoverflow hits, laatste update op Github was 2 maanden geleden. Niet mijn eerste "toekomstvaste" keuze. En om te zeggen "dan zit je niet vast aan React of Angular", nee dan zit je vast aan StencilJS.

Ik zeg niet dat StencilJS slecht is, mijn eerste snelle indruk geeft mij een React-vibe als het op syntax neerkomt. En misschien ga ik er ook wel even naar kijken, maar ik denk niet dat ik binnen het bedrijf nu zou gaan zeggen "jonges drop Angular en React, we gaan Stencilen".

Het grootste verschil tussen StencilJS en frameworks zoals Angular of React is dat voorgenoemde slechts een toolchain/compiler is om web components mee te genereren die je vervolgens weer overal kunt gebruiken, ongeacht het framework. Het is qua insteek dus wezenlijk anders dan React (syntax daargelaten). Het gebrek aan activiteit op hun Github is dan wel weer zorgwekkend.

Hoe je het ook went of keert, StencilJS is een framework. Zoek maar even op wat "Framework" betekend.

We kunnen het een "compiler" noemen, maar zowel Angular als React doen exact hetzelfde. Beide compileren hun code naar native javascript. Daarbij wel de kantekening dat output van Angular/React moeilijker bruikbaar zijn binnen andere projecten. Ik zeg moeilijker, want in beide gevallen is het wel mogelijk.

Ik zou zelf absoluut niet met StencilJS + een ander framework willen werken, ik zie gewoon de use-case niet maar wel de problemen met onderhoud aan meerdere frameworks binnen hetzelfde systeem. 80% van je interface in Angular maar wat componenten in StencilJS? Nee dank je.

Ze komen er wel achter denk ik. Maar ik zou als architect zou niet voor StencilJS kiezen. En dan kijk ik niet eens naar de toekomstvastheid van StencilJS.

In het gekozen framework (Angular/React/Vue/whatever) werk je met dat framework en niet met stencil, stencil bestaat eigenlijk niet in dat framework. Je neemt web-componenten af, native html/css/js componenten. Daar zit je styling en een deel van het gedrag al in, oftewel een kant-en-klaar onderdeel waar je alleen je data binding aan toevoegt en klaar ben je.

Om te zeggen dat je stencil i.c.m. een ander framework gebruikt klopt in die zin dan volgens mij ook niet. Of zie je dat anders?

Waarom zie ik het als een framework? Het "forceerd" je op een bepaalde manier iets te bouwen. Je krijgt hiervoor een API (https://stenciljs.com/docs/api) en een bepaalde flow (https://stenciljs.com/docs/component-lifecycle). Het is een minimalistisch framework, maar (in mijn ogen) nog steeds een framework.

Als de API en lifecycle als drop-in replacement in meerdere "compilers" gebruikt kunnen worden dan zie ik het niet meer als framework. Maar ik acht de kans vrij groot dat dit niet het geval is.

Ik ontken niet dat Stencil een framework is, maar ik probeer wel aan te geven dat het volgens mij niet klopt dat je stencil in combinatie met Angular gebruikt. Als jouw team een Angular project bouwt en daarbij webcomponenten gebruikt heb je niks te maken met stencil.

Als je vervolgens zelf componenten gaat maken om toe te voegen aan de componenten bibliotheek van stencil, dán heb je met Stencil te maken. Misschien is het een semantische discussie.

Het idee is inderdaad niet om de andere frameworks te droppen, maar om alle frameworks te bedienen. Het idee is dan web-components omdat je framework-agnostisch kan werken. Op die manier blijft het onderhoudbaar voor een relatief klein team en kan je op die manier een grote organisatie bedienen met minimale effort en toch een single-point-of-truth behouden

[Reactie gewijzigd door idesigner op 25 mei 2021 10:24]

Ik begrijp het helemaal hoor.

Maar als ik naar de rede kijk van het artikel zelf "Daarmee ben je niet afhankelijk van het Angular-framework en kun je gemakkelijk werken met html en Javascript" dan is zeker dat deel niet doordacht. Je vervangt de ene afhankelijkheid met de ander.

En een zin later wordt "React" een taal genoemd.

Ik kan dan nog verder gaan, ze willen dus React en Angular nog steeds gebruiken maar dit deels vervangen door componenten op basis van StencilJS die dan in beide "talen"(frameworks) bruikbaar is. Met het idee dat je later met minder effort van "hoofdframework" kunt wissel.

Want? Dat gebeurd zo vaak?

In mijn ervaring zijn er meerdere product teams bij grote bedrijven/organisaties die allen zelf de keuze vrijheid willen kwa framework react/angular/vue etc. Maar gelijkertijd heb je een design system team dat voor alle andere teams de basis design componenten aanbied.

Dus in de praktijk spreek je nog eens niet over wisselen tussen bijv. angular en react maar worden deze gelijkertijd gebruikt in verschillende projecten en sommige oudere projecten hebben dan ook nog vaak oudere versies.

Dus de w3c web component standaard heeft wel degelijk een groot voordeel voor grote bedrijven.

Ik vind de opmerking "meerdere product teams die allen zelf de keuze vrijheid willen" heel gevaarlijk. Ik ben daarin ook denk ik erg 'anti-scrum'. Het vereist hele volwasse teams om die vrijheid goed te gebruiken. Vrijheid is prima binnen een bandbreedte (imho).

Bij een oude klant wisten ze niet eens wie welke componenten gebruikte, toen ik dat opperde als "problematisch" zeiden een groot deel van de teams "tja wij reserveren gewoon x uur per sprint om alle componenten te updaten". Alsof het de normaalste zaak van de wereld was elke sprint meerdere dagen (want daar kwam het op neer) kwijt te zijn aan het updaten / fixen van componenten problemen. Ze vonden het ook geen probleem als een team de volledige specs van een component wijzigde.

Ik ben niet anti w3c web componenten, en indien goed gebruikt/gedocumenteerd/doordacht kan het prima werken. Maar het vereist hele volwasse teams. Ook het gebruik van meerdere frameworks vereist hele volwasse teams. En helaas zie ik veel te weinig volwasse teams om er in te geloven.

Je vergeet dat sommige bedrijven groter zijn dan je denkt. De voorbeelden die ik ken zijn internationaal met eigen sub bedrijven (sub merken) die op zich staand al zeer groot zijn. Denk hierbij aan vliegmaatschappijen met sub merken en banken met internationale vestigingen (onder andere merken).

De web component standaard zijn dan vooral ook ideaal voor deze situaties en niet perse een bedrijf met 3 producten en scrum teams die om een of andere reden niet samen kunnen kiezen voor een framework.

[Reactie gewijzigd door seapip op 25 mei 2021 13:54]

Want? Dat gebeurd zo vaak?

Jazeker. Er is een grote behoefte binnen grote organisaties om zoveel mogelijk UI componenten te delen. Veel van het werk programmeer werk vindt plaats aan de frontend. Dan is het fijn als je niet iedere keer opnieuw het wiel hoeft uit te vinden. Een library zoals stencilJS is daar heel erg geschikt voor.

Zelf had ik gekozen voor Lit Element (https://lit.dev) en niet voor Stencil. Ik denk Lit meer toekomst heeft omdat het naadloos aansluit op de ontwikkelingen rondom de web elements standaard. Ook niet gek als je weet dat Google een van de bedrijven achter Lit element is.

Overigens heeft Lit wel een runtime nodig, maar geen compile slag om te werken in moderne browsers. En ze hebben ondersteuning voor server side rendering.

[Reactie gewijzigd door hakog2 op 25 mei 2021 13:18]

Lit Element ziet wel wel leuk uit maar toch zie ik daar ook wel mijn bedenkingen. Ten eerste is het veel minder bekend en doet het volgens mij hetzelfde als Stencil. Dat Google er achter zit hoeft overigens niet heel veel goeds te beteken. Volgens mij is Lit een doorontwikkeling van Polymer wat niet echt geslaagd is in de wijde wereld.

Los daarvan zie ik dat de code gebruik maakt van decorators welken een work in progress spec is (stage 2). Het is IMO een mooie experimentele library maar ik zou voor productie verder kijken.

[Reactie gewijzigd door Ed Vertijsment op 25 mei 2021 13:55]

De decorators die je ziet zijn voorbeelden van Typescript implementaties. Dat is niet vereist.

Lit doet zeker niet hetzelfde als StencilJS. StencilJS compiled je componenten naar web elements standaarden. Lit is een kleine library (5kb) die enkel wat extra runtime features toevoegt aan je w3c componenten. Denk aan een re-render van bepaalde delen van de DOM als state wijzigt.

Polymer was z'n tijd een beetje vooruit denk ik, Lit 2.0 komt daaruit voort, we gaan zien hoe dit zich verder gaat ontwikkelen. Juist omdat Lit componenten out of the box werken in moderne browsers (volgens mij is alleen IE problematisch) is het een toekomst vaste oplossing.

[Reactie gewijzigd door hakog2 op 25 mei 2021 14:18]

Je zit vooral vast aan Web Components IMHO.

De afhankelijkheid van Stencil is een stuk kleiner dan die van een React of Angular. Daarnaast leg je je gebruikers ook niks op qua framework.
Componenten in React zijn sterk afhankelijk van React, zowel bij bouw als gebruik. Web Components zijn licht afhankelijk van Stencil, alleen bij bouw.

Even gecheckt, gelukkig zit er wel een bekend bedrijf (Ionic) achter en niet twee developers die het als experiment gebouwd hebben

Overigens zou ik eerder neigen naar Svelte, net als Stencil heeft het geen runtime library zodra je de boel compiled maar de minimale code die vereist is om de boel te laten werken. Dit framework is een stuk volwassener dan Stencil zover ik zie.

Overigens is er recent dit artikel voor mensen die al React ervaring hebben en benieuwd zijn naar hoe Svelte nou werkt t.o.v. React.

[Reactie gewijzigd door seapip op 25 mei 2021 12:12]

Het aantal vragen op SO is 477 voor Angular is dat 250000. Dat is echt wel een verschil.

Ah nu zie ik het, ik had verkeerd gekeken 😅

Waar komt die behoefte van FrontEnd/UX developers toch vandaan om maar weer het zoveelste framework te ontwikkelen? Er bestaan al zat andere frameworks met componenten, je zet er je eigen style zodat het eruit ziet zoals je verwacht en klaar.

Het gebruik van StencilJS komt waarschijnlijk omdat de ontwikkelaar daar ervaring mee had... en dan gelijk doordrukken.... zucht...

[Reactie gewijzigd door rvt1 op 25 mei 2021 08:46]

Ik denk dat dit voornamelijk komt door het gebrek aan standaardisatie/style-baarheid tussen de verschillende frameworks. Persoonlijk heb ik vaak genoeg geprobeerd een (bijvoorbeeld) Material based UI library te pakken en dat te vormen naar de wensen van de klant, maar je komt dan vaak in het "!important" landschap van CSS: Het werkt, maar mooi en onderhoudbaar is het niet.

De komst van CSS variabelen is dan ook een erg fijne introductie in het geheel, maar de adoptie is nog niet erg hoog onder de UI frameworks doordat de meeste nog IE(11) willen ondersteunen. Een project waar ik iets meer hoop op gevestigd heb is het Open UI WICG project: https://open-ui.org/
Ik hoop dat hier een basis design systeem uitkomt waar wij developers dan enkel een styling-sausje overheen hoeven te gieten zonder afhankelijk te zijn van al die frameworks voor een UI-schilletje.

Ik heb anders redelijke successen kunnen behalen met bootstrap. En dan vooral met het forken van de github repo. Dan kan ik met de scss relatief eenvoudig de styling tweaken. Dan hoef je niet al teveel !important toe te passen.

Waar ik pas echt van gruwel is (react) componenten die een eigen css gaan definiëren. En dan het liefst niet voldoen aan de huisstijl zodat je een technical debt van hier tot tokio krijgt.

Wat je inderdaad niet wilt is dat componenten hun styling gaan afdwingen mits via JS gegenereerde style attributen. Dit gebeurt steeds vaker maar is IMO allerminst fijn als je generieke componenten wilt maken. In dat geval zet je (nog altijd) een semantische HTML boom neer waar je kan inhaken met een custom stylesheet.

In mijn ervaring, als er een custom styling nodig is zitten generieke libraries daarvoor alleen maar in de weg, dat is voor de implementatie.

Wij gebruiken een intern ontwikkelde (open source) library die enkel de "plumbing" doet, niet de "kitchen sink".

Dit betekent dat je wel een grid systeem krijgt en een typografie library maar niet de implementatie en styling ervan. Je zult het zelf moeten toepassen mits scss mixins. Het betekent ook dat je zaken als gestandaardiseerde/configureerbare breakpoints krijgt maar deze, wederom met scss misins aanroept waar jij wilt. Je styling framework werkt dus niet door naar je html boom met rare classnames of attributen en je focust je dus enkel op het implementeren van je eigen componenten.

Dat werkt naar mijn ervaring beter dan proberen een generiek framework (waarvan het gebruik zijn time and place kent) proberen te customizen om iets anders te doen dan waarvoor het gemaakt is. Zelf de sass configuratie van Bootstrap inladen/aanpassen kan maar resulteert al vrij snel in verwarde developers omdat dingen 90% werken zoals in documentatie/community besproken wordt.

Het forken van de repo en dan aanpassen is zeker een goede oplossing, maar eigenlijk doe je dan bijna hetzelfde als wat ze hier met "Blauwdruk" hebben gedaan:
Je hebt je eigen implementatie gebouwd die je zelf moet onderhouden.

Natuurlijk hoef je voor heel veel dingen niet het wiel opnieuw uit te vinden, de logica voor bijvoorbeeld de datepicker is immers al en je hoeft enkel je eigen styling te onderhouden. Maar met elke update van Bootstrap, moet je je fork ook updaten en checken of alles nog werkt naar behoren.

Wat je overigens zegt van die componenten die hun eigen CSS definieren en forceren, sluit ik me volledig bij aan. Al meerdere malen een framework moeten gebruiken dat wel styling toestaat via theming, maar vaak niet verder dan een paar generieke kleurtjes (terwijl UX/VD juist meer wilt dan die kleurtjes, maar wel steevast blijft roepen dat het een Material Design based applicatie wordt). Waardoor je dus inderdaad de huisstijl van het project er doorheen moet forceren (met bijvoorbeeld de "!important" of diepgaande CSS paden die verre van leesbaar zijn)

Het is verstandig om goed na te denken over de wijzigingen die je maakt op de bootstrap code. Meestal is het redelijk eenvoudig om de upstream wijzigingen naar je eigen fork te mergen. Als je zoveel wijzigingen hebt dat dat echt moeilijk begint te worden heb je (als organisatie) er waarschijnlijk genoeg aandacht en dus geld voor over om dat te onderhouden. Maar het is inderdaad een punt van aandacht, of dat zou het moeten zijn.

Het voordeel van bootstrap code is dat er niet echt veel security issues uit voortkomen, maar eventuele bugfixes zijn meestal wel fijn om te mergen.

Na vele jaren ben ik er wel een beetje achter. Meeste ontwikkelaars (en dan niet eens FrontEnd/UX) zijn jong en hebben minder dan 5 jaar ervaring. Als je dus bijvoorbeeld 10 ontwikkelaars indienst hebt is de kans groot dat 7-8 van die 10 minder dan 5 jaar ervaring hebben.

En waar koos jij voor toen je net ontwikkelaar werd? Voor het minder sexy fortran/cobol (of geen idee hoe oud je bent ), of ging je voor de toen nieuwe C++ of iets later C# taal? Of welke keuze er toen ook was.

Als je dan kijkt naar frontend frameworks, daar gebeurd veel. Heel veel. Browsers gaan hard in ontwikkeling en de (nieuwe) frameworks volgen.

Als we dan 7 van de 10 (in mijn ogen junior) ontwikkelaars allemaal springen om hip and happening spullen, dan kom je op keuzes als StencilJS. En dan hoor je "grotendeels positieve" reacties.

Ik denk dat je de plank echt compleet mis slaat. Ten eerste: bron? Of is dit gewoon je onderbuik gevoel omdat je altijd bij bedrijven werkt met een hoge doorstroom?

Doubling rate van ontwikkelaars:
https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
(Uncle Bob heeft hier ook meerdere seminars over gegeven trouwens)

Jobs double:
https://www.ciodive.com/n...yment-growth-rate/563304/
(en waar denk je dat die mensen vandaan komen? uit de 5+ jaar ervaring pool?)

Toen ik een kleine 23-25 jaar geleden software ontwikkelaar werd waren er geen echte opleidingen hiervoor binnen Nederland te vinden. Misschien als je heel goed zocht, misschien op de universiteit (helaas was mijn vooropleiding daarvoor te laag). Je kon ook bijna geen andere software ontwikkelaars vinden.

Inmiddels is daar echt heel veel verandering in gekomen, en dat is echt te merken. De gemiddelde CV die langs mijn bureau kwam (toen ik daarvoor verantwoordelijk was) heeft echt minder dan 5 jaar aan ervaring er op staan. En mensen met 3 jaar noemen zich ook vaak "Senior".

Als je vraagt "waarom willen nieuwe software developers het nieuwste gebruiken", tja dat is inderdaad "een gevoel" wat ik heb gekregen met de ervaring met juniors. Misschien als ik even door google dat ik ook daar nog wel research/links voor kan vinden.

De grote grap is dat ik het niet eens heel negatief zie. Behalve als de persoon in kwestie tegenover mij zegt "het is beter want het internet zegt dat" (die heb ik gehad), of "omdat het nieuwer is".

Ik denk dat hij daar helemaal gelijk in heeft. Zelf ik merk ik dat ook (20 jaar ervaring). Het nieuwste framework is altijd het beste framework. Jonge engineers hebben de neiging om alle ins en outs van een framework te leren, maar niet begrijpen vaak niet waarom het framework nodig is, welke gaten vult het op en is het wel de juiste tool voor het project.

StencilJS is bedacht door Ionic (een framework om hybride apps voor Android en iOS te bouwen). Ionic https://ionicframework.com/ is (onder andere) een set aan componenten die de look & feel van iOS en Android componenten nabootst met web technologie.

Ionic heeft support voor Angular, React en Vue. Om de set van componenten tussen deze frameworks te kunnen delen hadden ze een compiler nodig om de componenten compatible te maken met deze frameworks. Dat is waarom StencilJS is bedacht. En dat is best logisch eigenlijk. Maar je zou het niet moeten gebruiken om je componenten librarie mee op te bouwen. Daarvoor zijn er meer geschiktere libraries zoals Lit element. Dat laatste is een mening overigens

[Reactie gewijzigd door hakog2 op 25 mei 2021 14:41]

"Inner-sourced open source"... klinkt meer als marketing prietpraat.

"Bij het bouwen in Angular kwam het team ook een technische bottleneck tegen, vertelt hij. “Niet alle projecten bij de politie die met Angular zijn geschreven maken gebruik van dezelfde versie." en wat nu als verschillende componenten, verschillende versies van StencilJS gaan gebruiken.

Blijft volgens mij nog steeds een pot nat. Noem het Angular / Stencil / Whatever...componenten zullen geupdate moeten worden.

+1 Humor voor 'Blauwdruk' bij de Politie

En nog meer +1 voor de naam van hun chatbot:
Wout

Dus je ontwikkelt een library op basis van een library maar dat werkt niet omdat niet iedereen op dezelfde versie zit van die basis library. En ipv de achterblijvers te helpen met updaten ontwikkel je een nieuwe library zodat iedereen moet updaten.
Logisch?

Inner sourced opensource-project

Dus iedereen kan gewoon pull requests maken binnen het bedrijf?

Dat is niet echt opensource Dat is gewoon intern git gebruiken.

Maar dit klinkt hipper dan Git natuurlijk 🙃

Het idee dat teams aan een product kunnen werken wat niet het product van hun team is, dat is niet de norm.

Een nadeel is dat de library minder compleet is dan wat al in Angular is te vinden, dus we moeten zelf meer bijbouwen. Daar zijn we inmiddels mee begonnen.

En daarom lopen de kosten van overheids IT altijd uit de hand, ze willen hun eigen wiel uitvinden.

Doet mij een beetje denken aan SOA. Standaard service die elke keer opgeroepen en hergebruikt kunnen worden in verschillende situaties, op verschillende momenten en in verschillende omgevingen.