Use Cases

In case you're wondering what problem does Vite.NET solve, this page is meant to give an answer to that. This library, though simple, offers flexibility to achieve things that aren't exactly obvious with the traditional way that SPAs are used in the ASP.NET Core space.

Allowing an MPA - SPA hybrid with modern UI composition ideas

Just like SvelteKit, NextJS and other meta-frameworks in the Node space have proven, the approach of hybridizing UI rendering in web applications offers a lot of freedom and choice of tradeoffs when building web apps.

I highly recommend watching this talk by Rich Harris, as it expounds the case for hybrid UI much better than I can in a few sentences.

But if you need a TLDW, then the main idea is that making everything a Single Page Application is a bad idea, but we can still enjoy some of the benefits of SPAs by hybridizing our UI composition when needed. Vite.NET is a step in that direction.

Improving SEO for a SPA

This is the easiest to understand benefit of hybridizing UI composition. SPAs are terrible at SEO, and no matter what improvements the crawlers get to become better at getting SEO from SPAs, they will always be inferior to simply crawling static or server rendered HTML.

By allowing you to discard the traditional index.html entry point file, you can have server-side/dynamic control of your meta tags in order to improve SEO with meta tags. This is particularly useful in cases where you need to allow social media link previewing in Facebook, Instagram, Twitter, WhatsApp or any platform that follows link previewing protocols.

Simplifying authorization in SPAs

Proper SPA authentication is hard. The most secure way to secure a SPA is to use OpenID Connect, which is a very solid protocol, but it is also very complex. As a successor protocol to OAuth2, it's made for all kinds of client-server interactions, it requires an identity provider server and understanding all of its authentication flows is not trivial.

The alternative to this complex, yet solid approach is the simple, yet flawed idea of authenticating with a JWT. It isn't that it doesn't work, JWTs definitely do work for this purpose, but they can, when implemented incorrectly (which will happen much more often than anyone would like) expose your application to XSS attacks and you don't even have a reliable way of revoking a session or extending it for multiple days.

Then, if you try to add a refresh token in order to provide better UX, you are begging to be hacked in a very easy way, and even though you will get warnings of this in the internet, you'll see just as many posts of people advocating for this as a solution.

Server rendered MPAs have no need for OIDC because HTTP only cookies are a secure and easy to implement security measure that allows sliding expiration without compromising security, but also keeping the implementation simple.

What Vite.NET offers in this sense is a great simplification of authentication and authorization in SPAs by simply letting you do what you always did, just use your normal scaffolded authentication code and expand from there, no need to have your SPA become more complex for a problem that is easier to solve on the server anyways.

Here you can find an example of a simple implementation with a simple ASP.NET Core Identity template.

Simplifying complexity and implementing Micro Front Ends

Organizing SPAs for scalability is hard. Writing a simple To-do list app is easy enough in any framework, but before long, and as applications grow in size and scope, all apps have to deal with state, communication between components, routing, when to make components or functions reusable and when to ignore the DRY principle among other things.

While there are good approaches to deal with complexity in SPAs, there's a lot of opinions and there is often a lot of variability in what makes sense for a SPA depending on its size, domain boundaries and other variables.

And here is where the use case comes. There can be scenarios where having multiple SPAs, hosted in a single server and sharing styles (or not) can be a proper technique for diffusing complexity in growing applications.

Smaller Single Page Applications are easier to maintain than bigger ones, since there are very clear domain boundaries that don't get crossed as easily, creating a mess in the long term. Ultimately, this is also one of the principles that drive the existence of micro front ends and module federation, this is just a different way of implementing it.

You can find an example of how that would look here.