3 ms·
The very restrictive nature of a template pseudo language is one of its beneficial attributes. If, for example, you use PHP to create your templates then the ve
by NathanKP 14y ago
The very restrictive nature of a template pseudo language is one of its beneficial attributes. If, for example, you use PHP to create your templates then the very power and flexibility of PHP allows you to make a "quick fix" for a model issue in the template, or a function call from the template, and next thing you know your template is no longer just a view, but instead a messy hodgepodge of code along the lines of what you often see when you open up the typical WordPress template.
The template pseudo languages enforce a strict separation between model and view, and they typically do so with a much more concise syntax and legible format compared with embedding PHP in HTML, for example.
I used to prefer general languages for templating, but once I learned the pattern of using Twig to the full I found that I could create templates much faster than before, and I could also go back to a template after a couple months of not looking at it and quickly understand what I was looking at.
- diminish 14y agoSomehow I expected, the valid argument against business logic mixing inside templates, making the case for a template language. I agree, but that way we are progressing towards dozens of languages in implementing a simple user function. For example, why not a language for controllers, and another one for models too? In contrary, I am in the pursuit for the one universal language to be used everyhere replacing, javascript, html, css, templating language, ruby/python/php, sql..
- chc 14y agoYou'd probably like Clojure. As an aside, though, part of the reason we have different languages for things like backend code, markup and styling is that they're commonly done by different people with different specialties. A general-purpose language will not offer much benefit to a designer, but it will trip them up more often. Having a language tailored to your specialist is a good thing. The only time you'd really want everything done in one language is when the same coders are doing everything. I admit I'm in that situation very often, but it's more maintainable if you just use CSS or similar so that normal front-end guys can work with it.
- NathanKP 14y agoThat makes sense. Ideally it would be nice to have one common elegant language which can do it all. But I doubt that any one language can do everything elegantly. The syntax of some languages make them much more elegant for certain purposes. For example compare XML and JSON. JSON is great as a lightweight way to represent simple objects, but XML is better for representing entire HTML documents. Likewise you can do all your CSS stuff by manipulating DOM properties in JavaScript, but pure CSS is a cleaner and more readable way to do things because it only does styling statements. (Unless you go out of your way to put logic into your CSS.) The bigger the project is the more you have to favor readability and maintainability first, and using multiple specialized languages to accomplish different specific tasks is an effective way to keep the codebase readable and maintainable.
- JeremyMorgan 14y agoThis is a very good point. Sometimes those "quick fixes" really aren't the best idea, I myself used to "hack" so much stuff in Wordpress when I was using it, and yes I solved whatever problem I was having at the time, but a few updates later it would come bite me in the you know what. So much of programming is protecting the programmer from him or herself. By enforcing rules you protect yourself from bad habits. I think a separate template system and keeping the view separate would help keep everyone honest. Eventually I started to do my modifications as plugins, which is one area where Wordpress really shines. Other systems could definitely take note of the way WP handles plugins.
- smacktoward 14y agoJust sandboxing what changes themes can make to the behavior of the system would be a win. As far as WordPress is concerned today, there's "themes" and there's "plugins", but there's no separation of what those two things can do -- plugins can change the site's look and feel, themes can change how the site (and WordPress itself!) works. As far as WP itself is concerned they're both just big bags of PHP code that can do anything PHP can do. That leads to all sorts of debugging fun when something weird is happening, and opens up naïve users who assume that a "theme" is somehow safer than a "plugin" (because all themes do is change the look and feel, right?) to security risks from downloaded or hacked-up themes.