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.

JS Rules! #2 - JS Modules / Apps are compatible across CMSes, Platforms and Versions!

This is part 2 of my short series JavaScript Rules! - make sure you have also read part 1 about the new WordPress architecture.

Let's start with an FAQ

  1. Q: Will JavaScript Apps work in DNN 6, 7 and 8?
    A: Yes!
  2. Q: Will JavaScript Apps work in the future neXt version of DNN, which won't be compatible to the current versions?
    A: Yes!
  3. Q: Will JavaScript Apps also work in Umbraco, Kentico, SiteFinity or SharePoint
    A: Yes!
  4. Q: …on Azure, Amazon, Google-hosted scenarios
    A: Yes!
  5. 5. Q: …on (heaven forbid!) PHP, Ruby, nodejs servers
    A: Yes!
  6. Q: Will it work across all these platforms with one code base for the App / UI?
    A: Yes!
  7. Q: Will it work across all these platforms with one server API code base?
    A: For DNN 7/8/neXt probably yes.
    A: For cross-platform or cross-CMS probably no. 

The Vision: Server Agnostic Applications

I would like to start with an example of an application I recently stumbled upon - simogeo/FileManager - a JavaScript based file manager which looks nice and doesn't care what server is running it - all it cares about is the server side API which is currently exists in PHP, MVC, classic ASP. It even has ColdFusion and Lasso! We're currently evaluating it to replace the Telerik-file-picker in 2sxc, because all we would have to do is create a DNN-API. 

This is the power of JavaScript - basically any kind of System which only cares about a simple API will become portable to many platforms and will become used on many platforms. What's really nice is that a JS-App-developer starting on DNN can also cater to Drupal, SharePoint or some Ruby-Server. The Requirement: Separation of UI and Server-Functionality

To get there the UI must really become independent of the server underneath. Any halfway implementation mixing server-rendered HTML with the JS-App will never reach the same broad audience as a properly separated system. Here's an example that won't make it (unless they refactor) ResponsiveFilemanager. It looks great - better than the simogeo/FileManager - but the core view is PHP rendered, making a DNN adaptation very "expensive" and parallel maintenance impossible.

Key Success Factor for Future Apps: Clear API

Assuming I'm right (and I have a track record in tech predictions :) then one of the key success factors of future apps is JavaScript-only UIs and a clear, replaceable API. This means that a good JS-App must…

  1. have a consistent way of calling WebAPI endpoints - preferably REST
  2. use a common, consistent format - preferably JSON 
  3. allow minimal configuration to address alternate WebApi endpoints (because urls will change a bit from system to system)
  4. clearly separate network-concerns from the core application (like authentication) - like our implementation of configuring $http in 2sxc to fit DNN

Basically developing a JS App this way will allow easy portability to other platforms and increase its adoption. In the same way any JS App developed this ways will be easy to port to DNN as well. 

Key Success Factor for Future Server-Platforms: Api-Flexibility and Dev-Speed

Being able to deliver a WebApi for an existing JS application is key to the success of future servers. This means all layers of the stack OS (Windows/Azure/Linux), web service (IIS, Apache), dev-framework (Java, PHP, .net), implementation (WebApi, etc.) and Frameworks built on top of this (like DNN or the 2sxc-REST-Api)

Microsoft has been doing a good job here for about 2 years now with WebApi . And I love what they are doing with opening up, promoting AngularJS - this will provide another great boost. 

How does DNN, 2sxc or custom 2sxc-App fit in this brave new world?

Surprisingly well - even DNN is extremely well prepared. The core question is how well is each part future-proof, based on the key success factors. This will be discussed in part 3 of my JS Rules! Series.

With love from Switzerland,

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 800 DNN projects since 1999. He is also chief architect of 2sxc (see forge), an open source module for creating attractive content and DNN Apps.

Read more posts by Daniel Mettler


Will Strohl
Thanks for continuing to create useful content, Daniel. Your articles will hopefully inspire many others to generate useful content as well.

As far as this post goes, I think this is an over-simplification of the topic. However, it's a great thing to think about and get more details on. For example...

It's not a question of "will it," but rather, "can it" and "how can I make it do that." I believe that some deep dives into those questions would be much more interesting to others in the community and myself.
Will Strohl Tuesday, January 5, 2016 11:38 AM (link)
Daniel Mettler
@Will I think I know what you mean with oversimplification (Point 2), I had similar discussions with Bogdan and probably many module vendors will say the same thing. I think one of the main causes is that many modules that have been on the market for very long tend to have a fairly deep integration with the DNN APIs or are specifically made to address a dnn weakness. For example DNN Sharps URL Adapter which fixes url handling in DNN. Of course such a module would never be platform agnostic as Umbraco would have different url-mapping needs. But 80% of functionalities are fairly simple data-in - store-in-db - template-data-out scenarios. These are easiest handled in 2sxc but are often still developed as own modules - and these would be very, very simple to port.

As to point 1 & 3 - I would love it if others would write more and also contribute more of those :). I have hundreds of topics to write about but it just takes soooo much time :)
Daniel Mettler Wednesday, January 6, 2016 12:46 AM (link)
David O'Leary
Great piece. Good stuff to ponder.
David O'Leary Wednesday, January 6, 2016 12:27 PM (link)

Comment Form

Only registered users may post comments.


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