SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It only takes a minute to sign up.
Sign up to join this community
If I have the option of using XSLT or JSLink, which one shall I chose?
I don't know anything about JS Link and so far I have done all work in XSLT but I have heard JS Link is the future as there may not be no more XSLT developments in SharePoint. Is it true?
It depends on what you want to do with it.
The power of using JSLink is that it uses JavaScript and runs in the client and you can use all the powerfull JavaScript libraries and for its easy to debug. It is easy to change the fields appearing and add some nice functionality to views.
The weakness however is that JSLink runs in the client and it depends on JavaScript. Its slower than serverside code. All processing is done after all information is served to the client.
XSLT however is very hard to learn and to read but for some operations it still rocks. Its fast and not depended on the client on how and when some things are rendered.
If you want to do some counting in views for example I found it easier and better performance to use XSLT. For example you want only totals returned for a certain category. When using XSLT you do the serverside processing and only return to information you want to show. Using JSLink it would require getting all information to the client and do some clientside processing.
However doing some nice ui goodness like transforming fields into nice slides etc i think JSLink is the better choice
There are a few advantages of using Client Side Rendering VS XSL.
Performance – Because the rendering is done Client Side, the burden is taken away from the server. This means that the pages can load faster when using CSR. Ease of Development – Let's face it: nobody really likes XSL – especially in SharePoint. All web developers should be familiar with JavaScript, which makes Client Side Rendering a lot easier to pick up. This should mean reduced development time, and less bugs. Flexibility – You can chose to overwrite just a particular field, the header, footer, or the entire view. You can also extend it; you're not limited to using just SharePoint JavaScript to process the list, you can use the whole power of JavaScript, as well as any plugins such as jQuery. The good news is that you don't have to use the JSLink yet if you don't want to. All of the web parts still support XSL, so if you feel more comfortable doing it this way, this should still work. You can simply select "Server Render", and point it to a valid XSL file.
Please refer to this article to learn more about JSLink: http://www.rbradbrook.co.uk/Blog/Post/10/Introduction-to-Client-Side-Rendering-in-SharePoint-2013
For which / How do you want to use XSLT / JSLink in SharePoint? What kind of use case?
For now, I know that XSLT is being used for styling webparts, ex. CQWP. Not really sure if you can use JSLink to style that one.
I know this is an old question but I want to share my experience. I just started learning XSL and already know Javascript (JSLink). While I start liking XSL more and more I still prefer JSLink whenever it's possible. However, you can only use one JSLink file per page. If you have a few web parts which use JSLink, the chance it gets messy or complicated to maintain is pretty big. Assigning different JSLink files to seperate webparts on the same page is not possible, at least in my experience.. ;)
