A Solution Looking For a Problem

I’ve recently came across few articles explaining how we can get Laravel’s Blade and Angular.js to work together.

For those unfamiliar with the terms, Laravel is a rising star PHP web application framework and Blade is its template engine responsible for meshing up web page templates with data models to render dynamic web content.

Angular.js is of course the brilliant client side web application framework from Google, allowing the development of complex web applications directly in the browser in following well structured MVC paradigm. Angular’s template engine is HTML itself (how native is that!) with very little angular specific markup, since angular essentially allows us to extend HTML itself by writing new directives.

Incidentally, both Blade’s data echoing tags and  Angular’s data binding tags use the same double curly braces notation, which of course would confuse Blade when it tries to compile our page containing the mixed tags. Let’s see a small example:

<strong>{{ $name }}, please provide your email address</strong>
<div ng-controller="myController">
    <input type="email" ng-model="vm.person.email">
    You have entered: {{ vm.person.email }} <!-- Blade is not going to like this -->
</div>

Luckily we have two options to resolve this conflict, the first is to use Angular’s $interpolateProvider and replace the double curly braces with something else (for example [[ ]]), and the second is to change Blade’s tag notation to something else.

So Where Is The Problem?

The problem does not lie with the proposed solution described above; it is actually the right way to solve the problem. The problem is that we’re even trying to do that!

I’ll explain. For many years we’ve been generating dynamic web content on our back-end using server template engines. This is how we did it with Java servlets (${ …. } ), in PHP web apps (<?php …. ?>), ASP.NET (<asp:tagName ….></asp:tagName>) and so on.

Along time, development practices have evolved and today we have a wealth of mature web application frameworks such as Django, Spring, Laravel, Ruby on Rails, CodeIgniter and Express to name a few. Each framework ships with its own or default template engine which we replace with any other supported template engine we choose – and there are many to choose from: Jinja, Jade, Mustache, Blade, FreeMarker and the list goes on.

These template engines are very strong and allow us to do template inheritance, template blocks/snippets inclusion, provide looping and logical constructs and many other features making the work of generating dynamic content a breeze.

Now we’re getting to the point: the point is that we should not be using them at all! Historically we had to use them since there was only HTTP POST/GET for entire pages. Then AJAX came along allowing us to perform asynchronous server requests and then manipulate the DOM, and nowadays we have frameworks like Angular.js and Node.js Socket.io which provide asynchronous and push communication capabilities. But despite all these advancements, many developments carried on today still follow the same old paradigm of generating the front-end on the back end side!

If this was not clear enough – I’ll repeat that: many web applications developed today render their front-ends on the back end using template engines. As far as I can tell this is profoundly wrong.

The Right Design Approach

The back end should focus entirely on providing an API for the front end, while the front-end should consume that API and handle the application logic and view / user input. That’s it.

For example, a Laravel based web application can expose a JSON over REST API to access system resources, with the front end Angular.js application consuming that API and handling all frontend logic and display/view. Since our back-end now only exposes an API, the template engine (Blade) is not required at all.

This approach produces a well structured application with properly separated application layers, elevating separation of concerns and a myriad of beneficial aspects design-wise.

Having Said That…

I’d like to make an exception. There are some use cases where the template engine is actually required, for example when sending email from our back-end application server; we could generate nice looking html templates and use the template engine to render personalized emails for us.

If you have other exceptional use cases I’d be happy if you shared with me.