Frameworkless movement

[Janoz]

Uhmmie schreef op woensdag 7 april 2021 @ 13:32:
Ik ben dan ook wel fan van de Frameworkless movement.

Wut?? Ik zag dit staan en het kwam op mij wat raar over. Ik heb het even doorgelezen, maar het enige wat ik daarop kan verzinnen is eigenlijk..

[Uhmmie]

Even voor de duidelijkheid
De quote hierboven komt uit een langere post mbt mijn ervaring met PHP. Die context is nu helaas helemaal weg. Ik kan me heel goed voorstellen dat dit totaal niet opgaat in het geval van C# met .NET of bij Java met Spring.

Ik heb in het andere topic ook meerdere malen aangegeven dat ik niet zeg dat je nooit frameworks moet gebruiken (dat staat overigens ook heel duidelijk op die pagina uit de quote). Waar het mij om gaat is dat ik er geen fan van ben dat men bij de start van een nieuwe project direct begint met het opzetten van een framework. Ik ben van mening dat wanneer je eerst je domein logica ontwikkeld in combinatie met de juiste packages/libraries (Wat overigens heel makkelijk gaat in PHP met composer. Ook voor onderdelen van symfony of laravel). Je pas daarna moet gaan kijken of dit allemaal past binnen een framework.

Als dat lukt? Mooi dan gebruik je dat framework. Maar op het moment dat dat niet past heb je nog een anderen keuze. Echter op het moment dat je het project begonnen bent met een framework en je komt er dan achter dat het niet past dan heb je een enorm probleem.

Janoz schreef op donderdag 8 april 2021 @ 17:30:
[...]


Wut?? Ik zag dit staan en het kwam op mij wat raar over. Ik heb het even doorgelezen, maar het enige wat ik daarop kan verzinnen is eigenlijk..

[Afbeelding]

Misschien is het bij C# wat minder logisch, maar bij PHP werkt dit prima. Dit betekend echt niet dat je alles zelf gaat ontwikkelen, want je haalt gewoon je benodigde packages binnen met composer. Het is hoogstens wat extra configuratie in het begin van je project, maar het zorgt vaak voor heel wat minder kopzorgen, zodra je wat verder gevorderd bent en iets net wat anders wilt doen dan hoe het framework het wilt. Je kan zaken ook veel beter isoleren.

Daarnaast zie je bij PHP vaak dat het framework een heleboel dicteert, waardoor je totaal geen keuze meer hebt in hoe je werkt.

Als dat aansluit bij wat je nodig hebt dan werkt dat prima. Maar ik heb ook vaak genoeg gevallen gezien waarin dit niet het geval is. Ik zeg dan ook vaak dat frameworks (in PHP) vaak prima voor kleine projecten zijn, maar dat ik voor grotere projecten toch echt liever de volledige keuze vrijheid heb en dat is zeker die eerste extra stap van configureren waard.

[edit]
En nog als toevoeging.. Ik gebruik soms echt wel frameworks, maar dat ga ik pas gebruiken nadat ik de domein logica geschreven heb.. Ik gebruik het framework dan eigenlijk alleen nog maar voor niet domein gerelateerde zaken (route, database toegang, etc, etc). Dat is dan ook weer zo te vervangen als een framework eol gaat etc.

[ Voor 45% gewijzigd door Uhmmie op 12-04-2021 09:20 ]

[NMe]

Uhmmie schreef op donderdag 8 april 2021 @ 18:03:
[...]

Misschien is het bij C# wat minder logisch, maar bij PHP werkt dit prima. Dit betekend echt niet dat je alles zelf gaat ontwikkelen, want je haalt gewoon je benodigde packages binnen met composer. Het is hoogstens wat extra configuratie in het begin van je project, maar het zorgt vaak voor heel wat minder kopzorgen, zodra je wat verder gevorderd bent en iets net wat anders wilt doen dan hoe het framework het wilt. Je kan zaken ook veel beter isoleren.

Zonder framework werken in PHP is dramatisch. PHP heeft enorm veel tekortkomingen en juist daarom zijn er zo veel goeie frameworks voor gemaakt. Er zullen vast talen zijn waar zonder framework developen handiger kan zijn maar PHP is er daar absoluut geen van, en dat zeg ik als iemand die ruim 15 jaar professionele ervaring heeft met voornamelijk PHP.

Daarnaast zie je bij PHP vaak dat het framework een heleboel dicteert, waardoor je totaal geen keuze meer hebt in hoe je werkt.

Ofwel je hebt naar de verkeerde frameworks gekeken, ofwel je wil echt veel te veel controle hebben over hoe dingen werken. Ik heb me in Symfony nog nooit beperkt gevoeld in wat ik wel en niet kon doen, en hoewel ik zelf geen fan van Laravel ben heb ik anderen hetzelfde over Laravel horen zeggen.

[ Voor 24% gewijzigd door NMe op 11-04-2021 13:52 ]

[Uhmmie]

NMe schreef op zondag 11 april 2021 @ 13:49:
[...]

Zonder framework werken in PHP is dramatisch. PHP heeft enorm veel tekortkomingen en juist daarom zijn er zo veel goeie frameworks voor gemaakt. Er zullen vast talen zijn waar zonder framework developen handiger kan zijn maar PHP is er daar absoluut geen van, en dat zeg ik als iemand die ruim 15 jaar professionele ervaring heeft met voornamelijk PHP.

[...]

Ofwel je hebt naar de verkeerde frameworks gekeken, ofwel je wil echt veel te veel controle hebben over hoe dingen werken. Ik heb me in Symfony nog nooit beperkt gevoeld in wat ik wel en niet kon doen, en hoewel ik zelf geen fan van Laravel ben heb ik anderen hetzelfde over Laravel horen zeggen.

Ik ben benieuwd wat een framework kan, wat je niet bijna net zo snel kan bereiken met packages via composer? Ik blijf gewoon zelf mijn packages kiezen net zo fijn werken dan dat die keuze voor mij gemaakt wordt in een framework. Het is niet dat ik alles zelf ga zitten programmeren.

Frameworks zorgen ervoor dat je sneller kan beginnen, maar bij echt grote projecten kan het je op den duur ook heel veel extra tijd gaan kosten.

Ga maar eens even een project migreren van symfony 2 naar symfony 4 (en dan heb ik het niet over een website van de bakker om de hoek).

Als je je domein logica heel netjes opgesplitst hebt, dan is het nog redelijk goed te doen, maar in alle andere gevallen is het echt een drama.

Nee dan heb ik toch echt liever dat ik zelf mijn packages kies met mijn eigen decorators/wrappers er omheen gebouwd, zodat ik ze op ieder moment vrij makkelijk en snel kan vervangen indien dat nodig is.

[YakuzA]

Janoz schreef op donderdag 8 april 2021 @ 17:30:
[...]


Wut?? Ik zag dit staan en het kwam op mij wat raar over. Ik heb het even doorgelezen, maar het enige wat ik daarop kan verzinnen is eigenlijk..

[Afbeelding]

Frameworkless programmeren wordt moeilijk als je al begint met het .NET framework idd

[Uhmmie]

YakuzA schreef op zondag 11 april 2021 @ 14:21:
[...]

Frameworkless programmeren wordt moeilijk als je al begint met het .NET framework idd

Ja daarom gaf ik ook al aan dat het bij C# misschien wel wat anders ligt ivm .NET.

[NMe]

Uhmmie schreef op zondag 11 april 2021 @ 14:17:
[...]

Ik ben benieuwd wat een framework kan, wat je niet bijna net zo snel kan bereiken met packages via composer? Ik blijf gewoon zelf mijn packages kiezen net zo fijn werken dan dat die keuze voor mij gemaakt wordt in een framework. Het is niet dat ik alles zelf ga zitten programmeren.

Packages werken niet op magische wijze ineens samen.

Ga maar eens even een project migreren van symfony 2 naar symfony 4 (en dan heb ik het niet over een website van de bakker om de hoek).

Dan heb je sowieso al niet heel goed je best gedaan als ontwikkelaar, want je hebt de site niet door de jaren heen bijgehouden. Ja, het kan, de LTS-versie van 2 ging pas EOL nadat Symfony 4 uitkwam, maar daar is ook alles mee gezegd. En dan nog: jij hebt met je losse packages exact hetzelfde gezeik als daar een major opgehoogd wordt, alleen dan vaker omdat elke package zijn eigen updateschema aanhoudt.

Nee dan heb ik toch echt liever dat ik zelf mijn packages kies met mijn eigen decorators/wrappers er omheen gebouwd, zodat ik ze op ieder moment vrij makkelijk en snel kan vervangen indien dat nodig is.

Sorry, maar het klinkt echt enorm als "NIH" en ik kan dit echt niet serieus nemen. Een framework ondersteunt je, besluiten dat je het zelf beter kan dan een community vol getalenteerde developers is nogal jammer. Een framework doet véél meer dan een paar bijeen geraapte packages.

[Uhmmie]

NMe schreef op zondag 11 april 2021 @ 15:04:
[...]

Packages werken niet op magische wijze ineens samen.


[...]

Dan heb je sowieso al niet heel goed je best gedaan als ontwikkelaar, want je hebt de site niet door de jaren heen bijgehouden. Ja, het kan, de LTS-versie van 2 ging pas EOL nadat Symfony 4 uitkwam, maar daar is ook alles mee gezegd. En dan nog: jij hebt met je losse packages exact hetzelfde gezeik als daar een major opgehoogd wordt, alleen dan vaker omdat elke package zijn eigen updateschema aanhoudt.


[...]

Sorry, maar het klinkt echt enorm als "NIH" en ik kan dit echt niet serieus nemen. Een framework ondersteunt je, besluiten dat je het zelf beter kan dan een community vol getalenteerde developers is nogal jammer. Een framework doet véél meer dan een paar bijeen geraapte packages.

Nee natuurlijk werken packages niet automatisch samen. Maar heel spectaculair is het ook niet wat er in symfony of laravel gebeurd.

En ja met packages moet je vaker kleinere migraties uitvoeren. Maar als je ze goed geïsoleerd hebt is dat ook maar op 1 plek in je software en stellen ze vaak niet veel voor.

Ik schrijf ook nergens dat ik het beter kan dan een framework. Dat maak jij ervan. Ik schrijf alleen dat ik de keuze vrijheid in mijn packages belangrijker vind, dan de voordelen van een framework.

En daarnaast lees je over het feit heen, dat ik al aangaf dat ik in bepaalde situaties nog steeds een framework gebruik. Maar het is niet mijn eerste stap als ik begin te ontwikkelen aan een project.

[ Voor 6% gewijzigd door Uhmmie op 11-04-2021 15:54 ]

[Janoz]

IK heb het topic even afgesplitst zodat het oude topic over Unitiy vs Unreal kan blijven gaan en we het hier over de Frameworkless movement kunnen hebben.

[Hydra]

Uhmmie schreef op zondag 11 april 2021 @ 14:17:
Ik ben benieuwd wat een framework kan, wat je niet bijna net zo snel kan bereiken met packages via composer?

Als ik als Java dev even in mag haken: een framework is eigenlijk weinig anders dan een verzameling libraries die andere mensen voor je samen onderhouden. En dat is de key; dit is een significant stuk werk. In Java land hebben we niet 1 framework; er zijn meerdere concurrerende waarbij Spring veruit de grootste is. Kan ik als Java dev zelf met de hand iets als Spring samenstellen? Tuurlijk. Maar het is gewoon enorm veel werk; waarom zou ik dat zelf willen doen?

Er zijn genoeg Java developers die, gewoon door een gebrek aan ervaring, niet weten hoe veel laagjes er in een API applicatie zitten die allemaal netjes samen moeten werken. Frameworks regelen dit voor je. Je hoeft dan niet je logging, tracing, metrics, externe calls, databases, security en configuratie (just to name a few) allemaal zelf op elkaar af te stemmen. Want ja; dat is nodig. Als je database laag 'tracing' niet snapt, heb je daar een blinde vlek.

Dit allemaal zelf willen doen omdat je denkt dat je het beter kan heeft een naam; Not invented here. 9 van de 10 keer is het beter om een bestaande oplossing te kiezen. De neiging om het zelf te bouwen omdat dat leuk is, en of je het dan beter snapt, is iets wat developers over tijd moeten leren te onderdrukken. Ik heb sterk de neiging te geloven dat mensen die denken dat een "Frameworkless movement" een ding zou moeten zijn, behoorlijk in de categorie "expert beginners" vallen.

[Uhmmie]

Hydra schreef op maandag 12 april 2021 @ 07:58:
[...]


Als ik als Java dev even in mag haken: een framework is eigenlijk weinig anders dan een verzameling libraries die andere mensen voor je samen onderhouden. En dat is de key; dit is een significant stuk werk. In Java land hebben we niet 1 framework; er zijn meerdere concurrerende waarbij Spring veruit de grootste is. Kan ik als Java dev zelf met de hand iets als Spring samenstellen? Tuurlijk. Maar het is gewoon enorm veel werk; waarom zou ik dat zelf willen doen?

Er zijn genoeg Java developers die, gewoon door een gebrek aan ervaring, niet weten hoe veel laagjes er in een API applicatie zitten die allemaal netjes samen moeten werken. Frameworks regelen dit voor je. Je hoeft dan niet je logging, tracing, metrics, externe calls, databases, security en configuratie (just to name a few) allemaal zelf op elkaar af te stemmen. Want ja; dat is nodig. Als je database laag 'tracing' niet snapt, heb je daar een blinde vlek.

Dit allemaal zelf willen doen omdat je denkt dat je het beter kan heeft een naam; Not invented here. 9 van de 10 keer is het beter om een bestaande oplossing te kiezen. De neiging om het zelf te bouwen omdat dat leuk is, en of je het dan beter snapt, is iets wat developers over tijd moeten leren te onderdrukken. Ik heb sterk de neiging te geloven dat mensen die denken dat een "Frameworkless movement" een ding zou moeten zijn, behoorlijk in de categorie "expert beginners" vallen.

Ik durf over Java totaal niet te oordelen. Dus dat ga ik dan ook niet doen. Ik baseer mijn mening op 15 jaar php, met zowel met als zonder frameworks. Ik heb met beide ervaring in grote lange projecten en vanuit die ervaring blijf ik van mening dat frameworks je sneller op weg helpen. Ze ideaal zijn om je te leren beter te programmeren, maar ze bij grotere complexere vraagstukken weldegelijk in de weg kunnen gaan zitten.

Gelijker wil ik ook zo aannemen dat dit niet opgaat voor .net en misschien ook wel voor een spring framework.

[Hydra]

Uhmmie schreef op maandag 12 april 2021 @ 08:16:
Ik durf over Java totaal niet te oordelen. Dus dat ga ik dan ook niet doen. Ik baseer mijn mening op 15 jaar php, met zowel met als zonder frameworks. Ik heb met beide ervaring in grote lange projecten en vanuit die ervaring blijf ik van mening dat frameworks je sneller op weg helpen. Ze ideaal zijn om je te leren beter te programmeren, maar ze bij grotere complexere vraagstukken weldegelijk in de weg kunnen gaan zitten.

Gelijker wil ik ook zo aannemen dat dit niet opgaat voor .net en misschien ook wel voor een spring framework.

Je haalt een link aan naar het "Frameworkless movement" waar toch vrij duidelijk mensen een mening hebben over andere ecosystemen. Voorbeeld: https://github.com/framew...wesome-frameworkless#java

Grappig genoeg is de 'top' link daar een link naar iemand die binnen de Java community nogal 'controversieel' is op z'n minst.

Daarnaast zie je gewoon dat, zoals gebruiken, de JavaScript 'community' weer voorop loopt in het laten zien wat Dunning Kruger inhoudt met maar liefst 13 voorbeelden van "Frameworkless" waarin ze laten zien dat je prima hello-world level front-ends kunt bouwen, zonder tests en zonder een framework. Deze "no shit sherlock" squad heeft volgens mij gewoon te weinig ervaring om in te kunnen zien dat een hoop software wel echt een stukje complexer is.

