Welcome to the Rencore Tech Talks show. In this episode I’m catching up with Mark Rackley on some topics around Client- Side Development in SharePoint.
[Recorded: 2017-02-14]
Listen to this show to learn more about things like:
- Should you customize Master Pages?
- What about custom Forms?
- Modern Team Sites vs. Classic
- Key takeaways from Mark about client- side development in SharePoint
- And more
Guest: Mark Rackley 
Mark is Partner and Chief Strategy Officer at PAIT Group and an Office Servers and Services MVP with more than 20 years of experience designing and developing software solutions. Mark has been doing JavaScript development in SharePoint since 2009 as is considered one of the pioneers of Client Side Development in SharePoint. As a globally recognized SharePoint geek, Mark is an active blogger, presenter, author (and bacon aficionado) who is eager to lend his real-world knowledge of SharePoint to all who need it
Show notes:
- Blog: www.markrackley.net
- Company: www.paitgroup.cm
- Blog Series discussed in the show: http://info.paitgroup.com/blog/5-things-sharepoint-client-side-developers-should-stop-doing-immediately
- StratusForms: www.stratusforms.com
Full transcript
[Tobias] = Tobias Zimmergren
[Mark] = Mark Rackley
[Tobias:] Hey, Mark Rackley, welcome to the show, man.
[Mark]: Thanks. Glad to be here.
[Tobias:] Speaking of client-side development and how it’s changed a lot since we both started working with SharePoint back in the day. For anyone who doesn’t know what client-side development entails in SharePoint, would you mind just elaborating a bit to clarify what is client-side development in general and how does it differ today from a few years back when we were working with solutions on- prem and things like that?
[Mark:] Sure. So client-side development the two basic things we will talk about is manage code that runs on your server and then client-side development, which is basically code running on your client’s device which could be your phone, laptop, desktop or whatever that client is that is consuming the application. The thing about client-side development it’s got restrictions over that manage code development since they’re not deployed to the server. So you don’t have as much access as you do to the server and you also typically use things like JavaScript for client-side development instead of .net or other managed code.
[Tobias:] Right, and that might actually be a good thing with the permission levels that the code cannot do whatever it wants on the servers, right?
[Mark:] Absolutely. For client-side code that JavaScript executes with the same permissions as the user who is currently logged in so that script can’t elevate permissions. Which is a good thing because then people could just inject script into your page whenever they wanted to and plug your site away so that’s actually a good thing.
[Tobias:] How does client-side development -because I know you’ve used a lot of JQuery and I’ve used that to modify forms, I’ve used that to modify different objects in the Object Model or the document object model – how does it differ today how you do your client-side development versus how you used to do it even if back in the day were using JavaScript? Is there any big differences from SharePoint 2007 when you did JavaScript there and how you can do JavaScript toady?
[Mark:] That’s kind of a tricky question from my standpoint because I really got thrown into client-side development back with SharePoint 2007 and this was back before we had Sandboxed Solutions, this was back before we had an add-in model, that was before we had the SharePoint Framework so your options for doing client-side development were very limited back then. And back then I would use the Content Editor Web Part to inject script on a page to make it do what I wanted it to do. And I had a large project that I had to do for a government agency where we did that and it worked out really well. It turned out that those same techniques translated over to 2010 well and the scripts I wrote for 2007 upgraded to 2010 well, and the same thing for 2013 when Office 365 came out. Those things worked really well in Office 365.
And it’s also a very easy way for people with not a deep technical background to start doing client-side development. They can write a script in Notepad, upload it to a document library and then reference it in a Content Editor Web Part and they’ve got some great functionality on their page and that’s without ever opening Visual Studio or any development tools. So still to this day when it makes sense I will use a Content Editor Web Part and reference a script in document library.
However, like you said, things have been changing. We did have the addition of the add-in model which you can also use for SharePoint hosted apps to write your JavaScript in a more managed way while using visual studio. Then just recently they came out with the SharePoint Framework which basically takes the entire process that we used to do in a Content Editor Web Part and it makes it much more manageable using open source tooling like Note, and Yeoman and all those other open source tools for the environment to do that now. So within the past year the changes going on are just incredibly drastic.
[Tobias:] Yeah. It’s kind of like all this Note and using Yeoman, templating and things like that, scaffolding off your project, the web development community has been doing that for a while but it wasn’t really possible in SharePoint for a big time. And now all of a sudden we can do that and with the evolvement of API’s in SharePoint and Office365 it kind of invites any web developer to build on SharePoint rather than having to have that specific SharePoint domain knowledge, right?
[Mark:] Absolutely. With the way they keep adding to the APIs you really don’t have to be the SharePoint expert you used to have to be to write server site code. Now you can take that open side developer who’s comfortable with that tooling and get them up and running in SharePoint faster than you could before.
[Tobias:] Speaking about that new kind of skillset, if you’re a traditional SharePoint developer or like myself I’m coming from SharePoint 2003, 2007, all the way up, and I was also heavily involved with developing other servers and solutions and I’ve upgraded a lot of my skills to the new type of SharePoint Framework and client-side development using the rest of APIs, but what would be your recommendations or your main takeaways for anyone that either wants to upgrade their skill or getting started with client-side development on top of SharePoint and Office 365?
[Mark:] That’s a great question. For those traditional .net developers it’s going to be quite a change for them and people really hate change. In fact if you look at some people complaining about the Framework most people are complaining about the new tooling they have to get used to, the new way they have to do things. You see less complains about the actual implementation or the functionality, it’s about getting up and going in the first place.
The number one thing I can tell those traditional .net folks is you’ve just got to accept it’s going to be different. Like you said, there’s a whole world out there that have embraced these tools a long time ago. It’s not what you’re used to doing but get past it. Andrew Connell told me once that, ‘’don’t get caught up in the tooling. Don’t let that be your barrier to it. Just accept it.’’ It’s doing the same thing we’re doing in Visual Studio only Visual Studio is not doing it for us now behind the scenes. We’ve got to manually do a lot of these processes to build our projects.
He’s also come out with a development course on his new site Voitanos that will help people come up to speed on those new toolings as well and I know that you guys have a lot of blog posts as well talking about the SharePoint Framework. There’s a ton of content out there if you just do some searching on the SharePoint Framework to get up to speed faster. Just kind of give into it a little bit and accept the way things are without being too upset at a change and your life will be a lot easier.
[Tobias:] I would say the key takeaway is learn the tooling. Don’t expect Visual Studio to do everything at this point, but learn the tooling and if you know the tooling then everything else is just standard development. Just a different API, different endpoint, but you still work towards an endpoint using JavaScript or whatever you do. And that’s going to be the same but if you get over that like you said with tooling, that barrier might be less frightening, if you will. Because that’s how I felt at least when I started with the SharePoint Framework, installing Note, installing this package manager. What is that in Yeoman? How do you do that? But after working with it for a while it makes perfect sense.
[Mark:] The thing about me I’ve been writing code for more years than I like to think about now. I have a .net background, I have a Java background, and a good litmus test for me is do I need to ask for help?
When I jumped into the SharePoint Framework I had to ask for help. It’s not going to be common sense if you’ve never done it before so don’t expect to be able to just fire it up, use it and be able to change it how you want to. You’re going to have to invest some time in learning the tooling and learning how things are built.
[Tobias:] That makes sense. Speaking about not only tooling but things that you can customize in SharePoint. I know this is a topic you know a lot about and it’s a big topic with customizing for example, master pages, which, with the new SharePoint Framework, maybe you do some web part implementations, maybe you can deploy custom actions, but when it comes to master pages that is a sensitive topic for a lot of people who use it inject scripts and things like that.
It’s changed a lot since SharePoint 2007 where the birth of real customizations, in my opinion, came to life. And that landscape has changed a lot since then. I know people are still developing new master pages, they’re customizing their out of the box ones and therefore they might break up credibility of their rolling into cloud in SharePoint Online. What’s your take on specifically Master pages and customizing them and adding scripts? Like you have your client-side development toolset, will you still be customizing those master pages?
[Mark:] Well, the thing is with the new modern sites there is no branding story and we don’t know what that branding story is going to be and I don’t think we should rely on master pages being there for those modern sites. So if you were relying on those master pages to get your scripts on a page that may not be an option for you. It’s not today if you use a modern site. Typically you want to not, I don’t want to say never change a master page because we have those clients who have to have their brand on the site, they have to have some changes made, and I think that’s just what is really important that you hire an expert in branding SharePoint. Because they’re going to know what they can tweak in that master page without breaking your site so it’ll still work well on SharePoint Online. Even that, look at should you be changing the master page.
So instead of using script references in my master page I recommend using custom actions because that’s just the supported approach to get those script references to reference a script for your site or site collection. There are several ways you can do it. Waldek has a great blog post using the add-in model to deploy a custom action. You can use Sandboxed Solutions, you can use PowerShell, but using custom actions those are supported on the modern sites to get those scripts referenced.
[Tobias:] So try to avoid master pages to the extent possible, especially if you start a new project or if you don’t have any customizations. There is really no reason, and Microsoft normally recommends you not to customize them, especially if you’re in SharePoint Online because if they roll a new update to a master page and you customized it you’re not going to get the update.
[Mark:] Exactly. Instead of editing those master pages look at just doing things that are supported. Creating a custom page layout that can handle most of your branding needs for a page. Look at using the themes, look at what you can do that’s not going to screw things up for you later.
[Tobias:] Master pages they exist in classic mode still if you go to modern, you should try to avoid them, but I know there’s an even more sensitive topic than that and that’s Forms. I know this is a huge topic and would require really its own episode in its entirety to be covered properly. But speaking about Forms which I know you know a lot about, what is the deal here today? Can you do anything with Forms and client-side or InfoPath being not really developed anymore as an alternative for SharePoint? You can still use the current version of InfoPath of course but what is the option you have for Forms and specifically as a client-side dev if you want to customize or create your own Forms, what options do you have?
[Mark:] That’s a great topic and, for the record, it’s no secret that I can’t stand InfoPath and it just wouldn’t die. This is on me, they won’t die. And I urge everybody to stop using InfoPath and start looking for that next Form solution. I know Microsoft has extended the life of InfoPath to like 2026 now or something like that. But what that tells me, you can tell me if you disagree with this, but what that tells me is that there is not going to be a way to migrate off of InfoPath. Because when you come to Microsoft in 2026 and say, ‘’Hey, I need to migrate all my InfoPath Forms.’’ They’re going to say, ‘’We gave you 13 years to get off the platform. You should’ve not been using it for the past 13 years.’’ So, by the fact that they’ve extended support that long tells me there is not going to be a migration path and that you need to get off of it and find a new platform now.
But as far as what your options are—do you disagree with that? They haven’t said that but that’s just kind of what I sense about the topic.
[Tobias:] Yes. I know that is a complex topic and that might be the case that they will not offer a solution for it. I know there’s things like Flow and you have PowerApps for building your lightweight type of apps and Forms and you can use Access Online if you will or Access Services, but it doesn’t really replace what used to exist in InfoPath.
[Mark:] Exactly. So, the options for actually customizing Forms—classic mode, you can do things like inject script onto your SharePoint default Forms using the same approach of Content Editor Web Part and you can totally change the way those Forms work. And that works really well because you can visually change what the user sees so you can format how you want it to look, you can add business logic to do conditional formatting, to do business rules, you can even hook into the presave item function to do some processing before the Form submits, so you can do a lot of stuff but that’s in classic view.
On the modern pages for the modern Forms those are now created using React so the entire layout of the Forms is totally different. And currently there is no way to inject script to those pages so you can’t modify the Forms with script at this point. I don’t know if that’s even going to come. But like you said, the future of Forms is going to be PowerApps. In fact, [Jeff] Teper said at a conference last year that Flow and PowerApps is the future instead of InfoPath and SharePoint Designer but they are not as feature-rich as those tools and they may never be as feature-rich as those tools.
So, if you’re still looking for other Forms solutions I have a biased opinion. I wrote a free tool called StratusForms and what StratusForms is, it’s a total client-side based Form creation tool where you can create Forms with HTML and JavaScript and then it write that data back to SharePoint list or read it from a SharePoint list and display the forum. But because it’s completely client-side based you can actually create StratusForms Forms using the SharePoint Framework to get those Forms on to the modern sites and the modern pages and still get all the complexity you really need in those Forms. And of course there’s the paid tool like K2 and Nintex for your Forms as well, so you do have Forms options.
[Tobias:] I’ve seen StratusForms that you built as well and I’ve tried it out and it kind of bridges that gap between InfoPath and all those major players for the major Form solutions that might not always be required –those are great for a lot of scenarios – but there has to be something in between for someone to quickly and easily just customize a Form. It’s a very, very simple requirement but it’s a very common one.
I want to customize a Form to look and behave exactly as I expect it to. That’s it, period. And that does that, so it bridges that gap perfectly.
[Mark:] I know. That was my plan so I appreciate that.
[Tobias:] Awesome. So, that’s the story for Forms and customizing Forms with client-side. What about injecting stuff or the document dot object model? The HTML that you have on a page in SharePoint where traditionally they were used to customizing with jQuery and various types of scripting. I know there are some caveats with this especially today if you want the modern experience. Like we brushed on with the custom actions versus master pages and if you want your pages to work reliable on the mobile – which a modern page today is by default or a modern Team site is by default mobile- friendly or enabled for mobile – what risks do you have if you start customizing by injecting scripts? Even if it’s a custom action or something else where you have an option to actually add scripts. Are there any risks with manipulating the dome or the document object model on those modern pages?
[Mark:] Yeah and I will say that the risk is probably greater than it is today on modern pages because of that SharePoint mobile application. Currently, you can’t have a Content Editor Web Part on the mobile sites but technically you could create a Content Editor Web Part with the SharePoint Framework. So, you can still get that same functionality where you could totally manipulate the page how you want to in the modern pages.
Maybe you spend two weeks on it and it looks perfect on the website because you’ve manipulated the DOM just how you want it to. Well, I would bet money that’s not going to work on the SharePoint mobile app. That mobile app is looking for specific elements to function the way it needs to function and if you go messing with the DOM you stand a great risk of actually breaking that SharePoint mobile app. It’s one of those things that you really need to be careful with what you’re doing. I use the term, it’s not the Wild West of the SharePoint development anymore. There are rules you need to follow to help make sure we get the best experience on all devices it’s not just about the web page anymore.
[Tobias:] That’s what we’ve been saying for a long time. Don’t break your customizations because that will break SharePoint. I think that’s actually a good approach with thinking about the mobile, especially since mobile first is a big thing with Microsoft today. Because I know a lot of people who’re customizing their pages not specifically modern team sites but in general in SharePoint, they’re never or very seldom testing for the mobile. They just test different browsers, different browsers stacks and that works and they are happy with that. But with the modern team sited being natively mobile friendly and supported of mobile I think that’s a very good tip to keep in mind that you might otherwise miss not knowing that the mobile pages or the mobile rendering is actually looking for specific things in the DOM.
This whole modern approach in modern team sites what if I want to keep the classic sites and I want to keep customizing them? Can I do that and is it a good idea? Obviously, I would say not for the reasons we already brushed upon but can I opt- out of the roll of modern team sites and lists? And would it be okay or are we breaking some of Microsoft’s recommendations by stepping back and saying, ‘’I want to remain on classic mode.’’?
[Mark:] That’s probably going to be a little bit of a religious debate I would say for some people. There are people who’ve gotten so much functionality created using this client-side techniques and they’re looking at the fact that it’s not going to work on the modern sites. And a lot of people don’t like the modern sites and again a lot of it is because of that change but currently the modern sites aren’t as fully functional as classic sites. You can actually specify in your admin panel in Office 365 that you want to have the classic or modern experience and you can also specify those settings in your library setting on your list of libraries to say you want classic versus modern views of those.
If you do accidentally switch to classic mode all you have to do is clear your cookies because that is just actually setting a cookie signature in the modern view now. Microsoft has said they have no plans to get rid of classic view. They’ve said that multiple times now and what that really says to me is that they’re looking at the telemetry. They’re seeing how many people are using classic view and how many people are using the modern view and if that telemetry ever makes sense to them to switch and get rid of classic view it wouldn’t surprise me if they did some day.
So I tell people, ‘’If you like classic view make sure you switch to classic view. Let that telemetry show that you are still using and you still need it.’’ because there are reasons to keep it for those customization reasons that we don’t have those customization options currently in the modern stuff.
[Tobias:] In general, I actually think they will approach with the modern team sites and modern lists and kind of follow suit with what Microsoft said a few years ago. Less customizations is better. Try not to customize too many things and specifically master pages like we mentioned and things like that. Like you said, it’s a religious debate whether you should keep classic and do all of your customizations the way you used to do or embrace the modern team sites and let go of the control of most of those customizations and actually use the product that rolls out and get those updates.
[Mark:] Yeah, and as a developer it hurts to lose that control because it’s fun to get there and do what you want to do. It’s hard to back away from that and just say ‘’No, we shouldn’t be doing that.’’
[Tobias:] As a developer that might be the case but in the end there has to be a use case for those customizations for the customer who benefit off the customer. I guess that’s where the question lies is, is it going to make more sense if we customize it or is it going to make more sense if we go with the rolling updates from Microsoft? And that’s also something you can debate until eternity of course.
Many things have changed since we started with SharePoint back in the day and the key takeaway for myself is keep your customizations under control, specifically with client-side now being the new black. There’s no bigger threat to your upgrade abilities, stability and security than customizations just running wild in your environment and that goes for both, on-prem and in the cloud. But what about you? If you were to list a few key takeaways for people customizing SharePoint using client-side development techniques. what would they think about in general?
[Mark:] Again, it kind of goes to what are your long-term goals. Do you want to go to SharePoint Online if you’re not there today? Do you want to embrace these new modern team sites? And if your goal is SharePoint Online and these modern team sites then you really need to look at changing the way you’re doing things today. You need to look at using the SharePoint Framework. You have to gather your master pages and stop making changes to your master pages and adding the script references there. You can’t modify those SharePoint Forms anymore so if that’s the approach you want to take you’ve got to make some changes today to get ready for that.
In fact, I’ve got a blog post that I’m posting this week about 5 things you should probably stop doing if you want to embrace modern team sites. Quickly, those are you shouldn’t be editing your pages in SharePoint Designer, and in fact no matter what you shouldn’t be editing anything in your SharePoint designer because it just opens up so many problems if you do that.
Adding script references to master pages, modifying those default forums by injecting script, manipulating the DOM we talked about. If we’re not changing the page too much it’s going to break your mobile view in the mobile app. You need to look at getting out of content in your web part even and going to those SharePoint Framework client web parts.
Because those client- side devs are going to get some great benefits out of the SharePoint Framework that they don’t have if there’s a Content Editor Web Part. I have people all the time who come to my blog and they’ll copy scripts from three or four blogs, throw them on a page and the page just blows up and they leave comments on my blog saying, ‘’Your script doesn’t work.’’ It’s because they didn’t understand what they were doing.
With the Framework it’s going to give more control and it’s going to give them script isolations so they’re not stepping over other scripts on the page. It’s also going to keep non-developers from running client web parts which is actually a good thing because it stops people from just throwing things on a page, having the page blow up and contact support, so it’s just some things you can do there.
[Tobias:] Cool. Those are some great tips and speaking of that blog post when that’s published I’m going to put that in show notes so that people can access that as well.
[Mark:] Excellent. Thank you.
[Tobias:] So is there anything else? I think I’ve brushed all the things I had in my mind. Do you have anything else you’d like to share about the client-side dev story?
[Mark:] I think the future of cloud development is its client-side dev. Well, it’s not the future, it’s kind of the present now. It’s a skill.
[Tobias:] It’s already here.
[Mark:] Yeah. I remember back when I was doing it in 2009 people were laughing at me and now I get to laugh at them. But it’s a skill that is going to carry you even outside of SharePoint because of the new tooling, because of the new APIs you’re no longer just a SharePoint developer you are now a client-side developer. You are this what they say full stack client-side developer.
You can take these skills outside of SharePoint. You can now hire people who don’t know SharePoint and get them up to speed quicker. So if you don’t have these skills these are great skills to invest in. Look at things like learning JavaScript, jQuery and TypeScript, so you can take full advantage of the SharePoint Framework. Take in the SharePoint Framework and break it. You’re not going to hurt your Forms, you’re going to be pre-hurting your web parts. So, play around, don’t be scared to try things.
[Tobias:] That makes perfect sense and there’s a lot of resources specifically on the SharePoint Framework now both from Office Dev PnP, we have Waldek in our team who’s blogging like a machine just blog post after blog post on how to do that stuff. I think that’s a good requirement. Just hit it, create a sandbox for yourself or a playground and just get over that threshold you mentioned before with the tooling and start playing around with it. And then you have all the modern tools you need for modern SharePoint client-side development, right?
[Mark:] Exactly. And like I said, Waldek is a great resource. He really helped me get over some early hurdles and again, Andrew Connell his course over at Voitanos. And I actually have a session that I have created that I’m going to start presenting and that session is going to walk you through the process of converting one of those Content Editor Web Part customizations to the SharePoint Framework. So be looking for those conferences that they actually let me speak at.
[Tobias:] That’s awesome. I’ll put your blog and whatever sources you have for those articles you mentioned you’re going to be publishing. And if you published your session as well, I’ll put that in show notes so people can download and go look at your blog as well.
[Mark:] Great. Thank you.
[Tobias:] So with that said, Mark, thank you a lot for joining us today for the show and thanks for the insights and I hope to catch you again soon for this show or otherwise I can still see you at the next conference somewhere around the globe.
[Mark:] Absolutely. Thanks for having me, Tobias. I greatly appreciate having the opportunity.
[Tobias:] Anytime. See you next time.
[Mark:] Take care.
