Detail information about the SharePoint Framework (2016):

What is SharePoint Framework?

SharePoint Framework is a new model for building customizations on the SharePoint platform. Although it has just been announced it isn't available for developers just yet. SharePoint Framework is based on the concept of building client-side solutions which integrate with the modern SharePoint UX.

 For building SharePoint Framework solutions you can use any JavaScript framework you want and, for the first time ever, building SharePoint solutions isn't limited to Windows and Visual Studio. Because SharePoint Framework leverages widely used web development stack, solutions can be built on any platform including OS X and Linux using code editor of your choice. For the first time Microsoft isn't using a proprietary development model specific to SharePoint, but instead leverages tools and techniques widely used by developers on all platforms and stacks. Also the Product Group is committed to using only the publicly available APIs to build their solutions on top of the framework which will allow developers to build solutions with capabilities comparable to what's available out of the box and more.

The SharePoint Framework is an evolutionary step in SharePoint extensibility that delivers a new client-side rendering framework leveraging open source JavaScript technologies. The client-side development framework will allow developers to use modern JavaScript and web tinplating frameworks across cloud and on-premises SharePoint.

Microsoft used the SharePoint Framework to create many of the experiences that we announced today, like the home page of a team site. Our customers can now build similarly powerful, rich apps and experiences in SharePoint, integrating services across Office 365 following the same patterns, practices and process we use to build native SharePoint experiences. Pages and experiences built with the SharePoint Framework will be mobile by default and will be integrated with the SharePoint mobile app.

The SharePoint Framework embraces the tools, frameworks and open source initiatives that developers rely on today, and it extends the scope of solutions that can be built on SharePoint, in the cloud and on-premises.

The SharePoint Framework will be released to Office 365 customers in First Release this summer. Web parts built with the framework can be added to modern pages and experiences and to existing pages.

In the third quarter of 2016, you will see:

• The Files API on Microsoft Graph.
• SharePoint Webhooks (preview).
• Client-side web parts for existing pages (preview).

And by the end of 2016, Microsoft will deliver:

• The Sites API on Microsoft Graph.
• SharePoint Webhooks (GA).

Custom sites on the SharePoint Framework.

The key benefit:

If you follow the guidelines and deliver your solutions according to the set forth practices; Your new solution will be 100% mobile friendly natively out of the box with the new modern Team Sites as well. This rhymes well with the cloud-first, mobile-first announcements in the past.

How does the SharePoint Framework work?

Tools and Frameworks

Since the SharePoint Framework is entirely JavaScript-based, you can decide what tools and techniques you use yourself. I have my personal recommendations and favorites of course, as I'm sure you do.

Yeoman, if you haven't used it before, is a scaffolding tool for modern web applications. It's very easy to use, and the benefit of using it is that within seconds you can create a new project structure and get ready to implement your custom functionality in that automatically generated project.

With the SharePoint Framework coming, there's going to be Yeoman scaffolding templates available as well, which will help you to get those projects created.

Gulp for task automation, tests and build

It's a task and build runner for developers. You can use it to perform repetitive tasks, automate minification, compression and a lot more. One of the great benefits of Gulp is that you don't have to write everything yourself. There's a whole sea of plugins available, ready to be used easily in your gulpfile.js.

Visual Studio, Visual Studio Code or something else?

One of the benefits of having a fully decoupled framework, purely written in mature JavaScript, is that you're not constrained to a specific development IDE or toolset. You can simplify development by using any tool you feel comfortable with. Personally, I've done my projects in Visual Studio and Visual Studio Code. Without getting into an argument about which IDE is best, I prefer Visual Studio Code for responsiveness and super-lightweight coding. But I prefer Visual Studio Ultimate when I need to use my integrations, extensions and plugins which currently aren't available for Visual Studio Code. As always, this comes down to a personal preference - and the great thing about the SharePoint Framework is that it doesn't require you to use any specific tooling you decide what you want to use.

Workbench - for local development:

There's something called the Workbench. This is interesting because it's really a way to develop your applications and web parts on your dev box, and by running gulp serve for example, it will spin up a new localhost environment called the SharePoint Workbench. From here you can simply add your new Web Part or Application and see how it works before even pushing this on to your actual environments. This means you'll get a light-weight and similar UX as the new SharePoint sites will offer in terms of how to add and work with your web parts etc - but offline for easier development efforts.

Most of this is fully automated. Simply running gulp serve in your new project will open up a browser and present the Workbench.

Benefits?

Test Web Parts or Applications without a connection to any server

Quick development turnaround from editor to verification in browser

Lightweight

Things you need to know about on the page

The Chrome contains your business context, if you will. It contains the logic offered by Microsoft out of the box - and any additional logic you may build on top of that.

Mobile friendly

It has its own branding, theming and business logic. If you play by the rules and follow guidance which will be made available, anything you run and build in the SharePoint Framework will also be looking great on mobile devices. There's plenty of benefits of following the rules - and since we're doing it from scratch for new customizations, there's no reason not to do it the right way from start.

Page Body

The Page Body (see picture above) is where the users mostly live and interact with anything you build. Web Parts, Applications and any customizations would most likely go into this area. Users can easily click on the plus sign and then add any app you've built from there.

Canvas

The canvas is simply the part of the page where you add your Web Parts of apps. You could relate them to what used to be Web Part Zones or Rich Text Editors perhaps. It's what you see in the previous image above.

