When it comes to sharing template rendering responsibilities with the client, there are certain limitations in the template rendering workflow that we need to acknowledge. First, and foremost, template files are defined on the web server.

Let's consider an example that follows the classic web application architecture to fully understand the limitations we face. Here's an example of server-side template rendering using a template file, edit.html, taken from the Writing Web Applications article (https://golang.org/doc/articles/wiki/) from the Go website:

func editHandler(w http.ResponseWriter, r *http.Request) {
  title := r.URL.Path[len("/edit/"):]
  p, err := loadPage(title)
  if err != nil {
      p = &Page{Title: title}
  }
  t, _ := template.ParseFiles("edit.html")
  t.Execute(w, p)
}

The editHandler function is responsible for handling the /edit route. The last two lines (shown in bold) are of particular interest for our consideration. The ParseFiles function in the html/template package is called to parse the edit.html template file. After the template is parsed, the Execute function in the html/template package is called to execute the template along with the p data object, which is a Page struct. The produced web page output is then written out to the client as a web page response using http.ResponseWriter, w.

The drawback of rendering templates in this manner is that we are anchored to the server-side file system, where the edit.html template file resides. The dilemma we face is that the client needs access to the contents of template files in order to render a template on the client-side. It is not possible to make the ParseFiles function call on the client side, because we don't have access to any template file that can be read on the local file system.

The robust security sandbox implemented in modern web browsers, prevents clients from accessing template files from the local file system, as it rightly should. In contrast, calling the ParseFiles function makes sense, from the server side, since the server-side application can actually access the server-side filesystem, where the templates reside.

So how do we get past this roadblock? The isokit package comes to our rescue by providing us the capability to gather a group of templates from the server-side file system, and create an in-memory template collection, called a template set.