Applies To: SharePoint 2013, 2016, Office 365
List View Client Side Rendering Primer: 2 of 5
About This Series
This series provides a brief overview of Client Side Rendering for List Views (often referred to as JSLink). Basic extension points and examples are included. The goal of this series is to get developers unfamiliar with this programming model quickly up to speed.
- An Introduction to Client Side Rendering
- Benefits of Client Side Rendering ⇐You Are Here
- Getting Started
- List View Extension Points
- Client Side Rendering Best Practices
XSLT Alternative
Extensible Stylesheet Language (XSL) is the XML based language used to transform XML generally into either HTML or XML. XSL Transformations (XSLT) is the set of XSL templates to be used in specific transformations.
Benefits
- Rendering performed Server-Side
- Very Fast
- Generally, great caching
- Many traditional SP developers already have XSL knowledge
Limitations
- Difficult to learn
- Out Of The Box (OOTB) examples are overly complex
- Impossible to debug
- SP limits use to XSLT 1.0 which, even with the ddwrt functions, is not equivalent to the power of XSLT 2.0+
- Office 365’s server distribution model negates many of the caching benefits seen in on premises versions (although still fast, large datasets and complicated transforms suffer from more performance issues in the cloud)
- Non-XSL integrations (JavaScript, CSS, etc.) can be very difficult
XSLT is continuing to be supported (and even improved) in current versions of SharePoint. Many of the OOTB features continue to take advantage of it and there is little alternative in SharePoint 2010/2007.
XSLT continues to be an easy way to make minor tweaks to OOTB rendering. Additionally, there is no reliance on end user technologies (JavaScript and, depending on the complexity, modern browsers) since the rendering is performed on the server before being delivered to the client.
Client Side Rendering Benefits
- Data retrieved Server Side
- “Faster” page loads since only the data and the formatting logic is downloaded to the client and the markup is created there. Practically speaking, standard pages will not see much benefit from this.
- Rapid development (debugging, simplified templates, etc.)
- Many more JavaScript developers
- Flexible Targeting
- Easy integration with web services, JavaScript frameworks, etc.
Client Side Rendering Limitations
- Potential for flashing based on client performance
- Not fully supported – Display templates are used in some search web parts, but only the XSLTListView web part provides the JS Link property
- Targeting multiple list views on the same page requires fragile or hacky workarounds
csrShim
csrShim is an open source solution that fills the gap of many of the limitations presented by OOTB client side rendering.
csrShim is an XSLT solution that can be used to:
- Enable JSLink CSR with Content by Query web parts
- Enable JSLink CSR with XMLViewer web parts supporting RSS, RDF, Atom, and Atom2
- Can be easily extended to enable JSLink CSR with XMLViewer web parts and custom XML
- Solve the multiple list views per page issue through simple parameter configuration
csrShim is available through GitHub at:
https://github.com/thechriskent/csrShim
Continue?
Alright, now you know why CSR is usually better than its predecessor, XSLT. You’ve gotten a small introduction to csrShim (although not required in any way for this series, the methods and techniques discussed for list view CSR will apply there too).
“CSR sounds awesome!!”, you scream. Well, since you’re super excited to give this thing a go and avoiding eye contact with your coworkers is probably a good idea right now, head on over to the next post in this series:
