ASP.NET Core 2.0 Razor vs Angular/React/etc

I don't have benchmarks. But, I have several projects running JQuery, Razor, .NET MVC (C#), AJAX. Not to the scale you're tackling.

Advice.. Be sure to think things through and follow best practices. To keep things maintainable be sure to break controllers, views, model into smaller and meaningful groups. When I started, I made the mistake of putting everything into one Home controller, and a ton of views in the shared folder. Was fine at first but when feature creep began, it became a mess and difficult to go back and redesign.

I also use Linq2SQL. I made the mistake of creating models for everything and then realized I could just return the result set from my queries as a model. duh.

If you go .NET MVC and are concerned about performance, these are the things I ran into:

DON'T return partial views that create large blocks of HTML! Be sure to minimize everything. Get rid of all the white space. Use smaller ID names. Take the time to create html that is as light as possible. Return JSON and have the client do some of the work.

Be careful on how you develop your CSS. Don't use a bunch of inline styles, take the time to incorporate into CSS files that you can later minimize.

Same goes for your client side JS. It's tempting to put the JS inside partial views. Keep things organized.

Rendering on IE is horrible. Especially if there are lots of images. Be sure to compress images as much as possible, without losing quality of course.

We ended up going with an Angular front-end and an ASP.NET Core API backend, using Azure SQL. We tested Core Razor and, although better than legacy Razor, Angular was much faster for us in the end. As far as user experience goes, Angular (or React) is far superior in terms of performance. The model-binding aspects of Angular we found to be a gigantic advantage of server-side rendering. Using Razor(or server side rendering in general) does, however, lend itself to better overall integrity as far as data goes and it makes for a better transition of data from front-end to back-end. There is a true disconnect between a front-end framework and an API. All data that is passed to the server has to be cast into typed objects - this means you have to manage two separate POCO model sets. This can cause issues if server objects and front-end objects do not align. At the moment, Entity Framework Core is not very matured so we have issues with updating objects, querying objects, including child objects, etc.

Overall, this setup has worked out great for us so far! I would imagine React would be a similar replacement to Angular if you're more comfortable with it. I had to learn Angular, which was a very easy transition, and I love it now!

By using Angular/React with API on the server-side:

• you eliminate the process of generating HTML on server-side and you save CPU
• API produces a small payload (JSON) and Razor (HTML) of course would be much larger in size, the constant full page reloads, and postback round trip, so API and SPA save bandwidth
• API and SPA could have different versioning, scaling and deployment scenarios
• By using API you can support mobile app too and if you start with Razor you may need API in future

But by using Angular/React, you should be worried about clients:

• client must enable javascript
• client must have modern browsers
• client must have enough powerful hardware
• SEO