As you are hopefully aware of, we’re big fans of the Jive Add-on framework. We use it for a number of projects and products on a continuous basis.

However, it is always a good idea to spend time with other development frameworks to hone your skills and find new approaches to problems.

One, somewhat unexpected, source of inspiration for a suggested improvement to the Jive Add-on framework came during a development project for … SharePoint Online (aka. Office365, though this also applies to SharePoint 2013).


Apps for SharePoint allow you to build applications that behave very similar to apps in Jive:

  • They have full access to the SharePoint object model, similar to the v3 JS API
  • They offer transparent single-sign on without the need to re-authenticate
  • They can be built using any development environment that supports HTML/JS
  • They offer various integration points throughout the UI
  • They run out of context of the server itself


One of the differences is that SharePoint offers a concept called an immersive app. An immersive app offer all of the features mentioned above, but it runs in a separate window after being launched from the Office365/SharePoint UI.

Here is an example of an immersive app


The app runs on a separate server from the SharePoint site (even the URL is different), but is passed the security context of the user launching it, giving it full access to the SharePoint API.

A minimalistic context of the SharePoint site is retained by the available chrome control at the top. It automatically makes a themed navigation bar (that mimics your site’s theme) available, and also injects a number of CSS classes so that you can brand your app similar to the customer’s site. (Something I wish we had in Jive apps).


Now why is this a good idea? The main benefit from a user’s perspective is performance. Despite all its power and the elegance of embedding functionality directly into Jive, the most common criticism we hear from customers is the sometimes slow response times, as a lot of html and all webservice requests are proxied through the Jive server.

From a developer perspective the main benefit for me personally is the lack of restrictions, which are imposed by the Jive apps framework. I would love to use modern technologies like AngularJS (not really, not a big fan of v1 ;-) ), Durandal or even BreezeJS in our Jive apps, but the amount of effort of rewriting these to play nice with the restrictions of the Jive framework is cost prohibitive in most cases.


The pros:

  • Better performance, as this is a “regular” web application, instead of running in a proxied iFrame
  • All modern web application frameworks and technologies are available without customization
  • A lot more screen real estate, as the Jive navigation and headers can take up as much as a third of the available screen, depending on the theme
  • Still able to create integrated apps that make use of the social graph and collaborative capabilities of Jive in a relevant way. (Don’t fall into the traps of the portal world! Watch my talk from JiveWorld13 here: JIVETalks: Developer - Video


The cons:

  • The user is taken out of context of the Jive environment. However, the same applies for a canvas based Jive apps. A chrome control can remedy some of that.
  • Not suitable for scenarios where the launch context (a place in Jive, a profile or content) is relevant.



Jive is actually very close to achieving a first version of this capability. All is needed is a “login via Jive” capability. One could build an immersive Jive app even now, but the lack of login by Jive means, that I would need to create a separate login and user management to do so. Take a look at this discussion for for an example of someone trying to achieve this (and failing): OAuth2 authorization process always ask for grant permissions

A next step would be an option to launch an app from the apps menu and have it launch in a separate window, without the need for an iFrame, and with the security context passed. This would allow us to use the v3 REST API.

A stretch goal would be to have the v3 JS API available in the app.


Question to Jive: When can we have this?


Ryan Rutan Yoav Derazon Aron Racho Clara Liang Matt Tucker