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.


The Future of DNN Speaks Razor - #5 - WebAPI is great for Apps but not for Content

So I hope you're read my previous posts why you should migrate to Razor ASAP, what it is and why WebForms and ASP.net MVC are all dead. In my 5th Post of my series The Future of DNN Speaks Razor I would like to delve into WebAPI, why It's awesome (especially for Apps) and why JSON-data is the future - especially combined with AngularJS or similar frameworks.

The Future of Web Apps is JSON, AngularJS and More

Think about the "cool" UIs you see today, like a powerful mail client (Google, Outlook), a neat game, a stylish business UI. All of them have in common, that the entire View is client rendered typically using AngularJS, knockoutJS or Kendo.

 

From what I can tell, this trend is unstoppable. Meaning: in a very short time, there will be loads of people that master these tools/technologies and will produce awesome web-apps and SPA-solutions - making others want to do the same. This causes a self-reinforcing loop practically eliminating all alternatives. I'm convinced that for such applications, all server-attempts to do the same will simply fail.

The Server Is Becoming What it Used To Be: A Data Backend.

But it does leave some very important jobs for the server to perform - and the better the server is at these jobs, the more successful the platform. Thank God & Gates that Microsoft figured this out just in time - and introduced ASP.net WebAPI.

I Love ASP.net WebAPI…

Probably the best thing since WebForms (or for the more progressive: since MVC) is WebAPI. And yes: it's part of MVC, but you must admit that it has nothing to do with the view generation. It's a very simple technology (embracing current web architectures) to degrade the function of the web server to simply exchange data! That's right: no focus on "we create the best HTML" or anything like that. Simply data input and output through JSON.

For web applications and SPAs (Single Page Applications) it's the way to go. When you have custom data (say a list of users) for your application to manage, the way today is to create an SPA, some interfaces and voila! The choice of server is not important for such an application - because everything happens in the client.

The Ideal solution for Admin-UIs and Data Consumption

Almost all data-manipulation Apps of the future will be based on a JavaScript-Framework + JSON combination - it's just a question of time. Here's an example of a ASP.net MVC-oriented CMS, which dumped the MVC-approach and is now employing an AngularJS backend :). I'm hoping DNN 8 will be similar - but the signs are good :)

Data consumption has a similar need: fast, quick working with data. Here's a screenshot of a help-application we created on DNN/Evoq for Ricardo using knockoutJS early 2012:

It's rather complex with many views and even though it's a JSON/JavaScript App, it's SEO optimized with Hashbangs.

Later we choose to focus on AngularJS - here a simple responsive References-App based on Angular:

The question knockoutJS vs. AngularJS is a great discussion for another post (anybody?) but spoiler alert: AngularJS wins.

…but WebAPI is not ideal for Content Presentation…

Ok, I'm getting ahead of myself. ASP.net WebAPI is great for data input/output. It's main strength is that I can give it a typed object (anonymously typed is also ok) and it will take care of the interface to HTTP/JSON etc. in both ways (in and out)

That's perfect for applications.

It's great for searching and list-filtering.

It's not very helpful for normal content.

It's terrible for SEO.

Data input/output is mainly relevant for management-applications and for application-style consumption (searches, lists, details).

But normal web content is 1% editing, sometimes data-consumption (list, search, filter) and between 70 and 95% content presentation & consumption. Content-consumption is usually focused on visually appealing content like a page showing the team of a company. This kind of content is usually highly customized for every customer and page page - and must be HTML-based for search engines. Not exactly your data input/output scenario…

…for which we need Razor!

In general, a piece of original content which should look good, be responsive and unique is usually placed on a specific page by an editor, edited there (and only there). It must be delivered as HTML - in pre-designed templates.

And for this the perfect solution is Razor! It's super easy to create perfect HTML-templates, it leaves responsiveness in the hand of the browser (with CSS and JavaScript) and it's focused on exactly 1 mission: perfect HTML-output, without nasty WebForms objectIDs, without ViewStates, without Postbacks :)!

Convinced?

I hope you also believe that the future lies in perfectly controlled HTML, in JavaScript frameworks and in JSON data-delivery. Either way - please give feedback! In IMHO the way to go is Razor, AngularJS and WebAPI (or some module specific JSON interface). Again - please tell me what you think…

…because then I'll continue with some getting-started helps posts :)

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.

 

PS: Want to get started before the entire Razor-series is out? For the impatient, try the DNN-Razor Host Module and watch this video  or try packaged code apps by installing 2sxc and some of the Razor Apps like the Razor Basic TutorialsList-Tutorials or the SQL and Peta-Poco Tutorials

 

Comments

Robert Fulop
Sounds good Dan!
Robert Fulop Tuesday, September 2, 2014 9:58 PM (link)
Erik Hinds
So I guess my question is why use razor as opposed to standard html views in an angular js app?
Erik Hinds Monday, September 8, 2014 11:45 AM (link)
Daniel Mettler
@erik
For many applications the html/js approach will be the correct way to go. Yet it's not the whole story:
1. I think of applications as a tool that does something - very similar to a module or a set of modules. They work as a standalone functionality - but they must be integrated into something larger. This could be the layout, the design, usually the platform or CMS or whatever, that also hosts many other applications....
2. Not everything can be done client side - there are limits based on current technology and other parameters. Technology used to force us to render charts on the server, that has passed. But technology still limits us in many other ways - say to generate an XML or a thumbnail or to save data etc. But yes, for Apps, the server is becoming more and more irrelevant...
3. Content doesn't work that way. It needs a semantic xml/html wrapper. For this, the server is extremely important - and the technology in use affects productivity. This is where Razor shines :)

Love from Switzerland,
Daniel
Daniel Mettler Monday, September 8, 2014 3:11 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