I recently finished a project which contains more than 30 different pages/features. Each one with some CRUD and more subpages. Each page is totally different from another in purpose. All of it was made using ASP.NET MVC Core and some Ajax for querying some rendered views.

Today I'm starting a new project that will be similar to that one in complexity. I would like to start with some SPA framework like Angular4 or React. However I do have some options:

  1. Make a giant SPA that will contain all the 30 different pages/features and all sub pages and use the Server site only for REST queries. (a giant SPA)

  2. Make a regular MVC server Application and use Angular or React just in some of then when needed. a loto of smaller self contained app. (a lot of mini SPA)

  3. forget about SPA.

When I look at some popular applications like YouTube, Facebook or even Stack Exchange (that is also built in ASP.NET MVC), I notice that it looks like they're using the 2nd option. Each page is a kind of rich SPA. when I click into a link, like settings or profile, it loads the DOM from server and all interaction is made using restfull queries.

I would like to know about another experienced web developers. What option is better?


  • 3
    Option 2 does kinda make sense, when you think about it. The web has always been all about pages. SPA frontends are favored over server-side pages (your third option) because they provide better user interactivity and modularity. Giant SPA feels more like old-school client/server. Mini-SPA has all the benefits of client-side interaction without losing the advantages of server-side pages. Oct 24, 2017 at 18:17
  • I totally agree. The web is made of a lot pages and some of them are SPA. Why an application cannot be it to. Oct 24, 2017 at 18:23
  • But it didn't got your point when you said that "Giant SPA feels more like old-school client/server" Oct 24, 2017 at 18:23
  • 2
    Imagine a desktop Windows application where you have a connection to a SQL database (server) and all the logic is on the client. Now imagine a giant SPA where you have a connection to a web service (server) and all of your logic is on the client. Oct 24, 2017 at 18:32
  • 3
    It depends on your requirements. For example if you need to use the client code in both a web browser, an Electron-based app, and a Cordova-based app, then you might consider option 1 or something like it. I think you have a slightly false dichotomy there-- I think you can maintain separation between the front-end and back-end, but not have the entire app in a single Angular/React codebase. Oct 24, 2017 at 19:52

1 Answer 1


After reading articles like “What should be in a Single Page Application?” and much others I’m pretty convinced that build a very large spa (even with lazy loading) is not good a solution for big systems with different areas.

The real reason one large SPA is wrong is because of coupling. If you build your whole application as a SPA then everything is coupled together. Making a small change in one obscure part of your application could have a global effect. With different pages the chance of an accidental global change is much smaller. It can only happen if the code is actually loaded on another page.


What that means in practice is that you split your application into functional parts. Just suppose for a moment you are building a large sales application. Then you probably need to build a customer management piece. There will also be an article management part. There will be an order entry part and finally there will be an order fulfillment part of the application. In reality there will be more but as an example these four are enough. These four are quite distinct, each has it’s own job to do and end users will not likely switch between them all the time to get their job done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.