Kiezen tussen traditionele web-apps en apps met één pagina (SPA's)

"Atwood's Law: Elke toepassing die kan worden geschreven in JavaScript, wordt uiteindelijk geschreven in JavaScript."
- Jeff Atwood

Er zijn momenteel twee algemene benaderingen voor het bouwen van webtoepassingen: traditionele webtoepassingen die de meeste toepassingslogica op de server uitvoeren en toepassingen met één pagina (SPA's) die de meeste logica van de gebruikersinterface uitvoeren in een webbrowser, die voornamelijk communiceren met de webserver met behulp van web-API's. Een hybride benadering is ook mogelijk, waarbij de eenvoudigste manier is om een of meer uitgebreide SPA-achtige subtoepassingen binnen een grotere traditionele webtoepassing te hosten.

Gebruik traditionele webtoepassingen wanneer:

• De vereisten aan de clientzijde van uw toepassing zijn eenvoudig of zelfs uitsluitend lezen.

• Uw toepassing moet functioneren in browsers zonder JavaScript-ondersteuning.

• Uw toepassing is openbaar en profiteert van zoekprogrammadetectie en verwijzingen.

Gebruik een SPA wanneer:

• Uw toepassing moet een uitgebreide gebruikersinterface met veel functies beschikbaar maken.

• Uw team is bekend met JavaScript, TypeScript of BlazorWebAssembly ontwikkeling.

• Uw toepassing moet al een API beschikbaar maken voor andere (interne of openbare) clients.

Daarnaast vereisen SPA-frameworks meer expertise op het gebied van architectuur en beveiliging. Ze ervaren meer verloop vanwege frequente updates en nieuwe clientframeworks dan traditionele webtoepassingen. Het configureren van geautomatiseerde build- en implementatieprocessen en het gebruik van implementatieopties zoals containers kan lastiger zijn met SPA-applicaties dan met traditionele web-apps.

Verbeteringen in de gebruikerservaring die mogelijk worden gemaakt door de SPA-benadering moeten worden afgewogen tegen deze overwegingen.

Blazor

ASP.NET Core bevat een model voor het bouwen van uitgebreide, interactieve en composeerbare gebruikersinterfaces met de naam Blazor. Blazor Aan de serverzijde kunnen ontwikkelaars met C# en Razor op de server een gebruikersinterface bouwen, waarbij de gebruikersinterface interactief en in realtime met de browser verbonden wordt via een permanente SignalR-verbinding. Blazor WebAssembly introduceert een andere optie voor Blazor apps, zodat ze in de browser kunnen worden uitgevoerd met behulp van WebAssembly. Omdat het echte .NET-code is die draait op WebAssembly, kunt u code en bibliotheken hergebruiken vanuit server-side delen van uw toepassing.

Blazor biedt een nieuwe, derde optie om te overwegen bij het evalueren of u een puur server-gerenderde webapplicatie of een single-page application wilt bouwen. U kunt rijke, SPA-achtige clientzijdegedragingen bouwen met behulp van Blazor, zonder dat er aanzienlijke JavaScript-ontwikkeling nodig is. Blazor toepassingen kunnen API's aanroepen om gegevens aan te vragen of bewerkingen aan de serverzijde uit te voeren. Ze kunnen waar nodig samenwerken met JavaScript om te profiteren van JavaScript-bibliotheken en -frameworks.

Overweeg om uw webtoepassing te bouwen met Blazor wanneer:

• Uw toepassing moet een uitgebreide gebruikersinterface beschikbaar maken

• Uw team is comfortabeler met .NET-ontwikkeling dan JavaScript- of TypeScript-ontwikkeling

Als u een bestaande webformuliertoepassing hebt die u overweegt te migreren naar .NET Core of het nieuwste .NET, kunt u het gratis e-book Blazor bekijken voor webformulierontwikkelaars om te zien of het zinvol is om het te migreren naar Blazor.

Zie Blazorvoor meer informatie over Blazor.

Wanneer kiest u traditionele web-apps?

De volgende sectie is een gedetailleerdere uitleg van de eerder genoemde redenen voor het kiezen van traditionele webtoepassingen.

Uw toepassing heeft eenvoudige vereisten aan de clientzijde die mogelijk alleen voor lezen zijn

Veel webtoepassingen worden voornamelijk op een alleen-lezen manier gebruikt door de overgrote meerderheid van hun gebruikers. Toepassingen met het kenmerk Alleen-lezen (of meestal lezen) zijn meestal veel eenvoudiger dan toepassingen die een groot aantal statussen onderhouden en manipuleren. Een zoekmachine kan bijvoorbeeld bestaan uit één toegangspunt met een tekstvak en een tweede pagina voor het weergeven van zoekresultaten. Anonieme gebruikers kunnen eenvoudig aanvragen indienen en er is weinig behoefte aan logica aan de clientzijde. Op dezelfde manier bestaat de openbare toepassing van een blog- of inhoudsbeheersysteem meestal voornamelijk uit inhoud met weinig gedrag aan de clientzijde. Dergelijke toepassingen zijn eenvoudig gebouwd als traditionele servergebaseerde webtoepassingen, die logica uitvoeren op de webserver en HTML weergeven die in de browser moet worden weergegeven. Het feit dat elke unieke pagina van de site een eigen URL heeft die kan worden gewijzerd en geïndexeerd door zoekmachines (standaard zonder deze functionaliteit als een afzonderlijke functie van de toepassing toe te voegen) is ook een duidelijk voordeel in dergelijke scenario's.

Uw toepassing moet functioneren in browsers zonder JavaScript-ondersteuning

Webtoepassingen die moeten functioneren in browsers met beperkte of geen JavaScript-ondersteuning, moeten worden geschreven met traditionele web-app-werkstromen (of ten minste kunnen terugvallen op dergelijk gedrag). SPA's vereisen JavaScript aan de clientzijde om te kunnen functioneren; als deze niet beschikbaar is, zijn SPA's geen goede keuze.

Uw team is niet bekend met JavaScript- of TypeScript-ontwikkeltechnieken

Als uw team niet bekend is met JavaScript of TypeScript, maar wel met de ontwikkeling van server-side webapplicaties, kunnen ze waarschijnlijk sneller een traditionele webapplicatie leveren dan een single-page application. Tenzij het leren programmeren van SPA's een doel is, of de gebruikerservaring die een SPA biedt vereist is, zijn traditionele web-apps een productievere keuze voor teams die al bekend zijn met het bouwen van dergelijke applicaties.

Wanneer moet u SPA's kiezen

In de volgende sectie vindt u een gedetailleerdere uitleg wanneer u een ontwikkelstijl voor één pagina kiest voor uw web-app.

Uw toepassing moet een uitgebreide gebruikersinterface met veel functies beschikbaar maken

SPA's kunnen uitgebreide functionaliteit aan de clientzijde ondersteunen waarvoor de pagina niet opnieuw hoeft te worden geladen wanneer gebruikers acties ondernemen of navigeren tussen gebieden van de app. SPA's kunnen sneller laden, gegevens op de achtergrond ophalen en afzonderlijke gebruikersacties reageren sneller omdat het laden van volledige pagina's zeldzaam is. SPA's kunnen incrementele updates ondersteunen, gedeeltelijk ingevulde formulieren of documenten opslaan zonder dat de gebruiker op een knop hoeft te klikken om een formulier in te dienen. SPA's kunnen uitgebreid gedrag aan de clientzijde ondersteunen, zoals slepen en neerzetten, veel gemakkelijker dan traditionele toepassingen. SPA's kunnen worden ontworpen om te worden uitgevoerd in een niet-verbonden modus, waardoor updates worden uitgevoerd voor een model aan de clientzijde dat uiteindelijk wordt gesynchroniseerd met de server zodra een verbinding opnieuw tot stand is gebracht. Kies een SPA-stijl applicatie als de vereisten van uw app uitgebreide functionaliteit bevatten die verder gaat dan wat typische HTML-formulieren bieden.

Vaak moeten SPA's functies implementeren die zijn ingebouwd in traditionele web-apps, zoals het weergeven van een zinvolle URL in de adresbalk die de huidige bewerking weergeeft (en gebruikers in staat stellen een bladwijzer of dieptekoppeling naar deze URL terug te zetten). Met SPA's kunnen gebruikers ook de knoppen terug en vooruit van de browser gebruiken met resultaten die hen niet verrassen.

Uw team is bekend met javaScript- en/of TypeScript-ontwikkeling

Het schrijven van SPA's vereist bekendheid met JavaScript en/of TypeScript en programmeertechnieken en bibliotheken aan de clientzijde. Uw team moet bekwaam zijn in het schrijven van modern JavaScript gebruikmakend van een SPA-framework zoals Angular.

Verwijzingen – SPA-raamwerken

• Angular: https://angular.io
• React: https://reactjs.org/
• Vue.js: https://vuejs.org/

Uw toepassing moet al een API beschikbaar maken voor andere (interne of openbare) clients

Als u al een web-API ondersteunt voor gebruik door andere clients, kan het minder moeite kosten om een SPA-implementatie te maken die gebruikmaakt van deze web-API's in plaats van de logica in server-side vorm te reproduceren. SPA's maken uitgebreid gebruik van web-API's om gegevens op te vragen en bij te werken wanneer gebruikers met de toepassing werken.

Wanneer moet u kiezen Blazor

De volgende sectie is een gedetailleerdere uitleg van wanneer u Blazor kiest voor uw web-app.

Uw toepassing moet een uitgebreide gebruikersinterface beschikbaar maken

Net als op JavaScript gebaseerde SPA's Blazor kunnen toepassingen ondersteuning bieden voor uitgebreid clientgedrag zonder pagina's opnieuw te laden. Deze toepassingen reageren meer op gebruikers, waarbij alleen de gegevens (of HTML) worden opgehaald die nodig zijn om te reageren op een bepaalde gebruikersinteractie. Correct ontworpen, kunnen apps aan de serverzijde Blazor worden geconfigureerd om te worden uitgevoerd als apps aan de clientzijde Blazor met minimale wijzigingen zodra deze functie wordt ondersteund.

Uw team is comfortabeler met .NET-ontwikkeling dan JavaScript- of TypeScript-ontwikkeling

Veel ontwikkelaars zijn productiever met .NET en Razor dan met talen aan de clientzijde, zoals JavaScript of TypeScript. Omdat de serverzijde van de toepassing al met .NET wordt ontwikkeld, zorgt het gebruik ervan Blazor ervoor dat elke .NET-ontwikkelaar van het team het gedrag van de front-end van de toepassing kan begrijpen en mogelijk kan bouwen.

Beslissingstabel

De volgende beslissingstabel bevat een overzicht van enkele basisfactoren die u moet overwegen bij het kiezen tussen een traditionele webtoepassing, een enkele pagina applicatie of een Blazor app.

Andere overwegingen

Traditionele Web Apps zijn meestal eenvoudiger en hebben betere SEO-criteria (Search Engine Optimization) dan SPA-apps. Bots van zoekmachines kunnen eenvoudig inhoud van traditionele apps gebruiken, terwijl ondersteuning voor het indexeren van SPA's mogelijk ontbreekt of beperkt is. Als uw app profiteert van openbare detectie door zoekmachines, is dit vaak een belangrijke overweging.

Tenzij u een beheerhulpmiddel voor de inhoud van uw single page application heeft gebouwd, kan het nodig zijn dat ontwikkelaars wijzigingen aanbrengen. Traditionele Web Apps zijn vaak eenvoudiger voor niet-ontwikkelaars om wijzigingen aan te brengen, omdat veel van de inhoud gewoon HTML is en mogelijk geen buildproces nodig heeft om een preview- of zelfs implementatieproces uit te voeren. Als niet-ontwikkelaars in uw organisatie waarschijnlijk de inhoud van de app moeten behouden, is een traditionele web-app mogelijk een betere keuze.

SPA's komen tot hun recht wanneer de app complexe interactieve formulieren of andere interactieve functies heeft. Voor complexe apps waarvoor verificatie is vereist en die dus niet toegankelijk zijn voor openbare zoekprogramma's, zijn SPA's in veel gevallen een uitstekende optie.