Moet altijd alles een moderne SPA zijn?

[Lethalis]

Ik ben benieuwd wat jullie mening is over het bouwen van single page applications (SPA's).

Anno nu lijkt het alsof iedereen niks anders doet dan Angular of React apps maken, waarbij de gehele frontend uiteindelijk puur uit frontend technieken bestaat en de backend eigenlijk alleen nog uit een REST API.

Terwijl we vroeger veel web applicaties met server side MVC frameworks maakten (ASP.NET MVC, Spring MVC, etc).

En wou je in die tijd wat interactiviteit toevoegen aan een applicatie, dan voegde je even jQuery aan het project toe en klaar was Kees. Well, not anymore... want je komt - als je alle blogs op het internet mag geloven - anno nu al gauw in een keten terecht van npm, webpack, babel, babel-loaders voor react, style-loaders, css-loaders, enzovoorts, enzovoorts.

Op mijn werk gebruiken we voor een aantal projecten bijvoorbeeld Angular. De Angular-cli neemt een deel van de ellende uit handen, maar je ziet wel dat een web applicatie bouwen een alles of niets situatie is: de hele site is in Angular (en daarmee een SPA), of niet.

Ga je naar de website van ReactJS, dan beloven ze jou dat je het ook gewoon in bestaande applicaties kan gebruiken... totdat je natuurlijk iets meer wil dan Hello World en voor je het weet, zit je jezelf af te vragen hoe je het in vredesnaam nog combineert met een bestaande webapplicatie van meer dan 5 jaar oud die nog in ASP.NET MVC gemaakt was.

En lijkt het dus uiteindelijk makkelijker om alles maar opnieuw te gaan bouwen...

Hoe gaan jullie hiermee om? Ik kan me zo voorstellen dat er bij andere bedrijven ook nog tig websites / webapplicaties gebouwd zijn met relatief ouderwetse technieken (server side MVC framework dat views rendert met een beetje jQuery / AJAX voor interactieve componenten).

Ga je voor die projecten dan rustig verder met MVC?
Probeer je met man en macht nieuwe technieken te integreren, zoals React componenten?
Of ga je zelfs zo ver dat - wanneer het binnen redelijke termijn kan - je de hele boel overboord gooit en opnieuw begint in Angular of React?

Of zijn er ook mensen die zich gewoon niet zoveel van dit alles aantrekken en nog steeds met MVC frameworks webapplicaties bouwen?

Want eerlijk is eerlijk, voor de dertien in een dozijn CRUD backoffice applicatie heb je al die nieuwe technieken misschien wel helemaal niet nodig? Niet elke page refresh is rampzalig. En waar het er wel toe doet, zou je dus eventueel React kunnen integreren (als het je lukt).

Is dat tegenwoordig echt not done? Of helemaal niet zo gek?

Of ben ik nu echt een dinosaurus aan het worden dat ik mij dit überhaupt afvraag?

[NMe]

We maken hier op kantoor best hippe websites maar ik heb persoonlijk nog nooit een SPA hoeven bouwen. Ik heb er wel eens een gebouwd die wat SPA-kenmerken had voor sub-onderdelen, maar daar is dan ook alles mee gezegd.

Het hangt vooral van de wens van de klant af. De meeste zakelijke websites hebben het echt niet nodig dat ze een SPA zijn. Een webshop als SPA implementeren kost meer tijd maar heeft eigenlijk geen enkel voordeel. Wat dat betreft is een SPA eigenlijk vooral zinnig bij hippe sites die als korte presentatie van een enkel product of een enkele dienst werken, of juist bij echte applicaties (denk aan Electron-apps zoals Discord en Slack).

[Gomez12]

Tja, het hangt er voornamelijk vanaf waar je het over hebt.

Je begint met te zeggen :

Anno nu lijkt het alsof iedereen niks anders doet dan Angular of React apps maken

En qua web-apps met interactiviteit etc zou ik zeker SPA's in meer of mindere mate aanraden.

Terwijl je het later weer over websites gaat hebben, waarbij wmb de noodzaak tot interactiviteit al bijna geheel weg is en je dus gewoon nog een MVC web-site kan maken.

Wmb als het de bedoeling/verwachting is dat >80% van je users enkel de pagina leest dan noem ik het een website en dan kan je volstaan met MVC
Echter als het de bedoeling/verwachting is dat >80% van je users interactief op de pagina bezig is dan noem ik het een app en dan zou je kunnen kijken naar een SPA.

Let wel op dat een SPA in mijn praktijk nooit een echte complete SPA is, de complete SPA's die geen server-side views etc gebruiken zijn wmb meer technische demo's dan praktijkvoorbeelden.

Puur omdat ik in de praktijk vaak genoeg hele duidelijke scheidingslijnen zie tussen gedeeltes in een app waar een page-refresh gewoon kan en die de overall complexiteit van de app al snel heel veel kleiner maakt.

Zoals NMe al zegt, een complete webshop als SPA voegt weinig toe, maar een bestelmandje / bestelproces als SPA kan er net voor zorgen dat je een paar page-refreshes mist waardoor men sneller kan bestellen en verdergaan.

Maar React zegt het zelf eigenlijk wmb al goed op hun website : A JavaScript library for building user interfaces

Is de website die je gaat bouwen een user interface, of is het een marketingplaatje?

[Lethalis]

Gomez12 schreef op woensdag 21 augustus 2019 @ 13:49:
Tja, het hangt er voornamelijk vanaf waar je het over hebt.

9 van de 10 keer gewoon over web applicaties waar je simpelweg dingen in onderhoudt.

Bijvoorbeeld klantgegevens, artikelen, orders tikt. Dingen die wel interactief zijn, maar ook niet per se technisch hoogstaand hoeven te zijn.

Sowieso boeit een page refresh niet als je van klantgegevens naar artikelgegevens zou gaan bijvoorbeeld. Maar zou je kunnen denken dat een grid weergave op zo'n pagina wel dynamisch is en client side.

Je zou zoiets dus kunnen oplossen door een MVC web applicatie te bouwen met controllers en views voor klantgegevens en artikelgegevens. Maar op deze views wél React componenten kunnen gebruiken, zodat het toevoegen of wijzigen van die gegevens wel vloeiend gaat. Of bijvoorbeeld het snel zoeken naar de juiste gegevens.

Het voordeel ten opzichte van alles in een SPA bouwen, is dan dat de web applicatie zelf relatief eenvoudig op te zetten is en dat je alleen wat client side componenten hebt om snel iets te zoeken op een pagina of een grid weer te geven dat je eenvoudig kunt sorteren etc.

Meestal als ik aan web applicaties werk, dan zijn dat backoffice dingen of inderdaad gespecialiseerde webshops. Een collega van mij is helemaal weg van Angular en heeft een belangrijke webshop dus helemaal herschreven daarin.

Op zich best knap, maar ik ben meestal niet zo van de complete rewrites en doe liever incrementele wijzigingen / verbeteringen. Vandaar dat ik meer naar React kijk (heb ook al met ReactJS.Net gespeeld, en zelf React from scratch tutorials gevolgd die met webpack en babel alles opzetten).

Maar ik ben dus geneigd het overgrote deel van de web applicaties gewoon MVC te laten zijn, met wat interactieve componenten hier en daar.

ASP.Net Core maakt het ook iets makkelijker dit te combineren, omdat je een wwwroot map hebt waar je client side app in kan leven en omdat de csproj files niet meer elk bestand hoeven te specificeren.

Echt websites bouwen, als een hippe presentatie van een bedrijf ofzo, doe ik zo goed als niet. We hebben het dus meer over webapplicaties waar je iets mee doet. Waar klanten op inloggen om facturen te downloaden, te controleren of artikelen op voorraad zijn, retouren af te handelen enzovoorts.

[Freeaqingme]

In mijn beleving is de frontend wereld een wereld waarin heel veel nieuwkomers beginnen (uiteraard heb je ook wel mensen die al 15+ jaar frontenden). Die nieuwkomers hebben nog weinig 'bagage' en pakken graag het nieuwste van het nieuwste. Waar bij bijv. PHP je al jaren Laravel en Symfony als leading frameworks hebt die vaak ook nog voor het grootste deel Backwards Compatible zijn, lijkt het in de frontendwereld alsof er iedere 6 maanden weer een ander/nieuw framework hip is. Eventuele nieuwe versies breken dan ook volop BC.

Dat is allemaal niet erg, maar heb wel het idee dat het ook deze groep mensen is die veelvuldig SPA's pusht. Hierboven werd aan Angular gerefereerd, dat werkt op zich allemaal fantastisch natuurlijk, maar het kan ook beperkend werken. Zo zou iedere pagina op gebouwd moeten zijn uit losse componenten. Wee je gebeente als je achteraf vraagt of 2 elementen gecombineerd kunnen worden. "Had dat vooraf gezegd!! Je kan helemaal niet componenten samenvoegen in Angular!".

Mijn conclusie is dat SPA's goed zijn voor extreem interactieve/complexe frontend toepassingen, maar dat de rest prima gewoon server side gerendered kan worden in iets traditionelers. Stel dat ik een kloon moet maken van Google Sheets dan is een SPA daar een mooie oplossing voor, maar het bijbehorende reactieformulier hoeft dat dan weer niet te zijn.

[killercow]

Ik vindt SPA's persoonlijk dood en dood zonde voor de kwaliteit van het web.
De applicaties zijn doorgaans vele malen zwaarder op de browser, en omdat ze niet knap in elkaar zitten qua backward compatibiliteit is het huilen met de pet op als je kijkt naar zoekmachine vriendelijkheid, bruikbaarheid voor slechtzienden etc.

Een jaar of wat terug was het piek-moment denk ik, mooie html / xml als backend, die optioneel ook als json te benaderen was. Eventueel zelfs met een mooie DTD om uitleg te geven over de structuur.
Strakke nette css om de boel op te maken, en als toetje een laagje javascript om zaken *optioneel* interactief te maken. Niemand die je tegenhoudt om dan alsnog via async calls de data uit de backend te lepelen al dan niet als json om zo de frontend (refresh-free) te voorzien van nieuwe informatie.

Dit soort artikelen slaan *echt* volkomen de plank mis over hoe je ene web-app bouwt, omdat er volkomen vanaf de verkeerde kant wordt geredeneerd, met gaat letterlijk een browser nadoen op de server zodat er op de server data gegenereerd kan worden om geserveerd te worden aan de client die geen javascript lust.

Uiteraard ook alleen aan bepaalde user-agents, zodat eigenlijk alleen een handje vol zoekmachines er wat aan hebben.

* https://coursetro.com/pos...y-(Angular-4-+-Universal)
* https://medium.com/@eduos...does-it-work-e745ca1fae7b

[Freeaqingme]

killercow schreef op woensdag 21 augustus 2019 @ 14:57:
Ik vindt SPA's persoonlijk dood en dood zonde voor de kwaliteit van het web.
De applicaties zijn doorgaans vele malen zwaarder op de browser, en omdat ze niet knap in elkaar zitten qua backward compatibiliteit is het huilen met de pet op als je kijkt naar zoekmachine vriendelijkheid, bruikbaarheid voor slechtzienden etc.

Een jaar of wat terug was het piek-moment denk ik, mooie html / xml als backend, die optioneel ook als json te benaderen was. Eventueel zelfs met een mooie DTD om uitleg te geven over de structuur.
Strakke nette css om de boel op te maken, en als toetje een laagje javascript om zaken *optioneel* interactief te maken. Niemand die je tegenhoudt om dan alsnog via async calls de data uit de backend te lepelen al dan niet als json om zo de frontend (refresh-free) te voorzien van nieuwe informatie.

Hear hear! Ik werd laatst uitgelachen door een frontender toen ik begon over semantisch juiste html en overzichtelijke CSS. "Dat was vroeger".

Nou frontend ik gelukkig niet zo veel maar ik hoop dat men ooit tot het inzicht komt dat beginnen met semantisch goede html, waarover je css plakt en misschien nog wat javascript sprinkelt toch ook echt z'n voordelen heeft.

[killercow]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 15:04:
[...]


Hear hear! Ik werd laatst uitgelachen door een frontender toen ik begon over semantisch juiste html en overzichtelijke CSS. "Dat was vroeger".

Nou frontend ik gelukkig niet zo veel maar ik hoop dat men ooit tot het inzicht komt dat beginnen met semantisch goede html, waarover je css plakt en misschien nog wat javascript sprinkelt toch ook echt z'n voordelen heeft.

Ik begrijp die lui niet, ze zien hun medium onder hun voeten verdwijnen elke paar jaar, en nog houden ze vast aan bouwen voor 1 specifiek medium tot ze er bij neer vallen.

We gingen van pc naar pc met groot scherm, naar tablets, naar mobiel naar smart-watch api's, en dan eigenlijk nu ook naar puur alleen het onderste laagje uit de pyramide, usefull content voor de spraak-assistenten.

Het ging al met met css frameworks voor de meute als je kijkt naar de zooi die bootstrap is met een utility-classes. Welke mafkees besluit de html nou vol te duwen met class="rounded", dat hoort daar helemaal niet!

Als je bij ons op kantoor zo iets flikt kun je je biezen pakken wat mij betreft, omdat ik de html / components gewoon netjes reusable wil houden zodat de backend-devvers ze kunnen copy-pasten / automatisch kunnen produceren aan de hand van het datamodel. En, ja dus ook cross-project en cross-client.

[Acroach]

Ik loop ook al een aantal jaar mee maar ben zelf wel fan van React, ik gebruik het voor de wat grotere applicaties.

Voor statische websites maak ik gebruik van de JAM stack, groot fan van Gatsby wat uiteindelijk je react code weer compileert naar gewone plain html en css.

[Freeaqingme]

Acroach schreef op woensdag 21 augustus 2019 @ 15:15:
Ik loop ook al een aantal jaar mee maar ben zelf wel fan van React, ik gebruik het voor de wat grotere applicatie.

Het ene SPA framework zal vast beter zijn voor bepaalde toepassingen dan het andere framework. Maar, waarom is het gebruik van zo'n SPA-framework nou beter dan gewoon de 'traditionele' manier van websites maken?

[ThomasG]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 15:18:
[...]


Het ene SPA framework zal vast beter zijn voor bepaalde toepassingen dan het andere framework. Maar, waarom is het gebruik van zo'n SPA-framework nou beter dan gewoon de 'traditionele' manier van websites maken?

Neem het voorbeeld van dit forum. Als je een reactiepost, of je eigen reactie bewerkt, wordt de gehele pagina opnieuw geladen met andere content. Dat is eigenlijk nergens voor nodig, en ook best vervelend. Bij een SPA gebeurt dat niet, en heb je een betere "workflow". Het probleem is alleen dat veel SPA's erg slecht gebouwd zijn. Bij een goede SPA merk je niet dat het een "SPA" is.

[DJMaze]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 15:04:
Hear hear! Ik werd laatst uitgelachen door een frontender toen ik begon over semantisch juiste html en overzichtelijke CSS. "Dat was vroeger".

Dan moet je een jaar later vragen of hij "even" iets wil aanpassen in zijn code.
En vraag dan een half uur later waarom het nog niet af is

Lethalis schreef op woensdag 21 augustus 2019 @ 12:55:
Ik ben benieuwd wat jullie mening is over het bouwen van single page applications (SPA's).

Ik vervloek SPA bouwers. Op de één of andere manier vind ik altijd bugs waardoor mijn User eXperience echt onder 0 zakt

[ Voor 29% gewijzigd door DJMaze op 21-08-2019 15:52 ]

[Acroach]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 15:18:
[...]


Het ene SPA framework zal vast beter zijn voor bepaalde toepassingen dan het andere framework. Maar, waarom is het gebruik van zo'n SPA-framework nou beter dan gewoon de 'traditionele' manier van websites maken?

Ik vind het vooral wat sneller ontwikkelen, zeker als je wat componenten hebt die hergebruikt moeten worden.

[killercow]

Acroach schreef op woensdag 21 augustus 2019 @ 16:02:
[...]


Ik vind het vooral wat sneller ontwikkelen, zeker als je wat componenten hebt die hergebruikt moeten worden.

Maar hoe dan?

Letterlijk *elke* manier van traditioneel bouwen kent oplossingen voor hergebruik, hgeck, in html 3.2 zaten al frames zodat je je header en footer netjes in losse files kon opslaan. Daarna kwamen 'server side includes' en *elk* maar dan ook *elk* server-side framework kan files lezen en combineren uit losse templates/html bestandjes.

Als ik nu naar 'moderne' jonge developers kijk zie ik ze vooral tool-chains installeren en beheren van tientalle karige nodejs tools om hun zaakjes aan elkaar te compilen, te minifyen en weet ik wat nog meer om maar aan een werkende frontend te komen. Uiteraard weer met allerlei andere tools om de boel te triggeren op file-change, en de nodige package managers om de meest triviale stukjes functionaliteit in allerhande versies van random web-repositories te trekken.

[Not Pingu]

Een reden om te kiezen voor SPA + REST API is als je naast je webapplicatie bijv ook smartphone apps hebt. Dan staat je web app in feite op dezelfde hoogte als je phone apps. Een REST API heb je sowieso nodig voor de phone apps dus is het zonde om zowel een API als een MVC site te bouwen.

Daarnaast kun je op deze manier makkelijk disciplines scheiden. De frontender en de backender bouwen ieder hun deel en hoeven niet op elkaar te wachten. De backender genereert gewoon een stub van de API waarmee de frontender kan testen.
In een MVC-applicatie is het moeilijker samenwerken met front- en backenders, eigenlijk moet je per definitie full stack developer zijn om met Razor te kunnen werken.

Overigens ben ik geen fan van het houterige gevoel van SPA's en worden ze toegepast op plekken waar ze helemaal niet nodig zijn. Maar de overwegingen zijn vaker van organisatorische aard dan van gebruiksvriendelijkheid.

[Hiroj]

Ik kan mij vinden in de meningen die hier gedeeld worden dat SPA's wellicht wat overbodig is.

Voor mijn werk heb ik aan talloze SPA's moeten werken, waarbij ik de UX juist minimaal goed vond opgebouwd. Creatievelingen krijgen in mijn opinie teveel vrijheid, waardoor je rare toeters en bellen krijgt waar je het praktische nut niet echt van inziet. Het is meer een nice-to-have, dan een must-have.

Wel durft ik toe te geven dat de backend veel vriendelijker is om te onderhouden in een SPA, doordat deze juist compleet los staat van de frontend. Echter een goede API bouwen vraagt veel aandacht, wat er vaak nou juist niet in gestoken wordt.

[boe2]

Mijn persoonlijke mening: Het is vooral het domein van wannabe hipsters die een vreemde kronkel in hun hersenen hebben waardoor ze javascript een fan-tas-tische programmeertaal vinden en liefst ook de backend in node maken. Die een hekel hebben aan degelijke tooling en het liefst een week aan het prutsen zijn alvorens een degelijke workflow opgezet te hebben.
Deze leercurve wordt je gegarandeerd door iedere maand compleet nieuwe tooling uit te vinden, waarbij niets echt compatibel met elkaar is. Wil je toch bij dezelfde tools blijven? Geen zorgen, dependencies worden volautomatisch voor jou gebroken, zodat je altijd aan het werk blijft. Je bent trouwens geen echte webdeveloper als je niet eerst 200MB aan libraries via npm binnensleurt voor iedere nieuwe pagina die je maakt. Geheugen is goedkoop, dus laat de browser van de gebruiker maar goed zweten. Vergeet zeker niet de mobiele gebruikers: Geef ze een goede reden om ieder jaar een duurdere, snellere telefoon te kopen. Oeps, er is een nieuw populair framework van de maand? Gooi je toch gewoon het oude weg en migreer je naar het nieuwe framework.

* boe2 aait .NET mvc.

[ Voor 9% gewijzigd door boe2 op 21-08-2019 16:28 ]

[Freeaqingme]

Not Pingu schreef op woensdag 21 augustus 2019 @ 16:13:
Een reden om te kiezen voor SPA + REST API is als je naast je webapplicatie bijv ook smartphone apps hebt. Dan staat je web app in feite op dezelfde hoogte als je phone apps. Een REST API heb je sowieso nodig voor de phone apps dus is het zonde om zowel een API als een MVC site te bouwen.

Doorgaans kan zo'n app exact even veel als de website. Dus als je die website fatsoenlijk responsive maakt dan heb je helemaal geen app nodig. Wil 'de business' dan toch graag een app dan maak je een app bestaande uit 1 html renderer die verder gewoon je website laat zien?

Als je dan toch al die REST* api bouwt, is het natuurlijk niet uitgesloten dat de applicatie die aan de hand daarvan een frontend rendert nog steeds een serverside applicatie is. Zo zie ik 't wel gebeuren dat je een API schrijft in Go, en vervolgens die API ontsluit via een PHP applicatie.

Not Pingu schreef op woensdag 21 augustus 2019 @ 16:13:
Daarnaast kun je op deze manier makkelijk disciplines scheiden. De frontender en de backender bouwen ieder hun deel en hoeven niet op elkaar te wachten. De backender genereert gewoon een stub van de API waarmee de frontender kan testen.

Dat je niet teveel in elkaars vaarwater wil zitten snap ik, maar als je die verantwoordelijkheden goed splitst kan dat prima in dezelfde applicatie. Zoals je een REST-api kan stubben, kan je ook de response uit je service laag stubben en 't frontenders daar mee laten doen. Dan moet een frontender misschien wat van backendtaal-X beheersen, maar dat lijkt me geen probleem (net zoals dat backenders niet panisch moeten reageren als ze een keer een typo uit de frontend moeten halen...).

Not Pingu schreef op woensdag 21 augustus 2019 @ 16:13:
In een MVC-applicatie is het moeilijker samenwerken met front- en backenders, eigenlijk moet je per definitie full stack developer zijn om met Razor te kunnen werken.

Reminiscent of the quote: "So you're a full stack developer? When was the last time you wrote a device driver?"

Verder ken ik Razor niet, maar het lijkt om dit project te gaan(?).

Not Pingu schreef op woensdag 21 augustus 2019 @ 16:13:
Overigens ben ik geen fan van het houterige gevoel van SPA's en worden ze toegepast op plekken waar ze helemaal niet nodig zijn. Maar de overwegingen zijn vaker van organisatorische aard dan van gebruiksvriendelijkheid.

Gebruiksvriendelijkheid voor wie? Wat zijn voorbeelden van wanneer ze helemaal niet/wel nodig zijn?

offtopic:
* Wat het maken van REST-api's betreft: REST lijkt een hip naampje te zijn voor alles wat via HTTP gaat en geen SOAP is. Ik daag iedereen uit die beweert RESTful API's te developen de thesis van Roy Fielding (PDF) te lezen (die de grondlegger van dat concept is) en naar het Richardson Maturity Model te kijken.

[ Voor 7% gewijzigd door Freeaqingme op 21-08-2019 16:42 ]

[Jory]

ThomasG schreef op woensdag 21 augustus 2019 @ 15:44:
[...]
Neem het voorbeeld van dit forum. Als je een reactiepost, of je eigen reactie bewerkt, wordt de gehele pagina opnieuw geladen met andere content. Dat is eigenlijk nergens voor nodig, en ook best vervelend. Bij een SPA gebeurt dat niet, en heb je een betere "workflow". Het probleem is alleen dat veel SPA's erg slecht gebouwd zijn. Bij een goede SPA merk je niet dat het een "SPA" is.

Het "en ook best vervelend" stuk, daar kan ik me absoluut niet in vinden. Als het laden van de nieuwe pagina gewoon snel gaat dan is er echt helemaal mis mee.
Daarbij bied het als voordeel dat alle standaard features van de browser (links, history, bookmarks, etc) fatsoenlijk blijven werken.

Not Pingu schreef op woensdag 21 augustus 2019 @ 16:13:
Een reden om te kiezen voor SPA + REST API is als je naast je webapplicatie bijv ook smartphone apps hebt. Dan staat je web app in feite op dezelfde hoogte als je phone apps. Een REST API heb je sowieso nodig voor de phone apps dus is het zonde om zowel een API als een MVC site te bouwen.

Hiroj schreef op woensdag 21 augustus 2019 @ 16:14:
Wel durft ik toe te geven dat de backend veel vriendelijker is om te onderhouden in een SPA, doordat deze juist compleet los staat van de frontend. Echter een goede API bouwen vraagt veel aandacht, wat er vaak nou juist niet in gestoken wordt.

Dit is wat mij betreft wat kort door de bocht. Wanneer er meerdere user interfaces zijn (website, iOS app, Android app) dan is het inderdaad een goed idee om 1 API te maken welke alle business logica bevat. Iedere user interface gebruikt deze API dan. Maar dat wil nog niet zeggen dat de website dan puur uit front-end code moet bestaan. Je kunt best een (waarschijnlijk vrij dunne) back-end hebben welke de API gebruikt en daarnaast de nodige presentatie logica bevat (bijvoorbeeld lokalisatie; daar heeft de API niets mee te maken, maar ik wil ook liever niet alle mogelijke vertalingen inladen in de front-end want dat is simpelweg nergens voor nodig).
Edit: Wat Freeaqingme zegt dus.

Not Pingu schreef op woensdag 21 augustus 2019 @ 16:13:
In een MVC-applicatie is het moeilijker samenwerken met front- en backenders, eigenlijk moet je per definitie full stack developer zijn om met Razor te kunnen werken.

Dan is dat een tekortkoming van het MVC framework dat gebruikt wordt. Wellicht dat ASP.NET (daar hoort Razor toch bij?) het niet mogelijk maakt om op eenvoudige wijze de front-end te ontwikkelen, maar dat ligt absoluut niet aan het MVC patroon.
(Desnoods maakt een back-end developer een "toon template op basis van query string" route waar de front-end developers dan gebruik van kunnen maken; niet mooi, maar dat werkt prima.)

[ThomasG]

Jory schreef op woensdag 21 augustus 2019 @ 16:40:
[...]


Het "en ook best vervelend" stuk, daar kan ik me absoluut niet in vinden. Als het laden van de nieuwe pagina gewoon snel gaat dan is er echt helemaal mis mee.
Daarbij bied het als voordeel dat alle standaard features van de browser (links, history, bookmarks, etc) fatsoenlijk blijven werken.

Bij een fatsoenlijke SPA website blijven de standaard browser features ook werken (want daar is een native API voor). Daarom zeg ik: het probleem is dat veel SPA websites zeer slecht gebouwd zijn. Ze zijn langzaam, en sommige dingen zoals page refresh werken niet meer. Al het echter een goede SPA is, werkt het veel beter dan een "klassieke website".

[ Voor 6% gewijzigd door ThomasG op 21-08-2019 16:43 ]

[boe2]

sowieso snap ik het "scheiding van frontend/backend" argument niet goed. Ok, een MVC pagina heeft wat niet-html syntax om omheen te werken (maar heeft verder een vrij goede scheiding), maar dat lijkt me toch veel doenbaarder dan wanneer een groot deel van je html pas in runtime door javascript gegenereerd wordt.

[ Voor 7% gewijzigd door boe2 op 21-08-2019 16:45 ]

[Freeaqingme]

ThomasG schreef op woensdag 21 augustus 2019 @ 16:42:
[...]
Bij een fatsoenlijke SPA website blijven de standaard browser features ook werken (want daar is een native API voor). Daarom zeg ik: het probleem is dat veel SPA websites zeer slecht gebouwd zijn. Ze zijn langzaam, en sommige dingen zoals page refresh werken niet meer. Al het echter een goede SPA is, werkt het veel beter dan een "klassieke website".

Maar je zei ook dat het opnieuw laden van de pagina best vervelend was:

ThomasG schreef op woensdag 21 augustus 2019 @ 15:44:
[...]
Als je een reactiepost, of je eigen reactie bewerkt, wordt de gehele pagina opnieuw geladen met andere content. Dat is eigenlijk nergens voor nodig, en ook best vervelend.

Wat is daar dan vervelend aan?

Ik denk dat het vooral vervelend is als je een SPA hebt van een paar MiB die iedere keer volledig moet worden ingeladen. Deze pagina is ge-gzip'ed 23.3 KB. 1 Round trip om de pagina op te halen kost 80ms, dat is te weinig voor een mens om zich aan te ergeren. Besides, je hebt natuurlijk nog steeds ECMA/javascript tot je beschikking. Als je echt 1 specifiek pijnpunt zou hebben hiermee dan kan je op dat ene punt natuurlijk nog prima een XmlHttpRequest doen (of het hippere alternatief wat ECMA-script sinds kort heeft, iirc). Het is dan niet nodig om je hele applicatie om te schrijven naar een SPA.

Wat verder nog niet langs kwam was hoe SEO-(un)friendly het is.

Daarnaast zie ik dat vanwege het gebruik van shadow DOMs, ctrl+f het vaak niet doet in m'n browser. Wil ik zoeken op een term die ik op dat moment voor me heb staan, dan nog zegt m'n browser doodleuk dat de pagina die term niet bevat. Kan een nadeel aan Firefox zijn, maar met niet-SPA's heb ik het nooit...

[killercow]

boe2 schreef op woensdag 21 augustus 2019 @ 16:44:
sowieso snap ik het "scheiding van frontend/backend" argument niet goed. Ok, een MVC pagina heeft wat niet-html syntax om omheen te werken (maar heeft verder een vrij goede scheiding), maar dat lijkt me toch veel doenbaarder dan wanneer een groot deel van je html pas in runtime door javascript gegenereerd wordt.

Je kunt prima html componenten etc in de backend produceren, genereren en naar de client sturen.
Dat de frontend-developer er daarna css en javascript overheen gooit om dingen mooi en 'actief' te maken is prima.

Wij werken veel met herbruikbare html, die 100% zonder opmaak is, en hoogstens wat classes meegeeft om missende html tags aan te vullen. Een header tag is duidelijk, een tab tag is minstens zo nuttig, maar ontbreekt.

Daar komt dat een kaal laagje css bij die een header, tab, form en table wat wireframe achtige opmaak geeft zodat alles ook zonder front-end inmening functioneel is. En daar mag de frontender dan zn sausje-du-jour overheen gieten.

Het leukere frontend werk is natuurlijk wel om die nieuwe modules te bouwen, dus juist mooi herbruikbaar, zonder keurtjes tenzij dat functioneel is, en herbruikbaar en testbaar zodat het door de backend code keer op keer gebruikt kan worden in allerlei projecten.

Door herbruikbare html te hebben kunnen we die met de backend testen, kunnen we die met de wireframe css testen, en kunnen we die hele handel ook in een keer met een klant-specifiek css sausje testen zonder dat het hele project er moet zijn.

[BarôZZa]

React vind ik vaak het nieuwe JQuery. Een tool waarmee dev'ers met minder skills/designers een hippe voorkant in elkaar kunnen flansen. Vaak met imo hele vieze code (niet altijd uiteraard, rustig aan)

SPA's kunnen een heel krachtig middel zijn voor sites/applicaties waar snelheid van belang is. Een webshop die veel sneller werkt zal ervoor zorgen dat gebruikers meer producten bekijken en meer kopen. Een community/social platform zal ervoor zorgen dat gebruikers meer actief zijn (toen ik een social site runde en het omzette naar SPA zorgde het ervoor dat gebruikers bijna 2x zoveel pagina's bekeken).

Voor een backoffice applicatie is het vaak totaal niet nodig. Werk momenteel aan een oldskool vanilla PHP applicatie en daar verdien ik prima mee. Een hippe frontend levert het bedrijf minder op dan zaken automatiseren of gegevens beter inzichtelijk te krijgen.

Maar zoals met alle technieken is het gewoon een extra optie. Absoluut handig om als wapen in je arsenaal te hebben, maar geen oplossing voor alles.

Het loskoppelen van frontend en backend waarbij de front-end via een API met de backend communiceert is in mijn ogen vaak wel een hele mooie oplossing.

[Lethalis]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 16:38:
[...]
"So you're a full stack developer? When was the last time you wrote a device driver?"

Voor de rest lees ik met interesse alle reacties in dit topic. Ik ben blij dat ik niet de enige ben die zich afvraagt of het allemaal wel de goede kant op gaat. Het is vooral dat mensen SPA's inderdaad overal voor willen gebruiken.

@Freeaqingme Je bedoelt de Fetch Api?

[Freeaqingme]

Lethalis schreef op woensdag 21 augustus 2019 @ 16:59:
[...]

@Freeaqingme Je bedoelt de Fetch Api?

Yep. Last time I checked mocht je die ook gebruiken zonder SPA

[Kwistnix]

Ik werk momenteel als frontend developer op een klus waarbij ik aan een SPA werk op basis van Angular, als onderdeel van een (SaaS) web applicatie. Zelf meer ervaring met het maken van web applicaties op basis van server side rendering in de Java wereld, voornamelijk op basis van Wicket. Het is een andere tak van sport en ik zie de voor- en nadelen van beide aanpakken eigenlijk wel.

[armageddon_2k1]

Zozo, dit topic heeft een aardige dosis "Vroeger werkte het ook goed" met hier en daar een snufje "Tegenwoordig kunnen die jongelingen niks meer".

Het feit dat website en SPA op 1 hoop gegooid worden vind ik al typisch. Dan heb je het gewoon niet begrepen en vraag ik me uberhaubt af of je ooit echt eens een webapplicatie hebt moeten maken.

Zoals met elke technologie valt of staat het natuurlijk met de toepassing ervan en dat is met SPA's niet anders. Uiteraard kan je op meerdere manier hetzelfde doel bereiken, maar het feit is dat React/Vue/Angular nu gewoon hartstikke populair zijn. Doordat ze zo populair zijn worden ze ook te pas en te onpas op verkeerde plekken gebruikt. Dat had je vroeger met Flash ook, en met Java Applets ook. Ook toen had je jonge developers en oude developers die niet wisten wanneer ze welke techniek moeten pakken.

Zelf ben ik dev-lead van een klein software team. Zelf werk ik vooral in Kotlin, server-side, maar we hebben onder andere het volgende draaien:
- JVM Backend Server
- PHP7-based publicatie site met REST interface naar JVM server
- SPA (JS) met REST interface naar JVM server

Onze SPA is echt een applicatie, wat wil zeggen dat er een hoge mate van interactiviteit is. Lees: slepen van elementen, flows die gegenereerd worden, multi-user, heftig canvas gebruik, undo/redo etc. Ongetwijfeld is dit met een 'normale' opbouw te doen met hier en daar een AJAX call, maar we hebben ervoor gekozen hier volledig SPA te gaan. History, bookmarking, SEO etc interesseert toch geen fuck. Net als bij Google Sheets heb je dat ook niet nodig. De applicatie is 1,2MB aan app-code, iets wat sowieso gecached wordt en modulair ingeladen, maar we weten van onze klanten dat ze toch op een kantoor zitten achter een desktop/laptop. Dus ik ga niet optimizen voor mobile, aangezien het een modelleer-applicatie is.

Onze PHP7 publicatie-site is een veel statischere versie van bovenstaande waar een lichte vorm van interactiviteit is (lees: favorieten aanmerken, comments plaatsen). Hier is een goede history en bookmarking van belang en zodoende niet handig voor een SPA te gaan, alhoewel dat niet het sterkste argument is. Hij is gewoon makkelijker te onderhouden.

Dan voor mij, als iemand die jaren geen enkele front-end technology heeft aangeraakt. Ik vind Angular en React tooling erg goed. In no-time ben je up en running, gebruik je een manier van werken die heel veel mensen kennen, is de documentatie zeer goed en kan je echt zonder problemen een goede performant lichte SPA maken. Zelfs als je history wil is het geen enkel probleem. Als bovenstaande blijkbaar niet lukt zit het probleem bij de ontwikkelaar. Webpack en NPM zijn echt niet zo eng hoor. Gradle en Maven hebben ook hun nukken. Helemaal de Gradle Kotlin DSL vind ik onwaarschijnlijk vervelend met al z'n magic shit die op de achtergrond gebeurt.

Zijn er andere stacks die vrijwel hetzelfde kunnen dan Angular/React/Vue? Jup. Is dat een argument tegen React/Angular/Vue? Nope. Als dev-lead is het voor mij makkelijker mensen vinden die React/Angular/Vue kunnen dan mensen die diep in ASP.net + Razor zitten. Het is ook een pragmatische keus.

Zou ik onze commerciele bedrijfswebsite in React maken? Nee, want dan ben je echt een volledige idioot. Maar ik heb in dit topic aardig het gevoel dat men voornamelijk kijkt naar de voorbeelden waar het duidelijk niet de goede keuze was geweest.

Addendum:
Sommige argumenten herken ik me ook niet in.
We hebben met succes React nu in een paar DOM-nodes gemount om bepaalde functionaliteit te kunnen hergebruiken door onze producten heen. Dit werkt feilloos. Met een Dead-Code-Eliminator is de extra JS ook verwaarloosbaar.

Dan het idee dat elke keer er vele mb's overgepompt moeten worden? Dan is je applicatie gewoon verkeerd ontworpen. Met een juiste module-structuur laadt je juist nooit teveel (assets incluis) en wordt alles on-demand geladen. Doordat het asynchroon geladen wordt kan je ook meerdere resources tegelijk binnen halen. Het mooie is dat dit bij Angular en React vrij gestandaardiseerd is.

[ Voor 8% gewijzigd door armageddon_2k1 op 21-08-2019 19:02 ]

[ThomasG]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 16:50:
[...]


Maar je zei ook dat het opnieuw laden van de pagina best vervelend was:

[...]


Wat is daar dan vervelend aan?

Ik denk dat het vooral vervelend is als je een SPA hebt van een paar MiB die iedere keer volledig moet worden ingeladen. Deze pagina is ge-gzip'ed 23.3 KB. 1 Round trip om de pagina op te halen kost 80ms, dat is te weinig voor een mens om zich aan te ergeren. Besides, je hebt natuurlijk nog steeds ECMA/javascript tot je beschikking. Als je echt 1 specifiek pijnpunt zou hebben hiermee dan kan je op dat ene punt natuurlijk nog prima een XmlHttpRequest doen (of het hippere alternatief wat ECMA-script sinds kort heeft, iirc). Het is dan niet nodig om je hele applicatie om te schrijven naar een SPA.

Wat verder nog niet langs kwam was hoe SEO-(un)friendly het is.

Daarnaast zie ik dat vanwege het gebruik van shadow DOMs, ctrl+f het vaak niet doet in m'n browser. Wil ik zoeken op een term die ik op dat moment voor me heb staan, dan nog zegt m'n browser doodleuk dat de pagina die term niet bevat. Kan een nadeel aan Firefox zijn, maar met niet-SPA's heb ik het nooit...

Volgens mij ben jij gewoon opzoek naar redenen om SPA te haten. Voor alle punten die jij noemt zijn namelijk een oplossing. Wat veel mensen echter niet begrijpen is dat het maken van een SPA website meer werk is dan een "klassieke website". Vaak krijg je dan slappe aftreksels, en mensen die "React gebruiken ter vervanging van jQuery". Die hebben het gewoon niet begrepen.

Zo heeft goede SPA website initial server-side rendering, waardoor het werkt met zoekmachines (SEO) en de eerste pageload super snel is. Daarnaast moet je niet de gehele applicatie in een keer inladen, maar dit lazy doen wanneer het nodig is. Etc. etc.

Het voordeel van een SPA dat de state bewaard blijft tijdens de workflow, en je makkelijk delen van de pagina kunt vervangen met andere content wanneer dat nodig is.

Het ontwerpen van onze SPA was meer werk dan wanneer we het op de "oude" manier gedaan zouden hebben, maar nu het eenmaal goed in elkaar zit is het onderhouden daarvan eenvoudig. Als we alles met "losse pagina's"gedaan zouden hebben ging het ten koste van de gebruikers ervaring, en waren een aantal dingen simpel weg niet mogelijk omdat je dan met teveel factoren rekening moet houden.

De sleutel tot een goede SPA is state management. Als er database content wordt aangepast hoeven wij geen rekening te houden met waar in het de interface het effect op heeft, het wordt gepushed naar de state en de rest gaat "automagisch".

History, bookmarks, e.d. werkt allemaal net zoals bij een "klassieke" website. Het is dat je voor onze applicatie ingelogd moet zijn, maar anders werkt indexeren door zoekmachines ook. Want initieel is er server-side rendering, met exact dezelfde code door de state te vullen op basis van de URL en de DOM server-side te laten opbouwen. Daarna gaat het als SPA verder. It works like magic!

Kortom: SPA is initieel meer werk qua architectuur, maar uiteindelijk heb je er veel profijt van. Dankzij de state management zijn nieuwe (interface-)features eenvoudig toe te voegen, waarbij we niet met duizend en een situaties rekening moeten houden. En mochten klanten dat willen kunnen ze op basis van onze API hun eigen UI en/of koppeling maken.

[Freeaqingme]

ThomasG schreef op woensdag 21 augustus 2019 @ 19:12:
[...]
Volgens mij ben jij gewoon opzoek naar redenen om SPA te haten. Voor alle punten die jij noemt zijn namelijk een oplossing. Wat veel mensen echter niet begrijpen is dat het maken van een SPA website meer werk is dan een "klassieke website". Vaak krijg je dan slappe aftreksels, en mensen die "React gebruiken ter vervanging van jQuery". Die hebben het gewoon niet begrepen.

[...]

Kortom: SPA is initieel meer werk qua architectuur, maar uiteindelijk heb je er veel profijt van. Dankzij de state management zijn nieuwe (interface-)features eenvoudig toe te voegen, waarbij we niet met duizend en een situaties rekening moeten houden. En mochten klanten dat willen kunnen ze op basis van onze API hun eigen UI en/of koppeling maken.

Ik denk niet dat ik SPA's haat. Wel heb ik aan een paar projecten gewerkt waar ook SPA's gebruikt werden en waar dit geen succes was. Devs die er op gezeten hadden, hadden allemaal geen flauw benul van hoe een browser werkt, en knutselden net zo lang door totdat het er ongeveer uitzag als dat ze wilden. Vervolgens was het schieronmoggelijk om later nog dingen te wijzigen. Nouja, kon wel, alleen was ik 3 keer zo lang bezig als wanneer het geen SPA was geweest.

Het is dus geen haat die je bespeurt, wel een hoop frustratie. Overigens zei ik in een eerdere post al dat voor een applicatie zoals Google Sheets het me een bij uitstek geschikte oplossing lijkt.

Echter, dit topic ging over 'moet altijd alles een moderne SPA zijn'. De indruk die ik krijg van een hoop (veelal beginnende) frontend devs is dat het antwoord volmondig ja zou moeten zijn. Daar ageer ik tegen. Zoals je schrijft is het vantevoren goed uitdenken van de architectuur een aandachtspunt, en dat wordt vaak overgeslagen. In het geval van simpele, weinig interactieve, projecten snap ik dat volledig, maar daarbij twijfel ik dan ook heel erg aan het nut van een SPA.

Hetzelfde gevoel bekruipt me als het om Kubernetes gaat. Dan hoor ik devs zeggen dat ze dat "wel even in een uurtje opzetten", en dan heb je een omgeving die geen enkele logging bevat, heel veel meer abstractielagen om te debuggen, in de toekomst nooit geupdate wordt, etc. Ja, K8S kan een goede oplossing zijn voor bepaalde problemen, maar als je alleen een hamer hebt is het wel jammer als je daarom ook maar alles voor spijker gaat aanzien.

De sleutel tot een goede SPA is state management. Als er database content wordt aangepast hoeven wij geen rekening te houden met waar in het de interface het effect op heeft, het wordt gepushed naar de state en de rest gaat "automagisch".

Kan je uitleggen wat je hier mee bedoelt?

Zo heeft goede SPA website initial server-side rendering, waardoor het werkt met zoekmachines (SEO) en de eerste pageload super snel is. Daarnaast moet je niet de gehele applicatie in een keer inladen, maar dit lazy doen wanneer het nodig is. Etc. etc.

Ik realiseer me dat Server Side Renderen een optie is. Daarmee houd je denk ik continue een http(2) verbinding open met de server en draait daar 1 actief proces/thread/coroutine om die verbinding continue te servicen? Puur uit interesse, wat doe je dan in de frontend als die verbinding wegvalt, bijv. als onderdeel van het uitrollen van een nieuwe versie?

[Not Pingu]

Freeaqingme schreef op woensdag 21 augustus 2019 @ 16:38:

offtopic:
* Wat het maken van REST-api's betreft: REST lijkt een hip naampje te zijn voor alles wat via HTTP gaat en geen SOAP is. Ik daag iedereen uit die beweert RESTful API's te developen de thesis van Roy Fielding (PDF) te lezen (die de grondlegger van dat concept is) en naar het Richardson Maturity Model te kijken.

Dat schip is allang vertrokken. Niemand bouwt APIs op die manier omdat het een onpraktisch idee is. Software gaat niet op dezelfde manier hyperlinks volgen zoals mensen dat doen omdat ze pas wat met het resultaat kunnen als daarvoor geprogrammeerd is. In de meeste gevallen heeft die state machine maar een beperkt aantal states.
REST betekent nu gewoon http+json.

[Freeaqingme]

Not Pingu schreef op woensdag 21 augustus 2019 @ 20:09:
[...]


Dat schip is allang vertrokken. Niemand bouwt APIs op die manier omdat het een onpraktisch idee is. Software gaat niet op dezelfde manier hyperlinks volgen zoals mensen dat doen omdat ze pas wat met het resultaat kunnen als daarvoor geprogrammeerd is. In de meeste gevallen heeft die state machine maar een beperkt aantal states.
REST betekent nu gewoon http+json.

Ik ben 't niet met je oneens dat een stricte RESTful api vaak onpraktisch is. HTTP+Json is ook helemaal prima. Alleen zou 't denk ik helpen als mensen zich bewust waren van de onderliggende principes en oorspronkelijke gedachten daarbij. Het is ook helemaal niet erg als je een HTTP+Json api bouwt, maar dan snap ik weer niet het verlangen om het allemaal REST te noemen.

Is allemaal geen ramp, alleen daarom dat ik 'REST' doorstreepte in 'REST api'.

[armageddon_2k1]

@Freeaqingme
Als de letterlijke vraag van het topic dan is of alles een Spa moet zijn is het antwoord natuurlijk nee. Alles omvat heel veel en er is nooit een tech stack die alles omvat. Is natuurlijk ook niet letterlijk bedoeld in de TS.
Als jouw argument is dat er voor je gevoel een hoop devs zijn die er ja op zouden antwoorden... Tja. Jammer voor je, maar doet niks vior de discussie. Ik ken die devs niet in ieder geval.

Over hippe tech gesproken. Wij hebben nu in een onderdeel Graphql getest en werkt perfect voor dat specifieke probleem. Aantal bugs gereduceerd, ontwikkelsnelheid omhoog. Klassiek REST was veel te inflexibel. Echter, ik zou nooit zomaar overal Graphql neerpleuren. Zelfde idee.

[ Voor 29% gewijzigd door armageddon_2k1 op 21-08-2019 21:00 ]

[Freeaqingme]

armageddon_2k1 schreef op woensdag 21 augustus 2019 @ 20:57:
@Freeaqingme
Als de letterlijke vraag van het topic dan is of alles een Spa moet zijn is het antwoord natuurlijk nee. Alles omvat heel veel en er is nooit een tech stack die alles omvat. Is natuurlijk ook niet letterlijk bedoeld in de TS.
Als jouw argument is dat er voor je gevoel een hoop devs zijn die er ja op zouden antwoorden... Tja. Jammer voor je, maar doet niks vior de discussie. Ik ken die devs niet in ieder geval.

Ik meen toch dat mijn posts significant uitgebreider waren dan een kaal 'nee'

armageddon_2k1 schreef op woensdag 21 augustus 2019 @ 20:57:
Over hippe tech gesproken. Wij hebben nu in een onderdeel Graphql getest en werkt perfect voor dat specifieke probleem. Aantal bugs gereduceerd, ontwikkelsnelheid omhoog. Klassiek REST was veel te inflexibel. Echter, ik zou nooit zomaar overal Graphql neerpleuren. Zelfde idee.

Omdat dit topic eigenlijk over SPA's ging ben ik niet verder op API's ingegaan, maar ik denk inderdaad dat Graphql voor een hoop toepassingen een geschikte oplossing is waar REST juist een beperking opleverde.

[Sebazzz]

Er is natuurlijk ook nog een tussenweg, wel full page reloads maar wel dynamische content via React, Knockout of wat dan ook op de pagina. Zo vind ik repeaters, zeker geneste, vervelend met ASP.NET MVC maar een stuk lekkerder met Knockout.

[defiant]

SPA frameworks zoals Angular/React/etc proberen te bereiken wat sinds decennia al beschikbaar is in traditionele GUI tookits: een uniforme robuuste manier om GUI's te maken die gekoppeld kunnen worden aan de API's van de onderliggende applicatie. Feitelijk is men bezig het wiel opnieuw uit te vinden, waardoor men uiteindelijk toch weer uitkomt bij bestaande concepten. De standaarden van het web (html/css/javascript/etc) bieden vanuit zichzelf onvoldoende abstractie om te kunnen functioneren als makkelijk herbruikbaar GUI componenten, er is enorm veel flexibiliteit, je hierdoor dan ook de populariteit van bootstrap die een werkbare abstractie aanbiedt (en waardoor veel websites ook weer op elkaar lijken).

Het zou imho een goede ontwikkeling zijn als voor webapplicaties (in tegenstelling tot meer statistische content, daarvoor blijven SPA's imho ongeschikt) als de frameworks de volwassenheid bereiken van traditionele van deze GUI toolkits zoals WPF/QT/Winforms/etc deden voor operating systemen.

Een welkome trend in de andere richting zijn de opkomst van static site generators voor meer statische content via een CMS. Het voordeel is meer performance en geen afhankelijkheden/kwetsbaarheden door code of het hosting platform.

Het probleem is tevens dat veel ontwikkelaars impliciet door hun eigen werkgever en/of de markt worden geacht hun skills up-to-date te houden. Aangezien de ontwikkelingen op het web gebied zo snel gaan, ben je haast wel verplicht iig als frontend/fullstack ontwikkelaar om kennis op te doen van SPA's. De beste manier om kennis op te doen is door het in de praktijk te brengen, dus dan wordt ook een minder geschikt project al snel een kandidaat.

Ik denk dat voor de meeste normale sites met een focus op redelijke statische informatie een SPA overkill is, maar doorontwikkeling en evolutie van SPA's een logische en noodzakelijke stap is richting meer robuustere en onderhoudbaar webapplicaties en de snelheid van ontwikkeling dus ook kan dalen tot een fatsoenlijke tempo, onderhoud is namelijk duur en gebeurd niet altijd. Een windows applicatie van een decennium oud draait nog steeds, maar een deprecated SPA qua versie krijg je alleen met veel moeite bij.

[Lethalis]

armageddon_2k1 schreef op woensdag 21 augustus 2019 @ 18:52:
Zozo, dit topic heeft een aardige dosis "Vroeger werkte het ook goed" met hier en daar een snufje "Tegenwoordig kunnen die jongelingen niks meer".

Het heeft niks met jong of oud te maken wat mij betreft, maar meer met het toepassen van bepaalde technieken puur omdat het kan of hip is.

Wat @defiant aanstipt, is ook waar: we worden geacht onze kennis up-to-date te houden. Dus duiken we op alles wat nieuw is om maar niet achter te blijven en wordt het risico dus groter dat je een bepaald framework gebruikt op een project, puur omdat het kan.

Ik breek hier ook niet voor niets mijn hoofd over... ik heb een jaar of 5 voornamelijk Windows Forms development gedaan omdat het nodig was op mijn werk, maar daardoor dus ook grofweg 5 jaar weinig web development gedaan... terwijl ik eigenlijk als web developer ben aangenomen ooit (vroeger veel Web Forms en MVC gedaan... net nog AngularJS meegekregen voordat ik op een groot Windows project werd gezet).

Hier en daar nog wel ingesprongen om te helpen bij webprojecten en dan gewoon gedaan wat ik moest doen... m.a.w. als Angular gebruikt werd, dan leerde ik zo snel mogelijk genoeg Angular om productief te zijn... maar echt reflecteren op de keuzes heb ik weinig tijd voor gehad.

Dat komt nu eigenlijk pas. Ik evalueer mijn kennis van web development en wat belangrijk is, omdat er weer wat web projecten op mij afkomen.

Als het aan een collega van mij ligt (die ironisch genoeg ouder is dan ik ), is Angular al gauw the way to go.

Voor sommige projecten geef ik hem gelijk, maar er zijn ook genoeg dingen waarvoor ik het overkill vind en eerder op zoek ga naar een tussenweg.

Vandaar dit topic.

[armageddon_2k1]

Lethalis schreef op woensdag 21 augustus 2019 @ 22:34:
[...]

Het heeft niks met jong of oud te maken wat mij betreft, maar meer met het toepassen van bepaalde technieken puur omdat het kan of hip is.
...

Als het aan een collega van mij ligt (die ironisch genoeg ouder is dan ik ), is Angular al gauw the way to go.

Voor sommige projecten geef ik hem gelijk, maar er zijn ook genoeg dingen waarvoor ik het overkill vind en eerder op zoek ga naar een tussenweg.

Vandaar dit topic.

Dan vind ik jouw collega weer raar. Want je kan niet Angular, React en Vue op een hoop gooien. Angular is echt een volledig framework met services, DI, en dwingt een harde type-safety af. React is een UI framework en is al een stuk lichter. Vue is weer een stuk lichter. Ik vind het dan ook vaag dat Angular blijkbaar dan al snel de enige oplossing is.

Dit is een beetje exemplarisch voor het topic. Want Angular is niet the way to go en elke developer die zonder nadenken naar Angular grijpt is niet goed bezig. Er zijn genoeg tussenwegen en je hebt niet allemaal idiote Webpack loaders nodig. Je kan gewoon een clean Vue.js / React site opzetten zonder enige bundler.

(Voor de mensen die haten op Webpack, ga dan Gradle maar eens proberen met z'n plugin systeem welke de DSL in-script aanpassen en z'n vreselijke plugin repository zonder enige documentatie)

Ik juich elke ontwikkeling van frameworks en technieken toe en hoop dat al die mensen die voor elk nieuw project het nieuwste van het nieuwste gebruiken dat lekker doen. Het web ontwikkelt ervan en ik kan de vruchten plukken van de experimenten die faalden en de projecten die succesvol zijn geworden.

defiant schreef op woensdag 21 augustus 2019 @ 21:47:
Het zou imho een goede ontwikkeling zijn als voor webapplicaties (in tegenstelling tot meer statistische content, daarvoor blijven SPA's imho ongeschikt) als de frameworks de volwassenheid bereiken van traditionele van deze GUI toolkits zoals WPF/QT/Winforms/etc deden voor operating systemen.

Ik vind WPF niet echt een goed voorbeeld van een 'traditioneel' UI kit. Het is overengineered en nodeloos complex gemaakt met een inefficiente rendering pipeline. Daarnaast is het, correct me if I am wrong, ook nog helemaal niet volledig ondersteund in .NET Core. Daarnaast is hun vertrouwen zelf in WPF en UWP ook niet echt denderend, kijkende naar hun veranderende roadmap daarop en het feit dat ze zelf steeds meer Electron apps maken.....Weet niet wat dat doet voor de volwassenheid van een framework.

Wanneer heeft een React of Angular de volwassenheid als een van de frameworks die jij noemt?
- LTS releases? Check
- Goede documentatie? Check
- Grote community? Check
- Actieve ontwikkeling? Check

[ Voor 37% gewijzigd door armageddon_2k1 op 22-08-2019 07:37 ]

[Lethalis]

armageddon_2k1 schreef op woensdag 21 augustus 2019 @ 18:52:
Dan voor mij, als iemand die jaren geen enkele front-end technology heeft aangeraakt. Ik vind Angular en React tooling erg goed. In no-time ben je up en running, gebruik je een manier van werken die heel veel mensen kennen, is de documentatie zeer goed en kan je echt zonder problemen een goede performant lichte SPA maken. Zelfs als je history wil is het geen enkel probleem. Als bovenstaande blijkbaar niet lukt zit het probleem bij de ontwikkelaar. Webpack en NPM zijn echt niet zo eng hoor. Gradle en Maven hebben ook hun nukken. Helemaal de Gradle Kotlin DSL vind ik onwaarschijnlijk vervelend met al z'n magic shit die op de achtergrond gebeurt.

Maar dan noem je ook iets...

Ik werk al ruim 16 jaar voornamelijk met .NET en in die wereld zijn dingen meestal iets gestroomlijnder.

Zodra je een solution in Visual Studio opent en je drukt op F5 dan build het gewoon en werkt het (normaal gesproken). We hebben NuGet en msbuild, love or hate them... maar je weet iig waar je moet zijn.

Toen ik aan de Open Universiteit Java bestudeerde, ging ik er ook privé mee aan de slag en als er 1 ding is aan Java waar ik helemaal simpel van werd, dan was het wel het enorme doolhof aan libraries dat er is en de tooling daaromheen.

Ik bleef uiteindelijk in mijn keuze tussen Maven en Gradle ook vaak bij Maven plakken, omdat ik dat gewoon simpeler vond en meer informatie erover kon vinden. Kotlin als programmeertaal vind ik dan wel weer mooi, het is alleen jammer (maar wel begrijpelijk) dat je dan min of meer vast zit aan IntelliJ.

Als ik React wil integreren met een bestaand ASP.NET MVC project, dan heb ik grofweg 2 opties van wat ik heb gezien:
1. ReactJS.NET gebruiken. Dit voegt een handler toe voor JSX, die server side de vertaling doet naar plain old JavaScript. De overige dependencies kun je dan het makkelijkste maar gewoon via de _Layout.cshtml toevoegen door simpelweg te linken naar unpkg.com.
2. Wil je meer flexibiliteit, dan zul je met NPM moeten werken. En daar ben ik inderdaad mee "aan het kloten". Ook daar geldt voor, wat doe je via NPM en wat niet. Als ik met css-loader's aan de slag ga voor zaken als bootstrap, dan worden mijn bundles al gauw te groot volgens webpack. Nou ja, dan gebruiken we wel weer een text extracter om CSS apart te genereren. Prima. Maar vervolgens zit het allemaal niet netjes in 1 build met Visual Studio. Oh ja, nou dan kunnen we wel weer diverse Task Runners via NuGet binnenhalen. Hmm. Enzovoorts. Enzovoorts.

Gekloot vind ik het.

Zal wel aan mij liggen Maar als ik dan vervolgens op internet ga zoeken hoe ik dit het beste kan doen, vind ik of tutorials met gigantische stappenplannen van 20 stappen of meer. Of YouTube filmpjes waar iemand er een half uur over doet.

En dan heb ik echt zoiets van "dit had vast handiger gekund".

AngularJS (het oude Angular) voegde je in 3 minuten aan een willekeurig project toe... dus ik heb nogal het idee dat er de laatste jaren een wildgroei aan allerlei tooling is ontstaan.

Natuurlijk kan ik nu denken "ik gebruik wel ReactJS.Net en be done with it", anderzijds irriteert het me (voornamelijk voor als ik later andere dependencies binnen wil halen en ze makkelijk wil kunnen bijwerken)... en dan ga ik weer verder kloten met webpack, babel, diverse loaders etc. It's frustrating.

defiant schreef op woensdag 21 augustus 2019 @ 21:47:
Een windows applicatie van een decennium oud draait nog steeds, maar een deprecated SPA qua versie krijg je alleen met veel moeite bij.

Zoals met alles is dit puur afhankelijk van de externe dependencies van het project. Zodra je dus tig NPM packages moet binnenhalen om het project te kunnen builden en draaien, bestaat er een groot risico dat het op een dag niet meer werkt, omdat 1 van die packages uit de gratie is geraakt.

Maar goed, dat geldt net zo hard voor die Windows applicatie. Als iemand die veel met legacy zooi te maken heeft gekregen de afgelopen 5 jaar, kan ik je vertellen dat zodra zo'n Windows applicatie 1 of ander ComponentOne component nodig heeft van 10 jaar geleden dat niet meer te krijgen is en niet meer ondersteund wordt... dat project ook gewoon een ramp is om weer draaiend te krijgen.

Ga dan maar alle Grid controls in zo'n project vervangen en de aansturing daarvan. Fijn als het op 150 forms voorkomt.

Het voordeel is alleen wel dat je bij zo'n Windows project er zelf wat meer bij bent welke externe dependencies je kiest. Bij een modern webproject met Angular zie ik in mijn node_modules map de meest gekke libraries voorbijkomen waar de gemiddelde developer waarschijnlijk niet eens van weet dat ze bestaan.

Dat is gewoon scary (en wordt soms ook misbruikt door hackers).

Nu is er gelukkig nog een scheiding tussen devDependencies en gewone dependencies, waardoor het draaien ervan meestal nog wel meevalt... maar ja, die build chain is echt bizar.

[ Voor 21% gewijzigd door Lethalis op 22-08-2019 09:21 ]

[gitaarwerk]

pf, niet hele topic doorgelezen :-), maar ik denk dat, vast wat meer hier schrijven... het hangt altijd af van wat je maakt. SPAs zijn heel tof, maar ook een crime om te onderhouden. Wat enorm makkelijk was in ouderwetse applicaties zijn ineens heel lastig nu, en vice versa. Ik vraag me af en toe af waarom we per se een SPA moeten hebben op mijn werk nu (waar ik full time aan werk). Iedereen is er van overtuigd, maar ik niet echt.

Persoonlijk vind ik ze superfijn als je een mobiele app moet maken, of een app met een specifieke taak. Zelfs daar is het niet altijd even handig. Ik vind bijvoorbeeld routing in een app enorm kut, maar state is dan weer awesome. Mooiste is gewoon, hert moet een ding doen, dat erg goed, vooral veel guidance wanneer je het nodig hebt. Echt rijke componenten bouwen, die de flow erg fijn maken is het mooiste.

[n9iels]

Ik denk dat het veel belangrijker is dat we de juist tool for the job kiezen dan één standaard richting. Deze juiste tool kan best lastig te bepalen zijn omdat zowel het project, ontwikkelaars en toekomst er een rol in spelen. Ik heb zelf bij een bedrijf gewerkt waarbij de combi .NET REST API + ReactJS SPA de standaard was. Naar mijn menig zijn daar website gebouwd waarbij een SPA overbodig was omdat het 90% statische content betrof die toch al uit een Wordpress back-end kwam. Het klonk heel hip, maar of het verstandig was...

Het claiming dat taal/framework A totaal ruk is en taal/framework B alles oplost is voor een websitebouwer die de "bakker op de hoek" websites doet prima te verantwoorden. Een software engineer die een groot platform maak o.i.d. heeft de taak geen blinddoek te dragen.

[Brilsmurfffje]

Ik vind ze vanuit een gebruikers perspectief echt een doorn in het oog.

Tweakers.net is een mooi voorbeeld, gewoon oude beproefde technieken die snel werken, hierdoor staat de site in minder dan een seconde op mijn scherm, echt top. Ik kan direct aan de slag met de dingen die ik wil doen, er hoeft geen content meer ingeladen te waren het is er gewoon allemaal in 1x. Als ik een reactie plaatst krijg ik een redirect wat ook super is want ik zie als gebruiker dat er iets gebeurt, hij laadt de pagina opnieuw. Sommige SPA sites die laten je niks zien en dan ineens uit het niets komt je actie..

Facebook is volgensmij ook een SPA want het is traag als kak door een trechter, zodra je de website opent zit je te kijken naar allemaal placeholders, als je ergens op wilt klikken verschuift de pagina etc..

Outlook.com is ook een SPA volgensmij, vroeger had je zo een simpel mailprogramma voor bij je internet abonnement, zag er niet uit maar als je op refresh duwde zag je of je nieuwe mail had. Nu met outlook.com is het er soms wel direct maar vaak moet je opnieuw naar de website navigeren omdat de applicaties zelf niet juist update. Heel wazig voor de gebruiker en gaat ook de functie volledig voorbij.

De ING omgeving is nog zo een mooi voorbeeld, geen idee wat die jongens en meisjes daar gedaan hebben maar die website werkt niet meer in EdgeHTML. Het is gewoon compleet onbruikbaar en een mogelijkheid om terug te gaan naar de oude, prima werkende, omgeving is er niet.

Als wij hier iets op werk maken dan gaan we helemaal voor de snelheid voor interne applicaties, wij willen niet dat onze interne applicaties net zo traag werken als een SharePoint omgeving. Ik juich het alleen maar toe als er een degelijk backend framework gebruikt wordt met een beetje AJAX voor wat dynamische content en javascript om bijvoorbeeld een status weergave te geven van een dynamisch object.

[dev10]

Brilsmurfffje schreef op donderdag 22 augustus 2019 @ 15:40:

[...]

Facebook is volgensmij ook een SPA want het is traag als kak door een trechter...

[...]

Dit is slaat als een tang op een varken. Facebook is inderdaad een SPA, maar een SPA is niet per definitie zo traag als dikke stront op steile helling.

Wat jij als een pluspunt ervaart bij Tweakers is ook te realiseren met een SPA, maar het is ook net zo makkelijk om een website als Tweakers traag te laten aanvoelen. Het een sluit het ander niet uit. Hoe snel een applicatie aanvoelt heeft niks te maken met of het een traditionele webapplicatie of een SPA is, maar veel meer met de competentie en focus van de ontwikkelaar.

[Brilsmurfffje]

dev10 schreef op donderdag 22 augustus 2019 @ 15:56:
[...]


Dit is slaat als een tang op een varken. Facebook is inderdaad een SPA, maar een SPA is niet per definitie zo traag als dikke stront op steile helling.

Wat jij als een pluspunt ervaart bij Tweakers is ook te realiseren met een SPA, maar het is ook net zo makkelijk om een website als Tweakers traag te laten aanvoelen. Het een sluit het ander niet uit. Hoe snel een applicatie aanvoelt heeft niks te maken met of het een traditionele webapplicatie of een SPA is, maar veel meer met de competentie en focus van de ontwikkelaar.

De ironie is juist dat het eerst prima responsive websites waren en dat nu totaal niet meer zijn..

[ThomasG]

Brilsmurfffje schreef op donderdag 22 augustus 2019 @ 16:15:
[...]


De ironie is juist dat het eerst prima responsive websites waren en dat nu totaal niet meer zijn..

Dat ligt dus aan de ontwikkelaars, want er is geen enkele reden waarom een website niet zowel SPA als responsive kan zijn.

[Lethalis]

Brilsmurfffje schreef op donderdag 22 augustus 2019 @ 16:15:
[...]
De ironie is juist dat het eerst prima responsive websites waren en dat nu totaal niet meer zijn..

Op het moment dat je client side de DOM manipuleert, gebruik je dus client side ook meer processorkracht en geheugen dan wanneer je hele stukken HTML gewoon kant en klaar van de server downloadt (server side rendering).

Als ik de webmail van outlook.com op een oude computer wou bekijken ging de CPU belasting naar de 100% en kon ik overal op gaan wachten, terwijl de webmail van Google het gewoon prima deed (alhoewel die recent ook is vervangen, geen idee hoe het nu zou zijn).

SPA's eisen dus meer van de client. Ik geef nu een oude computer als voorbeeld, maar het kan net zo goed een browser op een telefoon zijn die ook beperkt is qua processorkracht en geheugen.

Dat is dus wel een overweging als je zo'n applicatie bouwt.

Een ander dingetje dat ik eng vind - maar ik heb hier dus weinig ervaring mee - is dat Webpack veelvuldig gebruik lijkt te maken van de eval() functie. Dat lijkt me performance technisch niet echt ideaal... maar goed, dat zal vast anders in te regelen zijn (devtool op none zetten?). Maar ik kan mij zo voorstellen dat niet iedereen daar iets mee doet of er überhaupt naar kijkt in zijn JavaScript bundles.

[dev10]

Lethalis schreef op donderdag 22 augustus 2019 @ 16:21:
[...]

Op het moment dat je client side de DOM manipuleert, gebruik je dus client side ook meer processorkracht en geheugen dan wanneer je hele stukken HTML gewoon kant en klaar van de server downloadt (server side rendering).

Daar staat dan weer tegenover dat de de requests na de initiële request minder overhead zullen hebben dan wanneer je serverside de HTML aanbiedt.

De rendersnelheid wordt niet alleen bepaald door processorkracht van de client, maar ook door de complexiteit van de DOM en de bijbehorende CSS.

Je kunt niet per definitie zeggen dat een SPA langzamer of sneller is dan een traditionele web-app, omdat het type applicatie maar een van de factoren is die de snelheid of het gevoel van snelheid bepaalt.

Lethalis schreef op donderdag 22 augustus 2019 @ 16:21:
Een ander dingetje dat ik eng vind - maar ik heb hier dus weinig ervaring mee - is dat Webpack veelvuldig gebruik lijkt te maken van de eval() functie. Dat lijkt me performance technisch niet echt ideaal... maar goed, dat zal vast anders in te regelen zijn (devtool op none zetten?). Maar ik kan mij zo voorstellen dat niet iedereen daar iets mee doet of er überhaupt naar kijkt in zijn JavaScript bundles.

Volgens mij, maar pin me hier niet direct op vast, gebruikt Webpack eval in development mode en niet tijdens het builden van de productie assets. Dan is een beetje hetzelfde als zeggen dat er in een development build allerlei debug informatie wordt toegevoegd en dat dit potentieel gevaarlijk is.

[ Voor 32% gewijzigd door dev10 op 22-08-2019 16:50 ]

[Ed Vertijsment]

Het probleem is hoe goed de applicatie in elkaar zit en hoe goed de gebruiker er mee om kan gaan. Als je een "traditionele" request response pagina bouwt dwingt de flow om heel veel dingen gewoon goed te doen. Denk aan vorige/volgende (history states) en het opnieuw refreshen van de state.

Dit kan je allemaal ook in SPA's doen alleen is dat een stuk complexer waardoor er veel meer fout kan gaan, en dat dan dus ook vaak fout.

Ik vind at modulariteit belangrijk is, maar dat betekent niet je bij SPA's of React uitkomt. Je kan prima component based werken in een request response app, en als er geen noodzaak tot een SPA is zou ik dat ook gewoon niet doen. Mocht er een gedeeltelijke noodzaak ontstaan integreren we React in een bestaande request/response template (met een backend API). Alleen als er van te voren al vast staat dat er een absolute noodzaak is voor een SPA wordt dat vanaf de grond opgebouwd.

[dev10]

Ed Vertijsment schreef op donderdag 22 augustus 2019 @ 16:54:

Het probleem is hoe goed de applicatie in elkaar zit en hoe goed de gebruiker er mee om kan gaan.

Volgens mij is dat de hele crux: SPA's zijn niet slecht, slecht gebouwde (SP)A's zijn slecht.

Dit kan je allemaal ook in SPA's doen alleen is dat een stuk complexer waardoor er veel meer fout kan gaan, en dat dan dus ook vaak fout.

Nu spreek ik even vanuit de ervaring die ik heb met React+Redux en React Router. Deze combi zorgde er voor dat die hele flow die een gebruiker gewend is met historyState gewoon goed werkt. Dit was niet per se complex om te realiseren.

[Ed Vertijsment]

dev10 schreef op donderdag 22 augustus 2019 @ 17:11:
[...]


Volgens mij is dat de hele crux: SPA's zijn niet slecht, slecht gebouwde (SP)A's zijn slecht.


[...]


Nu spreek ik even vanuit de ervaring die ik heb met React+Redux en React Router. Deze combi zorgde er voor dat die hele flow die een gebruiker gewend is met historyState gewoon goed werkt. Dit was niet per se complex om te realiseren.

Op zich heb je gelijk (al laat ik maar niet beginnen over React Router), maar je hebt veel meer moving parts die allemaal stuk kunnen gaan en onderhoud nodig hebben, allemaal overhead die je normaal niet nodig hebt maar cadeau krijgt.

[armageddon_2k1]

@Ed Vertijsment begin maar eens wel over React Router. Ben benieuwd.

[Sebazzz]

Ed Vertijsment schreef op donderdag 22 augustus 2019 @ 19:08:
[...]


Op zich heb je gelijk (al laat ik maar niet beginnen over React Router), maar je hebt veel meer moving parts die allemaal stuk kunnen gaan en onderhoud nodig hebben, allemaal overhead die je normaal niet nodig hebt maar cadeau krijgt.

Ik begrijp wat je zegt, maar nu ga ik even heel flauw zijn. Je kan in .NET of C een Windows Forms app programmeren met allemaal native widgets of in Electron of wat dan ook een desktop app waarbij alle widgets handmatig zijn geprogrammeerd en het echte simuleren. Allemaal overhead die je normaal niet nodig hebt en wat kapot kan gaan (zoals bij veranderende DPI settings etc).

[Lethalis]

dev10 schreef op donderdag 22 augustus 2019 @ 16:42:
[...]
Daar staat dan weer tegenover dat de de requests na de initiële request minder overhead zullen hebben dan wanneer je serverside de HTML aanbiedt.

De rendersnelheid wordt niet alleen bepaald door processorkracht van de client, maar ook door de complexiteit van de DOM en de bijbehorende CSS.

Je kunt niet per definitie zeggen dat een SPA langzamer of sneller is dan een traditionele web-app, omdat het type applicatie maar een van de factoren is die de snelheid of het gevoel van snelheid bepaalt.

Daar heb je op zich gelijk in, maar er is wel een trend dat zodra mensen de mogelijkheden van een SPA tot hun beschikking hebben, ze die gaan gebruiken ook. Met als gevolg dat de DOM veel complexer wordt, er veel meer objecten in het geheugen worden gehouden (want het is toch wel makkelijk dat je instant door 10000 objecten kan zoeken) en er veel meer scripts moeten worden uitgevoerd die regelmatig checken of er dingen veranderd zijn etc.

Volgens mij, maar pin me hier niet direct op vast, gebruikt Webpack eval in development mode en niet tijdens het builden van de productie assets. Dan is een beetje hetzelfde als zeggen dat er in een development build allerlei debug informatie wordt toegevoegd en dat dit potentieel gevaarlijk is.

Okee Ik heb ook te weinig ervaring met webpack om er iets over te zeggen eigenlijk.

Het enige waar ik echt ervaring mee heb qua SPA's, is het bouwen van Angular apps met de Angular cli. En op zich levert dat een behoorlijk geoptimaliseerde distributie op. Alleen de weg er naartoe is pijnlijk vaak, zodra je met meerdere mensen aan 1 project werkt en iemand weer eens npm update heeft gedaan.

Het gaat dan echt altijd kapot. Soms zo erg dat ik de hele node_modules map maar gewoon wegdonder en opnieuw laat opbouwen.

Ook is het bouwen van SPA's vaak dubbel werk. Models die zowel server side als client side aangemaakt moeten worden, je bent echt 2 projecten aan het bouwen tegelijkertijd (client app en server api). En hoe mooi die scheiding ook is, het kost veel meer tijd om te maken dan gewoon een simpele ASP.NET MVC applicatie.

En dat is eigenlijk ook de crux van dit hele verhaal. Je wil efficiënt tot een bepaald doel komen, een oplossing bieden voor een business probleem, en niet per se jezelf op de schouders kloppen omdat je de allernieuwste technologie hebt gebruikt.

Ik wil graag pragmatisch zijn in wat ik doe. Wel netjes, maar pragmatisch.

In de situatie van Angular verlies ik dat gevoel en heb ik het idee dat ik een hoop werk voor niks doe (als het project ook gewoon een MVC app had kunnen zijn, ik heb het dus niet over hele complexe client software zoals bijvoorbeeld een HTML5 narrowcasting player die ik wél in Angular maak).

Simpelweg omdat ik genoeg applicaties bouw waar ik hoogstens een paar componenten heb die ik client side wil, zoals een grid wat je snel kunt sorteren met paging, of een typeahead search waarmee je bijvoorbeeld even snel in een klantenbestand kan zoeken.

Dat soort dingen zijn super handig en heeft de gebruiker ook echt wat aan.

Maar de rest kan gewoon ouderwets van de server komen wat mij betreft.

Natuurlijk kun je dan nog wel erover nadenken om voor die componenten wel React te gebruiken, omdat het in tegenstelling tot Angular gewoon een UI library is en niet meteen voor je wil bepalen dat je er een hele applicatie van moet maken. Een paar interactieve componenten zijn ook goed.

De vraag blijft dan nog wel wat je dan qua tooling daarvoor gebruikt. Ga je helemaal moeilijk doen met een hele JavaScript build chain, of kies je ook hier de pragmatische weg en doe je alleen het minimale?

Dat zou bijvoorbeeld kunnen zijn dat je in een MVC applicatie simpelweg de react.js en react-dom.js laadt vanuit een algemene layout page die op alle views voorkomt. En dat je alleen babel via npm binnenhaalt en een Task Runner voor NPM gebruikt om automatisch JSX bestanden te compilen naar plain old JavaScript.

Deze JavaScript bestanden ook simpelweg laden vanuit de HTML en je kan aan de slag.

En je kunt een library als bootstrap ook gewoon op de ouderwetse manier includen, zodat je project met minimale efforts in ieder geval ook op andere apparaten redelijk werkt, zoals een telefoon.

Hoe erg is dit? Word ik bij andere bedrijven afgebrand als ik het zo doe, of zijn er genoeg mensen die het belangrijker vinden dat ze snel tot een resultaat komen?

PS
Als dit wereldvreemd overkomt, ik werk al 12 jaar bij dezelfde werkgever Ik heb een vooruitstrevende collega die van alles graag het nieuwste gebruikt en ik heb een paar collega's die terughoudender zijn. Ik hang ergens in het midden.

[ Voor 4% gewijzigd door Lethalis op 23-08-2019 08:33 ]

[dev10]

Lethalis schreef op vrijdag 23 augustus 2019 @ 08:26:
[...]

Daar heb je op zich gelijk in, maar er is wel een trend dat zodra mensen de mogelijkheden van een SPA tot hun beschikking hebben, ze die gaan gebruiken ook. Met als gevolg dat de DOM veel complexer wordt, er veel meer objecten in het geheugen worden gehouden (want het is toch wel makkelijk dat je instant door 10000 objecten kan zoeken) en er veel meer scripts moeten worden uitgevoerd die regelmatig checken of er dingen veranderd zijn etc.

Ik denk dat dit behoorlijk verschilt per developer en applicatie. Ik heb alleen ervaring met React en Redux en weet dus niet precies hoe dit in andere frameworks gaat. Mijn ervaring met React is dat de DOM niet per se complexer wordt dan wanneer je gebruik maakt van plain-old HTML, omdat React alleen maar toont wat er getoond hoeft te worden en geen elementen verbergt.

Nu heb ik alleen nog maar relatief eenvoudig applicaties gebouwd met React, dus mijn ervaring is wellicht niet compleet.

Lethalis schreef op vrijdag 23 augustus 2019 @ 08:26:
Ook is het bouwen van SPA's vaak dubbel werk. Models die zowel server side als client side aangemaakt moeten worden, je bent echt 2 projecten aan het bouwen tegelijkertijd (client app en server api). En hoe mooi die scheiding ook is, het kost veel meer tijd om te maken dan gewoon een simpele ASP.NET MVC applicatie.

En toch, als ik met de applicatie waar ik aan werk opnieuw zou mogen bouwen zou ik kiezen voor een architectuur waarin de back-end voorziet in een API en de front-end een SPA is die deze API aanroept. De reden hiervoor is simpel: nu bouwen we een applicatie waarin we HTML templates aan het kloppen zijn en we bieden ook een API aan wat weer op een andere manier voor dubbel werkt zorgt. De views van de applicatie zijn voor 95% CRUD views die niet heel veel spannends doen. Het echte zware werk van de applicatie wordt op achtergrond gedaan met een job queue. Het voordeel hiervan voor mij zou zijn dat je front-end en back-end onafhankelijk van elkaar kunt ontwikkelen, deployen en schalen.

Lethalis schreef op vrijdag 23 augustus 2019 @ 08:26:
Hoe erg is dit? Word ik bij andere bedrijven afgebrand als ik het zo doe, of zijn er genoeg mensen die het belangrijker vinden dat ze snel tot een resultaat komen?

Bij de mensen die ik aanstuur hamer ik er op dat ze een compromis moeten sluiten tussen snel en goed zodat ze niet voor ontwikkelsnelheid gaan ten koste van alles.

[ Voor 9% gewijzigd door dev10 op 23-08-2019 09:31 ]

[Lethalis]

dev10 schreef op vrijdag 23 augustus 2019 @ 09:20:
[...]
Bij de mensen die ik aanstuur hamer ik er op dat ze een compromis moeten sluiten tussen snel en goed zodat ze niet voor ontwikkelsnelheid gaan ten koste van alles.

In principe moet je overal een middenweg in vinden.

Ontwikkelsnelheid moet zeker niet ten koste gaan van alles, maar dat geldt andersom net zo goed. Het gaat nergens over als je alles nodeloos ingewikkeld gaat maken en er daardoor veel te lang over doet.

De enige reden dat ik het toch in Angular zou bouwen, zou eigenlijk meer voor mezelf dan voor de business zijn: markt courantheid.

Simpelweg omdat iedereen verwacht dat je dit kan, dan maar gewoon ermee doorgaan zodat je iig niet achterblijft.

Maar als het mijn bedrijf zou zijn dan zou ik altijd voor de meest simpele tool for the job kiezen en schijt hebben aan wat momenteel populair is.

En dat voelt ergens "fout".

PS
Ik ben pas 38, maar begin mij als ontwikkelaar zijnde oud te voelen. Te vaak nieuwe technieken geleerd om ze een paar jaar later weg te gooien etc. En ja, nieuwe dingen leren is met een gezin veel moeilijker geworden dan toen ik nog 25 was en hele weekenden en avonden op het nieuwste kon duiken.

Project life cycles zijn ook vaak veel langer dan de levensduur van libraries anno nu. Genoeg projecten die rustig 10 jaar meegaan... tsja, die ga je niet 3 keer herschrijven omdat het toevallig hip is. Maar in de tussentijd moet je nog wel steeds nieuwe features ervoor bouwen en ze onderhouden (ik heb gisteren nog nieuwe functionaliteit met AngularJS gebouwd om deze reden ).

Voor nieuwe projecten wil je dan dus eigenlijk ook iets kiezen dat minimaal 10 jaar meegaat

AngularJS was voor mij dan ook een enorme domper. Ik werkte een jaar aan een project en vervolgens besloot Google dat de library die ik daarvoor gebruikt heb, dood is. Het project was amper af en eigenlijk al dood verklaard.

Dat soort dingen zijn enorm frustrerend en maken mij ook terughoudend.

React heeft dan nog het voordeel van dogfooding (heel Facebook is ermee gebouwd), dus de kans dat ze het overboord gooien is kleiner. Aan de andere kant begint het al ouder te worden en kun je je afvragen "hoelang heeft het nog?".

Vroeger werd ORM "the vietnam of computer science" genoemd, maar anno nu kijk ik zo tegen frontend development aan

[ Voor 42% gewijzigd door Lethalis op 24-08-2019 08:32 ]

[Gomez12]

dev10 schreef op vrijdag 23 augustus 2019 @ 09:20:
[...]
En toch, als ik met de applicatie waar ik aan werk opnieuw zou mogen bouwen zou ik kiezen voor een architectuur waarin de back-end voorziet in een API en de front-end een SPA is die deze API aanroept. De reden hiervoor is simpel: nu bouwen we een applicatie waarin we HTML templates aan het kloppen zijn en we bieden ook een API aan wat weer op een andere manier voor dubbel werkt zorgt. De views van de applicatie zijn voor 95% CRUD views die niet heel veel spannends doen. Het echte zware werk van de applicatie wordt op achtergrond gedaan met een job queue. Het voordeel hiervan voor mij zou zijn dat je front-end en back-end onafhankelijk van elkaar kunt ontwikkelen, deployen en schalen.

Zoals jij het beschrijft is er gewoon bij het begin van deze applicatie een grote keuze-fout gemaakt. En dat heeft niets met SPA of niet te maken.

Alleen ipv een applicatie te hebben, komt het op mij meer over dat jullie een API hebben met een voorbeeldimplementatie.

Of je de voorbeeldimplementatie nu in een SPA of een . net MVC bouwt vind ik dan nog niet eens relevant.

[Lethalis]

In mijn zoektocht op het internet nog een hoop blogs gelezen dit weekend en er zelf over nagedacht uiteraard.

1 groot nadeel van client side functionaliteit toevoegen aan een server side app is dat je een soort schizofrene oplossing krijgt. Ik heb het in een bestaand project dat ik ooit zelf geschreven heb ook. De webapplicatie is in principe met ASP.NET MVC gebouwd, maar op de views draait dan weer AngularJS (ja, de oude).

Omdat ik hier nog verder aan moet werken, heb ik het project helemaal opgeschoond en alle mappen onderverdeeld in zogenaamde Feature Folders. En dan wordt het effect nog zichtbaarder dat ik in feite 2 apps heb. Een AngularJS app en een ASP.NET MVC app.

Je kunt je dan afvragen waarom het niet 2 losse projecten zijn en dan kom je al gauw bij de SPA + backend oplossing uit.

De mate van interactiviteit is wel een dingetje. Hoe interactiever de webapplicatie moet zijn, hoe handiger een SPA wordt. Is aan de andere kant vooral SEO belangrijker en geeft de applicatie vooral informatie weer, dan is een server side framework weer handiger.

Om het wat verder te concretiseren naar mijn eigen situatie:
- Onze bedrijfswebsite doet er goed aan om lekker ASP.NET MVC te blijven.
- Maar onze support webapplicatie (die nu AngularJS én ASP.NET MVC is) zou prima een SPA kunnen zijn.

Bij die laatste twijfelde ik dus vooral. Wat de doorslag gaf, is toen ik zag hoe collega's van mij met de web applicatie werken. Dat ze even snel wat intikken, direct de juiste informatie op het scherm staat en ze meteen doorklikken naar wat ze willen. Het AngularJS deel wordt hevig gebruikt zeg maar.

[R4gnax]

boe2 schreef op woensdag 21 augustus 2019 @ 16:22:
Mijn persoonlijke mening: Het is vooral het domein van wannabe hipsters die een vreemde kronkel in hun hersenen hebben waardoor ze javascript een fan-tas-tische programmeertaal vinden en liefst ook de backend in node maken. Die een hekel hebben aan degelijke tooling en het liefst een week aan het prutsen zijn alvorens een degelijke workflow opgezet te hebben.
Deze leercurve wordt je gegarandeerd door iedere maand compleet nieuwe tooling uit te vinden, waarbij niets echt compatibel met elkaar is. Wil je toch bij dezelfde tools blijven? Geen zorgen, dependencies worden volautomatisch voor jou gebroken, zodat je altijd aan het werk blijft. Je bent trouwens geen echte webdeveloper als je niet eerst 200MB aan libraries via npm binnensleurt voor iedere nieuwe pagina die je maakt. Geheugen is goedkoop, dus laat de browser van de gebruiker maar goed zweten. Vergeet zeker niet de mobiele gebruikers: Geef ze een goede reden om ieder jaar een duurdere, snellere telefoon te kopen. Oeps, er is een nieuw populair framework van de maand? Gooi je toch gewoon het oude weg en migreer je naar het nieuwe framework.

* boe2 aait .NET mvc.

Lekker hyperbool.

Je hebt ook gewoon front-end developers die een compact client-side framework kiezen met goede performance en footprint characteristics en daar bij blijven, zonder met de hype mee te doen. En dependencies kunnen alleen stuk gaan als je ze bijwerkt. Zolang je je versies lockt; niets aan de hand.

Wel typisch dat je sluit met je voorkeur voor ASP.NET MVC aan te geven.
Jij gaat in licht van de rest van je schrijven, nog een hoop lol beleven aan .NET Core.
deprecated; obsolete; broken; not backwards compatible; no longer supported; need to migrate; etc.

Ed Vertijsment schreef op donderdag 22 augustus 2019 @ 16:54:
Je kan prima component based werken in een request response app, en als er geen noodzaak tot een SPA is zou ik dat ook gewoon niet doen. Mocht er een gedeeltelijke noodzaak ontstaan integreren we React in een bestaande request/response template (met een backend API). Alleen als er van te voren al vast staat dat er een absolute noodzaak is voor een SPA wordt dat vanaf de grond opgebouwd.

Eens. Je kunt prima met interactieve JS componenten werken binnen een traditionele request/response website. Dat maakt die site niet ineens een full-blown SPA waarbij je met routing, history, etc. rekening moet houden. Maar je kunt wel de vruchten plukken van andere technieken binnen een framework als Vue/React/etc. om de opzet van dat stukje UI wat interactief moet zijn, wat makkelijker te beheren dan 5 A4tjes aan procedureel geschreven jQuery. (ouch...)

[ Voor 20% gewijzigd door R4gnax op 26-08-2019 10:54 ]

[boe2]

R4gnax schreef op maandag 26 augustus 2019 @ 10:43:
[...]
Wel typisch dat je sluit met je voorkeur voor ASP.NET MVC aan te geven.
Jij gaat in licht van de rest van je schrijven, nog een hoop lol beleven aan .NET Core.
deprecated; obsolete; broken; not backwards compatible; no longer supported; need to migrate; etc.

Met het verschil dat niemand experimentele .core builds in productie gaat gebruiken, terwijl dit met javascript/node development de norm is

[Hydra]

Beetje laat maar; ik ben zelf primair back-ender maar heb redelijk wat front-end werk gedaan (AngularJS, Angular, VueJS en React) en zou zelf ook zeker de 'volgende keer' dat ik een front-end nodig heb voor (bijvoorbeeld) react gaan. Waarom? Onderhoudbaarheid. Je bent een mooie strikte scheiding tussen je back-end (je API) en je front-end, en als je front-end netjes component-based werkt; heb je code die over het algemeen een stuk cleaner is dan vanuit de back-end gegenereerde HTML met wat JavaScript tussendoor. Daarbovenop is het ook makkelijker samenwerken met front-end specialisten en UX/ers; als back-ender schrijf ik dan in zo'n SPA vooral de services (eigenlijk de client voor de web-service) en nemen zij de UX / flow / styling voor hun rekening.

Moet elke front-end een SPA zijn? Nee. Maar; waarom niet? Van moderne websites, ook die niet customer-facing zijn, wordt toch verwacht dat ze kwa gebruiksgemak een stuk verder zijn dan die oude oracle-forms meuk van 15 jaar terug. Natuurlijk zit er een heel groot gebied tussen dat en een SPA, maar ik zie zelf bijzonder weinig redenen om niet voor een SPA te gaan.

boe2 schreef op maandag 26 augustus 2019 @ 11:18:
Met het verschil dat niemand experimentele .core builds in productie gaat gebruiken, terwijl dit met javascript/node development de norm is

Dat is vooral een developer probleem. Als je een developer hebt die geen unit tests voor z'n JavaScript code schrijft, is dat niet de fout van JavaScript. Zelfde geldt voor het gebruik van externe dependencies.

[ Voor 17% gewijzigd door Hydra op 26-08-2019 11:21 ]

[MicroWhale]

Grappig om te lezen hier. Ik ben zelfstandig IT Architect en kijk iets anders aan tegen de keuze om een bepaald platform/framework te gaan gebruiken. Ik heb namelijk vaak te maken met een opdrachtgever, legacy systemen en (g)een visie voor IT. Ook zijn er altijd Devvers die roepen dat platform X gebruikt moet worden, terwijl dat in de organisatie nog nergens gebruikt wordt. Ook lopen er andere architecten rond met een bepaalde mening die ze graag bedrijfsbreed willen uitrollen. En zelf vanuit de business worden wel eens requirements ingeschoten voor een framework! (bij die laatste wordt Excel soms ook genoemd, want daar kunnen mensen uit de business ten minste mee overweg.)

Het draait om:
1. Wat de opdrachtgever al voor technologieën heeft en welk pad er uitgestippeld is voor het up-to-date houden of vernieuwen van technologieën
2. Of er investeringsbereidheid is voor het vernieuwen van een bestaand systeem (is het nu nodig? Zo ja, wie betaalt de investering?)
3. Wat de scope is van hetgeen vernieuwd moet worden
4. De mogelijkheden binnen de aanwezige ontwikkelstraten
5. De kennis en kunde van de aanwezige Devvers
6. De kennis en kunde van de Beheerorganisatie die de software moeten gaan beheren
7. Tijdspad versus beschikbaarheid van mensen en welke kennis ze hebben

Mijn ervaring:
Negen van de tien keer heb je inderdaad niks nieuws nodig. Het is echter wel zo dat een organisatie vaak vernieuwt om het vernieuwen. Vanuit hogerhand wordt dan besloten dat de IT 'niet achter mag blijven', waardoor er constant 'vernieuwd' wordt, maar dat eigenlijk zonder goede reden doet.

Een van de belangrijkste redenen om over te stappen is imo omdat je genoeg mensen hebt die een nieuw platform ook beheersen en daar beter mee kunnen bouwen + dat dat platform voordelen biedt ten opzichte van het huidige. Daarnaast is het dan een bonus als de migratie vrij snel kan verlopen.

Ik ben als architect een sterk voorstander van ontkoppelen en scheiden. Dit zorgt ervoor dat er per (deel) systeem een separate keuze gemaakt kan worden, mits nodig. Als er dan vernieuwd wordt, ligt ook niet het hele landschap plat en neemt het weinig risico's met zich mee.

[Ed Vertijsment]

boe2 schreef op woensdag 21 augustus 2019 @ 16:22:
Mijn persoonlijke mening: Het is vooral het domein van wannabe hipsters die een vreemde kronkel in hun hersenen hebben waardoor ze javascript een fan-tas-tische programmeertaal vinden

Zou je graag kunnen beargumenteren waarom JavaScript geen goede taal zou zijn. Je kunt het oneens zijn met bepaalde ideeën erachter en elke taal heeft wel wat issues maar volgens mij is het echt niet allemaal zo kut als jij doet voorstellen. Volgens mij heeft dat gewoon met kennis en kunde te maken. Ik ga ook niet beweren dat .net MVC kut is omdat ik er geen kennis van heb.

boe2 schreef op woensdag 21 augustus 2019 @ 16:22:
en liefst ook de backend in node maken.

Ook hier, zou je inhoudelijk kunnen beargumenteren waarom dat geen goed idee zou zijn? Niet dat we nou perse allemaal node code moeten gaan gebruiken voor een backend maar waarom is dat minder dan .NET mvc, PHP, Python, ruby of whatever?

boe2 schreef op woensdag 21 augustus 2019 @ 16:22:
Die een hekel hebben aan degelijke tooling en het liefst een week aan het prutsen zijn alvorens een degelijke workflow opgezet te hebben.

Nu laat je, jezelf kennen. JavaScript/Node heeft prima tooling. Ooit van WebPack gehoord? of create-react-app?

boe2 schreef op woensdag 21 augustus 2019 @ 16:22:
Deze leercurve wordt je gegarandeerd door iedere maand compleet nieuwe tooling uit te vinden, waarbij niets echt compatibel met elkaar is. Wil je toch bij dezelfde tools blijven? Geen zorgen, dependencies worden volautomatisch voor jou gebroken, zodat je altijd aan het werk blijft.

Hier heb je een beetje een punt, in de huidige cultuur is backwards compatibility een beetje een ondergeschoven kind, wordt overigens wel beter. BTW dependencies worden niet volautomatisch gebroken. NPM is heel goed in dit oplossen alleen dan moet je dus wel dependencies pinnen, en goh, waar is toch die package-lock.json voor?

boe2 schreef op woensdag 21 augustus 2019 @ 16:22:
Je bent trouwens geen echte webdeveloper als je niet eerst 200MB aan libraries via npm binnensleurt voor iedere nieuwe pagina die je maakt. Geheugen is goedkoop, dus laat de browser van de gebruiker maar goed zweten. Vergeet zeker niet de mobiele gebruikers: Geef ze een goede reden om ieder jaar een duurdere, snellere telefoon te kopen. Oeps, er is een nieuw populair framework van de maand? Gooi je toch gewoon het oude weg en migreer je naar het nieuwe framework.

Volgens mij begrijp jij frontend gewoon niet, en sure soms wordt en wat fanatiek gehyped met frameworks. Maar wat jij hier beschrijft is volgens mij vooraal een probleem met jouw kennis van frontend, en niet zo zeel met frontend zelf.

Je kan prima een tool gebruiken en daarbij blijven, je kan net zo goed framework jammen in backend land. Dat de cultuur binnen frontend soms een beetje van hot naar her springt herken ik, maar dat is niets wat je niet binnen je organisatie kunt oplossen/afdwingen en heeft ook zeker niet met een technologie te maken.

[boe2]

Ed Vertijsment schreef op maandag 26 augustus 2019 @ 11:47:
[...]

Nu laat je, jezelf kennen. JavaScript/Node heeft prima tooling. Ooit van WebPack gehoord? of create-react-app?

[R4gnax]

boe2 schreef op maandag 26 augustus 2019 @ 12:13:
[...]

Rot op zeg. Ed heeft gewoon gelijk.
Tooling zoals Webpack is gewoon volwassen. Er is in de huidige versies goed mee te werken en documentatie is ook goed op orde.

En als je denkt dat het minder volwassen is dan bijv. MSBuild; wens ik je veel plezier je eigen build targets met het handje te gaan schrijven in XML. Of wou je liever kijken in de richting van C/C++ en allerlei Make varianten? Mag ook hoor; maar ik garandeer je dat je daar helemaal niet vrolijk van wordt.

[ Voor 18% gewijzigd door R4gnax op 26-08-2019 12:21 ]

[Lethalis]

Ed Vertijsment schreef op maandag 26 augustus 2019 @ 11:47:
[...]
Zou je graag kunnen beargumenteren waarom JavaScript geen goede taal zou zijn.

Om precies de redenen waarom TypeScript en Flow zijn uitgevonden.

Naar mijn mening kun je niet zonder static type checking in grote projecten.

Ik hoop dan ook dat WebAssembly echt de toekomst is en dat ik straks gewoon een static taal kan gebruiken. Maakt mij niet eens uit of dat straks C#, F#, Golang, Java, Kotlin of wat dan ook is. Als het maar niet zo'n dynamisch script taaltje is

[Ed Vertijsment]

Lethalis schreef op maandag 26 augustus 2019 @ 14:36:
[...]

Om precies de redenen waarom TypeScript en Flow zijn uitgevonden.

Naar mijn mening kun je niet zonder static type checking in grote projecten.

Maar dan heb je het over dynamic typing, niet zo zeer over de taal zelf, er zijn immers meer dynamically typed talen. Ik ben het overigens met je eens dat static typing een welkome toevoeging zou zijn.

[gitaarwerk]

ThomasG schreef op donderdag 22 augustus 2019 @ 16:21:
[...]
Dat ligt dus aan de ontwikkelaars, want er is geen enkele reden waarom een website niet zowel SPA als responsive kan zijn.

Niet helemaal mee eens. Maar het ligt een beetje aan de details. Als we er vanuit gaan dat we voor SPA een framework gebruiken als angular, ember, react, etc.. dan is er gewoon een basis set met functionaliteiten die een payload van assets met zich meebrengen.

Als je kijkt met een hele simpele blanke pagina, is een no-spa altijd sneller/meer responsive. Maar er is natuurlijk een kantelpunt. En die ligt maar net aan de functionele eisen en de devs en of het offline beschikbaar is of niet. In veel gevallen voldoet een responsive webpagina prima, en soms is een SPA echt gewoon beter.

Maar er is niet echt een regel welke dit bepaald. Dat zou te complex zijn.


Type checking is erg fijn voor grote projecten. Maar niet altijd nodig. Ligt eraan hoe je interfaced. Meestal is het wel fijn. TypeScript is natuurlijk wel voordeliger betreft output, maar een ook wel weer wat overhead betreft dev tijd. FlowType is toch onderhand wel een beetje uitgestorven?

[ThomasG]

gitaarwerk schreef op maandag 26 augustus 2019 @ 14:55:
[...]


Niet helemaal mee eens. Maar het ligt een beetje aan de details. Als we er vanuit gaan dat we voor SPA een framework gebruiken als angular, ember, react, etc.. dan is er gewoon een basis set met functionaliteiten die een payload van assets met zich meebrengen.

Als je kijkt met een hele simpele blanke pagina, is een no-spa altijd sneller/meer responsive. Maar er is natuurlijk een kantelpunt. En die ligt maar net aan de functionele eisen en de devs en of het offline beschikbaar is of niet. In veel gevallen voldoet een responsive webpagina prima, en soms is een SPA echt gewoon beter.

Maar er is niet echt een regel welke dit bepaald. Dat zou te complex zijn.

Dit is dus gewoon onzin. Als je bijvoorbeeld React gebruikt is er geen enkele reden waarom het niet responsive zou kunnen zijn. React heeft namelijk geen "basis set met functionaliteiten die een payload van assets met zich meebrengen". Als je een knop wilt laten zien, moet je dat zelf doen al net zoals bij een no-spa website. Dat het sneller is, wellicht. Dat het meer responsive is? Nee. Dat ligt 101% aan de ontwikkelaar. Als je een no-spa site responsive kunt maken, kun je een SPA site (in ieder geval in React) ook responsive maken.

[gitaarwerk]

ThomasG schreef op maandag 26 augustus 2019 @ 15:01:
[...]
Dit is dus gewoon onzin. Als je bijvoorbeeld React gebruikt is er geen enkele reden waarom het niet responsive zou kunnen zijn. React heeft namelijk geen "basis set met functionaliteiten die een payload van assets met zich meebrengen". Als je een knop wilt laten zien, moet je dat zelf doen al net zoals bij een no-spa website. Dat het sneller is, wellicht. Dat het meer responsive is? Nee. Dat ligt 101% aan de ontwikkelaar. Als je een no-spa site responsive kunt maken, kun je een SPA site (in ieder geval in React) ook responsive maken.

Met responsive bedoel ik de snelheid waarmee de interface reageert. (Responsiveness)

Per definitie is het zo dat alles wat in het geheugen zit een impact *zou* kunnen maken op de performance. Al is het alleen maar de data die je binnenhaalt van het react framework.

Als je het over gewoon responsive hebt, met mediaQueries.. tja, dan heeft dan weinig relevantie.

[ThomasG]

gitaarwerk schreef op maandag 26 augustus 2019 @ 15:05:
[...]


Met responsive bedoel ik de snelheid waarmee de interface reageert. (Responsiveness)

Per definitie is het zo dat alles wat in het geheugen zit een impact *zou* kunnen maken op de performance. Al is het alleen maar de data die je binnenhaalt van het react framework.

Als je het over gewoon responsive hebt, met mediaQueries.. tja, dan heeft dan weinig relevantie.

Leuk dat jij met responsive responsiveness bedoelt, de rest van de wereld niet (het betekend ook gewoon iets anders). En ja, het heeft een impact op de performance. Maar als je inplaats van een "SPA" een website maakt en vervolgens DOM manipulatie doet met bijvoorbeeld jQuery (wat veel websites doen!), dan is een een UI library zoals React beter qua performance. Als je een statische pagina maakt is inderdaad niets sneller dan plain old HTML, maar zelfs dan kan het in bepaalde gevallen door CSS constructies en/of bepaalde HTML tags nog steeds langzaam zijn qua renderen.

[gitaarwerk]

ThomasG schreef op maandag 26 augustus 2019 @ 15:46:
[...]
Leuk dat jij met responsive responsiveness bedoelt, de rest van de wereld niet (het betekend ook gewoon iets anders). En ja, het heeft een impact op de performance. Maar als je inplaats van een "SPA" een website maakt en vervolgens DOM manipulatie doet met bijvoorbeeld jQuery (wat veel websites doen!), dan is een een UI library zoals React beter qua performance. Als je een statische pagina maakt is inderdaad niets sneller dan plain old HTML, maar zelfs dan kan het in bepaalde gevallen door CSS constructies en/of bepaalde HTML tags nog steeds langzaam zijn qua renderen.

Nou, je kan wel een beetje normaler reageren (je lijkt wel geirriteerd...). Verder eens. Er is ook overigens weinig wat jQuery meer toevoegt. Hun custom event-management is best goed, en ze hebben een hoop bijgedragen aan de proposals van de moderne javascript standaarden zoals querySelector. Verder was het een aantal jaar mooi om jQuery wel te gebruiken om browser inconsistenties af te vangen. Maar die tijd is wel een beetje voorbij nu.

[R4gnax]

gitaarwerk schreef op maandag 26 augustus 2019 @ 15:05:
Met responsive bedoel ik de snelheid waarmee de interface reageert. (Responsiveness)

Per definitie is het zo dat alles wat in het geheugen zit een impact *zou* kunnen maken op de performance. Al is het alleen maar de data die je binnenhaalt van het react framework.

Die metriek heet over het algemeen TTI oftewel; time-to-interactive.
En ook met een SPA kun je heel goed een lage TTI halen. Beter dan met een statische pagina zelfs.
Een SPA kan volledig ingericht worden op partieel inladen en in de achtergrond, of on-demand verdere onderdelen te downloaden. Bij een 'normale' website heb je de benodigde architecturele pré daarvoor juist vaak niet.

Een SPA kan ook middels een service worker de cache direct aansturen en pro-actief content binnenhalen waarvan gedacht wordt dat de gebruiker die zal gaan bezoeken. Gewoon in de achtergrond.

Diezelfde cache kan trouwens ook geprimed worden met lege pagina templates, welke zodra de gebruiker navigeert naar een nieuwe pagina eerst een soort van skelet tonen, waarna dit ingevuld wordt met content. Gebruikers kunnen op die manier de overkoepelende structuur van de pagina al in zich opnemen terwijl de content binnen druppelt. (Je kunt het; mocht het nodig zijn, zelfs streamen.)

Allemaal draagt het bij aan betere perceived performance.

Lethalis schreef op maandag 26 augustus 2019 @ 14:36:
[...]

Naar mijn mening kun je niet zonder static type checking in grote projecten.

Ik hoop dan ook dat WebAssembly echt de toekomst is en dat ik straks gewoon een static taal kan gebruiken. Maakt mij niet eens uit of dat straks C#, F#, Golang, Java, Kotlin of wat dan ook is. Als het maar niet zo'n dynamisch script taaltje is

Static type checking kan zeker wel wat toevoegen. Maar het kan zaken ook onnodig gecompliceerd maken. Er zijn voldoende voorbeelden van concepten die in statically typed talen vele malen moeilijker uit te voeren zijn, dan in dynamically typed talen.

[ Voor 17% gewijzigd door R4gnax op 26-08-2019 17:27 ]

[gitaarwerk]

R4gnax schreef op maandag 26 augustus 2019 @ 17:23:
[...]


Die metriek heet over het algemeen TTI oftewel; time-to-interactive.
En ook met een SPA kun je heel goed een lage TTI halen. Beter dan met een statische pagina zelfs.
Een SPA kan volledig ingericht worden op partieel inladen en in de achtergrond, of on-demand verdere onderdelen te downloaden. Bij een 'normale' website heb je de benodigde architecturele pré daarvoor juist vaak niet.

Een SPA kan ook middels een service worker de cache direct aansturen en pro-actief content binnenhalen waarvan gedacht wordt dat de gebruiker die zal gaan bezoeken. Gewoon in de achtergrond.

Diezelfde cache kan trouwens ook geprimed worden met lege pagina templates, welke zodra de gebruiker navigeert naar een nieuwe pagina eerst een soort van skelet tonen, waarna dit ingevuld wordt met content. Gebruikers kunnen op die manier de overkoepelende structuur van de pagina al in zich opnemen terwijl de content binnen druppelt. (Je kunt het; mocht het nodig zijn, zelfs streamen.)

Allemaal draagt het bij aan betere perceived performance.

Yup ik ben niet geheel onthouden op dit onderwerp. Heb een jaar geleden nog artikel geschreven betreft optimaal gebruik te maken van class names en gzip compressie. Er zijn veel leuke vondsten wat dat betreft. Veel gedaan op een high traffic e-commerce website

Maar spa heeft wel weer een hoop andere performance onderwerpen. Ook heel interessant overigens. Sluit overigens de 'gangbare' optimalisaties niet uit. Ben overigens aardig fan geworden van progressive images boven lazy loading.

[Lethalis]

Hydra schreef op maandag 26 augustus 2019 @ 11:20:
Beetje laat maar; ik ben zelf primair back-ender maar heb redelijk wat front-end werk gedaan (AngularJS, Angular, VueJS en React) en zou zelf ook zeker de 'volgende keer' dat ik een front-end nodig heb voor (bijvoorbeeld) react gaan. Waarom? Onderhoudbaarheid. Je bent een mooie strikte scheiding tussen je back-end (je API) en je front-end, en als je front-end netjes component-based werkt; heb je code die over het algemeen een stuk cleaner is dan vanuit de back-end gegenereerde HTML met wat JavaScript tussendoor.

Ach, toen ik afgelopen weekend aan het zoeken was, kwam ik een post op Reddit tegen waar iemand SPA's helemaal aan het afkraken was en toen reageerde een zeker iemand dat het vooral aan zijn gebrek aan ervaring met SPA's lag.

Dus zonder het te weten was je eerder dan je dacht

Daarbovenop is het ook makkelijker samenwerken met front-end specialisten en UX/ers; als back-ender schrijf ik dan in zo'n SPA vooral de services (eigenlijk de client voor de web-service) en nemen zij de UX / flow / styling voor hun rekening.

Op het moment dat je inderdaad in zo'n team werkt, kan ik me voorstellen dat je dit als backend ontwikkelaar heel fijn vindt. Ik heb zelf ook allerlei webservices en api's geschreven voor mijn collega die graag met Angular werkt.

Dat is inderdaad ook een persoonlijk aspect, ik vind backend ontwikkeling leuker dan frontend ontwikkeling. Maar dat komt deels ook door de tools die je daarvoor hebt.

Zo heb ik van oudsher altijd een hekel aan JavaScript gehad. HTML en CSS kan ik het op zich goed mee vinden, maar bij JavaScript heb ik echt altijd zo'n "het moet maar" gevoel gehad.

Op het moment dat we échte strongly typed toegang tot de DOM krijgen, zou ik het ook leuker gaan vinden. TypeScript wekt de illusie dat je dit hebt, maar er zijn helaas nog steeds constructies te bedenken die geldige TypeScript lijken, maar omdat het op de achtergrond nog steeds getranspiled wordt naar JavaScript blijf je met bepaalde beperkingen zitten en kun je onverwachte dingen krijgen.

Moet elke front-end een SPA zijn? Nee. Maar; waarom niet? Van moderne websites, ook die niet customer-facing zijn, wordt toch verwacht dat ze kwa gebruiksgemak een stuk verder zijn dan die oude oracle-forms meuk van 15 jaar terug. Natuurlijk zit er een heel groot gebied tussen dat en een SPA, maar ik zie zelf bijzonder weinig redenen om niet voor een SPA te gaan.

Een deel daarvan is angst voor de vluchtigheid van libraries. Natuurlijk zijn React en Angular zo naderhand wel volwassen geworden, maar als ik aan een project begin dat minimaal 5 tot 10 jaar mee moet gaan dan ben ik ergens bang dat halverwege Google besluit dat Angular het toch niet is en weer met wat anders komt.

Anderzijds heb je door de strikte scheiding van frontend en backend wel het voordeel dat de backend stabiel is en je in het worst case scenario alleen de frontend moet herschrijven.

Dus ik zou er nog plezier uit kunnen halen om iig hele duidelijke en stabiele api's te schrijven. En er een Angular frontend bij bouwen (met name omdat mijn collega ook met Angular bezig is, dan gebruiken we iig dezelfde technieken).

Maar de mate van interactiviteit bepaalt het inderdaad. Als het om een simpele website gaat waarbij het van belang is dat hij goed wordt geïndexeerd door zoekmachines, dan kan een MVC framework veel makkelijker zijn. Heb je echter een project waarbij dat helemaal niet van belang is en gebruikers veel meer interactie ermee hebben, dan wordt een SPA interessanter.

Dat is eigenlijk wat ik concludeer uit dit topic en wat ik de afgelopen week heb gelezen. In mijn geval betekent dat ook dat ik er tóch goed aan doe om meer SPA's te gaan bouwen, omdat de projecten die ik doe een hogere mate van interactiviteit hebben (snel zoeken in grids, dialogs, messageboxes, typeahead searches, veel forms, etc) en SEO helemaal niet belangrijk is.

PS


Dit is dus vooral wat ik met mijn JavaScript boek heb gedaan En de iMac die je niet in hoogte kunt verstellen

R4gnax schreef op maandag 26 augustus 2019 @ 17:23:
[...]
Static type checking kan zeker wel wat toevoegen. Maar het kan zaken ook onnodig gecompliceerd maken. Er zijn voldoende voorbeelden van concepten die in statically typed talen vele malen moeilijker uit te voeren zijn, dan in dynamically typed talen.

Het grote probleem is onderhoudbaarheid.

Een project is meer dan alleen zijn realisatie. Het moet daarna nog jaren onderhouden worden en aangepast worden. Bij strongly typed talen vind ik dit vele malen makkelijker te doen, omdat je heel precies kunt zien waar elke variabele en functie voor wordt gebruikt. Het type is ook meteen een stukje documentatie.

Daarnaast kun je veel sneller refactoren en met de juiste tools kun je dit ook met zo'n klein mogelijk risico.

[ Voor 11% gewijzigd door Lethalis op 27-08-2019 09:34 ]

[Hydra]

Lethalis schreef op dinsdag 27 augustus 2019 @ 09:11:
Ach, toen ik afgelopen weekend aan het zoeken was, kwam ik een post op Reddit tegen waar iemand SPA's helemaal aan het afkraken was en toen reageerde een zeker iemand dat het vooral aan zijn gebrek aan ervaring met SPA's lag.

Dus zonder het te weten was je eerder dan je dacht

Dat zie je vaak helaas veel bij developers en is een pitfall waar ik mezelf ook wel eens op betrap; iets niet 'okay' vinden gewoon omdat je er weinig ervaring mee hebt is een slechte houding. Ik zie genoeg Java devs bijvoorbeeld die ageren tegen de Java 8 changes (lambda's enzo) gewoon puur omdat ze nog steeds de syntax niet onder de knie hebben.

Niet dat er zaken aan te merken zijn aan het front-end ecosysteem overigens, maar vaak zijn dat soort meningen weinig genuanceerd.

Zo heb ik van oudsher altijd een hekel aan JavaScript gehad. HTML en CSS kan ik het op zich goed mee vinden, maar bij JavaScript heb ik echt altijd zo'n "het moet maar" gevoel gehad.

Op het moment dat we échte strongly typed toegang tot de DOM krijgen, zou ik het ook leuker gaan vinden. TypeScript wekt de illusie dat je dit hebt, maar er zijn helaas nog steeds constructies te bedenken die geldige TypeScript lijken, maar omdat het op de achtergrond nog steeds getranspiled wordt naar JavaScript blijf je met bepaalde beperkingen zitten en kun je onverwachte dingen krijgen.

Ik vind TypeScript wel fijn werken. Het is 'bijna Java' in de zin dat je IDE je meestal wel laat weten of je iets fout doet. En modern JavaScript is ook al een heel stuk beter dan het JavaScript van 8 jaar terug. Natuurlijk zitten er bepaalde wratten op de taal, maar het is een stuk werkbaarder tegenwoordig. Ik heb persoonlijk meer een 'hekel' aan het styling aspect van front-end development; maar da's gewoon een gebrek aan skills aan mijn kant. Ik zie wel dat het lelijk is, maar ben er niet creatief genoeg voor om dat te fixen. En da's frustrerend

Een deel daarvan is angst voor de vluchtigheid van libraries. Natuurlijk zijn React en Angular zo naderhand wel volwassen geworden, maar als ik aan een project begin dat minimaal 5 tot 10 jaar mee moet gaan dan ben ik ergens bang dat halverwege Google besluit dat Angular het toch niet is en weer met wat anders komt.

Het is open source dus dat zal niet zo'n vaart lopen. Daarbij kun je prime in de huidige versie van Angular verder werken zelfs als Google er opeens niks meer mee doet. Die community is tegenwoordig zo groot dat er een momentum is dat niet meer te stoppen is. Hetzelfde geldt voor React (waar ik een voorkeur voor heb).

[boe2]

R4gnax schreef op maandag 26 augustus 2019 @ 17:23:
[...]


Die metriek heet over het algemeen TTI oftewel; time-to-interactive.
En ook met een SPA kun je heel goed een lage TTI halen. Beter dan met een statische pagina zelfs.
Een SPA kan volledig ingericht worden op partieel inladen en in de achtergrond, of on-demand verdere onderdelen te downloaden. Bij een 'normale' website heb je de benodigde architecturele pré daarvoor juist vaak niet.

Een paar kB aan html VS een paar MB aan js libraries die moeten ingeladen worden alvorens je de rest kan beginnen inladen. Dat moet ik nog in de praktijk zien dat je spa een betere TTI heeft.

[Creepy]

boe2 schreef op maandag 26 augustus 2019 @ 12:13:
[...]

Misschien goed om eens uit te leggen wat jij een degelijke workflow vindt en waarom dat niet kan, of dat het simpelweg niet gedaan wordt, met de tooling die er voor JS e.d. beschikbaar is? Alleen een paar smilies posten is nogal makkelijk.......

De JS tooling is ook weer wat jaren verder. Ze hebben helaas veel naar zichzelf gekeken en opnieuw geprobeerd het wiel uit te vinden op een aantal punten. Mijn grootste irritatiepunt is/was semantic versioning en daardoor met enige regelmaat kapotte builds omdat een dependency ineens een andere versie van een andere dependency binnen hengelde en dat de build sloopt (errors of kapotte tests...), zonder dat je zelf wat had gewijzigd. Maar ook daar is gelukkig ondertussen van geleerd.

[Lethalis]

Creepy schreef op dinsdag 27 augustus 2019 @ 11:00:
[...]
Mijn grootste irritatiepunt is/was symantec versioning.

Je bedoelt semantic versioning?

Op zich is het concept niet slecht dat je aan een versienummer meteen ziet of hij breaking changes heeft.

Voor de rest ben ik blij met het "npm ci" commando, dat gewoon de package-lock.json gebruikt.

[ Voor 13% gewijzigd door Lethalis op 27-08-2019 11:17 ]

[Creepy]

Lethalis schreef op dinsdag 27 augustus 2019 @ 11:16:
[...]

Je bedoelt semantic versioning?

whoops

Op zich is het concept niet slecht dat je aan een versienummer meteen ziet of hij breaking changes heeft.

Qua concept opzich niet, maar in de praktijk zie je breaking changes bij het ophogen van bijv. 1.0.1 naar 1.0.2. Dus in theorie leuk, maar in de praktijk kapotte builds. Iets dat je niet zomaar ziet met tooling zoals bijv maven.

[Hydra]

boe2 schreef op dinsdag 27 augustus 2019 @ 10:40:
Een paar kB aan html VS een paar MB aan js libraries die moeten ingeladen worden alvorens je de rest kan beginnen inladen. Dat moet ik nog in de praktijk zien dat je spa een betere TTI heeft.

Ten eerste een vals dilemma (React bijvoorbeeld is 32kB gzipped), ten tweede is dat alleen de eerste load. Een 'traditioneel' server side rendered app heeft een delay bij elke actie omdat de hele page opnieuw opgebouwd moet worden, een SPA niet. Meestal voelt een SPA sneller voor de gebruiker.

[armageddon_2k1]

Waar haalt iedereen de paar MB JS libraries vandaan? Gebruikt er niemand dead-code elimination, lazy loading en weet ik wat al meer? Ik kom het echt zelden tegen, en als het wel zo is komt het meer doordat er 9000 tracking en ad-scripts ingeladen worden. Zelfs ons under-optimized web-app tikt net aan de 800kb aan.....

Of inspecteer je de grote van je node_modules mapje en denkt dat dat allemaal naar de client gaat?

Creepy schreef op dinsdag 27 augustus 2019 @ 11:19:
[...]

whoops


[...]

Qua concept opzich niet, maar in de praktijk zie je breaking changes bij het ophogen van bijv. 1.0.1 naar 1.0.2. Dus in theorie leuk, maar in de praktijk kapotte builds. Iets dat je niet zomaar ziet met tooling zoals bijv maven.

Heuh? Wat in Maven zorgt ervoor dat je geen kapotte builds kan krijgen met een versie-verhoging? Dat zit hem niet in Maven hoor... Heb het toch al gehad dat library-x in Maven een breaking-change had....

[ Voor 48% gewijzigd door armageddon_2k1 op 27-08-2019 19:45 ]

[Kwistnix]

armageddon_2k1 schreef op dinsdag 27 augustus 2019 @ 19:41:

[...]

Heuh? Wat in Maven zorgt ervoor dat je geen kapotte builds kan krijgen met een versie-verhoging? Dat zit hem niet in Maven hoor... Heb het toch al gehad dat library-x in Maven een breaking-change had....

Helemaal waar, maar er is een belangrijk verschil tussen hoe Maven (sinds 3 althans) en bijv. npm met versies omgaan. In Maven is het ongebruikelijk om met versie ranges te werken (is deprecated syntax), waarbij dat in npm wel vrij standaard gebeurd. In Maven zijn de dependency versies dus stabieler. Als semver netjes wordt toegepast zou het geen verschil moeten maken dat er af en toe eens een patch of zelfs een minor versie automatisch wordt gebumped, maar in de praktijk valt dat nogal tegen.

[Creepy]

armageddon_2k1 schreef op dinsdag 27 augustus 2019 @ 19:41:

Heuh? Wat in Maven zorgt ervoor dat je geen kapotte builds kan krijgen met een versie-verhoging? Dat zit hem niet in Maven hoor... Heb het toch al gehad dat library-x in Maven een breaking-change had....

Maar dan heb je zelf het versienummer opgehoogd waarschijnlijk. Met NPM hebben we dat in het verleden automatisch gehad vanwege semantic versioning. Wij niks aangepast. Dezelfde build, werkt lokaal wel, op de buildserver niet. Of dezelfde build, werkt prima op de buildserver maar een week later niet meer. Zonder aanpassing. Maar ja, ergens was een dependency van een dependency geupdate en hoppa, de build stuk. Natuurlijk, dat is tegenwoordig beter want je hebt nu .lock files.

[armageddon_2k1]

@Creepy Ja, daar geef je inderdaad het pijnpunt aan van semantic versioning als mensen zich er niet aan houden.

Wij moesten van een 3rd party een SNAPSHOT dependency gebruiken van hun eigen Nexus-server. In de API zat al heel lang een typo (ongeveer als onderstaand):

code:

public Node getChildrens() {}

en dat was van de ene op de andere dag geworden:

code:

public Node getChildren() {}

En daar gaat je build.....

Ook hier is het de persoon en niet het systeem dat het probleem is, net als bij semantic versioning. Sowieso onwenselijk om SNAPSHOT te moeten gebruiken, maar ja... 3rd party.

[Lethalis]

armageddon_2k1 schreef op dinsdag 27 augustus 2019 @ 19:41:
Waar haalt iedereen de paar MB JS libraries vandaan?

Wij hebben een Angular 7 project waar een "ng build --prod" het volgende oplevert:

code:

Date: 2019-08-28T06:06:34.955Z
Hash: 5676bcb58c7b792ce098
Time: 82445ms
chunk {0} runtime.26209474bfa8dc87a77c.js (runtime) 1.41 kB [entry] [rendered]
(hier zitten nog assets tussen, maar die heb ik ivm de privacy verwijderd)
chunk {8} main.010fe12084fc23dc5b30.js (main) 3.06 MB [initial] [rendered]
chunk {9} polyfills.6446f5cceeb1bf38e0f6.js (polyfills) 146 kB [initial] [rendered]
chunk {10} styles.406622e9be77a74640c8.css (styles) 160 kB [initial] [rendered]
chunk {scripts} scripts.cff5d11503a54bc5ba27.js (scripts) 368 kB [entry] [rendered]

De main bundle is 3.06 MB (blijft ongeveer 615 KB van over na gzip).

Nu geef ik toe dat dit een vrij groot project is (met in totaal 835 TypeScript files, waarvan 245 components) en vraag ik mij dus ook af wat je hier aan kunt doen.

Dependencies in package.json:

code:

  "dependencies": {
    "@angular-devkit/schematics": "^7.3.9",
    "@angular/animations": "^7.2.15",
    "@angular/cdk": "^7.3.7",
    "@angular/common": "^7.2.15",
    "@angular/compiler": "^7.2.15",
    "@angular/core": "^7.2.15",
    "@angular/forms": "^7.2.15",
    "@angular/http": "^7.2.15",
    "@angular/material": "^7.3.7",
    "@angular/platform-browser": "^7.2.15",
    "@angular/platform-browser-dynamic": "^7.2.15",
    "@angular/router": "^7.2.15",
    "@kolkov/angular-editor": "^0.13.1",
    "@schematics/angular": "^7.3.9",
    "ajv": "^6.10.0",
    "angular-animations": "0.0.8",
    "bootstrap": "^4.3.1",
    "chart.js": "^2.8.0",
    "core-js": "^2.6.8",
    "font-awesome": "^4.7.0",
    "jquery": "^3.4.1",
    "ng2-charts": "^1.6.0",
    "ngx-bootstrap": "^3.3.0",
    "ngx-json-viewer": "^2.3.1",
    "popper": "^1.0.1",
    "popper.js": "^1.15.0",
    "rxjs": "^6.5.2",
    "tether": "^1.4.6",
    "web-animations-js": "^2.3.1",
    "zone.js": "^0.8.26"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^0.13.9",
    "@angular/cli": "^7.3.9",
    "@angular/compiler-cli": "^7.2.15",
    "@angular/language-service": "^7.2.15",
    "@types/jasmine": "^3.3.12",
    "@types/jasminewd2": "~2.0.2",
    "@types/jquery": "^3.3.3",
    "@types/node": "^11.13.11",
    "codelyzer": "^4.3.0",
    "jasmine-core": "^3.4.0",
    "jasmine-spec-reporter": "~4.2.1",
    "jshint": "^2.10.2",
    "karma": "^4.1.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-cli": "^2.0.0",
    "karma-coverage-istanbul-reporter": "^2.0.5",
    "karma-jasmine": "^2.0.1",
    "karma-jasmine-html-reporter": "^1.4.2",
    "node-sass": "^4.12.0",
    "npm": "^6.9.0",
    "protractor": "^5.3.2",
    "replace-in-file": "^4.1.0",
    "ts-node": "^8.1.0",
    "tslint": "^5.16.0",
    "typescript": "^3.1.6"
  }

PS
Ik heb dit project niet zelf opgezet, maar er alleen aan meegewerkt... dus het kan zijn dat ik een collega even moet vragen waarom bepaalde dingen zo zijn als je iets opmerkt. Maar ik ben benieuwd.

[R4gnax]

Ik heb dit project niet zelf opgezet, maar er alleen aan meegewerkt... dus het kan zijn dat ik een collega even moet vragen waarom bepaalde dingen zo zijn als je iets opmerkt. Maar ik ben benieuwd.

Begin bij het begin en kijk waar het pijnpunt zit:
https://www.npmjs.com/package/webpack-bundle-analyzer

Is je applicatie gewoon zo groot?
Dan kun je kijken om deze op te splitsen in lazy loaded chunks.

Heb je ergens een fout gemaakt waardoor tree shaking / dead code elimination haar werk niet kan doen?
Dan kun je dat corrigeren.

etc.

[Lethalis]

R4gnax schreef op woensdag 28 augustus 2019 @ 09:31:
[...]
Is je applicatie gewoon zo groot?
Dan kun je kijken om deze op te splitsen in lazy loaded chunks.

Ik zie dat Angular zogenaamde Feature Modules heeft die lazy loaded kunnen zijn. Dat klinkt op zich wel handig voor ons project. Ik zal er eens naar kijken

https://angular.io/guide/lazy-loading-ngmodules

[Hydra]

Creepy schreef op dinsdag 27 augustus 2019 @ 21:35:
[...]

Maar dan heb je zelf het versienummer opgehoogd waarschijnlijk. Met NPM hebben we dat in het verleden automatisch gehad vanwege semantic versioning. Wij niks aangepast. Dezelfde build, werkt lokaal wel, op de buildserver niet. Of dezelfde build, werkt prima op de buildserver maar een week later niet meer. Zonder aanpassing. Maar ja, ergens was een dependency van een dependency geupdate en hoppa, de build stuk. Natuurlijk, dat is tegenwoordig beter want je hebt nu .lock files.

Ik vind niet dat dat perse de schuld van NPM is, maar meer dat de community het 'okay' vindt dat je geen specifieke versies gebruikt. Het is nogal naief / optimistisch te denken dat semver altijd werkt / mensen geen fouten maken. Maar da's wel een beetje het grootste probleem met het NPM ecosysteem; veel onervaren, naieve en te optimistische developers.

armageddon_2k1 schreef op woensdag 28 augustus 2019 @ 07:45:
Wij moesten van een 3rd party een SNAPSHOT dependency gebruiken van hun eigen Nexus-server.

M.i. is dat volledig jullie fout. Beetje hard, snap ik, maar dat kan gewoon simpelweg niet. Dan heb je dus een goeie tech lead / manager nodig die gaat regelen dat ze gewoon netjes versies publiceren. Er is, ook in hun build, nul reden om niet gewoon in hun eigen repo versioned artifacts te publiceren.

[ Voor 21% gewijzigd door Hydra op 28-08-2019 10:00 ]

[Shmorky]

Even een side-vraag over SPA frontends in Microsoft-omgevingen: heeft er hier iemand als eens iets met Blazor of een ander WebAssembly-framework gedaan in een project voor een klant? Dus buiten de hobby-sfeer zeg maar?

Heb er laatst een demo van gehad (Blazor dus) en moet zeggen dat ik het wel dig als oplossing voor de JS-framework-nachtmerrie waar we ons momenteel in bevinden. Het zit nu ook in .NET Core en nadert een (relatief) volwassen status, dus volgens mij is dit wel het moment om ermee te beginnen...

[armageddon_2k1]

Hydra schreef op woensdag 28 augustus 2019 @ 09:57:
[...]
M.i. is dat volledig jullie fout. Beetje hard, snap ik, maar dat kan gewoon simpelweg niet. Dan heb je dus een goeie tech lead / manager nodig die gaat regelen dat ze gewoon netjes versies publiceren. Er is, ook in hun build, nul reden om niet gewoon in hun eigen repo versioned artifacts te publiceren.

Ik zeg ook nergens dat het niet onze schuld is Het is gewoon wat het is en we hebben gewoon met deze partij te werken. Support is 0,0 van hun kant en het is een hoofdpijndossier waar ik graag vanaf wil als tech lead Iets met dubbeltje en eerste rij dat voordat ik kwam bepaald is. Je kan wel makkelijk zeggen dat 'je even gaat regelen dat ze gewoon netjes versies publiceren', maar als ze daar schijt aan hebben dan rest niks anders dan het product gewoon niet meer gebruiken. Daar zijn we dan ook mee bezig.

[Hydra]

armageddon_2k1 schreef op woensdag 28 augustus 2019 @ 10:18:
Ik zeg ook nergens dat het niet onze schuld is Het is gewoon wat het is en we hebben gewoon met deze partij te werken. Support is 0,0 van hun kant en het is een hoofdpijndossier waar ik graag vanaf wil als tech lead Iets met dubbeltje en eerste rij dat voordat ik kwam bepaald is. Je kan wel makkelijk zeggen dat 'je even gaat regelen dat ze gewoon netjes versies publiceren', maar als ze daar schijt aan hebben dan rest niks anders dan het product gewoon niet meer gebruiken. Daar zijn we dan ook mee bezig.

Snap het, vandaar mijn excuses dat ik het 'lomp' stelde en ik zeg ook zeker niet dat het jouw fout is. Maar ik heb zelf wel vaak met incompetente partijen moeten werken en als het moet ga ik dan zo 'hoog' als nodig is. En da's soms vervelend en ik heb ook een keer een technisch directeur van een externe partij uit moeten leggen dat met de hand XML aan elkaar concatenaten met een StringBuilder iets is wat alleen erg onervaren developers doen. Maar da's beter dan het alternatief; dat het aan onze kant continue stuk gaat en het mijn reputatie is, die op het spel staat.

Het is hoe dan ook een kutsituatie voor jou hoor

Voor de volgende keer; ik zou dat artifact dan zelf versioneren in onze 'eigen' repository, bijvoorbeeld met de MD5 hash van de .jar.

[MueR]

Lethalis schreef op woensdag 28 augustus 2019 @ 09:05:

Dependencies in package.json:
[...]

Persoonlijk zou ik eens beginnen met jquery er uit slopen. Ik snap niet helemaal waarom mensen dat perse in hun project frotten. Angular/React/Vue geven je allemaal prima mogelijjkheden om alles te doen wat je nodig hebt.. Zou het gewoon "ik weet hoe het in jquery moet" zijn? Je reactive framework is verantwoordelijk voor de dom, dan moet je imho niet ook nog eens met jquery er tussendoor gaan fietsen.

Overigens kunnen resources als bootstrap (en jquery als je die dan echt perse nodig hebt) ook gewoon vanaf een CDN worden gehaald (iig de JS), dan heb je al veel meer kans op cache hits bij gebruikers.

[ Voor 28% gewijzigd door MueR op 28-08-2019 10:38 ]

[Utoka]

MueR schreef op woensdag 28 augustus 2019 @ 10:33:
[...]

Persoonlijk zou ik eens beginnen met jquery er uit slopen. Ik snap niet helemaal waarom mensen dat perse in hun project frotten. Angular/React/Vue geven je allemaal prima mogelijjkheden om alles te doen wat je nodig hebt.. Zou het gewoon "ik weet hoe het in jquery moet" zijn? Je reactive framework is verantwoordelijk voor de dom, dan moet je imho niet ook nog eens met jquery er tussendoor gaan fietsen.

De laatste zijn frameworks en jquery was/is een soort toolset om het cross browser makkelijker te maken (en shortcuts).

Ben het eens met dat je jquery eruit moet slopen maar dan gewoon voor vanilla javascript. Ik hoop dat je voor een website met alleen een mobiel uitklap menu niet Angular/React/Vue gaat inzetten. Dan is het bloated jquery inruilen voor bloated x framework wat met 20 regels javascript waarschijnlijk kan.

[Kwistnix]

Lethalis schreef op woensdag 28 augustus 2019 @ 09:42:
[...]

Ik zie dat Angular zogenaamde Feature Modules heeft die lazy loaded kunnen zijn. Dat klinkt op zich wel handig voor ons project. Ik zal er eens naar kijken

https://angular.io/guide/lazy-loading-ngmodules

Is best een interessante aanpak, wordt ook gebruikt in de SPA waar ik nu aan werk. Je moet wel even goed opletten hoe je modules opdeelt en welke providers je waar onderbrengt, maar dan werkt dat best goed.

[armageddon_2k1]

Hydra schreef op woensdag 28 augustus 2019 @ 10:24:
[...]


Snap het, vandaar mijn excuses dat ik het 'lomp' stelde en ik zeg ook zeker niet dat het jouw fout is......

Het is hoe dan ook een kutsituatie voor jou hoor

Voor de volgende keer; ik zou dat artifact dan zelf versioneren in onze 'eigen' repository, bijvoorbeeld met de MD5 hash van de .jar.

No offence taken Gewoon het leven van de tech lead. 80% legacy, 10% ontwikkeling, 10% boze irrationele klanten. Iemand moet het doen. Zolang de trend maar opwaarts is.

We hebben nu onze eigen Nexus waar we een versie van hun artifacts hosten ja. Is de beste oplossing.

[R4gnax]

Shmorky schreef op woensdag 28 augustus 2019 @ 10:15:
Heb er laatst een demo van gehad (Blazor dus) en moet zeggen dat ik het wel dig als oplossing voor de JS-framework-nachtmerrie waar we ons momenteel in bevinden. Het zit nu ook in .NET Core en nadert een (relatief) volwassen status, dus volgens mij is dit wel het moment om ermee te beginnen...

Nee. Bij monde van MS zelf is het nog steeds experimenteel.
Daarnaast heb je nog steeds een footprint van 2MB aan .NET IL die niet alleen eerst gedownload moet worden, maar daarna ook nog naar bytecode gecompileerd moet worden door de in WASM geschreven .NET runtime. Het zal op met name de iets oudere telefoons en tablets niet echt fraai presteren.

De server zijde van Blazor, wat vroegâh Razor Components heette, is wel stable - soort van, in elk geval. Maar dat is niet waar jij hier naar verwijst, lijkt me.

[ Voor 15% gewijzigd door R4gnax op 28-08-2019 19:09 ]

[Webgnome]

MueR schreef op woensdag 28 augustus 2019 @ 10:33:
[...]

Persoonlijk zou ik eens beginnen met jquery er uit slopen. Ik snap niet helemaal waarom mensen dat perse in hun project frotten. Angular/React/Vue geven je allemaal prima mogelijjkheden om alles te doen wat je nodig hebt..

How about no? Voor heel veel taken / zaken is een simpele jquery/dojo/underscore oldschool javascript library meer dan voldoende daar hoef je echt niet naar een toolset als react/angular te grijpen. Echt niet. Dat je het dan net zo goed in vanilla js kan schrijven is een optie maar om heel eerlijk te zijn die eerdere genoemde libraries zijn ooit bedacht om een reden. En nee dat was niet alleen om IE6 zich te laten gedragen. Right tool for the job.

[MueR]

Webgnome schreef op woensdag 28 augustus 2019 @ 20:36:
[...]


How about no? Voor heel veel taken / zaken is een simpele jquery/dojo/underscore oldschool javascript library meer dan voldoende daar hoef je echt niet naar een toolset als react/angular te grijpen. Echt niet. Dat je het dan net zo goed in vanilla js kan schrijven is een optie maar om heel eerlijk te zijn die eerdere libraries zijn ooit bedacht om een reden. En nee dat was niet alleen om IE6 zich te laten gedragen. Right tool for the job.

How about yes? De TS heeft een Angular applicatie, dan is jquery overbodig. Right tool for the right job zoals je zegt. Ik ben niet per definitie tegen jquery, maar wel tegen het gebruik ervan omdat je een ajax request of basale grapjes als onclick dingen moet kunnen. Dan is jquery overkill, maar zeker wanneer de basis van je applicatie al een dom controller is.

[ Voor 15% gewijzigd door MueR op 28-08-2019 20:52 ]

[Lethalis]

MueR schreef op woensdag 28 augustus 2019 @ 10:33:
[...]
Persoonlijk zou ik eens beginnen met jquery er uit slopen. Ik snap niet helemaal waarom mensen dat perse in hun project frotten.

Overigens kunnen resources als bootstrap (en jquery als je die dan echt perse nodig hebt) ook gewoon vanaf een CDN worden gehaald (iig de JS), dan heb je al veel meer kans op cache hits bij gebruikers.

Eerlijk gezegd weet ik niet waarom jQuery er in zit. Ik zal het eens vragen, want ik heb eigenlijk niet het idee dat mijn collega jQuery daadwerkelijk gebruikt (hij is juist helemaal happy met Angular en RXJS, dus ik zie geen reden).

Het project bestaat al wel een paar jaar, dus misschien dat het ooit nodig was en inmiddels niet meer.

Bootstrap is wel een dingetje inderdaad. Zodra je dat include in een bundle, dan groeit deze echt enorm.

[ Voor 6% gewijzigd door Lethalis op 29-08-2019 08:27 ]

[armageddon_2k1]

@Lethalis Ik snap niet helemaal wat Angular en RXJS met jQuery van doen hebben? Er is nagenoeg geen overlap in functionaliteit of doel.