SPA of MPA?

[ikvanwinsum]

Ik ben bezig een webapplicatie te bouwen m.b.v. Laravel en Vue.js. Ik ben begonnen met deze applicatie te bouwen als een MPA. Maar het begint toch wel een beetje te jeuken. Een SPA heeft wel degelijk grote voordelen. Als ik een SPA ga maken zou ik dat waarschijnlijk doen m.b.v. vue-router. Ik ben er alleen nog niet helemaal uit hoe ik zaken als authorisatie (bijv. het verbergen van ontoegankelijke links) aan moet pakken, zonder al teveel code naar de client-side te moeten verhuizen.

Ik heb alvast een aantal voordelen voor SPA's en MPA's op een rijtje gezet:

Voordelen Single Page Application

• Beter gescheiden front-end en back-end
• De API is makkelijker te hergebruiken voor bijvoorbeeld een app
• Vaak sneller (geen page reloads)
• Werkt vaak mooier (vind ik)

Voordelen Multi Page Application

• Makkelijker te bouwen
• Minder afhankelijk van JS
• SEO is makkelijker

Vandaar mijn vraag: Wanneer je zou beginnen met het bouwen van een uitgebreide webapp/website, heeft een SPA of een MPA je voorkeur, en waarom?

[André]

Een SPA werkt ook prima met SEO, alleen moet je goed opletten wat je doet. En SEO is breder dan Google alleen: Bing werkt minder goed met JS, evenals Twitter en Facebook met hun preview functies. Dus de eerste initiële pagina zou alsnog een volledige DOM moeten hebben vanuit de server, idealiter gezien.

Als ik kijk naar metingen en tools is een SPA ook wat ingewikkelder. Met een goede implementatie krijg je het meeste wel aan de praat. Maar het wordt technisch allemaal net iets ingewikkelder. Waar bij een MPA een marketeer nog wel eens wat voor elkaar krijgt met een Tag Manager, ben je bij een SPA afhankelijk van een technisch iemand met SPA kennis. Tools als IO, Hotjar, VWO, enz moeten net even anders ingesteld worden, er moeten calls naar toe gemaakt worden bij pageviews, wat bij een MPA standaard niet hoeft.

[TheBorg]

Als alleen kijkt naar het eindresultaat en je SEO buiten beschouwing laat dan maakt het niet uit. Maar wat het handigste is om te ontwikkelen hangt helemaal af van je applicatie. Vaak lenen applicaties zoals we die klassiek uit Windows kennen zich heel goed voor een SPA.

Mijn aller grootste irritatie van SPA's is dat de navigatie gewoon voor geen meter werkt. Om maar iets te noemen, ik zit in een tabblad transacties. Ik wil die refreshen. Refresh knop zit niet in de (web) app. Ik kan dus twee dingen doen. F5 of nog een keer op de tab klikken. F5 brengt me naar de hoofdpagina en actieve tabs hebben geen event dus klikken werkt niet. Totaal kut dus.

Maar dat het niet werkt komt niet omdat het een SPA is. Het is gewoon bagger gemaakt. Echter is het wel makkelijker om met een SPA dit soort fouten te maken. Daarom vind ik dat er te snel voor een SPA wordt gekozen. Maar dat heeft meer met onkunde te maken.

Ik weet niet of je bij de ING bank zit maar de nieuwe webapp die ze sinds een paar weken hebben is de hel op aarde. Leuk dat de interface op alle devices werkt maar op een PC is het gewoon niet gebruikersvriendelijk. Hadden ze voor een MPA gekozen dan hadden ze de navigatie blunders niet begaan.

Schets eens op een paar stukken A4 papier hoe je interface er uit moet komen te zien. Dan wordt waarschijnlijk wel duidelijk wat voor je app de makkelijkste weg is.

[botwood]

Je kan ze ook combineren, maar ik weet niet wat je dan allemaal op je nek haalt. Maar wellicht is dat ook een optie voor je?

[Spinal]

