In-Depth

SharePoint Framework Embraces JavaScript

Building modern apps with the forthcoming new SharePoint Framework is tailored made for hybrid environments.

• By Elliot Luber
• 02/03/2017

You're charged with engineering a new but important app that the company CEO wants all employees to add to their routines and it should be accessible from any device. The nature of the app would lend itself well to an organization's SharePoint environment, but some groups are moving to the online service available with Office 365, while others connect to the server edition.

Such an implementation project would not be feasible or even possible until recently thanks to the new Microsoft SharePoint Framework, released to developers as a preview last summer, and set to become generally available this month. The offering enables one to build and deploy apps based on the popular JavaScript-based programming language. The ability to use JavaScript aims to broaden the appeal of SharePoint, offering modern and immersive experiences for users of both the on-premises server edition and the online offering available with Office 365.

JavaScript has become the preferred environment for building such mobile apps. That's why JavaScript is the cornerstone of the SharePoint Framework (see Christian Buckley's Inside SharePoint column,  "Acclimating to the New SharePoint Framework"). It will work with existing SharePoint Sites as well as those built on the new framework. While supporting and building upon .NET, the new SharePoint Framework removes dependencies on that framework.

Project Considerations
As the IT project manager, the first thing you typically do is share the requirements with your development and design teams. But, what if the graphic designer comes back to you with an in incredibly long and complex HTML string? This represents a challenge because the complexity of updating it, running it, changing data or linking it to other apps can quickly get out of hand.

The responsible thing to do is to componentize the string into easily digestible, edible, repeatable and reusable pieces of JavaScript. Therein lies the true art of application engineering. Seasoned development managers say they never have to ask whose code they are looking at -- code reflects the personality, style and thought pattern signature of the author the way fiction writers have their own way of revealing a plot.

Angular or React?
Today, as clients get more sophisticated, there are also three excellent ways to automate this front-end componentization process based on the recent updates of the major frameworks: Angular, Ember and the React library. All three solutions are open-source, each with its own advantages, but observers seem to see them moving toward a potential long-term convergence as new generations share similar values such as server-side rendering, native play across consumer devices and better management to enable speed.

And, because the new SharePoint Framework now supports these different JavaScript variations, these apps will offer this modern UX that developers can write once and deploy to SharePoint Server 2016 and Office 365. Developers can also tap into other JavaScript apps or components now in deployment.

Implementing these values in the framework has not been even, but the real differentiation of the systems depends on your own organization, skills base, application requirements and access to additional server resources. Also, recent code changes from Facebook, which developed and maintains React, have triggered rumors of some future rights concerns, though nothing solid to date has turned up in the blogosphere as of this writing. It bears some vigilance.

This is not to paint Facebook as the bad boy here, because both Google and Facebook have contributed massive amounts of solid code to the cause -- enough to make developers take a second look at the React library (and related compatible libraries) in addition to checking out the leading Angular solution, developed and maintained by Google and the miraculously resilient Ember framework, which people once feared would die a quick death, though still evolving (sponsorship has shifted over the year -- it's currently in the hands of LinkedIn and Tilde).

The advantage of React is that it is less of a solution. It lets you do what you need to do less elegantly, but without making the same commitment. As Ben Beecher puts it, "For large companies with complex projects and a lot of developers used to doing things their own way with their favorite libraries, it makes a lot of sense. But it is highly recommended that users learn JavaScript."

But Beecher, founder and CTO of LightMatter -- a platform-agnostic app development firm that offers full stack and responsive development and API design services with experience in all three JavaScript iterations -- also explained that use of supplemental libraries, frameworks and applications might necessitate the deployment of a second "build" server, which may create governance or budget issues, while the more automated frameworks will not. "It's not for everyone, but it's worth considering," Beecher said during a Jan. 10 presentation delivered to the New York Enterprise Collaboration Group

Onus on Your Dev Team
The decision also puts the onus on developers to manage "state," when refreshing data because the system has no internal data handling schema. It refreshes and displays, but the addition of queries or application calls add considerable complication to a project. Beecher recommends a strategy with componentization to manage state as simply as possible to minimize React complexity.

One major React advance is the new third-party application React Nature, which allows porting of JavaScript applications directly into the fabric user interface supporting SharePoint applications natively across end-user platforms.