Web Development and Template Engines
While half of the web dev community was arguing about what not to use to build your webpage, master Alpha Blogger Jeff Atwood dropped a bomb on the heads of template engines lovers: template engines are pointless. Of course, answers were not late to pop up, on blogs and reddit.
Why did these template engines appeared anyway? Because, back in the dark ages of web development, a little after the prehistoric time (cgi and stuff), there was this bad practice that poisonned developers life: spaggeti code.
... [server side code to connect to the database] Page title [server side code to query the db and get some results] display those results [server side code to get some other results] display these other results etc
If you want to see some real world examples, get phpNuke or an older phpBB. There must be some fossils somewhere on the intertubes.
So, what did the scientists do?
They started by adding some sistematization to the scripts, like doing the whole data retrieve on top of the script and the output to the bottom. You could tell the designer: “Dude, don’t touch anything from here to here or I’ll kill you, infidel!” and that worked.
Then, because this wasn’t enough, the mighty scientists invented THE TEMPLATE ENGINES.
They did this to allow the developer to separate application logic from the data presentation. To be honest, I never felt that anyone is forcing me to mix them up and my application logic code was nicely up there in the top of the script, while the html part was way down there on the bottom. I usualy also had a comment line in between, the “don’t touch this part or I’ll kill you” part.
The scientists also believed that by introducing a new language, the template language, the designers could work on your script too. The reason why Smarty gained so much more popularity over patTemplates, apart the fact Smarty was/is developed by the php.net guys, was a Dreamweaver plugin that allowed users to do a bunch of stuff to the Smarty tags. For the younger generation, Dreamweaver was the abomination tool of choice for the 2000 and something era web designers to convert the psd/png images to html files (for the ones that actually did that…) But, I never found a designer that couldn’t grasp the simple PHP skills needed to do the display tasks, but was able to learn a template engine language. May my coffee be sour if I lie to you!
Yet another feature that was advertised by some template engines, was caching. Most people, managers, developers, designers, missunderstood this and the myth, that by using a template engine your application became faster, was born. Actually, the engine was marely caching its own operations so your scripts were exactly as fast as they were before you started using the template engine. If they didn’t suddenly became slower.
The only real benefits the template engines introduced were a forced organisation of the code and, in some rare cases, a way for the designer to mess with the scripts and stop bothering you.
Fast forward a couple of 3 years and now, the new toy for the web developers are the frameworks. The biggest benefit they introduced was code separation by task (this part is in bold because this is what Jeff Atwood does and the link is there for the same reason). As most of the frameworks implement a variation of the MVC pattern, you already have specific places where to write specific code: put the data code in the model, the bussiness part in the controller and the display in the view. Unless you have a special ability to do things wrong, there is no way to write spagetti code in this setup. So, the biggest benefit of the template engines is no longer needed.
However, now you are in danger of producing tag soup. Your web cooking abillities are dimished, from the delicious spagetti to the dull soup. And the web scientists considered now is the proper time to tell the designer to “keep your fingers out of my soup” and invented the code generating code. Very usefull thing if you write autogenerating forms. At least you don’t have to learn another language.
First candidate is Jeff Atwood. He pokes template engines because they tend to get complicated.
[...] but you can see where templating naturally tends toward a frantic, unreadable mish-mash of code and template — Web Development as Tag Soup. If your HTML templates can’t be kept simple, they’re not a heck of a lot better than the procedural string building code they’re replacing. And this is not an easy thing to stay on top of, in my experience. The daily grind of struggling to keep the templates from devolving into tag soup starts to feel every bit as grotty as all that nasty string work we were theoretically replacing.
Dear Jeff, I suppose you are familiar with an ancient programming concept, called functions. You know, you get a bunch of code, give it a name and replace all instances of that code with the name. Your code will look cleaner and it will be easy to maintain. Most “non sucky” template engines have something similar to functions, the sub-templates. Using the same principle, you can split your huge, unmaintainable and messy template and it will became smaller and easier to maintain. I am a genius!
Next on list is Aaron Oliver:
By keeping markup very far away from business logic, the core logic is more stable and there’s less temptation to mingle concerns.
You think your template code is better than Jeff’s mixed code? How is mixing VB with HTML worse than mixing Template Language code with HTML? They are both examples of mixing code with markup. There is no difference between a bad tag soup and a cocktail of VB and HTML, with JavaScript on top for flavour!
As a conclusion, you both are terrible wrong. There is nothing inherently wrong about any of the solutions, apart the guy that is criticising. Both complain the other solution is ugly, unmaintainable and a pain in the ass. But they are like that because of your own inability to do better. It’s like saying you drive too fast because the gas pedal is easy to push.
Enough fun, let’s go back to serious stuff, young padawan
The problem at hand is easy to describe: get some data from somewhere and display it to the user.
What are the solutions for this? Answers below.
1) Plain scripts
1) Get and prepare the input parameters (from POST, GET etc). 2) Fetch the data. 3) Prepare the data for output. 4) Output all the html, mixing code and markup.
This is the one and only real solution to the problem, all others are based on this and are just ways to accomplish the same thing easier.
Use this everywhere, if you can master it.
2) Framework with no templates for output
Same as above, but helps you separate the logic parts of the script and reuse the code. It will automatically prepare the input parameters (if the framework is a good one), gives you some premade data fetching code and it is pretty clear where you need to insert the display part, the mix of code and markup.
This is a smarter alternative to the first solution. However, it adds some overhead.
3) Plain scripts with a template engine
Same as the first solution, but you use a template engine to forcefully separate your main language from the markup.
Use this if you don’t want the overhead added by a framework and you find that mixing main code with markup it’s worse than mixing template language with the markup. You still get to learn a new mini language. Or you are a lucky guy that knows that smart designer.
4) Framework with a template engine
Separation with even more overhead.
Use this if the overhead doesn’t bother you and you work with that smart designer.
5) Plain scripts with markup generating code
Instead of writing markup by hand, some generator is used. The code and markup mix is hidden below a layer of functions/objects.
Use this if you don’t require any advanced markup skills. Also, see point 7 below.
6) Framework with markup generating code
OOP at it’s max. However, the generator might not be perfect and some complicated workarounds might be needed.
Use this if you like all the benefits of a framework, are not bothered with the limitations and you have doubts about your markup skills.
7) Plain script/framework with ajax
Instead of doing all the work on the server side, the display is delegated to the browser. The browser is already re-parsing your output to render it on the screen. You send data in a format the browser will understand (XML or Json), with no display indicators and the browser will display it as it sees fit. However, no browser can do that by itself and another application needs to be build, that will instruct the browser on how to display your data. While each of the logic tasks are now completly separated, the web server might not like it if your biggest bottleneck is the HTTP request itself and not the data fetching or processing.
This is a special case of the solutions 5 and 6.
Use this if you know exactly how your clients will react and the HTTP request is your main bottleneck: intranet apps.
Conclusion: as you can see, all solutions are based on 4 simple steps (see the first solution). If you have problems using the first solution, then you will have problems using any other solution. In the end, use whatever you want, but stop bashing other solutions just because you fail to use it properly.
