Do we need MVC on the Server when Google indexes JavaScript?

Google processes JavaScript ( see blog post here). So yes: when you create a cool app using knockoutJS, AngularJS or any other JS framework you can still rank top spots in Google. As Adam Audette put it "It should be noted that this type of functionality by Google explains how sites built using the AngularJS framework and the HTML5 History API (pushState) can be rendered and indexed by Google, ranking as well as conventional static HTML pages.". 

Why is this important? Because ASP.net WebForms is dead! And with this, the alternative ASP.net MVC may become irrelevant. Yes, there will be a new version - and it will be better than WebForms. But...

We have to develop today for the future

Right now we (2sic) are working on various projects on DNN and SharePoint - and all these projects have one thing in common: All of them run on "old" technologies which are officially dead (ASP.net WebForms). But when our customers pay thousands of $$$ to do something then I want to guarantee that the money isn't wasted. The only way I can do this is to develop something that works on WebForms AND MVC. 

And this basically means: I don't really rely on server HTML-assembly capabilities. Neither in SharePoint nor in DNN. Because if I do use server-html-rendering, then I cannot guarantee an upgrade in 2 years time.

Is it better to use ASP MVC? Maybe. The way ASP.net is evolving (.net core etc.) I can guarantee that Razor is here to stay, and WebAPI as well. My very personal opinion is:

1. WebAPI will stay and become the cornerstone of all web development
2. Razor will stay and be the primary server-side html-rendering to deliver the basic page
3. DNN-Tokens will stay and be the preferred server-side-html rendering because it's safe (no code injection, no security breaches)
4. Server-Side-MVC (so the concept of handling HTML-Rendering and Click-processing on the server) will become a rare use-case. The core weakness is the user interaction handling which just doesn't make sense on the server (slow, messy, hard to develop, hard to test, uncool, not portable to other systems) - and when you stop handling clicks on the server, then much of MVC becomes irrelevant. 

IMHO this is how it must work in the Future

There are basically two types of applications/modules in a CMS. Output-oriented Apps (to display content to users) and data-changing Apps (where users interact with the content to change data in a database behind the CMS). We'll start with the more complex: the apps with user-interactions:

1. Principle 1: All applications / modules which require user interaction will run in JavaScript, be quick and elegant and communicate with the Server through WebAPI. This is the only cool way to do it - anything that requires page reloads is just soooo 1990 and feels unprofessional in today's world. 
2. Principle 2: When you obey Principle 1 and handle all clicks, user-actions, info-messages and view-changes on the client, then you will also do most of the HTML-buildup in the client because it's easier to develop. The old mix where server-code generates many parts of the HTML and then tries mixing it with JavaScript was terrible, confusing, required too much know-how and never really scaled well. Think of all the clunky ID-generation issues where the server tried to create unique id-attributes in HTML so that JavaScript could then work with it - it was nasty. Such issues become trivial when all the HTML is already starts as a knockoutJS or AngularJS (or any other framework) template. 
3. Principle 3: If we assume that the Principles 1 and 2 are correct (and I would love to hear opposing views with good reasons contradict me) - then the entire UI will be built on the client. The only thing the server actually has left do to is
   1. Provide a clear WebAPI - in most cases this will be a generic REST API which will not require any coding
   2. Provide a data-storage and caching system - in most cases this will be generic and not require coding (like SharePoint or 2sxc)
   3. Provide a custom query system - either based on a REST-like schema (OData) or a configuration based Query Designer (I'm currently voting for the query designer because OData would pose difficult security challenges to only allow certain types of queries)
   4. Handle security related issues which cannot be delegated to a client - in most cases generic / configuration-based (no-code)
   5. Provide an initial context for the app to start with - for example DNN-Modules need a Module-Id, the correct scripts and some initial simple HTML

Assuming these 3 principles are correct (and nobody has managed to point out the flaws so far), then the server will just generate some initial state, parse simple HTML-templates, provide some data etc. - all generic actions which require simple templates but little or no code on the server. Based on these 3 principles, the act of supplying a Complex User-Interaction App becomes the same as supplying a Simple Content-Output-App. 

So let's look at the simple Content-Output-App: 

1. The server must retrieve some data (the content) and some state...
2. ...the parse it through a template to create some HTML

This can be done in ASP.net MVC - but why bother? It's such a generic, common use case that various systems give you the ability to do this without wasting time with writing data-layers and controllers. There will be 2-3 such generic system and these will cover 95% of all use cases. Foremost I would like to mention (our) Open-Source 2sxc, but others are also working on such solutions like Sasha with OpenContent + some for-pay-options in the DNN-Store. Maybe DNN will also provide such a framework in the near future. 

MVC as a Concept will Stay for all...

To be clear: the server will use MVC separation of concerns (SoC) meaning the separation of the data=model from the view=template and the controller=system-connecting-this. But I'm convinced that in 95% of all cases it the App-developer will only spend time on the View and get the Model and Controller for "free" from a tool like 2sxc or OpenContent. 

...Custom WebAPI will be needed in 10% of all cases

All Content-Output-Apps will not need WebAPI, and most input/output Apps will use generic REST. So in about 90% of all cases the developer will not write any server code at all, and in about 10% of the cases where normal REST doesn't suffice (for example 1. uploading files or 2. cases where extra security-checks are needed when updating parts of content-items or 3. when you want to run custom workflows on the server) then the developer will create some custom WebAPI. But this will be the exception, not the norm, and as the generic stack gets better, the need will become smaller. 

...Server-Side ASP MVC for Pages is only for 5%

Since probably 95% of all cases can work with a generic Model/Controller system for rendering HTML, then only some very exotic cases will actually need real ASP.net MVC as a page-generating system. Will an image-gallery need this? Nope. Job-listings or real-estate? Nope. Blog? Unlikely. FAQ? Not a chance. Line-of-Business-Apps? I don't think so. 

So at the moment I can't think of any real use cases for Server-Side MVC that I couldn't solve better with JavaScript/WebAPI. But I'm convinced that there are use cases for it - and I would love to hear which ones you think would apply. 

In another post I'll tell you more about how we learned these things developing for SharePoint, and how we transferred this learning to our DNN work. 

With love from Switzerland,
Daniel