I've noticed a massive trend of users using JSLink for customization, while I've always found it to be a bit of a pain. What does the community think?

  • I only use it to customize views. For forms, I put a CEWP on the page and use Jquery, SPUtility.js, and SPServices.js.
    – mannaggia
    Mar 24, 2017 at 18:25
  • Do you mean JSLink as what it is - a mechanism for loading Javascript files? Or do you really mean Client Side Rendering (CSR)? (Which many people confuse with JSLink since you often use JSLink to load CSR files.) Mar 24, 2017 at 18:43
  • @mannaggia you can use JSLink to load all of those script files, it is not restricted to CSR scripts. Mar 24, 2017 at 18:44
  • I am referring specifically to JSLink - the mechanism used to load script files (CSR included). Mar 24, 2017 at 20:25
  • Yes, I was just saying that's the way I do it.
    – mannaggia
    Mar 24, 2017 at 20:47

3 Answers 3


I use JSLink a lot, sometimes for CSR, and sometimes not, and so, from the perspective of JSLink is a mechanism to load scripts in different places, and is not directly correlated with CSR, here's my thoughts:

In the comments above @mannaggia says that for customizing forms they usually add a CEWP to the page and link in scripts from that. But why bother adding a CEWP, when you can just edit the form web part and pull in the scripts using JSLink? I've done plenty of form customization with the JSLink on my form web part set to something like


where the "MyCustomForm.js" is doing all kinds of DOM manipulation, making REST calls to get data from other lists and render it on the form as well, you name it, but it's not doing any kind of CSR or linking in to the CSR framework.

Then on the other hand, I do use it for CSR as well, and in that sense it really handy that there is a JSLink property on fields themselves, so you can dial up your custom rendering for a particular field, and then make sure the script is linked to no matter where that field is used. You don't have to worry about "oh, what happens if a user adds a LVWP to this other site page, I'll have to make sure to add the CSR script there" because it'll be there already because it's attached directly to the field.

So I guess, Pros for me include:

  • Being able to load any scripts I want to pages with LVWPs or form web parts without having to figure out how to add <scrip src="..."></script> tags in the HTML of the page somewhere.
  • Ensuring that CSR scripts follow the things they are rendering around wherever they go. Or even any scripts I want loaded when, say, a certain field is present.

As far as Cons, I can't really think of any except that, as @DannyEngelman mentions, JSLink is disabled in the "Modern Experiences" in SPOnline/O365, which you might consider a problem if you've done a lot of CSR customization and you are in that environment.

In my particular case, however, I am on-prem, so JSLink is available to me.

  • And then one step further is UserCustomActions. JSLinks are still tied to pages so there is some maintenance and governance. With a UCA Scriptlink you have one file which checks which page its on and does what it needs to do. That is only one file to maintain for the whole SiteCollection. Tomi Tavela SPEditor is the tool to manage UCAs Mar 25, 2017 at 11:43

Strictly speaking it is not JSLink.

You are programming CSR : Client Side Rendering and JSLink loads your CSR (JavaScript) files

It is only JavaScript your are programming with,
and you use the CSR Library/Syntax to talk to SharePoint

You don't need JSLink to load CSR files,
and JSLink can load any JS file (like jQuery), it doesn't have to be CSR code

CSR/JSlink was introduced in SharePoint 2013

So I guess it has been around for 5 years now (counting the early previews)

It never got popular with .Net heads because they (in general) dislike JavaScript.
Some MVP 'wizards' still refer to JavaScript as "rogue" scripting.

Then Microsoft created TypeScript.. which IS ECMAScript 6 (JavaScript) with some sugar on top.

And now SPFx "gurus" develop in TypeScript ... producing stupid JavaScript code patterns because they never learned JavaScript.
(learn the Array map and reduce methods if you are reading this!)

Important to know is that all that CSR stuff does not work in Microsofts "Modern Experiences"

They have disabled JSLink and UserCustomActions (in Modern Experiences) a year ago, and have yet to come up with an alternative. Latest information is that they are working on "Scenarios" and "CodeParts" to allow scripting and branding, but no-one has a clue what they mean by that.

In every presentation they repeat the words:

"We want to protect you from making [javascript] mistakes"

So I guess Microsoft still thinks JavaScript developers are morons...

Anyone interested in JavaScript and SharePoint must be aware of these tools:


Another plus for using JSLink on a view instead of using CEWPs - CEWPs on views will force the ribbon to be initially hidden, so you've got to click in the data of the list to show the ribbon. JSLink doesn't cause that.

For forms, I've used CEWPs for my scripts they're second nature to me. All my code is located in files I store in the SiteAssets library, whether I do CEWPs or CSR JSLink stuff, so editing it basically the same. CSR is more complex for me since I'm used to JQuery/SPServices type of edits - I can do those in my sleep.

  • The Ribbon is hidden by the JSLink to a Microsoft CSR file already on every view. There is a design flaw in JSLink. So when you add a WebPart JSLink it effectively cancels out all View JSLinks. If you attach that (I think its clienttemplates.js) CSR file as WebPart JSLink then you will get the same behaviour Mar 25, 2017 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.