SharePoint Saturday Boston 2016 Follow Up

Thanks to everyone who attended my session at SharePoint Saturday Boston on ‘Best Practices for Small-Scale Client-Side Development in SharePoint’. I’ve posted my slides on SlideShare for everyone’s enjoyment.

Be sure to follow my series on Sympraxis Client Side Development Pipeline for more details on some of the approaches and methods I demonstrated in the session.

Thanks to Heather Newman for the photo!

Thanks to Heather Newman for the photo!

The SharePoint Framework (SPFx) Is Here!

There’s no official blog post to point to yet (I’ll add it when it appears later), but today is a big day for SharePoint! The new SharePoint Framework is ready for its developer preview.

UPDATE: Here’s the REAL post.

SPFx Workbench To Do Web Part

I’ve been watching the Twitter feed from SharePoint Fest Seattle, and Jeff Teper (@jeffteper) announced the preview in his keynote – or someone else did when they were talking.

In case you missed it, the SharePoint Framework was announced publicly at the big May 4 The Future of SharePoint event in San Francisco.

When it’s available, you will see it on Github/SharePoint:

SharePoint on Github

In case you get confused by all the new terminology for “software release” these days, I’d call the developer preview a pre-alpha. The Microsoft folks would say it’s more solid than that, but they do say that things may change, you should not use it in production (and truthfully, you can’t unless your Office 365 tenant supports it), etc. In other words, it’s ready, but not THAT ready.

As someone who can realistically claim to be one of the early client side developers for SharePoint, I’m really excited about the possibilities here. When we build client side code, we’re giving users of SharePoint a much better user experience (UX) – if we do things right. Rather than the old school “conversation” with the server – and the attendant postbacks – we bring the responsiveness right behind the glass of their device. The UX becomes far more intimate. People are used to this sort of UX from everywhere but classic SharePoint. The consumer Web and most other Web-based enterprise products have been there for a while.

If you’re coming from server side development, I think this Brave New World is going to feel pretty weird for you. What I’d ask is that you give the SPFx more than one chance. If you dig into it today and find things confusing, or the documentation a bit light, or the tooling pretty weird, or the examples not quite up to snuff, stick with it. These are early days.

This is the first time Microsoft has put a development model out there and agreed that it will be how THEY build things in the future. No chicanery; no trickery. In fact, they claim that many of the new “experiences” we are seeing are built with the SharePoint Framework. I have some doubts that they are playing by the rules on this quite yet – the SPFx seems a bit lean to get to the types of “experiences” they are giving us – but they will abide by this pact.

Those of us who were able to attend one of the the Developer Kitchens earlier this year and play with the early versions of the SPFx came away energized and impressed. Not ecstatic and blissful – most of us a realists after all – but energized and impressed. There are many holes to fill and we will encounter bumps in the road. But given the open source foundations of the SPFx, we can help drive this Brave New World forward with Microsoft. Now that’s a new thing, for sure.

 

If you’d like to know more about the SharePoint Framework, check out my previous posts:

From the SPServices Discussions: Why Should I Bother to Learn XSLT?

Client Server DiagramHere’s a question from gdavis321 from the good old SPServices discussions. In most cases, I just answer the questions in situ, but occasionally – as you frequent readers know – I realize what I’m writing feels more like a blog post, so I move it over here.

It seems that Spservices (thank you for this god send) can do anything that you might want to do with a content query webpart or other webpart… am I missing something? Why should I bother to learn XSLT?

It’s a fair question. As someone who loves using the Data View Web Part (DVWP) – which is XSL-based – the answer is, as always, it depends.

Doing everything client side isn’t always a great idea. For each specific requirement, you should look at whether it makes more sense to do the heavy processing on the server or client. There are many variables which go into this, like client machine capabilities, data volume, number of data sources, need to join data from different sources, skills on the development team, desired time to market, etc.

In SharePoint 2013, much of the processing has moved to the client side (often called Client Side Rendering, or CSR), so many people think that we should just process everything client side now. I worry about this sort of myopia.

Client machines – meaning the machine sitting on your desk or in your lap or hand rather than the server, which sits in a data center somewhere – have better and better capabilities. Yet in many organizations, you may still see Windows XP machines with 1Gb of RAM – or worse!

Additionally, client side processing may mean moving a huge volume of data from the server to the client in order to roll it up, for example. If you’re moving thousands of rows (items) to make one calculation, it *can* feel sluggish on client machine without a lot of oomph.

So client side libraries like SPServices or KnockoutJS or AngularJS (among many others) are fantastic for some things, not so fantastic for others.

When it comes to the JavaScript versus XSL question, both approaches should be part of your toolset. Sometimes good old XSL will be an excellent call if you can do some of the heavy lifting on the server, then pass the results to the client for further processing. The output need not be just nicely formatted list views, but could be sent in such a format as to make the client side processing easy to start up upon page load. My approach is often to ship the data to the browser via a DVWP and then process it further with jQuery on the client.

The mix of what happens where is on a spectrum, too, depending on what you need to do. You might roll up tens of thousands of items in a DVWP and then request items from two or three other lists from the client as the page loads to optimize your architecture.

Yup, there’s that architecture word. A good SharePoint architect will know when to use each of the tools in the toolkit, and JavaScript and XSL are just two of many.

Keep in mind that because “it depends”, your mileage may vary in any and all of this: cavete architectus.

Setting a Conditional Breakpoint in Firefox with Firebug

Every once in a while I click randomly on something and realize that I’ve been an idiot. OK, sometimes it doesn’t require clicking on anything.

First off, if you’re working on client side code and you aren’t using Firefox with the Firebug add on, you should be. It gives you all the debugging capability that you need to win. (Some others swear by Chrome, but I’ve been developing with Firefox for a long time.)

Firebug

Everyone else has probably known this for millennia, but I just figured out today that I can set a conditional breakpoint in Firebug. If you right click on a line where you’ve set a breakpoint (this was my random click), you get a syntax menu that looks something like this:

Firebug Breakpoint Context Menu

By selecting Edit Breakpoint Condition… you can add any valid JavaScript condition. Here’s one I used to break when I was processing row 55 in a loop:

Firebug Conditional BreakpointSetting a condition like this is really useful, especially when you know that item 55 out of 4645 is causing an error and you just want to step through your script for that item.

There’s more to conditional breakpoints in Firebug [I know now], as you can read in the Firebug Tip: Conditional Breakpoints post on the Firebug blog.

Perhaps because I’m old school, while I’ve truly wanted to be able to set conditional breakpoints like this I’ve simply changed my indices or put in conditional debugging statements. I’ve gotten by just fine, but I’m going to be a lot more efficient now. If you didn’t know about this little trick, then hopefully you’ll be more efficient now, too.

Or maybe I’m just an idiot.