In July, we were at a junction.
We had just wrapped up a new SharePoint On-Premises module with Angular v1.4 and ngOffice UI Fabric. Our previous module was Angular v1.2 with UI Bootstrap. We knew the SharePoint Framework was coming, and would even eventually come down to On-Premise in 2017. Plus, at the rate JavaScript moves, we basically need to refresh our toolbox every 3 months.
It was about time to do a bit of research – and so we did.
This research culminated in writing the Preparing Your Toolbox for the SharePoint Framework with Angular, Webpack and Kendo UI whitepaper, which is built around this Contract Register demo (GitHub). The technologies we picked focused primarily on what we were familiar with, but also what we knew would be supported in the SharePoint Framework. We double checked with the examples from many professionals who have been blogging about their SharePoint Dev Kitchen experiences and against all the PnP SPFx videos.
We started with Angular and Kendo UI using Gulp, but the build process involved bundling to a CDN, so we added WebPack.
Finally, instead of talking to SharePoint directly, or using Kendo UI DataSource components (which also support SharePoint REST), I wanted us to use pnp-js-core – a fluent API for talking to the REST endpoint from the Office PnP team.
We bumped our version to Angular v1.5 because we wanted to be at the best position to be able to "deploy to production" today, but still write to the components spec that will be the norm in Angular v2. Moreover, the SPFx-webparts will run in the SharePoint Mobile App in the future. So without explicitly doing too much extra work - we are building toward that future where we build and it runs in the browser and on mobile.
As for PnP JS Core, the fluent API was a joy to work with, and the way batching was done is quite magical. In v1.0.3 the library started to support NodeJS as well, which means you can use the same JavaScript code to interact with SharePoint from both the browser and the server. Writing the same code that runs in both places is the holy grail that we always look towards. If JavaScript can run everywhere, then the libraries we want to use should be able to run everywhere.
As we dived deeper into the wonder that is WebPack, its magic unfolded. In this little demo video we recorded for Contract Register, you may notice how fast WebPack injects code into the browser – the app is ready before the Office 365 suite bar appears. This is a side effect of code splitting - WebPack doesn't just merely concat and uglify the JS file, it blasts JavaScript modules into the browser like a shotgun - all at the same time. WebPack almost removes the need for Gulp in the process. Gulp is still needed to start different tasks - but WebPack does the work underneath, and it does it really well.
We debated a lot about TypeScript. It would have made the IntelliSense and code checking better, but we decided to leave it out. It would have been that "one more thing" to learn, and the list was already getting long. Have a look at the code we wrote for the contract-register (GitHub) and let us know if we made the right choice.
I want to talk about Kendo UI as well. I hadn’t used Kendo UI before this project. My colleague and co-author of this whitepaper, Bart Bouwhuis, is a big fan and he is constantly showing me cool features. The whitepaper is not an advertisement for Progress (formerly Telerik), but I also think we don't really talk about Kendo UI as much as we ought to.
My feeling is that the Kendo UI components are really mature – in some areas rivaling or exceeding UI Bootstrap.
Components like Grid, Window and PDF export were easy to add. They already support Office 365 theme, so they don't look out of place.
Telerik supports Angular v1 and they just released the developer preview for Angular 2. We ended up spending very little time making the components work for us – in most cases, we looked up the example on Telerik Docs and it just worked! An additional blessing is that we never needed to tweak the CSS to fix some styling problem – that was actually quite a painful issue with UI Bootstrap or ngOfficeUIFabric.
Things are moving quickly. The SPFx developer preview came out during the writing of the whitepaper. Remember that train? Turns out it was coming really fast. We love how fast the SharePoint team is running. But it means we have a few notes to add.
Firstly, the whitepaper isn't just about SPFx. It is about SharePoint as a platform with AngularJS and WebPack, and having those pieces ready and aligned for SPFx. It is about a stable set of core tools that works well together. It is about a set of tools that runs today on SharePoint 2016, SharePoint 2013 and SharePoint Online. You can already use these, without having to wait for SPFx.
Secondly, with SPFx there are even more opportunities. We will have better support for Angular and SPA modes - currently both scenarios are not yet released. So the story will evolve and become more awesome. The contract register demo can run in the SPFx webpart mode - in that case, the code to initialize the app and set up the various lists that should go into the web part property panel. Only the contributor can have access to creating the lists.
How we've decided to manage this constant flux is to publish a blog update when SPFx is formally released to fill in the “gaps” – the things unknown as of the time of publishing the whitepaper. So stay tuned for such an update, likely after Microsoft Ignite. We also have a bunch of crazy ideas listed for the Contract Register. So if you want to get your hands dirty and have a go, we are taking pull requests!
The time to jump in is always now (or as soon as you can). Here we present two months of work representing our hardest effort to promote modern web technologies and SharePoint as a platform.
Please download our whitepaper Preparing Your Toolbox for the SharePoint Framework with Angular, Webpack and Kendo UI, compare it to what you guys use and let us know what you like or love.
Related Resources
Based in Sydney, John specializes, blogs and speaks frequently on client-side scripting, custom development, workflows and forms. John loves finding ways to apply the latest web technologies to extend the SharePoint platform.