You should use traditional web applications when:
You should use a SPA when:
Additionally, SPA frameworks require greater architectural and security expertise. They experience greater churn due to frequent updates and new frameworks than traditional web applications. Configuring automated build and deployment processes and utilizing deployment options like containers are more difficult with SPA applications than traditional web apps.
Improvements in user experience made possible by the SPA model must be weighed against these considerations.
ASP.NET Core (2.0+) ships several web application templates that are available from Visual Studio or the dotnet CLI which can be used to get started building traditional or SPA-style applications. These are just a few of the templates that are shipped and these are just starting points. You may find useful 3rd party and open source templates or create your own:
The recommended approach for many traditional applications is Razor Pages, which offer the same architectural advantages of ASP.NET Core MVC, but with fewer files and folders. You can also choose the MVC template, which will be very familiar to developers with experience using ASP.NET MVC or ASP.NET Core MVC 1.x. If you don’t require any server-side rendering of pages or views, you can use the Web API template, and create your application using static files that use JavaScript to call your API methods. The eShopOnWeb sample application includes two web projects, demonstrating both MVC and Razor Pages approaches to organizing the UI project. It’s important to point out that Razor Pages is a page-based model that builds on top of the MVC Model. You can add more Pages OR more Controllers for either HTML or Web APIs and mix and match as you like.
You’ll find built-in templates for Angular as well as React and Redux to help you get started building a SPA. These templates set up the necessary files and client-side build tools to allow you to get started quickly. These templates use npm (node package manager) to install their client-side dependencies.
Figure 3-1. Installing the Angular project template from dotnet CLI.
Make sure you have the latest version of nodejs installed, then build and run the app (dotnet run from the command prompt).
Figure 3-2. Running the Angular project template from dotnet CLI.
The angular template provides a simple SPA that includes navigation and routing and examples of implementing client-side and server-side behavior.
Figure 3-3. The Angular SPA in the browser.
The following is a more detailed explanation of the previously-stated reasons for picking traditional web applications.
Your application has simple, possibly read-only, client-side requirements
Many web applications are primarily consumed in a read-only fashion by the vast majority of their users. Read-only (or read-mostly) applications tend to be much simpler than those that maintain and manipulate a great deal of state. For example, a search engine might consist of a single entry point with a textbox and a second page for displaying search results. Anonymous users can easily make requests, and there is little need for client-side logic. Likewise, a blog or content management system’s public-facing application usually consists mainly of content with little client-side behavior. Such applications are easily built as traditional server-based web applications which perform logic on the web server and render HTML to be displayed in the browser. The fact that each unique page of the site has its own URL that can be bookmarked and indexed by search engines (by default, without having to add this as a separate feature of the application) is also a clear benefit in such scenarios.
Your application needs to function in browsers without JavaScript support
Web applications that need to function in browsers with limited or no JavaScript support should be written using traditional web app workflows (or at least be able to fall back to such behavior). SPAs require client-side JavaScript in order to function; if it’s not available, SPAs are not a good choice.
Your team is unfamiliar with JavaScript or TypeScript development techniques
If your team is unfamiliar with JavaScript or TypeScript but is familiar with server-side web application development, then they will probably be able to deliver a traditional web app more quickly than a SPA. Unless learning to program SPAs is a goal, or the user experience afforded by a SPA is required, traditional web apps are a more productive choice for teams who are already familiar with building them.
The following is a more detailed explanation of when to choose a Single Page Applications style of development for your web app.
Your application must expose a rich user interface with many features
SPAs can support rich client-side functionality that doesn’t require reloading the page as users take actions or navigate between areas of the app. SPAs can load more quickly, fetching data in the background, and individual user actions are more responsive since full page reloads are rare. SPAs can support incremental updates, saving partially completed forms or documents without the user having to click a button to submit a form. SPAs can support rich client-side behaviors, such as drag-and-drop, much more readily than traditional applications. SPAs can be designed to run in a disconnected mode, making updates to a client-side model that are eventually synchronized back to the server once a connection is re-established. You should choose a SPA style application if your app’s requirements include rich functionality that goes beyond what typical HTML forms offer.
Note that frequently SPAs need to implement features that are built-in to traditional web apps, such as displaying a meaningful URL in the address bar reflecting the current operation (and allowing users to bookmark or deep link to this URL to return to it). SPAs also should allow users to use the browser’s back and forward buttons with results that won’t surprise them.
Your team is familiar with JavaScript and/or TypeScript development
Writing SPAs requires familiarity with JavaScript and/or TypeScript and client-side programming techniques and libraries. Your team should be competent in writing modern JavaScript using a SPA framework like Angular.
Your application must already expose an API for other (internal or public) clients
If you’re already supporting a web API for use by other clients, it may require less effort to create a SPA implementation that leverages these APIs rather than reproducing the logic in server-side form. SPAs make extensive use of web APIs to query and update data as users interact with the application.
The following decision table summarizes some of the basic factors to consider when choosing between a traditional web application and a SPA.
