JavaScript Templating with SharePoint 2013 (Part 1)

After a very long hiatus I am back hoping to contribute to the SharePoint community. It’s been too long. Today I want to touch on a subject that is getting much traction in the MVC and front end development realm: JavaScript templating. These developers have been quick to utilize client-side templating to build slick and user friendly applications. Beauty is nice but the major benefit is a no-brainer: increase performance due to a decrease in response payloads.

Although the benefits are awesome and obvious, the presence of client-side templating is rare in the SharePoint space, I don’t see it very much. I don’t even hear it talked about often. Let me say that I’m not dissing any one. I’ve been known to revert back to server side web parts in a New York minute. I think several SharePoint developers do the same. It’s because that’s what we’re comfortable with. It’s what we’ve done in SharePoint for years and it works over and over again. It’s like tradition! But a wise man once said “It’s also a tradition that times must and always do change my friend.” [2 bonus points to whoever can name that movie!]

This will be part 1 of a 4 part series involving JavaScript templating. In this post I’m going to lay a foundation for the next 3 posts. This one is heavy on text. The others will be heavy on screenshots and code…I promise!

Getting Started

So, the first thing you need to decide is what templating engine you want to use. There are several choices to choose from. All have their pros and cons. But the one templating engine that I’ve fallen slap-happy in love with is Handlebars. Again, it has some drawbacks but it’s incredibly easy to learn and the syntax just makes sense. My demos will all use Handlebars.

Identify Components

Most JavaScript templating engines require 3 components:

1) Data source

In this series I’ll cover a few different data sources:

  • In Part 2 of the series I will use a simple SharePoint list as my data source. We’re talking about JavaScript templating so I’ll need to get at the data from the client’s browser. Fortunately SharePoint has a REST API layer that will return list data as an Atom feed (XML) or JSON data. I HIGHLY recommend working with JSON. It’s much lighter than XML, which results in faster response times for users.
  • In Part 3 I’ll cover the very exciting SharePoint Search REST API. This will allow us to pull data from multiple lists and libraries within SharePoint.
  • In Part 4 I’ll dig into getting business data that doesn’t live in SharePoint. You’ll want to stick around for this one.

2) Data Retrieval

This will be the JavaScript that pulls data from the API. SharePoint has a JavaScript client object model but I do not recommend it. Why? The SharePoint team is embracing the web much more and so should we. I will use jQuery ajax calls to get data back.

3) The Template

This is the actual HTML that you want rendered. After data is retrieved we’ll bind it to our template to fill in the placeholders with useful information. Sounds kind of complicated on the surface but Handlebars makes this part easy.

One added layer of complexity with developing in SharePoint (or any CMS for that matter) is the need to encapsulate your component and make it modular. Unlike traditional development, you have to keep in mind that the user should ultimately be in control of what page and where on that page your template should live. Sounds like a web part to me! Technically you could bundle your template and the code for your ajax call in the html of your web part. But before you get too excited, please don’t. For ease of debugging and hygiene purposes, I recommend separating them into separate files.

Now that you have a foundation, let’s dig in. Stay tuned for the next post.

5 thoughts on “JavaScript Templating with SharePoint 2013 (Part 1)

  1. Michael Macias

    Definitely interested in the remainder of this series. Sounds exactly like what I want to achieve: SP2013, Handlebars.js and Sharepoint Client Side Javascript REST API.

    Can you clear up one line I stumbled on: “This will be the JavaScript that pulls data from the API SharePoint has a JavaScript client object model but I do no recommend it.” You do NOT recommend it? I wasn’t sure if you did or did not.

    Any time frame from completing this blog series?

    1. LesterLester Post author

      Terrible typing on my part. My apologies. I updated the post for futures but I should qualify my stance. I do NOT recommend using the SharePoint JS client object model for retrieving list data. In fact, if SharePoint was a web service endpoint I can use, I’ll always use jQuery instead of the SharePoint JS object model. I’m sure there are times using the SP JS object model makes sense. This, in my opinion, is not one of those times. Mostly I try to stay away from that object model because anything I build using the SharePoint JS object model is only good for SharePoint. Not to mention it is crazy complicated and within a couple versions, it will probably be considered useless information. Just my opinion.

      I look to post part 2 within the next couple of days.


      1. Michael Macias

        Thanks for the quick reply Lester!

        Definitely understand your logic about using the client side object model vs using the more web friendly standards that the RESTful APIs allow. Embrace the web indeed.

        Anxiously await Part 2. Thanks.

  2. Santosh

    I think when we have sharepoint webparts, why do we have to go with handlebars which serves similarly to webparts but with extra scripting from developers side. webparts comes with feature called content query and while we add handlebars to div elements we will have to query database from the client side.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>