Products

Solutions

Resources

Partners

Community

About

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.


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 

Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 600 DNN projects since 1999. He is also chief architect of 2sxc (2SexyContent - see forge), an open source module for creating attractive content and DNN Apps.

Comments

Rodney Joyce
Agree completely.

I am using pure Angular hitting a DnnApi for all my latest mobile apps and we apps.

My latest app (a rewrite of the poker leagues module) on PokerDIY uses Angular and Breeze. The amount of server side code I have to write is tiny... And the end user experience is far better. Now I am waiting patiently for dnn 8 so I can embed an Spa in my dnn site. At this point I will be rewriting the User Profile modules etc to make a much better user experience than the dated Dnn default modules. If that fails I am moving off Dnn ;) Sneak peak at new league module: http://pokergamemanager.azurewebsites.net/#/
Rodney Joyce Tuesday, May 26, 2015 5:51 PM (link)

Comment Form

Only registered users may post comments.

NewsArchives


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out