Will SharePoint Framework solutions work on classic Sites?

The SharePoint Framework will eventually work on your existing team sites, and on the new modern team sites. However, the classic solutions will not work on the new modern team sites.

This means it's a good idea to get to know this enhancement in the developer experience, and see how it fits into your customization story.

Hosting your code and applications

When a development effort is ready enough to try out live in a dev/test environment, or even production, it is a good idea to know where to host it.

Using a CDN (content delivery network) of your own choice might be a good idea for performance, geolocation and caching etc. There's plenty of ways you can achieve that.

Key aspects for developers  

• Client web parts and client-side applications are the new building blocks. As discussed in the last post, these go along with the new page model.
• It’s a JavaScript world  Config files are in JSON, and code is implemented in JavaScript on the client-side.
• The packaging of artifacts is different! There are new manifest files to learn about (e.g. a web part manifest), and other files such as bundle.json, package-solution.json, upload-cdn.json and more. Gulp tasks are used for packaging.
• Files for your web part or app can live anywhere (e.g. a CDN, or a website you host) - they don’t have to live in SharePoint. Anywhere that can be accessed on a URL by the end-user basically.
• The “local development” model is very different – Gulp and node.js are used to host files locally, so you don’t need to use IIS on your local machine. A special “workbench.aspx” page is used to support this.
• No particular JavaScript framework is mandated – you can use Angular, React, Knockout, Handlebars or whatever you like. The one thing to consider is that React will already be on the page as it’s used by some SharePoint components, so that’s one less file to download the first time users hit your site or customization – useful, but probably not a massive factor for intranets though.
• You should consider learning TypeScript – at least the key parts such as modules, the type system and so on.
• You no longer NEED to work in Visual Studio - if you prefer another tool (e.g. because you’re not a “career” SharePoint developer), that’s fine. Other lightweight code editors such as Visual Studio Code or Sublime are now 100% viable options because the packaging of artifacts is different. Even I (as a 10 year SharePoint developer) have started to prefer using VS Code, even if some bits are slightly painful initially.
• SharePoint Webhooks – these are the new “event receivers”. This is a move towards a more standards-based approach to responding to changes in SharePoint/Office 365.
• The App Catalog is used as a packaging and registration method – both client web parts and client-side applications are packaged in this way (moving away from the web part gallery we’re used to)
• Page security needs some consideration – because anything on the page can theoretically access anything else (e.g. by scraping the DOM), that could raise some interesting questions when the user’s mail is shown (for example) and web parts from different sources/vendors are present. To counter this, some operations are blocked in the new framework but other governance may be required. special thanks to CHRIS O'BRIEN for his wonder full blog on SharePoint framework your contribution to SharePoint world is awesome.

Deploying to production (e.g. deploy to CDN)

Once we’re ready to have our solution used in test or production, we need to move away from the locally-hosted model. Now the JavaScript, CSS and any other files needed at runtime need to live in a location which can be accessed by all users – this can be a CDN, a simple website such as an Azure web app, or any other location of your choosing. You *can* continue to deploy to SharePoint libraries (e.g. Site Assets) if you choose, but now we have an option which moves us away from needing key files deployed (and duplicated) in each site collection – woohoo! You are responsible for providing this location (unless you’re choosing SharePoint)

Client applications 

As well as client web parts, let’s touch briefly on client applications. These are coming later in the year, and in the same way that client web parts offer a JavaScript-only version of web parts, client applications do a similar thing for full page apps. I summarized the flavors in my previous post like this:

Page-based apps – an alternative to provider-hosted apps (which remember, are implemented with server-side code).

List-based apps – think of these as an alternative to JSLink for transforming the display/edit/new experience around list items

Client applications are implemented purely in JavaScript, but have benefits such as having full “context” and using the Office 365 suite bar etc. There is a framework or scaffolding page in your SharePoint site/Office 365 tenancy, but the main page body is implemented in your JavaScript/HTML/CSS. It’s pretty easy to understand the page-based apps, but the list-based flavor is interesting too. Recently I’ve worked on several mini-applications which provide a custom interface, but store their data as items in a SharePoint list. We built a page which takes a URL parameter for the item ID, and then issued a REST call to fetch the data and build the page around that. One example was a “office locations directory”, where the locations were stored in the list but we provided a nice presentation with an embedded map, particular layout of the data elements and so on. You can consider list-based client applications as a formalisation of that – it will be quicker and easier to build such solutions, almost in a “JSLink on steroids but without the proprietary display template framework”-kinda way. Nice.

Summary

That might be the best word to describe what is coming out of the productivity machine at Microsoft. There are plenty of opportunities for developers and foremost I like the idea of decoupling things from SharePoint even more, hosting them as scripts from CDN etc instead. Keep your SharePoint clean and alive - and focus on what's important. And don't forget - always play by the rules so you don't end up in the same customization madness that so many people have done in the past.

Now it finally feels like we're moving into a modern world, and that SharePoint is actually up to current standards. You don't have to spend all your development efforts in outdated techniques, tools or frameworks - choose whatever you want for yourself and your team, and go build stuff! In the simplest way possible I'd say it's all about consuming API's and working with them - what you leverage in order to communicate with those API's, that's entirely up to you. Thanks for Reading. Hope it helps you…J Cheers…