Why does Jet have no templating system for views?
Handily, one could say: Because PHP itself is the best for that! This is exactly what PHP was originally created for. So why use anything else?
Well, I promised arguments. This may be an argument, but it's a poor one on its own. Let's take a look at it as techies and summarize the pros and cons. First, the arguments for the templating system.
Why have a templating system
Security
Better protection against XSS and "infesting" the output with unwanted code is probably the most common argument. And I say, okay, I'll take that, but ...
Is there no other way to handle this? And isn't the output generation layer the very last layer where security should be addressed? After all, the golden rule says that security starts at the input, and that's how you really need to start.
Some effort to secure the output is just a crutch, and it can actually subconsciously induce bad habits - like foolishly relying on it and not saving the input as much.
And last but not least: Isn't it a bit of a big-bore howitzer for rabbit hunting? Building an entire ecosystem and new technology that someone has to learn to have a coded output? I mean, that's insanely expensive. Either the development or the unjustifiably inflated demands on the learning curve.
Thus: I partially accept, but ... See below.
Separation of output from logic
But that's what we have MVC for, right? This is supposed to be solved by properly understanding the meaning of the architecture, because only a proper understanding is the way to a good result.
The templating system doesn't really bring anything fundamental to the issue of separating an application into layers.
It's cool! It's punk! It's got nicer syntax
Well ... That's purely subjective and unmeasurable, so sorry, I don't take that as an argument.
Delivering projects to clients on time, in perfect quality and for decent money that will last a long time is cool, and then going out to go clubbing with your friends is punk.
A templating system is neither. On the contrary, it makes it harder for me to achieve the given goal - i.e. maximum efficiency. See below.
Why not have a templating system
It's expensive and inefficient - in terms of finances
Yes, I put finances first. Because we do the work professionally, projects need to be financially competitive and so on. It's not a hobby, so it's about money first and foremost. Well, a templating system means problems for me from a financial and organizational point of view:
- The person who will develop the frontend must know the templating system or learn it. This further complicates my personnel woes.
- PHP is such a widespread and de facto standard technology that many people know it - at least the basics that are necessary for view development. There are X number of templating systems, and if I do X+1, it doesn't help the situation much and narrows the pool of potential colleagues for front end developer positions ...
- There are bound to be technical limitations of a templating system, or lack of knowledge of the people trying to use it. This will bring futile hours to the project - i.e. time spent unproductively. And in the end, someone will somehow bend it - reducing the quality of the project ... This is not good in the short or long term.
- In real terms, it can make the project more expensive - the customer then pays for something that does not deliver anything ...
It's technically inefficient
- No matter what you do, a templating system developed in and running on PHP will never be as powerful as PHP itself. Yes, templates can be "compiled" into PHP in various ways, but even then, it necessarily involves some overhead (CPU power consumption, memory, IO) that isn't really useful for anything. You have to check if you already have the template compiled and so on ...
- This often imposes unnecessary restrictions and obstacles. Various filters etc. Why? Why don't I just call a certain method when I need it?
- The modern IDE for PHP makes it incredibly easy to work with (I have one favourite in which Jet is created). If the IDE is to be effective, it must support the technologies well ... And PHP support is really top-notch nowadays and the work is comfortable ... Why complicate things with something non-standard.
- ... and to top it all off ... I've seen templating systems that allow you to insert PHP code into the template ... Thus, after a trip around the world, a bender brace was created :-)
Summary ...
I don't see a single argument that justifies bringing a new not-so-standard technology to projects. Both technically and financially it just doesn't work for me ...