TheBorg schreef op dinsdag 26 juni 2018 @ 11:12:
Mijn aller grootste irritatie van SPA's is dat de navigatie gewoon voor geen meter werkt. Om maar iets te noemen, ik zit in een tabblad transacties. Ik wil die refreshen. Refresh knop zit niet in de (web) app. Ik kan dus twee dingen doen. F5 of nog een keer op de tab klikken. F5 brengt me naar de hoofdpagina en actieve tabs hebben geen event dus klikken werkt niet. Totaal kut dus.

Dat probleem heeft niks te maken met SPA of niet, maar met:

Het is gewoon bagger gemaakt.

De SPA waar ik dagelijks aan werk kun je wél gewoon refreshen, bookmarken, e.d.

Echter is het wel makkelijker om met een SPA dit soort fouten te maken.

Hierin geef ik je wel 100% gelijk.

[Hiroj]

Ik zou je NuxtJS willen aanbevelen. Dit is een framework gebouwd boven op VueJS (ja, framework bovenop een framework), waarbij je zowel MPA als SPA kan ontwikkelen.

Daarnaast maakt NuxtJS het je erg makkelijk om SEO te implementeren!

[gitaarwerk]

Is iets waar wij ook vaak tegenaal lopen. Het begint allemaal makkelijk. Maar zodra je resources wilt fetchen bij iedere route bijna... dan denk ik dat je beter een MPA kunt blijven. Je zou kunnen kiezen om kleine mini applicaties te maken. Maar ligt compleet aan je wensen.

Imho. Routes + different resource = MPA.

[ Voor 9% gewijzigd door gitaarwerk op 27-06-2018 09:55 ]

[ikvanwinsum]

Bedankt voor jullie input. De applicatie die ik maak is voor een vereniging, dus tools zoals Hotjar zal ik niet gaan gebruiken. Het is wel een hele grote applicatie (ik heb nu al honderden routes), dus ik denk dat ik voorlopig bij een MPA blijf, en eventueel later onderdelen omzet naar een SPA applicatie.

[mcDavid]

Ik zou een aantal van de voordelen van je SPA willen weerleggen:

1) beter gescheiden frontend en backend
True, maar dat gaat alleen op als je html echt 100% statisch is. Anders zit je alsnog met twig en heb je ineens je templates over 2 plekken verspreid, twig en JS. Daarnaast heb ik nog nooit een chille manier gevonden om in JS templates te parsen (ben dan ook geen frontender maargoed). Twig zou het wmb winnen.
2) Api is makkelijk te hergebruiken
Dit is geen voordeel van een SPA. Dit is een voordeel van een goedwerkende API. Die goedwerkende API zou voor een MPA net zou bruikbaar zijn.
3) Vaak sneller
Is dat echt zo? Browsers kunnen HTML razendsnel parsen. Dom manipulaties zijn vaak trager. Ook heb je (vooral bij statische content) minder voordeel van caching. Ik heb geen voorbeelden/cijfers bij de hand maar ik denk niet dat je het hiervoor zou moeten doen. Dat beetje extra data dat over de lijn moet is zelden de grootste bottleneck.
4) werkt vaak mooier
Sja dat is heel erg afhankelijk van de implementatie. Zoals al meer aangehaald, je moet echt je best doen om je applicatie dezelfde basisfunctionaliteit te geven die een MPA al out-of-the-box heeft, dankzij eeuwenoud beproeft browsergedrag. Er zijn erg veel pitfalls. Gevolg is dat in de praktijk de meeste implementaties tegenvallen. Ga bij jezelf te rade of je de kennis en (vooral) tijd hebt om jouw applicatie dusdanig goed aan te pakken dat je dit daadwerkelijk kunt bewerkstelligen.

Als ik zelf deze keuze zou moeten maken zou ik het anders benaderen. Wat wil je bewerkstelligen en in hoeverre leent een SPA zich daarvoor? Een aantal mooie voorbeelden van SPA's zijn bijv. google docs, draw.io, telegram web, etc. Die hebben allemaal goeie functionele redenen om voor een SPA te kiezen, het is gewoon het meest praktisch of zelfs de enige mogelijkheid. Hoe ze front- en backend code zouden scheiden is echt geen argument geweest voor die applicaties.