Not too long ago I had the displeasure of using Smarty in a PHP project for a major client. You’re probably wondering what the heck anyone would be using Smarty for in 2012… well, lots of turnkey systems (shopping carts, CMS, etc.) built from 2007-2010 use all sorts of templating engines, but Smarty, at the time, was definitely the most popular. These days, I guess PHP developers have wised up to what I had been saying for years, since you don’t really see these things being used anymore. Old-school templating engines had many obvious problems that nobody really thought of, while they were busy worshipping the concept of model-view separation. Don’t get me wrong, there’s nothing inherently wrong with this line of thinking, but… why did this seem to always necessitate the creation of an entirely new programming language? Did the Smarty people forget that PHP itself is already an amazing text processing language, and doesn’t really need an additional templating language written on top of it? To be fair, there are some nice templating engines out these days that use PHP itself as a templating engine, but honestly with good development practices, you can adequately MVC your way through a project without the need for a templating engine. If it scares your designers, then hire new ones. So anyway, the team got together and we basically all said, “is it just me, or is Smarty, well, stupid?” Unfortunately, we were stuck with it, so it didn’t matter that the development team loathed it.

I believe that templating system fiasco of yesteryear serves to prove an important point: the web development fads of today may or may not be the practice of tomorrow. It’s incredibly important that you don’t unnecessarily tie up thousands or millions into a project because it “has to be done in Node.js-SproutCore-Backbone-ExtJS-Coffeescript-SASS-HAML-960gs-Bootstrap-NoSQL”, or whatever bleeding edge technology stack of the week. It might be the hipster CTO thing to do, but keep in mind: some of these technologies may be keepers, but half of these technologies will be long forgotten in 3 years, and one or two of these will make your new programmers laugh, then hard-time you until you pay them to rewrite it in something more sensible. There’s a reason Java, .NET, and PHP continue to thrive, while stuff like Python and Rails seem to have peaked last year could be going the way of Perl and Tcl/Tk. They’re proven scalable, they have support of millions of developers, they have robust libraries already written basically everything, and they are used by the largest sites on the web. They may all be sugarless, downright ugly languages, but heck if they don’t get the job done everytime. I’m not saying all new technology is bad, obviously. Lots of amazing stuff has been popping up lately, but it doesn’t mean I’m going to rush out and use some unproven technology on a Fortune 500 company’s project, though I might experiment in certain places. There’s doing the cool thing, and there’s doing the smart thing. And yeah, I know it’s scary to use the “old way” on new websites sometimes, but I’ve certainly seen my share of situations where the old way was apparently done that way for a reason. Hopefully this doesn’t make me sound like a cranky old person afraid of change, because that’s not at all what I’m trying to convey, heh.