Thanks for that.
Whats MVC got to do with it? Thats about as relevant to the discussion as procedural to OO. Whether you are using procedural, OO or MVC the benefits of splitting HTML and PHP code stand.
Both can co-exist and IMO should. So separate business and viewstate logic (combined the application code) and separate application code from UI code.
Well that depends on your approach and how you optimize. Strawman argument I'm afraid; lots of those in your post.
I would disagree.
Maybe we should use HTML as originally conceived as well, lets jump back to 1990's style HTML and ditch CSS shall we?
I'm sorry but PHP is a whole different animal to what it was back in the day and applications as a whole have gotten so much more complicated and the types of people responsible for and working on websites has changed. Thats an unavoidable business reality.
Great, I use a custom built template engine, which isn't as rudimentary as the one you've just knocked up but certainly involves no bloat at all.
Love the strawman argument there, pick out a bloaty and not so great template engine and use that as the benchmark argument for not using template engines. How about I pick out the nastyest, most bloaty and bug laden MVC framework I can find and use it as an argument against MVC?
My template engine is one class library with 6 methods, totaling about 300-400 lines of code, which parses templates, handles replacement variables, variable registering, in-line conditionals where required, caching and template validation.
Invoking a template is 1 line of code + variable registrations (so that designers cannot access vars they aren't supposed to).
I could write an application procedurally and use exactly that same argument, but it wouldn't be good enough and neither is your argument. I find it amusing that in your argument you've resorted to implementing some kind of template engine to prove your point.
As for saying designers are stupid if they cannot handle <?php blah blah ?>, thats not really the point in address, the point in address is designers accessing PHP scripts and modifying blocks of code that could be unwise for a non developer to be making alterations to and of course keeping code clean and UI nice and modular.
Thats true, because you just devised a lean template engine and compared it to two bloated ones.
Well what you just created is a template engine of sorts. Using a good template engine, whether 3rd party of bespoke is furthering proper code organization, not an either/or.
So now we are onto the designer is lazy if you don't want them modifying application code. Maybe we want our designers to be experts in UI design and our programmers to be experts on programming. Maybe we don't want designers modifying bits of code they may not understand.
I wasn't demanding Smarty or Twig, I was stating that template engines as a whole are not a bad thing; which is what you said. I personally use neither of those solutions, I use my own bespoke solution.