Skip to content


moon indicating dark mode
sun indicating light mode

Reflection on ASP.NET Core, Vue multi page application project setup

February 04, 2021


In our company, we’ve been using a different ASP.NET Core MVC, Vue project setup.

It’s a multi-page application(MPA), where its each page can act like a SPA on its own.

Our intention was not to make each page a SPA, I said just because it’s a possibility.

All we wanted was to build user interfaces using Vue while getting the most out of that the ASP.NET Core MVC already provides, like routing, authentication, and access control.

Having contributed to the project setup and worked on two similar projects, I want to reflect on the pros, cons, and possible improvements in this approach.

My first experience with ASP. NET Core, Vue MPA

Two years before, I was tasked to set up Webpack to project. At that time, I was the only main developer.

The project was already set up as an ASP.NET Core MVC application. The project had Angular JS 1, jQuery as drop-in dependencies. Initially, I was assigned to refactor to replace those dependencies with Vue. I started using Vue as a drop-in dependency, loaded using CDN. Basically, I wrote the template(HTML) in razor views and component logic(computed, methods, etc.) in IIFEs. All styles were managed in a global CSS file without built-in minification, post CSS setup 😐.

Later, as time passed, we realized the need for a build system. Being a beginner developer, only having gone through some ASP.NET Core, Vue Pluralsight, Udemy courses, I found the task very challenging. In-fact almost all of the tutorials that I’ve gone through discussed ASP.NET Core as either Razor/MVC MPA or web API with a Vue/Angular/React SPA.

However, with some awesome Webpack courses from Pluralsight, Front End Masters 🙏, I managed to come up with a working setup 💪. In that setup, the majority of the content was rendered on the server-side using Razor. We used Vue for only components that needed reactivity. We didn’t have many reactive components in that project, also SEO is a key project requirement, so rendering most of the content on the server-side was a must. If I’m asked now, I would suggest using Gatsby instead, anyway, this was my first experience with an ASP.NET Core, Vue MPA setup.

My second experience with ASP.NET Core, Vue MPA

Six months later, I was assigned to a new project and asked to come up with a similar project setup. But this time SEO is not a concern at all. Considering the complexities in setting up the project I pinged our Technical Lead in chat asking why not a SPA.

Screenshot of question asked to the technical lead regarding why not SPA

Screenshot of reply from the technical lead

While the reply was convincing, picking SPA + API would be easier kind of feeling often came to me.

Later, we were told that we’ll be using the vue-core-ui-pro component library. So, unlike in the previous setup, this time all UI needs to live in Vue components. Using a component library is helpful for rapid development, and we don’t need SEO for this project, so moving all logic to Vue made sense to me. But still, why not SPA remained a mystery to me.

After two years, having contributed to the project setup and worked in two similar projects, I want to reflect the pros, cons and possible improvements in setting up ASP.NET Core, Vue as an MPA instead of SPA.


  1. Routing is super simple - we rely on ASP.NET Core’s built-in routing system which works out of the box by convention over configuration.
  2. Authorization/ access-control is super simple - again we rely on ASP.NET Core’s authorization middleware for this
  3. No need to always make API request to get initial data - we can set data to a javascript variable in the returned HTML during server-side rendering
  4. We have an option to render the layout in server side and use Vue only as necessary.
  5. Have more control over SEO.
  6. Want to use Vue in one page and Svelte in another page, no problem, we can do that.


  1. Setting up the project is not trivial
  2. Less documentation on this approach
  3. As the project grows, webpack-dev-server start time, HMR time increases
  4. Upgrading Webpack can be challenging
  5. Code duplication


  1. I haven’t tested this yet, but I think using Parcel/Snowpack would make things easier, I’ll try setting up the project using Parcel and share my experience in a separate post.

Final words

I quite like the ASP.NET Core, Vue MPA approach, and I prefer this approach over SPA for my pet projects as well.

In my next post I’ll share the codes and walk you through the code while answering the whats and whys.

This is my second blog post 🍻. Whenever I think about writing a blog, I doubt about my English skills, I worry if I have a good amount of knowledge on the topic, etc. This feeling often prevents me from writing. Nowadays, I have strictly decided to get along this feeling by writing more content.

Having said that there is a good chance I missed something, or you might have some similar experience to share. Feel free to comment and share your thoughts 😍.

👋 Hi! Welcome to my blog. I'm Kajan, a full-stack engineer focusing on JavaScript(Vue, React) and ASP.NET Core stack. I am thankful to the internet community for helping me out on various occasions 🙏😘. I hope to give back to the community by sharing my experience, and knowledge.