Ik ben zelf geen PHP dev (laatste keer dat ik er mee gewerkt heb is zo'n 21 jaar geleden) maar als ik mensen hier die wel die ervaring hebben zie zeggen dat Symphony en Laravel dit issue niet hebben, geloof ik dat graag. Ik zie ook in de Java wereld genoeg developers ageren tegen de 'complexiteit' van Spring, maar dat is niks meer dan een gebrek aan ervaring.

[Woy]

Sowieso is het nogal een wazige definitie wanneer je iets een framework noemt, en wanneer gewoon een package.

In veel programmeertalen/eco-systemen wordt gewoon een "framework" meegeleverd als base library. Het is ook zonde om elke keer zelf het wiel opnieuw uit te gaan vinden of om alles zelf te gaan bouwen.

Enige goede punt wat er natuurlijk wel in zit is dat je bij elke dependency die je aanlegt wel weer een extra dependency hebt die ook kosten met zich meedraagt. Maar alle zelf maken/samenstellen brengt ook kosten met zich mee.

Bij het toevoegen van een dependency is het dus wel een goed idee om jezelf even af te vragen of de voordelen opwegen tegen de nadelen. Nou ben ik ook geen PHP developer, maar als ik Symphony en Laravel even gelijk stel aan bijvoorbeeld ASP.NET, dan zou voor de meeste web gereleteerde projecten mijn antwoord daar ja zijn.

[Croga]

Als ik zo de stukken lees dan zie ik er wel wat in.....

Ik kan me zomaar voorstellen dat mensen een framework als een keurslijf zien. Iets wat hún manier van programmeren in de weg zit.

Toen ik zo'n 30 jaar geleden begon met programmeren wat het standpunt: Je moet er alles aan doen om het programmeer proces zo eenvoudig mogelijk te maken voor jezelf. Op die manier is het stukje software wat je bouwt zo goedkoop mogelijk functioneel.

Ondertussen weten we dat dat onzin is. De kosten van software zitten niet in het bouwen. De kosten zitten in zorgen dat het blijft werken. Vandaar ook de Clean Code en Patterns beweging. Dingen bouwen op een manier die er voor zorgt dat het eenvoudig aan te passen en te onderhouden is, is vele malen belangrijker dan het zo eenvoudig mogelijk in elkaar zetten.

Frameworks zijn een belangrijk onderdeel daarvan. Gebruik Spring/Maven, Laravel, WPF/WCF, Symphony en je onderhoudbaarheid en aanpasbaarheid worden beter. Niet alleen voor jezelf maar met name voor anderen.

Zoals @Hydra aanhaalt zullen er vast stukken code te bedenken die meer last dan profijt hebben bij een framework. Maar dat zijn over het algemeen niet de stukken code die nodig zijn om professioneel niveau functionaliteit te realiseren.

Ik ben 2 jaar geleden, na een 15 jaar hiatus, weer naar software development gaan kijken (nou ja, professioneel software development dan. Mijn huis-projectjes ben ik altijd blijven doen). En de eerste keer dat ik met Spring mocht werken was een verademing! Daarna heb ik een codebase gezien van een bedrijf wat al heel wat jaartjes in Spring ontwikkeld en ik had weinig moeite de code te doorgronden. Met name vanwege het gebruik van een framework.

[Uhmmie]

Hydra schreef op maandag 12 april 2021 @ 08:34:
[...]


Je haalt een link aan naar het "Frameworkless movement" waar toch vrij duidelijk mensen een mening hebben over andere ecosystemen. Voorbeeld: https://github.com/framew...wesome-frameworkless#java

Grappig genoeg is de 'top' link daar een link naar iemand die binnen de Java community nogal 'controversieel' is op z'n minst.

Daarnaast zie je gewoon dat, zoals gebruiken, de JavaScript 'community' weer voorop loopt in het laten zien wat Dunning Kruger inhoudt met maar liefst 13 voorbeelden van "Frameworkless" waarin ze laten zien dat je prima hello-world level front-ends kunt bouwen, zonder tests en zonder een framework. Deze "no shit sherlock" squad heeft volgens mij gewoon te weinig ervaring om in te kunnen zien dat een hoop software wel echt een stukje complexer is.

Ik ben zelf geen PHP dev (laatste keer dat ik er mee gewerkt heb is zo'n 21 jaar geleden) maar als ik mensen hier die wel die ervaring hebben zie zeggen dat Symphony en Laravel dit issue niet hebben, geloof ik dat graag. Ik zie ook in de Java wereld genoeg developers ageren tegen de 'complexiteit' van Spring, maar dat is niks meer dan een gebrek aan ervaring.

Hoi Hydra, de quote uit de openingspost is een beetje onhandig, want hierin is 1 regel tekst uit een ​langere post van mij geknipt, waarin ik mijn ervaring met PHP deelde.. Die hele context is nu dus verdwenen in de openingspost.

Daarnaast heeft slecht programmeren volgens mij niks te maken met wel of niet gebruik maken van een framework. Want er zullen ook genoeg mensen code met frameworks schrijven zonder tests .

Woy schreef op maandag 12 april 2021 @ 08:43:
Sowieso is het nogal een wazige definitie wanneer je iets een framework noemt, en wanneer gewoon een package.

In veel programmeertalen/eco-systemen wordt gewoon een "framework" meegeleverd als base library. Het is ook zonde om elke keer zelf het wiel opnieuw uit te gaan vinden of om alles zelf te gaan bouwen.

Enige goede punt wat er natuurlijk wel in zit is dat je bij elke dependency die je aanlegt wel weer een extra dependency hebt die ook kosten met zich meedraagt. Maar alle zelf maken/samenstellen brengt ook kosten met zich mee.

Bij het toevoegen van een dependency is het dus wel een goed idee om jezelf even af te vragen of de voordelen opwegen tegen de nadelen. Nou ben ik ook geen PHP developer, maar als ik Symphony en Laravel even gelijk stel aan bijvoorbeeld ASP.NET, dan zou voor de meeste web gereleteerde projecten mijn antwoord daar ja zijn.

Ik durf niet te zeggen in hoevere .NET iets weg heeft van Symfony of Laravel (leuk feit is dat 1/3 van de codebase van Laravel ook gewoon symfony is). Maar wat veel mensen vergeten is dat 95% van de source van symfony ook gewoon uit packages bestaat en de laatste 5% is de glue die het allemaal verbind.. Dus met het weglaten van symfony als framework raak je vooral de glue kwijt. Ik heb geen die of dat ook mogelijk is bij een spring of .NET?

[Uhmmie]

Uhmmie schreef op donderdag 8 april 2021 @ 18:03:
Even voor de duidelijkheid
De quote hierboven komt uit een langere post mbt mijn ervaring met PHP. Die context is nu helaas helemaal weg. Ik kan me heel goed voorstellen dat dit totaal niet opgaat in het geval van C# met .NET of bij Java met Spring.

Ik heb in het andere topic ook meerdere malen aangegeven dat ik niet zeg dat je nooit frameworks moet gebruiken (dat staat overigens ook heel duidelijk op die pagina uit de quote). Waar het mij om gaat is dat ik er geen fan van ben dat men bij de start van een nieuwe project direct begint met het opzetten van een framework. Ik ben van mening dat wanneer je eerst je domein logica ontwikkeld in combinatie met de juiste packages/libraries (Wat overigens heel makkelijk gaat in PHP met composer. Ook voor onderdelen van symfony of laravel). Je pas daarna moet gaan kijken of dit allemaal past binnen een framework.

Als dat lukt? Mooi dan gebruik je dat framework. Maar op het moment dat dat niet past heb je nog een anderen keuze. Echter op het moment dat je het project begonnen bent met een framework en je komt er dan achter dat het niet past dan heb je een enorm probleem.

Ik heb even mijn eerste post die naar dit topic verplaatst is aangepast om meer content aan mijn uitspraak te geven.

[ Voor 26% gewijzigd door Uhmmie op 12-04-2021 09:20 ]

[Oon]

Hydra schreef op maandag 12 april 2021 @ 07:58:
[...]
Dit allemaal zelf willen doen omdat je denkt dat je het beter kan heeft een naam; Not invented here. 9 van de 10 keer is het beter om een bestaande oplossing te kiezen. De neiging om het zelf te bouwen omdat dat leuk is, en of je het dan beter snapt, is iets wat developers over tijd moeten leren te onderdrukken. Ik heb sterk de neiging te geloven dat mensen die denken dat een "Frameworkless movement" een ding zou moeten zijn, behoorlijk in de categorie "expert beginners" vallen.

Ik heb door de jaren heen zowel met Java als PHP als .NET gewerkt (significant deel PHP, beetje van alles daarbuiten) en ik kan toch alleen maar zeggen dat je hierin een belangrijk punt highlight. Datzelfde zie je ook veel in discussies over bepaalde programmeertalen zelf; mensen die de taal en omgeving wel kennen maar niet echt beheersen. Als écht ervaren developer weet je gewoon wanneer je libraries en/of frameworks toe kan passen om je te helpen, maar ga je echt je tijd niet verdoen met een 'movement' tegen frameworks alsof ze nooit goed toe te passen zijn.

Het is bij PHP wel vaak wat makkelijker om geen libraries toe te passen dan bij .NET of Java, waardoor je heel veel NIH tegenkomt, maar daarvan wordt de code niet beter. Ik zie liever een project met een package waar al enkele jaren geen update van is binnengehaald maar dat wel nette documentatie en comments in de code heeft, dan een project waar alle code zelfgeschreven is, ook nooit aangepast, en waar geen touw aanvast te knopen is.

Ik heb ook heel weinig argumenten gezien van dat soort mensen die niet neerkomen op 'ik wil mijn code niet updaten', en dat vind ik een hele gevaarlijke gedachte.

[Uhmmie]

Oon schreef op maandag 12 april 2021 @ 09:11:
[...]

Ik heb door de jaren heen zowel met Java als PHP als .NET gewerkt (significant deel PHP, beetje van alles daarbuiten) en ik kan toch alleen maar zeggen dat je hierin een belangrijk punt highlight. Datzelfde zie je ook veel in discussies over bepaalde programmeertalen zelf; mensen die de taal en omgeving wel kennen maar niet echt beheersen. Als écht ervaren developer weet je gewoon wanneer je libraries en/of frameworks toe kan passen om je te helpen, maar ga je echt je tijd niet verdoen met een 'movement' tegen frameworks alsof ze nooit goed toe te passen zijn.

Het is bij PHP wel vaak wat makkelijker om geen libraries toe te passen dan bij .NET of Java, waardoor je heel veel NIH tegenkomt, maar daarvan wordt de code niet beter. Ik zie liever een project met een package waar al enkele jaren geen update van is binnengehaald maar dat wel nette documentatie en comments in de code heeft, dan een project waar alle code zelfgeschreven is, ook nooit aangepast, en waar geen touw aanvast te knopen is.

Ik heb ook heel weinig argumenten gezien van dat soort mensen die niet neerkomen op 'ik wil mijn code niet updaten', en dat vind ik een hele gevaarlijke gedachte.

Volgens mij mis je hier toch wel een aantal punten. Ze zijn niet tegen frameworks. Er wordt alleen gesproken over dat het ook prima mogelijk is zonder frameworks.

The Frameworkless Movement is a group of developers interested in developing applications without frameworks. We don't hate frameworks, nor we will ever create campaigns against frameworks, but we perceive the misuse of frameworks as a lack of knowledge regarding technical debt and the availability of alternatives given by the vanilla language or by dedicated libraries.

Dat is een heel groot verschil.

Daarnaast gaat het al helemaal niet over het wel/niet gebruikt van packages/libraries. Ik denk dat iedereen het er wel over eens is dat die heel veel toevoegen.

Ik zou me echt niet kunnen voorstellen om ook maar iets serieus op te zetten zonder packages/libraries.

[ Voor 10% gewijzigd door Uhmmie op 12-04-2021 09:33 ]

[Oon]

Uhmmie schreef op maandag 12 april 2021 @ 09:30:
[...]

Volgens mij mis je hier toch wel een aantal punten. Ze zijn niet tegen frameworks. Er wordt alleen gesproken over dat het ook prima mogelijk is zonder frameworks.

Dat is een heel groot verschil.

Daarnaast gaat het al helemaal niet over het wel/niet gebruikt van packages/libraries. Ik denk dat iedereen het er wel over eens is dat die heel veel toevoegen.

Ik zou me echt niet kunnen voorstellen om ook maar iets serieus op te zetten zonder packages/libraries.

Tja, je kan ook prima fietsen zonder zadel, maar ideaal is het niet.

Ik ben het er niet mee oneens dat sommige frameworks enorm zijn en dat dat niet voor ieder project nodig is, maar er zijn toch echt wel heel veel situaties (grootste deel van web development) waarin een framework een hele hoop werk scheelt en tot een kwalitatief beter en veiliger product leidt.

[Uhmmie]

Oon schreef op maandag 12 april 2021 @ 09:32:
[...]

Tja, je kan ook prima fietsen zonder zadel, maar ideaal is het niet.

Ik ben het er niet mee oneens dat sommige frameworks enorm zijn en dat dat niet voor ieder project nodig is, maar er zijn toch echt wel heel veel situaties (grootste deel van web development) waarin een framework een hele hoop werk scheelt en tot een kwalitatief beter en veiliger product leidt.

Totdat je halverwege het project er achterkomt dat je dat over de snelweg heen moet, en je gekozen framework alleen fietsen ondersteund.

[Croga]

Uhmmie schreef op maandag 12 april 2021 @ 09:34:
[...]

Totdat je halverwege het project er achterkomt dat je dat over de snelweg heen moet, en je gekozen framework alleen fietsen ondersteund.

Dan heb je óf een compleet verkeerd framework gekozen, óf je kunt alsnog de snelweg library toevoegen...

Een framework is niet beperkend (anders is het een slecht framework) maar iets wat mogelijkheden geeft.

[Lethalis]

Uhmmie schreef op maandag 12 april 2021 @ 09:34:
[...]
Totdat je halverwege het project er achterkomt dat je dat over de snelweg heen moet, en je gekozen framework alleen fietsen ondersteund.

Kun je daar een praktisch voorbeeld bij geven?

[Oon]

Uhmmie schreef op maandag 12 april 2021 @ 09:34:
[...]

Totdat je halverwege het project er achterkomt dat je dat over de snelweg heen moet, en je gekozen framework alleen fietsen ondersteund.

Daarom kies je een framework dat alle transport ondersteunt, waarbij je zelf kan kiezen welke voertuigen je daadwerkelijk gebruikt.

Dat is het hele mooie aan bijv. Laravel, je kan helemaal zelf kiezen wat je wel en niet gebruikt, met relatief weinig overhead. Heb je een hele ingewikkelde query dan kun je zelfs de raw query optie gebruiken ipv de query builder, en alle code kun je overriden en toch gebruik maken van de rest.

Als je een goed framework gebruikt maakt het niet uit of je op de snelweg of achteraf moet rijden, die maakt van je fiets automatisch een auto waar nodig of geeft je een optie (dmv config of losse packages) om die achteraf toe te voegen.

[Lethalis]

Oon schreef op maandag 12 april 2021 @ 09:11:
[...]
Het is bij PHP wel vaak wat makkelijker om geen libraries toe te passen dan bij .NET of Java, waardoor je heel veel NIH tegenkomt, maar daarvan wordt de code niet beter.

Het grote gevaar van de "expert beginner" is dat hij of zij het allemaal niet meer zo lastig vindt, ook niet bij .NET of Java Dus kan er van alles gebeuren.

Maar de grap is dat ze uiteindelijk altijd zelf hun eigen "framework" bouwen.

Ik kan het weten, want ik heb mij daar zelf vroeger schuldig aan gemaakt. Bij mij is alleen ergens wel de wijsheid gekomen dat het allemaal zonde van de tijd is en ik beter gewoon een bestaand framework kan gebruiken. Zelfs al werkt het anders dan ik zelf zou willen, dan nog is het beter.

Dat was in mijn geval eigenlijk de moeilijkste stap... accepteren dat niet altijd alles precies is zoals ik het wil.

[Uhmmie]

Croga schreef op maandag 12 april 2021 @ 09:39:
[...]

Dan heb je óf een compleet verkeerd framework gekozen, óf je kunt alsnog de snelweg library toevoegen...

Een framework is niet beperkend (anders is het een slecht framework) maar iets wat mogelijkheden geeft.

Oon schreef op maandag 12 april 2021 @ 09:42:
[...]

Daarom kies je een framework dat alle transport ondersteunt, waarbij je zelf kan kiezen welke voertuigen je daadwerkelijk gebruikt.

Dat is het hele mooie aan bijv. Laravel, je kan helemaal zelf kiezen wat je wel en niet gebruikt, met relatief weinig overhead. Heb je een hele ingewikkelde query dan kun je zelfs de raw query optie gebruiken ipv de query builder, en alle code kun je overriden en toch gebruik maken van de rest.

Als je een goed framework gebruikt maakt het niet uit of je op de snelweg of achteraf moet rijden, die maakt van je fiets automatisch een auto waar nodig of geeft je een optie (dmv config of losse packages) om die achteraf toe te voegen.

Lethalis schreef op maandag 12 april 2021 @ 09:40:
[...]

Kun je daar een praktisch voorbeeld bij geven?

Ik heb wel een voorbeeldje, zonder dat we meteen heel complex gaan worden. We gaan dan wel een aantal jaar terug.

We maakte gebruik van Symfony met Doctrine. Op een gegeven moment hadden we een reden waarom we de auto-incremental ids moesten vervangen door een uuid als primary key. Helaas werd dat op dat moment niet ondersteund door doctrine. Er was toen wel al een mogelijkheid om je eigen ids te generen, maar helaas pakte dat toch anders uit dan gewenst. We hebben toen ook nog contact gehad met een ontwikkelaar van Doctrine en hun gaven toen zelf ook aan dat het op dat moment nog niet mogelijk was, maar dat ze wel met een oplossing bezig waren.
Op dat moment zit je muurvast. Niet alleen in doctrine, maar ook in symfony aangezien je totdat moment alles netjes via de de gangbare manier hebt opgezet.

[hellfighter87]

Ik heb bovenstaande even doorgelezen, en zoals ik het begrijp (en dat kan natuurlijk ook verkeerd zijn)
gaat frameworkless helemaal niet over het niet gebruiken van frameworks, maar meer over het volgende (even uit het eco systeem van PHP):

Wat je vaak in projecten ziet is dat iemand een bepaald framework fijn vind en daar dus alles van pakt:
voor rendering: symfony
voor routing: symfony
voor injection: symfony
etc.

terwijl framework less meer uitgaat van, pak voor elke functionaliteit de beste optie
voor rendering: symfony
voor routing: laravel
voor injection: ?
etc.

De PSR standaarden binnen PHP zijn interfaces die bepalen: als router krijg je deze input, en moet je deze output terug geven, verder of het ding cached en of andere logica heeft wat hem beter maakt dan een andere router moet die package zelf weten.

Maar door die gestandaardiseerde interfaces zijn de packages compatbible met elkaar.
En dat kan je in elke taal bereiken.

Waarom zou je dit doen:
omdat als je library 1 gebruikt, en die heeft een renderer, router, injection etc. dat misschien de router niet aansluit op wat jij wil, en in plaats van er omheen te werken, gebruik je een andere router die wel jou gewenste functionaliteit heeft.

Het nadeel is natuurlijk, als je alles van symfony gebruikt, dan weet je ook wat je met de rest kan.

[Uhmmie]

hellfighter87 schreef op maandag 12 april 2021 @ 10:10:
Ik heb bovenstaande even doorgelezen, en zoals ik het begrijp (en dat kan natuurlijk ook verkeerd zijn)
gaat frameworkless helemaal niet over het niet gebruiken van frameworks, maar meer over het volgende (even uit het eco systeem van PHP):

Wat je vaak in projecten ziet is dat iemand een bepaald framework fijn vind en daar dus alles van pakt:
voor rendering: symfony
voor routing: symfony
voor injection: symfony
etc.

terwijl framework less meer uitgaat van, pak voor elke functionaliteit de beste optie
voor rendering: symfony
voor routing: laravel
voor injection: ?
etc.

De PSR standaarden binnen PHP zijn interfaces die bepalen: als router krijg je deze input, en moet je deze output terug geven, verder of het ding cached en of andere logica heeft wat hem beter maakt dan een andere router moet die package zelf weten.

Maar door die gestandaardiseerde interfaces zijn de packages compatbible met elkaar.
En dat kan je in elke taal bereiken.

Waarom zou je dit doen:
omdat als je library 1 gebruikt, en die heeft een renderer, router, injection etc. dat misschien de router niet aansluit op wat jij wil, en in plaats van er omheen te werken, gebruik je een andere router die wel jou gewenste functionaliteit heeft.

Het nadeel is natuurlijk, als je alles van symfony gebruikt, dan weet je ook wat je met de rest kan.

Nice dat is dus inderdaad precies wat ik bedoel. Bedankt voor de heldere omschrijving.

[Oon]

Uhmmie schreef op maandag 12 april 2021 @ 10:09:
[...]


[...]


[...]


Ik heb wel een voorbeeldje, zonder dat we meteen heel complex gaan worden. We gaan dan wel een aantal jaar terug.

We maakte gebruik van Symfony met Doctrine. Op een gegeven moment hadden we een reden waarom we de auto-incremental ids moesten vervangen door een uuid als primary key. Helaas werd dat op dat moment niet ondersteund door doctrine. Er was toen wel al een mogelijkheid om je eigen ids te generen, maar helaas pakte dat toch anders uit dan gewenst. We hebben toen ook nog contact gehad met een ontwikkelaar van Doctrine en hun gaven toen zelf ook aan dat het op dat moment nog niet mogelijk was, maar dat ze wel met een oplossing bezig waren.
Op dat moment zit je muurvast. Niet alleen in doctrine, maar ook in symfony aangezien je totdat moment alles netjes via de de gangbare manier hebt opgezet.

Maar dat is iets dat je bij je eigen framework ook had gehad, misschien zelfs nog erger afhankelijk van hoe netjes het in elkaar zat. Dat is overigens ook wel een extreme vraag waar zo goed als geen net antwoord op is, want primary keys zijn iets waar je over het algemeen vanaf blijft. Nou is het tegenwoordig zo dat bijv. Laravel heel makkelijk toestaat om een andere primary key te gebruiken, maar dan nog is het 9/10 keer het beste om gewoon een auto increment ID te gebruiken

[Oon]

hellfighter87 schreef op maandag 12 april 2021 @ 10:10:
Ik heb bovenstaande even doorgelezen, en zoals ik het begrijp (en dat kan natuurlijk ook verkeerd zijn)
gaat frameworkless helemaal niet over het niet gebruiken van frameworks, maar meer over het volgende (even uit het eco systeem van PHP):

Wat je vaak in projecten ziet is dat iemand een bepaald framework fijn vind en daar dus alles van pakt:
voor rendering: symfony
voor routing: symfony
voor injection: symfony
etc.

terwijl framework less meer uitgaat van, pak voor elke functionaliteit de beste optie
voor rendering: symfony
voor routing: laravel
voor injection: ?
etc.

De PSR standaarden binnen PHP zijn interfaces die bepalen: als router krijg je deze input, en moet je deze output terug geven, verder of het ding cached en of andere logica heeft wat hem beter maakt dan een andere router moet die package zelf weten.

Maar door die gestandaardiseerde interfaces zijn de packages compatbible met elkaar.
En dat kan je in elke taal bereiken.

Waarom zou je dit doen:
omdat als je library 1 gebruikt, en die heeft een renderer, router, injection etc. dat misschien de router niet aansluit op wat jij wil, en in plaats van er omheen te werken, gebruik je een andere router die wel jou gewenste functionaliteit heeft.

Het nadeel is natuurlijk, als je alles van symfony gebruikt, dan weet je ook wat je met de rest kan.

Je vergeet alleen dat dat precies is wat de meeste frameworks al doen. Laravel is voor een groot deel Symfony packages, en is heel makkelijk uit te breiden met andere packages naar keuze.

Een goed framework is een platform om op verder te bouwen met eigen/andere code, maar dat wil niet zeggen dat het framework zelf geen toegevoegde waarde heeft

[Uhmmie]

Oon schreef op maandag 12 april 2021 @ 10:11:
[...]


Maar dat is iets dat je bij je eigen framework ook had gehad, misschien zelfs nog erger afhankelijk van hoe netjes het in elkaar zat. Dat is overigens ook wel een extreme vraag waar zo goed als geen net antwoord op is, want primary keys zijn iets waar je over het algemeen vanaf blijft. Nou is het tegenwoordig zo dat bijv. Laravel heel makkelijk toestaat om een andere primary key te gebruiken, maar dan nog is het 9/10 keer het beste om gewoon een auto increment ID te gebruiken

Maar het verschil is, dat ik eerst mijn domein logica programeer met packages die daarvoor geschikt zijn, niet met packages die mee komen met het framework..

Door eerst mijn domein logica te ontwikkelen met de juiste packages (die op die manier dmv wrappers ook makkelijk te vervangen zijn) kan ik heel specifiek de dingen pakken die het beste bij mijn wens aansluiten.. Pas op het allerlaatste moment wanneer ik alles aan elkaar ga lijmen kan ik kiezen voor een framework (of niet).

[Croga]

Uhmmie schreef op maandag 12 april 2021 @ 10:18:
Maar het verschil is, dat ik eerst mijn domein logica programeer met packages die daarvoor geschikt zijn, niet met packages die mee komen met het framework..

Door eerst mijn domein logica te ontwikkelen met de juiste packages (die op die manier dmv wrappers ook makkelijk te vervangen zijn) kan ik heel specifiek de dingen pakken die het beste bij mijn wens aansluiten.. Pas op het allerlaatste moment wanneer ik alles aan elkaar ga lijmen kan ik kiezen voor een framework (of niet).

Met als gevolg dat het voor nieuwelingen heel lastig is om jouw code te begrijpen. Resultaat; Slechte aanpasbaarheid en onderhoudbaarheid.

Terwijl het omdraaien geen wezenlijk verschil oplevert:
Kies je framework
Bouw je domein logica op de manier die het meest gebruikelijk is in het framework
Voeg packages toe waar het framework niet toereikend is

Gevolg: Iedereen die ooit in het framework gewerkt heeft kan relatief eenvoudig door je code heen.

Het extra werk wat jij moet doen om je code in het framework te krijgen weegt niet op tegen de enorme tijdswinst die in de toekomst behaald zal worden. De experts achter Clean Code en Design Patterns hebben hier uitgebreid onderzoek naar gedaan en de eind conclusie was dat de originele codeer-tijd in het niet valt bij de tijd die nodig is om een product te onderhouden. De conclusie was dat wanneer je twee keer zoveel tijd nodig hebt om originele code te schrijven, een 5% verbetering van onderhoudbaarheid het nogsteeds waard is.

[Uhmmie]

Croga schreef op maandag 12 april 2021 @ 10:25:
[...]

Met als gevolg dat het voor nieuwelingen heel lastig is om jouw code te begrijpen. Resultaat; Slechte aanpasbaarheid en onderhoudbaarheid.

Terwijl het omdraaien geen wezenlijk verschil oplevert:
Kies je framework
Bouw je domein logica op de manier die het meest gebruikelijk is in het framework
Voeg packages toe waar het framework niet toereikend is

Gevolg: Iedereen die ooit in het framework gewerkt heeft kan relatief eenvoudig door je code heen.

Het extra werk wat jij moet doen om je code in het framework te krijgen weegt niet op tegen de enorme tijdswinst die in de toekomst behaald zal worden. De experts achter Clean Code en Design Patterns hebben hier uitgebreid onderzoek naar gedaan en de eind conclusie was dat de originele codeer-tijd in het niet valt bij de tijd die nodig is om een product te onderhouden. De conclusie was dat wanneer je twee keer zoveel tijd nodig hebt om originele code te schrijven, een 5% verbetering van onderhoudbaarheid het nogsteeds waard is.

Volgens mij scheelt onze aanpak niet eens zo heel veel. Want ik kan mijn domein logica prima gebruik laten maken van bv allerlei symfony packages, alleen op het eind heb ik nog wel de keuze om laravel te gebruiken voor niet domein relevante code, om wat voor een reden dan ook. Misschien wel omdat we een developer in dienst hebben die liever in laravel ontwikkeld. Ik zeg niet dat dat aan te raden is (alhoewel die twee enorm dicht bij elkaar liggen).

Jij past je developers aan de software aan (door iedereen symfony te laten leren). Ik pas mijn software aan aan de developers (waar kunnen we als team het meeste mee berijken). En ja mensen moeten in een bedrijf niet zelf zomaar die keuzes gaan maken, maar ik neem aan dat dit soort keuzes besproken worden in een meeting.

[Woy]

Uhmmie schreef op maandag 12 april 2021 @ 08:51:
[...]
Ik durf niet te zeggen in hoevere .NET iets weg heeft van Symfony of Laravel (leuk feit is dat 1/3 van de codebase van Laravel ook gewoon symfony is). Maar wat veel mensen vergeten is dat 95% van de source van symfony ook gewoon uit packages bestaat en de laatste 5% is de glue die het allemaal verbind.. Dus met het weglaten van symfony als framework raak je vooral de glue kwijt. Ik heb geen die of dat ook mogelijk is bij een spring of .NET?

Maar als ik die 5% glue zelf moet gaan schrijven, gaat dat nog ten koste van het project dat ik daadwerkelijk uit wil voeren. Als je zelf dat soort glue schrijft moet je het ook nog eens gaan onderhouden.

Natuurlijk kun je in .NET ook gewoon cherry picking doen van packages. Sommige packages/frameworks hebben wat beter aan scheiding gedaan dan anderen. Maar bij goed opgezette frameworks/packages heb je gewoon een hoop synergie die zonde is om weg te gooien.

Maar dat verandert niks aan het feit dat je een goede afweging moet maken of je een dependency wil toevoegen of niet. Zonder dependency's ga je niet efficient wat voor elkaar krijgen, maar je wil ook niet voor alles een dependency toevoegen.

Daarbij is het ook belangrijk hoe je de rest van je code opzet. Als je alles volledig als spaghetti monster opzet dan ga je grotere problemen hebben, maar dat is niet de schuld van een framework/package. Alles heeft een cost, zowel zelf dingen maken als gebruik maken van packages/frameworks, dus je zult er een goede afweging voor moeten maken.

Maar het idee van een "Frameworkless movement" vind ik nogal idioot. Dat soort zwart-witte statements kan ik niet zo heel veel mee. Op hun pagina zelf zijn ze natuurlijk ook minder zwart-wit, maar puur de naam al zorgt al dat ik er niet veel vertrouwen in heb

[ Voor 6% gewijzigd door Woy op 12-04-2021 10:48 ]

[Croga]

Uhmmie schreef op maandag 12 april 2021 @ 10:36:
Jij past je developers aan de software aan (door iedereen symfony te laten leren). Ik pas mijn software aan aan de developers (waar kunnen we als team het meeste mee berijken). En ja mensen moeten in een bedrijf niet zelf zomaar die keuzes gaan maken, maar ik neem aan dat dit soort keuzes besproken worden in een meeting.

Iets met "arguments not in evidence"...
Het gaat mij om de volgorde, niet welk specifiek framework.... Als het team zegt dat Laravel beter werkt dan Symphony dan ga vooral je gang, ik schrijg nergens Symphony voor. Ik zeg alleen dat de manier van software ontwikkelen aanpassen aan het framework een goede manier is om de onderhoudbaarheid te verbeteren. En dat kan niet wanneer je eerst een stuk code bouwt en pas daarna je framework kiest. Tenzij je al die gebouwde code achteraf gaat aanpassen (en dat is een beetje QED voor mijn stelling.......)

[Johnny]

Een slecht gekozen framework kan een slechtere keus zijn dan een weloverwogen keuze voor geen framework. Maar uiteindelijk is er ook een factor geluk omdat je van te voren niet weet hoe de applicatie en frameworks zich gaan ontwikkelen.

Voor PHP zijn er heel erg veel dramatisch slechte frameworks. Hierboven worden steeds Laravel/Symfony genoemd, dat is momenteel de populairste. Dat zijn de uitzonderingen. Enkele jaren geleden was Zend helemaal hot, inmiddels zijn die projecten verdwenen of hebben ze grote rewrites gedaan naar Symfony.

De meerderheid van PHP-frameworks is van bedenkelijke kwaliteit, moeilijk uit te breiden en legt een bepaalde manier van werken op die misschien niet past met je doelstellingen. Misschien wel in het begin, als je applicatie nog niet zo veel doet, dan is het makkelijk op gang komen en leuk voor de developers om wat nieuws te proberen.

Maar na een jaar begin je tegen de beperkingen op te lopen. Dan blijk dat er wel vaak security updates nodig zijn, en dat de updates bestaande functionaliteit breken, na een paar jaar komen er helemaal geen updates meer. Dan fork je uiteindelijk het framework om zelf aanpassingen er in te kunnen maken. Uiteindelijk wil niemand er meer mee werken en moet je overstappen op een ander framework en begint het hele verhaal weer opnieuw. Misschien kan je op zo'n moment beter de functionaliteit die je wel gebruikt zelf implementeren in plaats van een volledig nieuw framework er proberen in te schuiven waar je geen ervaring mee hebt.

[Hydra]

Johnny schreef op maandag 12 april 2021 @ 11:17:
Voor PHP zijn er heel erg veel dramatisch slechte frameworks.

Dat is de kern van het verhaal en denk ik ook de reden dat je dit 'frameworkless' gebeuren bij front-end mensen vandaan ziet komen. Het is gewoon de verkeerde vervolgstap op de "Mijn framework is slecht" conclusie. Niks meer dan dat.

[kwaakvaak_v2]

Grappig... maar als je je vervolgens bedenkt dat veel frameworks in PHP eigenlijk vaak ook een geopinieerde samenvoeging van meerdere packages zijn met wat glue code al dan niet afgedwongen door één van de PSR standaarden zijn.

Vraag ik mij dan toch ook een beetje af of de upgrade tijd die nodig is als één van de packages ineens besluit een andere richting op te gaan het conversie / migratie traject nu echt veel minder werk is dan bij een framework die precies hetzelfde doet, maar waarbij de maintainers in ieder geval de verschillen in kaart hebben gebracht, en als je beetje courant framework hebt je zeker niet de enige bent die deze migratie uitvoert.

[drm]

Ik begrijp niet zo goed hoe ik uit dat manifesto op moet maken dat je geen frameworks moet gebruiken? Of kunnen we gewoon concluderen dat het een erg slecht gekozen naam is voor een "movement"?

[Hydra]

drm schreef op maandag 12 april 2021 @ 15:48:
Ik begrijp niet zo goed hoe ik uit dat manifesto op moet maken dat je geen frameworks moet gebruiken? Of kunnen we gewoon concluderen dat het een erg slecht gekozen naam is voor een "movement"?

Sowieso heeft het natuurlijk echt nul inhoud. Daarbij is hun awesome list zo dood als een pier, evenals het manifesto zelf. Wat mijn eigen reactie betreft; die gaat meer in op het princiepe achter dit soort ideeen en dat is dat het gewoon vaak een gebrek aan ervaring is.

[drm]

Hydra:
Wat mijn eigen reactie betreft; die gaat meer in op het princiepe achter dit soort ideeen en dat is dat het gewoon vaak een gebrek aan ervaring is.

Eens.

Ik zou er nog aan toe willen voegen dat dogma's sowieso altijd fout zijn.
(recursive pun intended).

[Hydra]

drm schreef op maandag 12 april 2021 @ 17:11:
[...]
Eens.

Ik zou er nog aan toe willen voegen dat dogma's sowieso altijd fout zijn.
(recursive pun intended).

"Only a sith deals in absolutes!"

[Verwijderd]

Ik ben dan wel benieuwd naar of de spring fans hier bijvoorbeeld spring boot met de standaard configuratie toepassen of toch nog eens nadenken over bepaalde instellingen zoals het spring.jpa.open-in-view=false.

Frameworkless klinkt wat resoluut, maar als je leest wat ze echt zeggen kan ik daar niet heel veel op tegen hebben. Ja ik heb mijn eigen ORM geschreven in de tijd dat er nog geen hibernate bestond en nee dat doe ik niet nog eens. Maar het is zeer verstandig om je af te vragen of het wel verstandig is om altijd hibernate toe te passen omdat dat nou eenmaal zo gemakkelijk is. Als je 10 jaar lang alles met spring bouwt ben je dan niet een one trick pony aan het worden?

edit: typo

[Patriot]

hellfighter87 schreef op maandag 12 april 2021 @ 10:10:
Ik heb bovenstaande even doorgelezen, en zoals ik het begrijp (en dat kan natuurlijk ook verkeerd zijn)
gaat frameworkless helemaal niet over het niet gebruiken van frameworks, maar meer over het volgende (even uit het eco systeem van PHP):

Wat je vaak in projecten ziet is dat iemand een bepaald framework fijn vind en daar dus alles van pakt:
voor rendering: symfony
voor routing: symfony
voor injection: symfony
etc.

terwijl framework less meer uitgaat van, pak voor elke functionaliteit de beste optie
voor rendering: symfony
voor routing: laravel
voor injection: ?
etc.

De PSR standaarden binnen PHP zijn interfaces die bepalen: als router krijg je deze input, en moet je deze output terug geven, verder of het ding cached en of andere logica heeft wat hem beter maakt dan een andere router moet die package zelf weten.

Maar door die gestandaardiseerde interfaces zijn de packages compatbible met elkaar.
En dat kan je in elke taal bereiken.

Waarom zou je dit doen:
omdat als je library 1 gebruikt, en die heeft een renderer, router, injection etc. dat misschien de router niet aansluit op wat jij wil, en in plaats van er omheen te werken, gebruik je een andere router die wel jou gewenste functionaliteit heeft.

Het nadeel is natuurlijk, als je alles van symfony gebruikt, dan weet je ook wat je met de rest kan.

Toch zit deze uitleg van het standpunt me niet helemaal lekker. Het is alsof iemand het lijstje met de "tegens" die je bedenkt als je overweegt een (bepaald) framework te gebruiken heeft genomen en die als enige argument opvoert. Zo van "Een/dit framework is kut. Er zijn nadelen aan het gebruik van een/dit framework. QED."

[hellfighter87]

Patriot schreef op dinsdag 13 april 2021 @ 18:23:
[...]


Toch zit deze uitleg van het standpunt me niet helemaal lekker. Het is alsof iemand het lijstje met de "tegens" die je bedenkt als je overweegt een (bepaald) framework te gebruiken heeft genomen en die als enige argument opvoert. Zo van "Een/dit framework is kut. Er zijn nadelen aan het gebruik van een/dit framework. QED."

Ik heb in het verleden de situatie gehad dat de routing vam ons huidige framework te traag was. Toen hebben we de router vervangen door een die op snelheid focuste. Natuurlijk had de nieuwe router niet alle features van de langzame, maar die gebruikte we toch niet.

Om maar een voorbeeld te noemen. Er zijn altijd situaties waarin je uitwiselbare components wilt hebben. Echter in de meeste gevallen voldoet het prima om gewoon volledig symfony te pakkeb

[Patriot]

hellfighter87 schreef op dinsdag 13 april 2021 @ 18:43:
[...]


Ik heb in het verleden de situatie gehad dat de routing vam ons huidige framework te traag was. Toen hebben we de router vervangen door een die op snelheid focuste. Natuurlijk had de nieuwe router niet alle features van de langzame, maar die gebruikte we toch niet.

Om maar een voorbeeld te noemen. Er zijn altijd situaties waarin je uitwiselbare components wilt hebben. Echter in de meeste gevallen voldoet het prima om gewoon volledig symfony te pakkeb

Maar je vertaalde het "doel" van frameworkless naar: Dan kun je de componenten (veel makkelijker) uitwisselen. Nu lijk je te zeggen: We gebruikten wel een framework en hebben toch een component uitgewisseld. Dan zet je toch de bijl in het argument van frameworkless?

Buiten dat is de moeite die ik heb met jouw uitleg van frameworkless dat het geen afweging is. Het lijkt neer te komen op "het is flexibeler." Dat is natuurlijk strikt genomen waar, maar als ik mijn been op 5 plaatsen breek kan ik mijn voet ook in mijn nek leggen. Is dat dan beter dan mijn been niet op 5 plaatsen breken?

[ Voor 0% gewijzigd door Patriot op 13-04-2021 21:48 . Reden: punctuatie is soms moeilijk ]

[Hydra]

Verwijderd schreef op maandag 12 april 2021 @ 22:21:
Ik ben dan wel benieuwd naar of de spring fans hier bijvoorbeeld spring boot met de standaard configuratie toepassen of toch nog eens nadenken over bepaalde instellingen zoals het spring.jpa.open-in-view=false.

Ik vind het een rare en nogal gesloten vraag eerlijk gezegd. Dat ik veel Spring gebruik betekent dat ik het framework goed ken, niet dat ik denk "YOLO, het zal wel goed wezen!".

Frameworkless klinkt wat resoluut, maar als je leest wat ze echt zeggen kan ik daar niet heel veel op tegen hebben. Ja ik heb mijn eigen ORM geschreven in de tijd dat er nog geen hibernate bestond en nee dat doe ik niet nog eens. Maar het is zeer verstandig om je af te vragen of het wel verstandig is om altijd hibernate toe te passen omdat dat nou eenmaal zo gemakkelijk is. Als je 10 jaar lang alles met spring bouwt ben je dan niet een one trick pony aan het worden?

Ik gebruik geen Hibernate; het is een gedrocht dat meer problemen oplevert dan het oplost. En je doet hier nogal een aanname dat vooral Spring professioneel gebruiken betekent dat je andere frameworks niet kent of niet gebruikt.

Maar experimenteren met andere frameworks doe ik niet in productie code. Dat vind ik nogal onprofessioneel namelijk.

[Verwijderd]

Hydra schreef op woensdag 14 april 2021 @ 08:53:
[...]


Ik vind het een rare en nogal gesloten vraag eerlijk gezegd. Dat ik veel Spring gebruik betekent dat ik het framework goed ken, niet dat ik denk "YOLO, het zal wel goed wezen!".


[...]


Ik gebruik geen Hibernate; het is een gedrocht dat meer problemen oplevert dan het oplost. En je doet hier nogal een aanname dat vooral Spring professioneel gebruiken betekent dat je andere frameworks niet kent of niet gebruikt.

Maar experimenteren met andere frameworks doe ik niet in productie code. Dat vind ik nogal onprofessioneel namelijk.

Het is een vraag om te peilen of, als er dan bijv. een framework als spring ingezet gaat worden of dan ook de standaard instellingen worden overgenomen. Het maakt het leven voor veel mensen namelijk makkelijk. Maar het is imo niet heel verstandig om die instellingen mee te nemen.

Maargoed, er is dus een groep mensen met een mening die stellen dat het kiezen van een framework een meer expliciete keuze moet zijn waar nogal kritisch op gereageerd is hier. En dan komt er een mening langs als hibernate is een gedrocht dat meer problemen oplevert dan dat het oplost. Is dat niet een gevalletje de pot verwijt de ketel?

En ik doe geen aanname over Spring, ik gebruik dit specifieke geval als voorbeeld.

[Hydra]

Verwijderd schreef op woensdag 14 april 2021 @ 09:06:
Het is een vraag om te peilen of, als er dan bijv. een framework als spring ingezet gaat worden of dan ook de standaard instellingen worden overgenomen. Het maakt het leven voor veel mensen namelijk makkelijk. Maar het is imo niet heel verstandig om die instellingen mee te nemen.

Dat is nogal een statement. Spring heeft over het algemeen gewoon sensible defaults. Als je Spring Security toevoegt bijvoorbeeld, moet je expliciet endpoints open zetten. Maar dat neemt niet weg dat het je taak als developer is te weten wat er aan of uitstaat.

Maargoed, er is dus een groep mensen met een mening die stellen dat het kiezen van een framework een meer expliciete keuze moet zijn waar nogal kritisch op gereageerd is hier.

Het heet letterlijk het "frameworkless movement" niet het "maak een bewijst besluit welk framework je kiest"-movement. Dat zou ook nogal raar zijn want "maak een bewuste keuze" is eigenlijk gewoon "wees een professioneel software engineer". De keuze voor Spring (bijvoorbeeld) is ook gewoon een bewuste keuze; juist dat het de de-facto standaard is, heeft veel voordelen.

Misschien moet je ook even kijken naar de informatie waar ze naar linken want dit zijn vooral blog-post waarin mensen vertellen waarom je het allemaal zelf moet doen. Dus wel 'frameworkless'.

Bovendien; ik zie niet wat er hypochriet is aan een sterke dislike voor hibernate. Ik ben daar niet bepaald de enige in; je ziet in Java-land al langer een trend weg van JPA/hibernate, vooral in microservices. Ik kan ook prima uitleggen waarom; maar dat is niet on-topic hier. Ik ben niet tegen het maken van bewuste keuzes; jij doet alleen een aanname dat een keuze voor Spring, Laravel of Symphony bijv. geen bewuste keuze is.

[Verwijderd]

Hydra schreef op woensdag 14 april 2021 @ 09:34:
[...]


Dat is nogal een statement. Spring heeft over het algemeen gewoon sensible defaults. Als je Spring Security toevoegt bijvoorbeeld, moet je expliciet endpoints open zetten. Maar dat neemt niet weg dat het je taak als developer is te weten wat er aan of uitstaat.


[...]


Het heet letterlijk het "frameworkless movement" niet het "maak een bewijst besluit welk framework je kiest"-movement. Dat zou ook nogal raar zijn want "maak een bewuste keuze" is eigenlijk gewoon "wees een professioneel software engineer". De keuze voor Spring (bijvoorbeeld) is ook gewoon een bewuste keuze; juist dat het de de-facto standaard is, heeft veel voordelen.

Misschien moet je ook even kijken naar de informatie waar ze naar linken want dit zijn vooral blog-post waarin mensen vertellen waarom je het allemaal zelf moet doen. Dus wel 'frameworkless'.

Bovendien; ik zie niet wat er hypochriet is aan een sterke dislike voor hibernate. Ik ben daar niet bepaald de enige in; je ziet in Java-land al langer een trend weg van JPA/hibernate, vooral in microservices. Ik kan ook prima uitleggen waarom; maar dat is niet on-topic hier. Ik ben niet tegen het maken van bewuste keuzes; jij doet alleen een aanname dat een keuze voor Spring, Laravel of Symphony bijv. geen bewuste keuze is.

"hibernate is een gedrocht" is net zo'n statement. Dus ja pot verwijt.

Ik zeg niet dat de keuze voor Spring in alle gevallen onbewust is maar in veel gevallen wel. En daarom snap ik prima dat er een tegenbeweging ontstaat. Het is een hele simpele yin en yang beweging hoor. En die trend waar je het over hebt herken ik helemaal niet.

[bwerg]

Verwijderd schreef op woensdag 14 april 2021 @ 09:06:
[...]


Het is een vraag om te peilen of, als er dan bijv. een framework als spring ingezet gaat worden of dan ook de standaard instellingen worden overgenomen. Het maakt het leven voor veel mensen namelijk makkelijk. Maar het is imo niet heel verstandig om die instellingen mee te nemen.

Dan nog, de keuze is dan:

• Gewoon de betekenis van de instellingen leren. Oftewel, de documentatie doorlezen. Met een beetje goed en professioneel framework is die documentatie ook goed en begrijpelijk.
• Accepteren dat je er niks vanaf weet, en dat je de defaults dus overlaat aan mensen die slim genoeg waren om een framework te schrijven. Om te leren en voor experimentele speelgoedprojectjes helemaal prima, de details kom je vanzelf een keer tegen, of ga je uitzoeken als je er serieus mee aan de slag gaat.
• Je gaat het hele ding van A-Z zelf bouwen en zo kom je alle technische details waar het framework een instelling voor had vanzelf tegen - en dan hoop je maar dat jouw keuzes en opties net zo goed worden als die van het framework.

Ik weet wel welk van deze opties in ieder geval het minst aantrekkelijk klinkt.

Ja, het kan zijn dat er stiekem onduidelijk gedocumenteerde keuzes gemaakt worden in een framework die onverstandig zijn, of dat het best duidelijk gedocumenteerd is maar dat een gebruiker gewoon door had moeten hebben dat hij iets heel anders wilde dan de standaardopties. Een framework garandeert niet dat alles altijd goed gaat, natuurlijk. Alles zelf doen garandeert dat echter nog een stuk minder.

[Hydra]

Verwijderd schreef op woensdag 14 april 2021 @ 10:13:
"hibernate is een gedrocht" is net zo'n statement. Dus ja pot verwijt.

Ik vind dit zo onconstructief dat ik het er verder bij ga laten.

[Verwijderd]

Hydra schreef op woensdag 14 april 2021 @ 12:11:
[...]


Ik vind dit zo onconstructief dat ik het er verder bij ga laten.

ok, beetje jammer dat je mij verwijt "nogal een statement te maken" en dat zelf net zo goed doet mbt hibernate. Zeker als je aangeeft dat Spring sensible defaults heeft. Enige dat ik aangaf is dat er misschien wel enige waarde gezien kan worden in de frameworkless beweging ipv het af te fakkelen.

edit: ik stelde trouwens dit "Maar het is imo niet heel verstandig om die instellingen mee te nemen." wat een beetje overstated is. Het idee was, het is niet verstandig om blindelings de default instellingen over te nemen.

[ Voor 19% gewijzigd door Verwijderd op 14-04-2021 12:38 ]

[Verwijderd]

Om maar niet te verzanden in de discussie over specifieke frameworks. In mijn optiek is het vooral een financiële (lees: ontwikkeltijd) keuze ipv een technische. Uiteindelijk moeten er dingen opgeleverd worden en moet er geld in de la komen. Alles zelf ontwikkelen is leuk, maar kost meestal zeer veel tijd. Als het aan mij ligt hou ik het liefst ook alles zelf in de hand, echter heb ik in de loop van de jaren geleerd dat het zeer zelden gaat over de beste technische oplossing, maar vooral om geld .

En verschillende onderdelen van frameworks aan elkaar koppelen ipv het bij één framework houden, lijkt mij nou niet echt een definitie van frameworkless te werk gaan.

[Giesber]

Verwijderd schreef op woensdag 14 april 2021 @ 12:52:
Om maar niet te verzanden in de discussie over specifieke frameworks. In mijn optiek is het vooral een financiële (lees: ontwikkeltijd) keuze ipv een technische. Uiteindelijk moeten er dingen opgeleverd worden en moet er geld in de la komen. Alles zelf ontwikkelen is leuk, maar kost meestal zeer veel tijd. Als het aan mij ligt hou ik het liefst ook alles zelf in de hand, echter heb ik in de loop van de jaren geleerd dat het zeer zelden gaat over de beste technische oplossing, maar vooral om geld .

En verschillende onderdelen van frameworks aan elkaar koppelen ipv het bij één framework houden, lijkt mij nou niet echt een definitie van frameworkless te werk gaan.

Het gaat ook over technische zaken: onderhoudbaarheid, integratie, beveiliging, stabiliteit en dan vergeet ik misschien nog iets. Tenzij je technisch zo goed bent dat je code even veilig, stabiel en integreerbaar met andere technologiën is dan code waarover meerdere andere ontwikkelaars jaren hebben nagedacht. Dan trek ik mijn woorden in (spoiler: dat ga ik dus waarschijnlijk niet moeten doen ). Qua onderhoudbaarheid zal het misschien nog prima zijn zolang je er alleen aan werkt.

Of het kan zijn dat je project zo simpel is dat een framework overkill is, maar ik ga ervan uit dat we hier aan het praten zijn over projecten waarvoor een gemiddelde developer op zijn minst over een framework zou nadenken.

[Hydra]

Verwijderd schreef op woensdag 14 april 2021 @ 12:52:
Om maar niet te verzanden in de discussie over specifieke frameworks. In mijn optiek is het vooral een financiële (lees: ontwikkeltijd) keuze ipv een technische. Uiteindelijk moeten er dingen opgeleverd worden en moet er geld in de la komen. Alles zelf ontwikkelen is leuk, maar kost meestal zeer veel tijd. Als het aan mij ligt hou ik het liefst ook alles zelf in de hand, echter heb ik in de loop van de jaren geleerd dat het zeer zelden gaat over de beste technische oplossing, maar vooral om geld .

Het is niet alleen de up front ontwikkeltijd; je hebt ook tot het eind der tijden een framework te onderhouden, en dat wordt nogal eens vergeten. Als er in Spring bijvoorbeeld een security issue zit, komt er in no time een update uit. Denken dat je hetzelf beter kan is nogal naief; het is nogal wat aannemelijker dat omdat je de enige bent die het gebruikt, je gewoon niet weet dat er een security issue in zit.

Ik ben zelf al zo'n 20 jaar developer maar heb echt niet de illusie dat ik op kan tegen een heel ecosysteem van slimme developers die samen open source frameworks onderhouden. Dat zou nogal arrogant zijn. Tuurlijk zijn er soms componenten die niet lekker werken (concreet voorbeeld is Spring HATEOAS), maar die hoef je ook niet perse te gebruiken.

[Verwijderd]

@Giesber en @HydraIk bedoel in het eerste deel hetzelfde als wat jullie stellen. En dat ik het zelf beter kan, er staat niets voor niets een knipoog achter desbetreffende zin, misschien is online sarcasme niet mijn sterkste punt... (was als grap bedoelt, dat developers alles zelf beter denken te kunnen)

Bedoelde eigenlijks dat om op het niveau te komen van reeds bestaande en bewezen frameworks er heel veel kosten aan verbonden zijn. Vandaar het financiële aspect. En ja, daar hoort naast ontwikkeltijd ook onderhoud bij. Zoals hoogstwaarschijnlijk ook support richting gebruikers.

[Hydra]

Verwijderd schreef op woensdag 14 april 2021 @ 15:08:
@Giesber en @HydraIk bedoel in het eerste deel hetzelfde als wat jullie stellen.

Snap ik hoor; het was ook meer bedoel als aanvulling op wat je zei.

[Oon]

Hydra schreef op woensdag 14 april 2021 @ 14:56:
[...]


Het is niet alleen de up front ontwikkeltijd; je hebt ook tot het eind der tijden een framework te onderhouden, en dat wordt nogal eens vergeten.

Ik denk dat veel mensen dit niet zo zien. Die trekken de nodige packages binnen, pushen die naar de repo (ipv dependency management te gebruiken) schrijven daar eenmalig een eigen framework mee, en dat is het dan. Wanneer het tijd is dat de programmeertaal waar het op rust een significante versie heeft (PHP 5 -> 7, Java 7 -> 8, iedere taal heeft wel wat grote versies waarin oude deprecated rommel eindelijk echt verwijderd wordt) dan komen ze weer naar Tweakers om hier te zeuren over hoe slecht het gebruik van packages is want het kost zoveel tijd om te upgraden.

Maar wat die mensen over het hoofd zien is dat als je een framework gebruikt en regelmatig update, of in ieder geval je dependencies regelmatig update, je op de ene grote wijziging in de zoveel tijd eigenlijk maar heel weinig bij hoeft te houden en vooral zo nu en dan een keer een config optie moet renamen of een andere functie aan moet roepen. Met de juiste abstraction layer (of het juiste framework) tussen je packages en je productcode kun je dat dan in de meeste gevallen in een uurtje per week of maand gefixt krijgen.

Het ergste argument dat ik steeds terug zie komen is dat ze denken het zelf beter te kunnen, maar eigenlijk gewoon op Mt Stupid van het Dunning-Kruger effect zitten. Heel zelfverzekerd, maar daarmee zien ze even over het hoofd dat zelfs de beste developer ter wereld in z'n eentje niet op kan boksen tegen een framework waar een tiental ervaren developers jarenlang aan hebben gewerkt. Er zijn redenen om delen van een framework niet te gebruiken (bijv. de query builder in veel frameworks is niet erg goed voor performance omdat het vaak neer komt op een concat van losse statements waar je weinig controle over hebt), maar ik heb nog geen enkel goed argument gehoord om helemaal geen framework te gebruiken wanneer het om een project gaat dat toekomstbestendig zou moeten zijn.

[FrankHe]

Er zijn uiteraard uitzonderingen.

Voor zaken die simpel en snel moeten werken gebruik ik met opzet geen framework. Heb bijvoorbeeld voor een platform een component die audio-bestanden flac / mp3 kan streamen. Dat bestaat uit pakweg 100 regels PHP-code voor input sanitisation, het beheer van HTTP 206 Partial Content headers en het uitserveren van brokken content. In een andere taal dan PHP zou het waarschijnlijk nog sneller kunnen maar het huidige component voldoet en ik heb er verder geen onderhoud aan. Niets dat stuk kan gaan.

Voor meer uitgebreide zaken zijn er in iedere programmeertaal legio frameworks beschikbaar. De ene meer geschikt voor het project dan het andere.

[Verwijderd]

Ik heb met symfony gewerkt vanaf versie 1 en heb mijn eigen framework gemaakt ernaast thuis als hobby. Doctrine zit tegenwoordig ook in mijn eigen framework. Je begint ergens en het wordt steeds beter. Vooral in oplossingen merk ik de laatste tijd dat programmeren in mijn eigen framework veel sneller gaat dan in symfony. Maar de onderhoud aan het framework is in het begin even een karwei. Later als alles staat moet je in symfony altijd opzoeken hoe iets werkt terwijl dat in je eigen framework zo uit de mouw wordt geschut. Wat heb je nodig: request, sessie,cookie routing, vertaling, mvc en database. Wat doet symfony extra, forms op een waardeloze manier?

[FrankHe]

Verwijderd schreef op woensdag 14 april 2021 @ 21:47:
Ik heb met symfony gewerkt vanaf versie 1 en heb mijn eigen framework gemaakt ernaast thuis als hobby. Doctrine zit tegenwoordig ook in mijn eigen framework. Je begint ergens en het wordt steeds beter. Vooral in oplossingen merk ik de laatste tijd dat programmeren in mijn eigen framework veel sneller gaat dan in symfony. Maar de onderhoud aan het framework is in het begin even een karwei. Later als alles staat moet je in symfony altijd opzoeken hoe iets werkt terwijl dat in je eigen framework zo uit de mouw wordt geschut. Wat heb je nodig: request, sessie,cookie routing, vertaling, mvc en database. Wat doet symfony extra, forms op een waardeloze manier?

Heb inderdaad ook zo mijn zelfontwikkelde zaken die meer een soort MVC framework-light vormen dan dat het nu en allesomvattend framework is. In tegendeel zelfs, mijn credo is, 'less is more'.

Zelf werk ik graag heel dicht tegen de data aan. Onlangs nog een verbeterde XML module gebouwd die heel slank is en daardoor waanzinnig gemakkelijk te doorgronden en te onderhouden is.

Wat betreft de datalaag praat ik voornamelijk met MySQL-smaken. Vroeger ook met MS-SQL en Oracle-databases gewerkt in BI-DWH projecten en eerlijk is eerlijk wanneer het op ETL aankomt is SQL gewoon SQL. Even afgezien van merkspecifieke functionaliteit kun je in MariaDB / MySQL vrijwel hetzelfde bereiken als bij Microsoft en Oracle. Soms moet je even om dingen heen werken die MariaDB / MySQL niet heeft en wat je bij de duurbetaalde databases wel standaard aan boord hebt maar daar zijn doorgaans goede oplossingen voor te bouwen.

Een applicatie is gewoon sneller wanneer er minder abstractielagen tussen zitten. Een framework die voor mij gaat bedenken hoe de SQL er moet uitzien doet het in 98% van de gevallen gewoon minder handig dan dat ik dit zelf zou doen. Met als resultaat dat de applicatie op mijn eigen code stukken sneller werkt dan welk framework dan ook voor elkaar zal krijgen. En ik heb de vrijheid om de dingen te bouwen zoals ik ze wil hebben.

Hoe zit het dan met routing? Ook daar geldt het credo, 'less is more'. Hoe minder overervingen en andere ongein je systeem bevat, hoe sneller het is. Is mijn methode ook geschikt voor hele grote projecten? Wellicht niet, maar het past wel precies bij de projecten waar ik aan werk.

Bij de presentatielaag het zelfde verhaal, hoe kleiner de kerstboom is die je optuigt hoe overzichtelijker het geheel is en des te sneller de applicatie werkt. Wil je ingewikkelde dingen laten zien? Laad de boel dan client side in verschillende div containers in, dan blijft het server side overzichtelijk en een bijkomend voordeel is dat op die manier zaken vanzelf parallel worden ingeladen. Daarbij kun je caching ook nog eens heel mooi sturen. Win-win!

[Hydra]

FrankHe schreef op woensdag 14 april 2021 @ 23:46:
Zelf werk ik graag heel dicht tegen de data aan. Onlangs nog een verbeterde XML module gebouwd die heel slank is en daardoor waanzinnig gemakkelijk te doorgronden en te onderhouden is.

Grappig voorbeeld.

Ik heb in m'n carriere 3 situaties meegemaakt waar developers zelf XML gingen parsen of schrijven i.p.v. standaard library te gebruiken die geleid hebben tot tienduizenden euro's aan extra ontwikkelkosten omdat dingen als 'validatie' of 'unicode' als onnodig beschouwd werden, of uberhaupt niet op de radar waren.

Nu zul jij ongetwijfeld de uitzondering zijn op die regel, maar je laat wel mooi het probleem zien. Het werkt vaak allemaal prima totday iemand een accent in z'n naam heeft

Een applicatie is gewoon sneller wanneer er minder abstractielagen tussen zitten. Een framework die voor mij gaat bedenken hoe de SQL er moet uitzien doet het in 98% van de gevallen gewoon minder handig dan dat ik dit zelf zou doen. Met als resultaat dat de applicatie op mijn eigen code stukken sneller werkt dan welk framework dan ook voor elkaar zal krijgen. En ik heb de vrijheid om de dingen te bouwen zoals ik ze wil hebben.

Een expert als jij zou toch moeten weten dat bij database IO de 'abstracties' over het algemeen niet de bottleneck zijn? Dat is eigenlijk altijd de IO zelf. Ik vind dit wel erg sterk ruiken naar iets naar "ik wil het graag zelf doen".

Hetzelfde geldt voor routing. Bij netwerk IO is een extra laagje echt de bottle neck niet. Onderhoudbaarheid en leesbaarheid in code 'kost' daar veel meer dan een microseconde verschil. Vergeet niet dat wat jij schrijft over 4 jaar door een andere developer gelezen moet kunnen worden. Als dat een 'standaard' manier is, kost dat gewoon veel minder tijd dan als hij moet gaan raden hoe jouw ondergedocumenteerde systeem werkt. En uiteindelijk zijn development uren vrijwel altijd de grootste kostenpost in projecten.

Kijk ik ben (zoals eerder beschreven) geen fan van specifiek hibernate maar dat betekent niet dat ik dan maar zelf plain JDBC ga doen. Het wordt al snel aardig wat werk als je ook dingen als transacties zelf moet gaan regelen.

[ Voor 48% gewijzigd door Hydra op 15-04-2021 12:13 ]

[FrankHe]

Hydra schreef op donderdag 15 april 2021 @ 12:07:
[...]

Grappig voorbeeld.

Ik heb in m'n carriere 3 situaties meegemaakt waar developers zelf XML gingen parsen of schrijven i.p.v. standaard library te gebruiken die geleid hebben tot tienduizenden euro's aan extra ontwikkelkosten omdat dingen als 'validatie' of 'unicode' als onnodig beschouwd werden, of uberhaupt niet op de radar waren.

Nu zul jij ongetwijfeld de uitzondering zijn op die regel, maar je laat wel mooi het probleem zien. Het werkt vaak allemaal prima totday iemand een accent in z'n naam heeft

PHP bevat standaard enkele methodes om met XML te werken en die voldoen uitstekend. Daar borduur ik op voort, ga inderdaad niet zelf helemaal het wiel opnieuw uitvinden Heb zelf mijn uitermate strikte manier van validatie middels (voor mij) standaard methoden die ieder goed gedocumenteerde reguliere expressies bevatten. Verder is het een kwestie van zelf even netjes de variabele escapen. Dat gebeurt op een centrale plaats. Ik kan nu binnen no-time de ondersteuning voor een nieuw XML formaat implementeren.

[...]

Een expert als jij zou toch moeten weten dat bij database IO de 'abstracties' over het algemeen niet de bottleneck zijn? Dat is eigenlijk altijd de IO zelf. Ik vind dit wel erg sterk ruiken naar iets naar "ik wil het graag zelf doen".

Hang af van de toepassing. Voor een simpele website gaat het inderdaad geen zoden aan de dijk zetten. Maar voor de toepassingen waar ik aan werk, redelijk zware reports, maakt het voor mij wel degelijk uit als ik de SQL -statements helemaal zelf componeer. Het is inderdaad een beetje een niche toepassing.

Hetzelfde geldt voor routing. Bij netwerk IO is een extra laagje echt de bottle neck niet. Onderhoudbaarheid en leesbaarheid in code 'kost' daar veel meer dan een microseconde verschil. Vergeet niet dat wat jij schrijft over 4 jaar door een andere developer gelezen moet kunnen worden. Als dat een 'standaard' manier is, kost dat gewoon veel minder tijd dan als hij moet gaan raden hoe jouw ondergedocumenteerde systeem werkt. En uiteindelijk zijn development uren vrijwel altijd de grootste kostenpost in projecten.

Routing zou bij mij inderdaad beter kunnen, dat geef ik ook toe. In dit geval wegen simplicity en performance op tegen toegevoegde complexiteit. In andere gevallen gebruik ik inderdaad de routing van een framework zoals bijvoorbeeld Codeigniter. Maar andere zaken uit Codeigniter gebruik ik dan weer juist niet omdat ik geen fan ben van de gekozen oplossing.

Kijk ik ben (zoals eerder beschreven) geen fan van specifiek hibernate maar dat betekent niet dat ik dan maar zelf plain JDBC ga doen. Het wordt al snel aardig wat werk als je ook dingen als transacties zelf moet gaan regelen.

Nu weet ik verder niets van Java, zit zelf meer in de PHP hoek. En daarin vind ik het managen van transacties niet ingewikkeld. Wat mij betreft horen transacties trouwens ook meer thuis in de database in plaats van in de applicatie. Al kom je er soms gewoon niet omheen, in de meeste gevallen lukt het prima om een transactie te offloaden na de database. Alles wat met goed fatsoen op een MySQL / MariaDB database kan worden uitgevoerd moet als het even kan ok daadwerkelijk daar plaatsvinden. De database kan het namelijk in alle gevallen veel sneller dan dat PHP het kan. Hoe minder I/O hoe beter. Ik sluit niet uit dat de situatie in Java anders kan zijn. Al verwacht ik dat een database ook dan doorgaans sneller zal zijn.

[Janoz]

FrankHe schreef op donderdag 15 april 2021 @ 12:52:
..Al kom je er soms gewoon niet omheen, in de meeste gevallen lukt het prima om een transactie te offloaden na de database. Alles wat met goed fatsoen op een MySQL / MariaDB database kan worden uitgevoerd moet als het even kan ok daadwerkelijk daar plaatsvinden. De database kan het namelijk in alle gevallen veel sneller dan dat PHP het kan....

Het afhandelen van de database wijzigingen binnen de transactie wordt natuurlijk door de database gedaan, maar die kan niet op magische wijze verzinnen waar de transactie begint en eindigt of wat er verder bij een rollback gebeuren moet. Bij php is het misschien wat simpeler omdat je daar toch alleen maar een request scope hebt. Blijkbaar is het in jou geval voldoende om een 500 gooien, maar dat is niet altijd zo. En wat nu wanneer je ook message queues hebt, of andere dingen mee wilt nemen in je transactie? Super gebruikersvriendelijk om een activatie mailtje te versturen terwijl de registratie van die activatie vervolgens gerollbacked wordt.

[Patriot]

FrankHe schreef op woensdag 14 april 2021 @ 23:46:
[...]
Een applicatie is gewoon sneller wanneer er minder abstractielagen tussen zitten. Een framework die voor mij gaat bedenken hoe de SQL er moet uitzien doet het in 98% van de gevallen gewoon minder handig dan dat ik dit zelf zou doen.
[...]

Een mooi één-tweetje tussen NIH en premature optimization.

[WernerL]

Voor 90% van de gevallen voldoen de queries die een ORM genereerd vaak wel. En als dat een keer niet het geval is kun je altijd nog een stored procedure schrijven. Zeker voor grote enterprise applicaties die long-term onderhouden moeten worden zou ik niet zelf abstractie-lagen gaan schrijven voor dingen waar al goede abstracties voor bestaan. In het geval van .NET is dat entity framework voor je database-abstractie. In java-land heb je daar hibernate voor.

Frameworkless zou ik alleen voor kiezen voor kleinere applicaties waar een framework vooral overhead toevoegd.

[ Voor 4% gewijzigd door WernerL op 15-04-2021 18:15 ]

[DaFeliX]

Zo ver ik begreep gaat frameless niet over het al-dan-niet gebruiken van ORM, en of je je eigen routing schrijft, maar dat je niet aan framework vastbind.

Een framework is een (opinionated) verzameling van verschillende packages die goed met elkaar samenwerken. Volgens mij is frameless het zelf verzamelen en koppelen van verschillende packages zodat ze goed met elkaar samenwerken. Er zit verschil tussen, absoluut, maar het is volgens mij niet de extreme tegenhanger van frameless en dat je zelf alles bare-metal moet gaan programeren. Het is volgens mij de vrijheid om zelf te kiezen welke packages je gebruikt. Je hoeft heus niet alles zelf te gaan schrijven om frameless te werken zoals ik uit de discussie die hierboven plaatsvind haal.

Ik vind het idee van frameless wel aantrekkelijk, omdat je flexibeler bent dan bij gebruik van een framework. Daar is het vaak dat je 'overgeleverd' bent aan de packages die meekomen. Je kunt natuurlijk ergens omheen werken om tóch je eigen alternatieve package te gebruiken, maar dat zal iets meer moeite kosten dan als je de packages zelf samenstelt. Bovendien, als je een belangrijk component van een framework niet gebruikt zit 't alleen maar in de weg. Daarentegen zal de setup van een frameless codebase waarschijnlijk iets meer tijd in beslag nemen omdat je zelf de juiste packages moet uitzoeken.

[Hydra]

DaFeliX schreef op donderdag 15 april 2021 @ 20:25:
Het is volgens mij de vrijheid om zelf te kiezen welke packages je gebruikt.

Genoeg frameworks die je daarin niet beperken hoor, dus ook dat verhaal vind ik een beetje 'meh'. Toevallig recent voorbeeld is dat ik bijvoorbeeld geen Spring HATEOAS gebruik maar het maar zelf doet, omdat die dat stukje onze usecase niet goed ondersteunt.

Daarentegen zal de setup van een frameless codebase waarschijnlijk iets meer tijd in beslag nemen omdat je zelf de juiste packages moet uitzoeken.

Goed voorbeeld van hoe dat over het algemeen onderschat wordt. Cross cutting concerns die door je hele stack heengaan (metrics, logging, tracing, security) allemaal zelf op orde maken kost niet "iets meer tijd". Alles is simpel als je een Hello World achtige applicatie ziet in een blog post, maar als je echt productiesoftware moet schrijven is het een heel ander verhaal.

Maargoed. We hebben een hele discussie over een site gewoon hardstikke dood is, dus kennelijk hebben de auteurs ondertussen ook wel het licht gezien.

[ Voor 44% gewijzigd door Hydra op 16-04-2021 08:34 ]

[FrankHe]

WernerL schreef op donderdag 15 april 2021 @ 18:11:
Voor 90% van de gevallen voldoen de queries die een ORM genereerd vaak wel. En als dat een keer niet het geval is kun je altijd nog een stored procedure schrijven. Zeker voor grote enterprise applicaties die long-term onderhouden moeten worden zou ik niet zelf abstractie-lagen gaan schrijven voor dingen waar al goede abstracties voor bestaan. In het geval van .NET is dat entity framework voor je database-abstractie. In java-land heb je daar hibernate voor.

Frameworkless zou ik alleen voor kiezen voor kleinere applicaties waar een framework vooral overhead toevoegd.

Dat laatste is bij de projecten waar ik voornamelijk aan werk het geval. De reports bestaan grotendeels uit database intensieve handelingen en wat er in- en uit gaat middels PHP is naar mijn mening redelijk recht toe recht aan. De meeste frameworks zitten op die momenten gewoon te veel in de weg.

Aanvulling, door de jaren heen heb ik een set gereedschappen verzameld die het werk voor mij een stuk eenvoudiger maken voor specifiek dit soort projecten. Een framework-light. Uitstekend toegerust op kleine projecten en inderdaad minder goed geschikt voor hele omvangrijke projecten waar je met een enorm team aan ontwikkelaars aan zit te werken. Dat is ook helemaal niet de scope van deze tools. Noem het NIH, ik zie het als een verdomde handige set componenten waarin ik heel goed mijn weg ken.

Daarnaast werk ik natuurlijk ook de nodige ander projecten waarin de bekende (PHP) frameworks zijn toegepast en een er zijn altijd wel onderdelen te vinden waarop een specifiek framework minder goed is toegerust maar waarbij het gewoon te laat is om op dat onderdeel iets anders naar binnen te schuiven. Dan is het een kwestie van doorbijten en de functionaliteit zo goed mogelijk te integreren binnen de reeds bestaande omkadering.

[ Voor 32% gewijzigd door FrankHe op 16-04-2021 09:03 . Reden: aanvulling ]

[Kalentum]

DaFeliX schreef op donderdag 15 april 2021 @ 20:25:
Zo ver ik begreep gaat frameless niet over het al-dan-niet gebruiken van ORM, en of je je eigen routing schrijft, maar dat je niet aan framework vastbind.

Een framework is een (opinionated) verzameling van verschillende packages die goed met elkaar samenwerken. Volgens mij is frameless het zelf verzamelen en koppelen van verschillende packages zodat ze goed met elkaar samenwerken. Er zit verschil tussen, absoluut, maar het is volgens mij niet de extreme tegenhanger van frameless en dat je zelf alles bare-metal moet gaan programeren. Het is volgens mij de vrijheid om zelf te kiezen welke packages je gebruikt. Je hoeft heus niet alles zelf te gaan schrijven om frameless te werken zoals ik uit de discussie die hierboven plaatsvind haal.

Ik vind het idee van frameless wel aantrekkelijk, omdat je flexibeler bent dan bij gebruik van een framework. Daar is het vaak dat je 'overgeleverd' bent aan de packages die meekomen. Je kunt natuurlijk ergens omheen werken om tóch je eigen alternatieve package te gebruiken, maar dat zal iets meer moeite kosten dan als je de packages zelf samenstelt. Bovendien, als je een belangrijk component van een framework niet gebruikt zit 't alleen maar in de weg. Daarentegen zal de setup van een frameless codebase waarschijnlijk iets meer tijd in beslag nemen omdat je zelf de juiste packages moet uitzoeken.

Nou een goed framework draagt standaardoplossingen aan maar dwingt je niet af om ze te gebruiken. Of maken het makkelijk om bv de standaardoplossing te vervangen of te wijzigen.

Een goed framework, daar hoef je dus niet 'omheen te werken' maar je kan gewoon makkelijk component X vervangen door Y of je eigen component Z baseren op component X.

Ik gebruik zelf Ruby on Rails en moet er niet aan denken om wielen als 'routing' of 'parameter parsing' of 'views' opnieuw uit te vinden. Neemt niet weg dat ik voldoende flexibiliteit heb om bv een andere template engine te gebruiken of een andere database abstractielaag te gebruiken. Of de de standaard ActiveJob oplossing te negeren en dat lekker zelf te doen.

Overigens zal ik niet snel afwijken van 'de standaardmanier' tenzij $redenen want ik moet ook rekening houden met de developers na mij en dan is het wel zo handig als dingen voorspelbaar zijn. En een framework helpt daarbij.

[Janoz]

FrankHe schreef op vrijdag 16 april 2021 @ 08:43:

Aanvulling, door de jaren heen heb ik een set gereedschappen verzameld die het werk voor mij een stuk eenvoudiger maken voor specifiek dit soort projecten. Een framework-light. Uitstekend toegerust op kleine projecten en inderdaad minder goed geschikt voor hele omvangrijke projecten waar je met een enorm team aan ontwikkelaars aan zit te werken. Dat is ook helemaal niet de scope van deze tools. Noem het NIH, ik zie het als een verdomde handige set componenten waarin ik heel goed mijn weg ken.

En toen stak je de weg over en kwam er een bus aan... Vervolgens blijkt het vinden van een nieuwe FrankHeReports specialist een stuk lastiger is dan bijvoorbeeld een JasperReports specialist en zit je werkgever met een bak niet te onderhouden rapportages.

Wat ik hier voornamelijk mee wil zeggen is dat hiet niet alleen om de kwaliteit van een NIH oplossing gaat. Zelfs al heeft je eigen oplossing de allerbeste kwaliteit ter wereld, dan nog zijn er factoren die het een anti-pattern maken.

[Lethalis]

Janoz schreef op vrijdag 16 april 2021 @ 10:02:
[...]

En toen stak je de weg over en kwam er een bus aan... Vervolgens blijkt het vinden van een nieuwe FrankHeReports specialist een stuk lastiger is dan bijvoorbeeld een JasperReports specialist en zit je werkgever met een bak niet te onderhouden rapportages.

Wat ik hier voornamelijk mee wil zeggen is dat hiet niet alleen om de kwaliteit van een NIH oplossing gaat. Zelfs al heeft je eigen oplossing de allerbeste kwaliteit ter wereld, dan nog zijn er factoren die het een anti-pattern maken.

True, maar dan moeten we ook niet vergeten dat er genoeg developers zijn die dit expres doen om zichzelf onmisbaar te maken

[FrankHe]

Ik heb het zelf vaak genoeg dat ik een project op mijn bord krijg waar het nodige aan schort. Daarom probeer ik zelf mijn zaakjes op orde te hebben. De PHP-code is goed onderhoudbaar. Functionaliteiten zijn overzichtelijk opgesplitst en alles heeft een logische naamgeving. Het systeem is daarbij netjes voorzien van uitgetekende flowdiagrammen en uitgeschreven documentatie. Heb voor klanten de nodige backup- en restore procedures opgesteld, in geval van nood kunnen ze zelf zaken terug zetten. Maar het voornaamste doel van documenten is voor mezelf of een andere ontwikkelaar om gemakkelijk inzichtelijk te krijgen waarom bepaalde keuzes zijn gemaakt.

[Hydra]

FrankHe schreef op vrijdag 16 april 2021 @ 11:56:
Ik heb het zelf vaak genoeg dat ik een project op mijn bord krijg waar het nodige aan schort. Daarom probeer ik zelf mijn zaakjes op orde te hebben. De PHP-code is goed onderhoudbaar. Functionaliteiten zijn overzichtelijk opgesplitst en alles heeft een logische naamgeving. Het systeem is daarbij netjes voorzien van uitgetekende flowdiagrammen en uitgeschreven documentatie. Heb voor klanten de nodige backup- en restore procedures opgesteld, in geval van nood kunnen ze zelf zaken terug zetten. Maar het voornaamste doel van documenten is voor mezelf of een andere ontwikkelaar om gemakkelijk inzichtelijk te krijgen waarom bepaalde keuzes zijn gemaakt.

Ik vind het eigenlijk wel jammer dat je dit soort keuzes blijft verdedigen en niet lijkt te willen onderkennen dat er gewoon een keerzijde zit aan het maken van dit soort keuzes. Dit komt op mij over alsof je eigenlijk gewoon nog niet de ervaring hebt met de andere kant hiervan; het moeten werken met dit soort DIY projecten.

Zelfs al ben je de beste developer van de wereld; alle code die je zelf schrijft kost tijd. Niet alleen nu; ook totdat de software uit gebruik genomen wordt. Dus zelfs als je geen fouten maakt; is het over het algemeen gewoon efficienter kwa tijd om 'standaard'spul te gebruiken. Dus zelfs in een best case scenario ben je over het algemeen gewoon 'langzamer' dan een gewoon goede developer die de juiste bestaande tools toepast en zich vooral focust op de business-specifieke code.

Kijk en misschien ben jij wel die ene uitzondering die alles meteen goed doet. Maar ik heb dit exacte verhaal de afgelopen 20 jaar gewoon te vaak gehoord. En meestal waren die mensen het onderhouden van hun spullen vrij snel beu (een webserver from scratch bouwen is leuker dan datzelfde ding onderhouden) en kwam het er uiteindelijk op neer dat anderen dan met die shit te dealen hadden. En dus bijvoorbeeld aan een manager uit mogen leggen waarom we de komende 2 maanden een applicatie gaan refactoren en geen business value op gaan leveren. Dus vergeef me als ik gewoon enorm sceptisch wordt van dit soort redenaties; ik heb ze te vaak gehoord.

[FrankHe]

Hydra schreef op vrijdag 16 april 2021 @ 18:56:
[...]

Ik vind het eigenlijk wel jammer dat je dit soort keuzes blijft verdedigen en niet lijkt te willen onderkennen dat er gewoon een keerzijde zit aan het maken van dit soort keuzes. Dit komt op mij over alsof je eigenlijk gewoon nog niet de ervaring hebt met de andere kant hiervan; het moeten werken met dit soort DIY projecten.

Zelfs al ben je de beste developer van de wereld; alle code die je zelf schrijft kost tijd. Niet alleen nu; ook totdat de software uit gebruik genomen wordt. Dus zelfs als je geen fouten maakt; is het over het algemeen gewoon efficienter kwa tijd om 'standaard'spul te gebruiken. Dus zelfs in een best case scenario ben je over het algemeen gewoon 'langzamer' dan een gewoon goede developer die de juiste bestaande tools toepast en zich vooral focust op de business-specifieke code.

Kijk en misschien ben jij wel die ene uitzondering die alles meteen goed doet. Maar ik heb dit exacte verhaal de afgelopen 20 jaar gewoon te vaak gehoord. En meestal waren die mensen het onderhouden van hun spullen vrij snel beu (een webserver from scratch bouwen is leuker dan datzelfde ding onderhouden) en kwam het er uiteindelijk op neer dat anderen dan met die shit te dealen hadden. En dus bijvoorbeeld aan een manager uit mogen leggen waarom we de komende 2 maanden een applicatie gaan refactoren en geen business value op gaan leveren. Dus vergeef me als ik gewoon enorm sceptisch wordt van dit soort redenaties; ik heb ze te vaak gehoord.

Wanneer het nuttig is zal ik een framework gebruiken. Maar ook dan gebruik ik hoogstens 50% van de functionaliteit die een framework biedt. Veel zaken zijn gewoon overhead en niet van toepassing op het project.

Bij .NET en JAVA zal het een en ander wat beter geregeld zijn. Een "industriestandaard" framework is in de PHP-wereld nog wel eens een vloeibaar begrip. Het framework dat vandaag hot is is morgen obsolete. Een framework is niet zo heilig als mensen soms plegen te beweren. Er is een behoorlijke wildgroei aan PHP frameworks.

In de afgelopen jaren heb ik veel producten gezien die in een framework zijn gebouwd dat negen jaar geleden helemaal de bom was, maar dat geen actuele ondersteuning meer kent. De organisatie heeft er daarom verder geen onderhoud aan laten plegen en ineens krijgen ze een brief van hun hostingprovider dat ze nu echt PHP versie 5.3 gaan uitschakelen. Via via komen ze dan bij mij terecht of ik ze uit de brand kan helpen. De code is nooit geüpdate, het state of the art framework van toen staat bijna op instorten. Dan moet je redden wat er te redden valt en het framework van binnenuit repareren. Deprecated en obsolete methodes vervangen en proberen de boel weer een beetje bij de tijd te brengen.

Of wat ik nog wel eens tegenkom is dat er een mooi framework is gebruik maar dat je in de code duidelijk kunt zien dat de PHP-developers onderling oorlog hebben gehad met als resultaat dat je tegen compleet schizofrene code aan zit te kijken. Dat komt dus ook voor.

Of te wel, frameworks zijn nuttig mits goed gekozen en goed toegepast. Maar zelfs dan komt het met grote regelmaat voor dat minder dan de helft van de geboden functionaliteit daadwerkelijk wordt gebruikt en je er eigen tools tegenaan zet om de dingen te kunnen doen die je wilt doen.

[DJMaze]

Hydra schreef op donderdag 15 april 2021 @ 12:07:
Ik heb in m'n carriere 3 situaties meegemaakt waar developers zelf XML gingen parsen of schrijven i.p.v. standaard library te gebruiken die geleid hebben tot tienduizenden euro's aan extra ontwikkelkosten omdat dingen als 'validatie' of 'unicode' als onnodig beschouwd werden, of uberhaupt niet op de radar waren.

Ik heb in m'n carriere meerdere situaties meegemaakt waarbij ik alle XML fouten van grote bedrijven moest repareren.
En ja, ik heb de problemen bij de mannen van booking.com , postnl, etc. etc. gemeld.
Vooral de XML hel in SOAP/WSDL via .NET was patch gekkenwerk.

Geef mij dan maar XMLReader van PHP om de rommel op te ruimen


Verder gebruik ik alles wat werkt voor het doel. Je zal bij mij dus altijd stukjes/delen van frameworks, micro-frameworks, libraries en weet niet wat vinden.
Want als je kijkt naar de code is die eigenlijk altijd wel weer verouderd.

[ Voor 13% gewijzigd door DJMaze op 17-04-2021 00:04 ]

[Creepy]

Ik ben wel heel benieuwd tegen wat voor problemen je aanliep met de soap api's van de bedrijven die je noemt. Want als de XMLreader ze kan lezen, was het blijkbaar in elk geval valide XML. Want ik vind je nogal heel kort door de bocht met je "alle XML fouten van grote bedrijven" omdat die "grote bedrijven" 9 van de 10 keer dus wel frameworks gebruiken en alle XML zaken dus worden gegenereerd door een framework of library

[Oon]

FrankHe schreef op vrijdag 16 april 2021 @ 23:39:
[...]
Bij .NET en JAVA zal het een en ander wat beter geregeld zijn. Een "industriestandaard" framework is in de PHP-wereld nog wel eens een vloeibaar begrip. Het framework dat vandaag hot is is morgen obsolete. Een framework is niet zo heilig als mensen soms plegen te beweren. Er is een behoorlijke wildgroei aan PHP frameworks.

Dan weet ik niet welke industrie jij in werkt, maar er zijn toch echt gewoon design patterns die heel erg gestandaardiseerd zijn, en een aantal frameworks waarvan sommige gewoon echt industriestandaarden zijn.

Ja, er zal vast ooit een keer komen dat ook die hun ontwikkeling stippen, maar het gaat hier niet om frameworkjes die door iemand in 'n weekend in elkaar gezet zijn voor de hobby, maar om hele organisaties die evenementen organiseren en echt hele goeie developers in hun repo's hebben. Daar kan jouw setje snippets echt niet tegenop, en de kans dat jij jouw snippets nog onderhoudt over 10 jaar is vele malen kleiner dan dat die frameworks dan nog bestaan.

[ Voor 8% gewijzigd door Oon op 17-04-2021 01:02 ]

[MarcoC]

Frameworks zijn niet slecht of goed. Frameworks zijn een keuze, en elke keuze heeft kosten en baten. Wat vaak niet goed gaat, is dat bij de evaluatie van frameworks enkel gekeken wordt naar de baten en niet naar de kosten. Een framework is een extra afhankelijkheid en elke afhankelijkheid brengt kosten met zich mee. Plots moet je vertrouwen op de kwaliteit van het framework en wordt je productkwaliteit sterk beïnvloed door de kwaliteit van het framework. En zit die ene error in je applicatiecode, je framework, of de gluecode die alles met elkaar verbindt? Plots wordt debuggen een stuk ingewikkelder.

Daarnaast moet je ook de baten evenwichtig beschouwen. Software schrijven is goedkoop, onderhouden niet. Frameworks dwingen vaak ook een bepaalde way-of-working en standaardisatie af. In sommige organisaties kan dat veel voordelen hebben. Oneindige keuzevrijheid brengt autonomie, maar dat brengt ook als nadelen versplintering van kennis en het meermaals opnieuw uitvinden van het wiel.

Overigens merk ik dat deze discussie veel over PHP gaat, maar de wereld is natuurlijk veel breder dan dat. PHP is een vreemde eend in de bijt omdat het vrijwel uitsluitend in een ecosysteem gebruikt wordt (we hebben niet voor niets termen als "LAMP"-stack bedacht, dat zie je in andere talen veel minder). PHP zonder frameworks doet vrij weinig.

[Lethalis]

Creepy schreef op zaterdag 17 april 2021 @ 00:47:
Ik ben wel heel benieuwd tegen wat voor problemen je aanliep met de soap api's van de bedrijven die je noemt. Want als de XMLreader ze kan lezen, was het blijkbaar in elk geval valide XML. Want ik vind je nogal heel kort door de bocht met je "alle XML fouten van grote bedrijven" omdat die "grote bedrijven" 9 van de 10 keer dus wel frameworks gebruiken en alle XML zaken dus worden gegenereerd door een framework of library

In all fairness: ik moet vanuit .NET ook weleens XML met de hand parsen / aanpassen, omdat de andere kant Java gebruikt. En Java kan bepaalde zaken met bijvoorbeeld enums die .NET simpelweg niet ondersteunt.

Dat is echter niet de fout van "grote bedrijven" Maar simpelweg de WSDL parser / proxy generator van Microsoft die over zijn nek gaat als hij dingen tegenkomt die hij niet snapt.

[n9iels]

FrankHe schreef op vrijdag 16 april 2021 @ 23:39:
[...]
Of te wel, frameworks zijn nuttig mits goed gekozen en goed toegepast. Maar zelfs dan komt het met grote regelmaat voor dat minder dan de helft van de geboden functionaliteit daadwerkelijk wordt gebruikt en je er eigen tools tegenaan zet om de dingen te kunnen doen die je wilt doen.

Maar is het erg om maar 50% van de functionaliteiten te gebruiken? Veel Frameworks zijn modulair opgezet waardoor je ongebruikte onderdelen niet inlaad en ook niet mee compileert.

Er bestaat geen framework wat perfect is en voor elke taak 100% geschikt. Om exact die reden zijn veel frameworks uitbreidbaar zodat een ontwikkelaar, indien nodig, zijn eigen tools erin kan zetten. Het gebruiken van framework A schrijf tenslotte niet voor dat alles uit framework A moet komen. Is de discussie hier niet eerder dat frameworks vaak te log en alles omvattend zijn?

Het werken zonder groot framework zou moeten kunnen zolang je het dan zelf maar met een bekend en goed design pattern aan elkaar knoopt. Maar het zelf implementeren van JSON/XML patsers, authenticatie en database ORM's is vragen om problemen en vindt ik zonde van mijn tijd. Liever gebruik ik dan een licht-gewicht framework wat kan fungeren als kapstok waar ik zelf mijn spullen aan hang.

[ Voor 4% gewijzigd door n9iels op 17-04-2021 09:05 ]

[FrankHe]

MarcoC schreef op zaterdag 17 april 2021 @ 01:10:
Frameworks zijn niet slecht of goed. Frameworks zijn een keuze, en elke keuze heeft kosten en baten. Wat vaak niet goed gaat, is dat bij de evaluatie van frameworks enkel gekeken wordt naar de baten en niet naar de kosten. Een framework is een extra afhankelijkheid en elke afhankelijkheid brengt kosten met zich mee. Plots moet je vertrouwen op de kwaliteit van het framework en wordt je productkwaliteit sterk beïnvloed door de kwaliteit van het framework. En zit die ene error in je applicatiecode, je framework, of de gluecode die alles met elkaar verbindt? Plots wordt debuggen een stuk ingewikkelder.

Daarnaast moet je ook de baten evenwichtig beschouwen. Software schrijven is goedkoop, onderhouden niet. Frameworks dwingen vaak ook een bepaalde way-of-working en standaardisatie af. In sommige organisaties kan dat veel voordelen hebben. Oneindige keuzevrijheid brengt autonomie, maar dat brengt ook als nadelen versplintering van kennis en het meermaals opnieuw uitvinden van het wiel.

Overigens merk ik dat deze discussie veel over PHP gaat, maar de wereld is natuurlijk veel breder dan dat. PHP is een vreemde eend in de bijt omdat het vrijwel uitsluitend in een ecosysteem gebruikt wordt (we hebben niet voor niets termen als "LAMP"-stack bedacht, dat zie je in andere talen veel minder). PHP zonder frameworks doet vrij weinig.

Ik heb vaak genoeg PHP-code gezien waarin geen framework is toegepast. En dan heb ik het niet over mijn eigen producten. En het klopt inderdaad dat PHP een beetje een vreemde eend in de bijt is. Stikt genomen is het een scriptingtaal. Dat is althans waar het vandaan komt. Met versie 7 is dat al een stuk verbeterd en nu met versie 8 op komst begint het meer trekken te krijgen van een programmeertaal.

[jbdeiman]

Uhmmie schreef op maandag 12 april 2021 @ 10:09:
[...]


[...]


[...]


Ik heb wel een voorbeeldje, zonder dat we meteen heel complex gaan worden. We gaan dan wel een aantal jaar terug.

We maakte gebruik van Symfony met Doctrine. Op een gegeven moment hadden we een reden waarom we de auto-incremental ids moesten vervangen door een uuid als primary key. Helaas werd dat op dat moment niet ondersteund door doctrine. Er was toen wel al een mogelijkheid om je eigen ids te generen, maar helaas pakte dat toch anders uit dan gewenst. We hebben toen ook nog contact gehad met een ontwikkelaar van Doctrine en hun gaven toen zelf ook aan dat het op dat moment nog niet mogelijk was, maar dat ze wel met een oplossing bezig waren.
Op dat moment zit je muurvast. Niet alleen in doctrine, maar ook in symfony aangezien je totdat moment alles netjes via de de gangbare manier hebt opgezet.

Maar even... Dit probleem zou je toch ook gehad hebben wanneer je zelf je packages kiest? Want die kies je omdat die 'op dat moment' het beste passen voor wat je wil.bereiken. wanneer je er tussen tijds achter komt dat het anders moet worden zal je moeten hopen dat de gekozen package de betreffende optie ondersteund.
En zo ja, kan je mazzel hebben maar het kan dan nog steeds zo zijn dat je package het niet ondersteund en je op zoek moet naar een ander, of dat je er zelf een aanvulling voor moet bouwen.

Ok, bij veel frameworks heb je (voor je gevoel) niet dezelfde controle over de packages, maar er is (technisch) geen enkel probleem om een andere routing package te kiezen, kost je alleen meer werk om de dependencies dan aan te passen, maar dat heb je eigenlijk ook wanneer je zelf op basis van eigen gekozen sets aan packages een eigen framewot hebt opgezet.

[Hydra]

Creepy schreef op zaterdag 17 april 2021 @ 00:47:
Ik ben wel heel benieuwd tegen wat voor problemen je aanliep met de soap api's van de bedrijven die je noemt. Want als de XMLreader ze kan lezen, was het blijkbaar in elk geval valide XML. Want ik vind je nogal heel kort door de bocht met je "alle XML fouten van grote bedrijven" omdat die "grote bedrijven" 9 van de 10 keer dus wel frameworks gebruiken en alle XML zaken dus worden gegenereerd door een framework of library

Een van de issues die ik heb gehad was een integratie met spul van HP (ja die van die scanners) waar een stagair met de hand XML in elkaar geklust had. Dus dat het een groot bedrijf is, is geen garantie dat het goed gedaan wordt.

[Hydra]

Lethalis schreef op zaterdag 17 april 2021 @ 08:33:
[...]
Dat is echter niet de fout van "grote bedrijven" Maar simpelweg de WSDL parser / proxy generator van Microsoft die over zijn nek gaat als hij dingen tegenkomt die hij niet snapt.

Dit is al heel lang zo. Microsoft heeft vaak grote issues zich aan de standaarden te houden. Terug in 2005 was dit al een groot probleem.

En nog maar een paar jaar geleden moeten integreren met een API gebouwd door Microsoft consultants; lekker 200 status teruggeven bij een error, volledige willekeur of iets een post of een put was, etc. Drama. Heb geen hoge pet op van MS.

[Hydra]

FrankHe schreef op vrijdag 16 april 2021 @ 23:39:
In de afgelopen jaren heb ik veel producten gezien die in een framework zijn gebouwd dat negen jaar geleden helemaal de bom was, maar dat geen actuele ondersteuning meer kent. De organisatie heeft er daarom verder geen onderhoud aan laten plegen en ineens krijgen ze een brief van hun hostingprovider dat ze nu echt PHP versie 5.3 gaan uitschakelen. Via via komen ze dan bij mij terecht of ik ze uit de brand kan helpen. De code is nooit geüpdate, het state of the art framework van toen staat bijna op instorten. Dan moet je redden wat er te redden valt en het framework van binnenuit repareren. Deprecated en obsolete methodes vervangen en proberen de boel weer een beetje bij de tijd te brengen.

Als men daar alles zelf had willen doen, dan was het hele probleem gewoon nog veel erger geweest. Dit is eerder een argument voor het gebruik van frameworks dan tegen.

Niet bijblijven is sowieso een risico dat bedrijven vaak onderschatten. Maargoed; ik zit sowieso op hele andere projecten waar een 'hostingpartij' geen mening gaat hebben over welke versie ik gebruik van wat dan ook.

[Voutloos]

FrankHe schreef op zaterdag 17 april 2021 @ 09:18:
[...]

Ik heb vaak genoeg PHP-code gezien waarin geen framework is toegepast. En dan heb ik het niet over mijn eigen producten. En het klopt inderdaad dat PHP een beetje een vreemde eend in de bijt is. Stikt genomen is het een scriptingtaal. Dat is althans waar het vandaan komt. Met versie 7 is dat al een stuk verbeterd en nu met versie 8 op komst begint het meer trekken te krijgen van een programmeertaal.

PHP is al jaren geen ‘scriptingtaal’, als je maar een beetje discipline hebt. Die term wordt anno nu echt bijna alleen maar door trolls gebruikt, dus ik laat het hierbij. Gewoon met je team kiezen voor de populaire PSRs, composer etc en je kan prima netjes bezig.
En met symfony, Laravel, etc zijn er voldoende goede componenten of frameworks. De tijden van elke maand een nieuwe brakke concurrent voor het eveneens brakke Zend Framework 1 zijn lang achter ons.

[ Voor 11% gewijzigd door Voutloos op 17-04-2021 15:48 ]

[Voutloos]

Eigenlijk, als je het nu nog een scriptingtaal noemt, zegt dat misschien ook iets over jezelf.

[Dricus]

Voutloos schreef op zaterdag 17 april 2021 @ 15:53:
Eigenlijk, als je het nu nog een scriptingtaal noemt, zegt dat misschien ook iets over jezelf.

offtopic:
Dat PHP een Wikipedia: Scripting language is, is gewoon een feit, net zoals dat voor JavaScript, Python, Groovy, etc zo is. Blijkbaar heeft de term "scripttaal" bij veel mensen een negatieve connotatie. Dat zegt meer over die mensen dan over de term en de talen die onder die noemer vallen.

Ontopic:
Ik ben geen PHP programmeur, maar heb wel veel ervaring met Java en .NET. In die twee ecosystemen zijn zulke goede, volwassen frameworks beschikbaar dat het gebruik daarvan wat mij betreft een no-brainer is. Bij de organisaties waar ik werk en gewerkt heb wordt bij de selectie van (open source) frameworks wel goed gekeken naar volwassenheid, en hoe actief het onderhouden wordt. Nieuwe, hippe FOTM frameworks zullen uitgeprobeerd worden, maar niet zo snel in serieuze productiecode toegepast worden.

Daarnaast ben ik er ook een voorstander van om die frameworks niet je complete applicatie-architectuur te laten domineren. In een Wikipedia: Hexagonal architecture (software) bijvoorbeeld, zal ik de Application (core) layer zo veel mogelijk vrij houden van frameworks, met name om de testbaarheid van die code te maximaliseren. In de Adapters layer is het gebruik van frameworks in mijn ogen een no-brainer.

[Kwistnix]

Hydra schreef op woensdag 14 april 2021 @ 08:53:
Ik gebruik geen Hibernate; het is een gedrocht dat meer problemen oplevert dan het oplost.

Gaat licht offtopic, maar ik ben wel erg benieuwd hoe je daar in de praktijk mee wegkomt, want in mijn hele carrière heb ik nog niet bij een klant gezeten waar ze geen Hibernate of equivalente JPA implementatie (EclipseLink) gebruikten. En ik ben wel benieuwd wat jij een beter alternatief vindt, jOOQ?

[Lethalis]

Kwistnix schreef op zondag 18 april 2021 @ 14:30:
[...]

Gaat licht offtopic, maar ik ben wel erg benieuwd hoe je daar in de praktijk mee wegkomt, want in mijn hele carrière heb ik nog niet bij een klant gezeten waar ze geen Hibernate of equivalente JPA implementatie (EclipseLink) gebruikte. En ik ben wel benieuwd wat jij een beter alternatief vindt, jOOQ?

Interessante vraag. In de .NET wereld is toch ook best veel Entity Framework, en is het zelfs ronduit lastig om het niet te gebruiken als je andere frameworks wil gebruiken zoals het Identity Framework.

Ik gebruik weleens Dapper (micro orm), maar zodra de boel complexer wordt, krijg je daar ook weer spijt van.

[Hydra]

Kwistnix schreef op zondag 18 april 2021 @ 14:30:
Gaat licht offtopic, maar ik ben wel erg benieuwd hoe je daar in de praktijk mee wegkomt, want in mijn hele carrière heb ik nog niet bij een klant gezeten waar ze geen Hibernate of equivalente JPA implementatie (EclipseLink) gebruikten. En ik ben wel benieuwd wat jij een beter alternatief vindt, jOOQ?

jOOQ is fijn, alleen is licensing vaak een issue. Maar eerlijk gezegd vind ik gewoon Spring Data JDBC ook eigenlijk gewoon fijn werken. Exposed is ook wel een fijn framework.

Hibernate vermijd ik actief. De laatste keer dat ik er mee gewerkt heb, was iets van 5 jaar geleden. Ter info; de mobiele bank-end van de ING bijvoorbeeld, gebruikt ook geen Hibernate.

[Woy]

Lethalis schreef op zondag 18 april 2021 @ 15:43:
[...]

Interessante vraag. In de .NET wereld is toch ook best veel Entity Framework, en is het zelfs ronduit lastig om het niet te gebruiken als je andere frameworks wil gebruiken zoals het Identity Framework.

Ik gebruik weleens Dapper (micro orm), maar zodra de boel complexer wordt, krijg je daar ook weer spijt van.

Mwah, valt wel mee wat mij betreft. Het ligt er ook vooral vanaf hoe het opgezet is. Als alles door alle lagen heb gebruik maakt van EF is het een ramp. Maar als het gewoon netjes geïsoleerd is in de data access layer is het prima, en kun je het ook wel vervangen als het echt nodig is.

Dat moet wat mij betreft ook de insteek zijn bij het kiezen van frameworks. Het levert een hoop op, maar als je alles er aan verbind dan levert dat op termijn altijd kosten op omdat elk framework eens outdated raakt. Dat is overigens niet anders bij zelf geschreven of bij elkaar geraapte frameworks.

Soms is het ook een bewuste keuze om iets niet voor de lange termijn te schrijven, maar dan moet je ook niet opkijken dat je die kosten een keer moet pakken als het product toch langer meegaat dan gepland

[Lethalis]

@Woy
Daarom is wat @Dricus schrijft over het toepassen van hexagonal architecture op zich ook niet verkeerd.

De gemiddelde .NET backend bij mij bestaat uit:
- Framework: ASP.NET web api (core) controllers
- Service laag: services die eigenlijk de applicatie vormen en meestal via dependency injection worden gekoppeld aan de controllers
- Data laag: kan van alles zijn

Maar het is juist die scheiding tussen het framework en de service laag die ik belangrijk vind. Want het is exact daar waar ik vaker in de problemen ben gekomen in het verleden. Dat je een leaky abstraction had, framework code vermengd was met de applicatiecode, enzovoorts.

Even upgraden naar een ander framework werd dan een hel.

Terwijl ik nu gewoon een nieuw project kan aanmaken, een reference naar mijn service assembly maak, de boel weer aan elkaar knoop en verder ga met mijn leven.

Daarnaast is het een mooi aanknooppunt om tests op te schrijven (op de service laag).

Helaas deed ik dat 14 jaar geleden nog niet en werk ik nog bij dezelfde tent, dus soms moet ik even door de zure appel heen bijten als ik een oud project weer tot leven moet wekken.

[FrankHe]

Hydra schreef op zaterdag 17 april 2021 @ 15:17:
[...]

Als men daar alles zelf had willen doen, dan was het hele probleem gewoon nog veel erger geweest. Dit is eerder een argument voor het gebruik van frameworks dan tegen.

Niet bijblijven is sowieso een risico dat bedrijven vaak onderschatten. Maargoed; ik zit sowieso op hele andere projecten waar een 'hostingpartij' geen mening gaat hebben over welke versie ik gebruik van wat dan ook.

Het zijn ook niet mijn eigen projecten maar de bouwsels van anderen die via via op een gegeven moment bij mij terecht komen. Wat ik probeerde te illustreren is dat tijdig onderhoud belangrijk is en een obscuur framework van tien jaar geleden ook echt voor veel problemen kan zorgen.

De wereld is groter dan alleen PHP maar feit is dat de meeste toepassingen online in PHP zijn geschreven en in veel gevallen gewoon niet zo heel erg goed zijn geschreven. Ik kom echt van alles tegen, zoals plain text wachtwoorden in een bestand, daar waar het framework een prachtige goedwerkende module heeft om accounts af te handelen. Een framework is leuk maar als een ontwikkelaar vervolgens hele andere dingen gaat zitten doen dat was het framework eigenlijk zo goed als zinloos.

Ik hoop dat het in C# en Java een stuk beter is. Al gloort er wel hoop voor PHP met versie 8 in het vooruitzicht zoals eindelijk strict typing.

[FrankHe]

Voutloos schreef op zaterdag 17 april 2021 @ 15:45:
[...]
PHP is al jaren geen ‘scriptingtaal’, als je maar een beetje discipline hebt. Die term wordt anno nu echt bijna alleen maar door trolls gebruikt, dus ik laat het hierbij. Gewoon met je team kiezen voor de populaire PSRs, composer etc en je kan prima netjes bezig.
En met symfony, Laravel, etc zijn er voldoende goede componenten of frameworks. De tijden van elke maand een nieuwe brakke concurrent voor het eveneens brakke Zend Framework 1 zijn lang achter ons.

Mee eens. Er draait ook nog steeds heel veel legacycode. Toepassingen van enkele jaren geleden die zijn gebouwd op basis van wat inmiddels verouderde frameworks zijn. Die code moet blijven draaien en die zaken moeten dus linksom of rechtsom van PHP versie 5.4 naar 7.3 worden getrokken. Dat zijn de soort projecten waar je als ontwikkelaar nog wel eens mee te maken hebt. "Abandonware" die voor de klant toch ineens heet belangrijk blijkt te zijn en kosten wat het kost in leven moet worden gehouden. Zend en varianten kom ik nog geregeld tegen.

[Lethalis]

FrankHe schreef op maandag 19 april 2021 @ 09:55:
[...]
1. Wat ik probeerde te illustreren is dat tijdig onderhoud belangrijk is en een obscuur framework van tien jaar geleden ook echt voor veel problemen kan zorgen.

2. Ik hoop dat het in C# en Java een stuk beter is. Al gloort er wel hoop voor PHP met versie 8 in het vooruitzicht zoals eindelijk strict typing.

1. Daarom moet je ook altijd voor een veelgebruikt framework kiezen. Dat krijgt namelijk veel support.

2. Ook daar zul je een hoop rotzooi tegenkomen. Bij .Net misschien nog wat meer dan bij Java, omdat daar veel ex VB developers tussen zitten die een nieuw trucje hebben geleerd maar niet per se kwalitatief hoogwaardige oplossingen leveren om het zo maar te zeggen.

Het feit dat Microsoft regelmatig is aangevallen in hun blogs omdat ze WebForms niet porten naar .Net Core / .Net 5 zegt genoeg

[Mugwump]

FrankHe schreef op maandag 19 april 2021 @ 09:55:
[...]

Het zijn ook niet mijn eigen projecten maar de bouwsels van anderen die via via op een gegeven moment bij mij terecht komen. Wat ik probeerde te illustreren is dat tijdig onderhoud belangrijk is en een obscuur framework van tien jaar geleden ook echt voor veel problemen kan zorgen.

De wereld is groter dan alleen PHP maar feit is dat de meeste toepassingen online in PHP zijn geschreven en in veel gevallen gewoon niet zo heel erg goed zijn geschreven. Ik kom echt van alles tegen, zoals plain text wachtwoorden in een bestand, daar waar het framework een prachtige goedwerkende module heeft om accounts af te handelen. Een framework is leuk maar als een ontwikkelaar vervolgens hele andere dingen gaat zitten doen dat was het framework eigenlijk zo goed als zinloos.

Ik hoop dat het in C# en Java een stuk beter is. Al gloort er wel hoop voor PHP met versie 8 in het vooruitzicht zoals eindelijk strict typing.

In elke taal kun je natuurlijk bagger produceren. Het verschil is wel dat .Net en Java historisch gezien niet zijn ontstaan als scriptingtaaltjes en geen wildgroei aan flavor-of-the-week frameworkjes hebben gehad. In een ver verleden heb ik nog wel PHP gedaan en toen had ik inderdaad ook wel wat van die mensen met een frameworkfobie, omdat ze in het verleden wel met frameworks hadden gewerkt die óf opeens niet meer ondersteund werden óf allerlei concepten op een halfbakken wijze uit fatsoenlijke OO-talen hadden gejat waardoor het allemaal nogal complex werd.

.Net heb ik slechts sporadisch wat gedaan, maar een belangrijk voordeel van Java is dat er op veel vlakken wel een soort van centrale specificatie aan ten grondslag ligt waar verschillende frameworks zich dan min of meer conformeren, net als relationele databases zich min of meer conformeren aan de SQL standaard.

Maar ik zit nu toevallig in een stukje migratie waarbij de tranen me ook vaak in de ogen schieten bij het zien van de oude code. Zaken als letterlijk harde koppelingen tussen logica in de front-end applicatie en logica in de repository implementatie in de back-end, stukjes dataverwerking die zo procedureel als wat zijn door een of andere anemic model sequentieel muteren door een lange procedurele lap met methodesvan de vorm void setSomething(MutableModel model) en daartussen dan weer allerlei control structures die het datamodelletje gebruiken om te bepalen wat er gedaan moet worden.
Daar moet dus onder andere een ander type datastore onder komen te hangen. Bij fatsoenlijk geschreven code zou dat (technische complicaties daargelaten) eigenlijk niets meer moeten zijn dan een nieuwe repository implementatie toevoegen en wiren. Maar als je totaal geen abstractie toepast en je front-end zo ongeveer SQL naar een repository implementatie laat spugen, dan wordt dat lastig natuurlijk.

Frameworks of niet, een goede opzet van code maakt het in principe mogelijk om de domeinlogica te extraheren en in een compleet ander framework te hangen. Wellicht wat annotaties aanpassen voor autowiring, maar dat zou het dan ook moeten zijn.
Sowieso is het een beetje de vraag wanneer je van een framework spreekt en wanneer je precies van een library spreekt. Zijn unit test of mocking zaken als JUnit of Mockito libraries of frameworks of zijn frameworks enkel zaken die zo breed zijn dat de ze de structuur van (een groot deel) van je hele applicatie voorschrijven?