1. PHP as a templating language

    There’s been quite a bit of talk, recently, in PHP-land about templates and the ramifications of enforcing “pure” PHP scripts by preventing scripts from entering HTML mode. I’m not quite sure how I feel about this RFC, but it got me thinking about the whole idea of using PHP for templating in modern web apps.

    For many years, I was a supporter of using PHP as a templating language to render HTML. However, I really don’t buy into the idea of adding an additional abstraction layer on top of PHP, such as Smarty (and many others). In the past year or so, I’ve come to the realization that even PHP itself is no longer ideally suited to function as the templating engine of current web applications — at least not as the primary templating engine for such apps.

    The reason for this evolution is simple: modern web apps are no longer fully server-driven.

    PHP, as you know, is a server technology. Rendering HTML on the server side was fine for many years, but times have changed. Apps are becoming more and more API-driven, and JSON is quickly becoming the de facto standard for API envelopes.

    We can no longer assume that our data will be rendered in a browser, nor that it will be rendered exclusively in HTML. With Gimme Bar, we render HTML server-side (to reduce page load latency), in JavaScript (when adding or changing elements on an already-rendered page), in our API (upcoming in a future enhancement), in our iPhone app, and certainly in other places that I’m forgetting.

    Asset rendering in Gimme Bar can be complicated — especially for embed assets. We definitely don’t want to maintain the render logic in more than one place (at least not for the main app). We regularly need to render elements in both HTML and JavaScript.

    This is precisely why we don’t directly use PHP to render page elements anymore. We use Mustache (and Mustache-compatible Handlebars). This choice allows us to easily maintain one (partial) template for elements, and we can render those elements on the platform of our liking (which has been diversifying more and more lately, but is still primarily PHP and JavaScript).

    Rendering elements to HTML on the server side, even if transferred through a more dynamic method such as via XHR, really limits what can be done on the display side (where “display side” can mean many things these days — not just browsers).

    We try hard to keep the layers our web applications separated through patterns such as Model/View/Controller, but for as long as we’ve been doing so, we’ve often put the view bits in the wrong place. This was appropriate for many years, but now it is time to leave the rendering duties up to the layer of your application that is actually performing the view. This is often your browser.

    For me, this has become the right way to do things: avoid rendering HTML exclusively on the server side, and use a techonology that can push data rendering to your user’s client.

    9 Responses

    Feed for this Entry
    • David Yell

      2012 May 14 11:19

      I've read this twice and I'm still not sure I get it. Do you mean build the whole app in javascript? So the whole interface is rendered using AJAX?

    • I've been following this trend for a couple years now, and it does seem, indeed, "the future." That said, there are a number of places where I have doubts.

      While I like the idea of primarily rendering client-side, it falls apart for me when I consider users with JavaScript disabled (certainly a minority), and accessibility. In these cases, it feels imperative to deliver a full HTML document created on the server, to ensure these users are able to get at content and interact with the page.

      There are solutions, of course -- many of the client-side libraries have ports in PHP as well (hell, I wrote a Mustache port to PHP myself) -- but these often have small disparities that can lead to client-side issues.

      I'm curious if you could blog more on how you might handle such situations, and how you handle delivering HTML from PHP, when not embedding.

    • David: some of our pages are rendered primarily with JavaScript, via XHR ("Ajax"), yes.

      MWOP:
      Most of Gimme Bar simply doesn't work with JavaScript disabled. We're mostly OK with that to be honest. I realize that not everyone has the liberty to make decisions like this, but luckily, we can.

      When not embedding, we use a PHP Mustache renderer on the server side. This allows us to maintain one set of templates that work in both places (aforementioned disparities notwithstanding).

    • When Ed tweeted a while back about not generating content in PHP anymore, I laughed it off as Ed being crazy (again).

      Just a few days later I looked at code I was writing for Natural Load Testing. I was initially creating a results table in PHP, then further populating that form using JavaScript as more data became available. It didn't take long for me to drop the PHP creation, and create it exclusively in JavaScript.

      Not being as skilled with JavaScript as I am with PHP I tend to build pages in PHP until some sort of Ajax based update is required, then I flip the switch over to doing it client side.

    • Good post, thank you. I thought I was getting smarter by building markup in my PHP into functions but am reconsidering it altogether due to the repurposing issue. Even if it is as simple as templating for a 'regular' browser I am switching back to client side structures and server side information sources, née PHP. 

    • Another option, using Twig (which I find a bit more expressive and complete than Mustache) is to use either the pure-JS implementation of twig (https://github.com/justjohn/twig.js) or the other implementation which basically compiles your twig templates to JS code (https://github.com/schmittjoh/twig.js). The latter sounds interesting because you don't have to parse templates in the browser anymore, which definitely has a runtime cost.

    • XSLT works well in this regard for us.

    • Pawel Kalisz

      2012 May 16 02:24

      This is really interesting approach. Especially if we consider using APIs in our applications which became quite popular. I am currently working (actually right now ;)) on project which uses this sick method of sending rendered HTML via XHR, and I must say that it makes mi depressed. It is hard to maintain such code and even small change may be very dangerous. Although I am not a JS fan, I think that for example Google Closure Templates is perfect solution and it may works fine in your approach.

      However I can't find myself using only JS for rendering for pages which are not using XHR...

      Thanks for interesting article! :)  

    • To render server-side or not to render server-side? I think it has to be decided on a case-by-case basis. Does pushing lots of HTML over the connection take time? Yes, but server machines are usually faster than client machines... and what if it takes some real computation to generate that HTML content? What if it takes a significant-sized Javascript program, which then must be transmitted to the client?

      So at least in some cases I'm not ready to give up on server-side rendering. Another advantage of doing things server-side: you are free to use whatever language you want to manipulate the page structure. For example, I like working with Scheme for rendering - http://gcbenison.wordpress.com/2012/02/19/guile-vs-php/