You can build your site Javascript, or you can have SEO.

When it comes to websites, simple is almost always better - even if it's not pretty. This is especially true if you care about search engine results.

Take this website, for example. It's gone over several iterations, mostly around picking a decent UI framework (currently Bulma). There's a little Javascript here and there, but we strive to keep it to a bare minimum - and we think that's a good thing.

Why? Because you're here reading this. This blog post is one of our most popular blog posts on our site. And we know you got to us almost entirely from a Google referral. We know this because SEO is our most important focus when building an external-facing web app.

So with these things in mind, feel free to take these opinions with a grain of salt.

I went through the Pluralsight training course Building a Website with React and ASP.NET Core a while back. It was a great course, and taught a lot about getting the two to work together. What struck me is how limited they are in their interactions together. Some takeaways:

• Server Side Rendering (SSR) is vital for Search Engine Optimization (SEO), a critical requirement for the web apps we're building for customers - and ourselves.
• React on the server does SSR, but so does ASP.NET. However, to get React to do SSR, you have to build the React server side infrastructure manually.
• ASP.NET's function for client and server side rendering is that of the API layer, and pretty much nothing else.
• You don't get SSR out of the box with the create-react-app, the amazing React starter kit tool. In fact, you pretty much have to 'break' CRA in order to get SSR to work, thereby making it pointless (more or less) to use CRA with your app.

For .NET developers looking to migrate, it doesn't appear that moving into React SSR gives you a lot of benefits - especially with all of the performance and scaling features and improvements in ASP.NET Core. Indeed - unless you were highly comfortable with 'full stack' NodeJS development, and security isn't a big requirement, I'd say there isn't much reason to move into it - on the server side, that is. For client-side features, it may be another story...You can also use the Gatsby static site generator for your React application, which does offer some SEO capabilities. But readability isn't a strong feature when peering into the source code of a React-driven application.

When to use ASP.NET

Use a good server-side rendering engine like ASP.NET Core when you want to build readable HTML in your web applications. Simple as that. Use it if SEO is important to you.

As it stands, SEO is critical for nearly every website out there - Search Engine Watch just published an article featuring a case study about a company that is estimated to lose over $8k/day in sales because they built a Javascript application instead of a SEO-friendly website. Because of this design decision, they're losing over $1.5 million per year in potential revenue because nobody's seeing their products. You don't need me to tell you that in today's economy, that's a very big deal.

When to use React or a Javascript Framework

Use these also when the user experience is the most important feature of your web app. Javascript application frameworks can create fast, responsive, aesthetically pleasing applications that feel more like native applications than 'regular' web applications rendered on the server.

There's no shortage of great JS frameworks - Vue, React, etc. are great choices. Svelte is one of our favorite frameworks at the moment - it's one of the smallest, fastest, developer-friendly frameworks out there.

You can have both if you know what you're doing

Google and other search engines are working on the ability to be able to deploy bots capable of reading the output of Javascript libraries; one workaround has been the inclusion of schema.org data objects in the HTML files containing the Javascript, so that's always an option as well.

At the end of the day, it boils down to a question of preference a ratio of technical skill over technical debt and your organization's pain tolerance in accordance with that ratio. There are large swaths of C# and developers. And while this was not intended to be an 'either C# or Javascript' debate, it warrants some careful consideration into one simple question:

Are we writing a maintainable, sustainable application that we'll be able to find ample, qualified resources for? We're obvious biased here, but it's because we think C# has a better reputation - and labor pool - than Javascript. I might have to revise this observation in five years, but then again - we might be living in a Flutter vs. Blazor world in the battle for the best WebAssembly applications, too.

Unsure of how to get started in your next big application? Looking for someone to bounce ideas off of? We're here to listen with a free consultation and competitive pricing!