No, my only issue is that PHP doesn't let you just echo the HTML directly, because despite being designed for generating HTML, the language doesn't actually know what it is.
Raw PHP is far from its roots as a templating tool and is a full featured programming language. I don't really see any reason why you'd want to use it for templates.
It's not that far. PHP is much better as a language than it used to be, but it's still a hypertext preprocessor (they can retcon the acronym but the language is still designed around taking requests and sending responses), and templating is still almost exclusively what it's used for, because that's what it's best at.
That's... what I just said almost everyone is doing with PHP, that and not much else. Those templates are what the "Hypertext Preprocessor" part of PHP is about.
OK, let me be clearer then. If PHP itself is just being used as a templating language, where does the demand for multiple templating engines implemented in PHP, and intended for use in PHP projects, with their own non-PHP syntax, such as Twig, come from?
Those engines provide features that PHP natively lacks, or doesn't support well. With raw PHP, you have to manually escape every variable with htmlspecialchars, or mix HTML and PHP contexts in a way that can make it difficult to reason about complex templates, (see: Wordpress) or separate concerns (anyone editing templates now has to know how to write PHP, because templates are just PHP.)
A template engine can give you context-sensitive escaping, template caching and inheritance, macros, and other features that increasingly become necessary for modern web development, and many of which you would probably wind up implementing anyway, once a project reaches sufficient scale and complexity. While raw PHP is arguably faster, it's also more difficult to do properly.
Also, culturally, the PHP community isn't as centralized as other web development language communities seem to be. It doesn't have one 'correct' framework or one 'correct' templating language you're expected to use, so there is competition between multiple engines.
But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.
Well, yes, exactly, that's why I recommended them, and then I get the objection that they eventually are generating strings. I don't really get it.
> But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.
Sure, that's what most PHP apps do... but it's also what most Rails, ASP.NET MVC/WebAPI, Spring, etc. apps do too. And it involves a fair bit more than templating -- database access, data validation, security, etc.
It's true that PHP is rarely used off the Web (although it's possible), but I can't see how what you're describing makes PHP different from any other technology commonly used for Web dev.
PHP is designed around handling HTTP requests and responses, so it already comes with a lot of the functionality you would need to import into other languages. Whether or not that's an advantage or a hindrance is in the eye of the beholder.
I don't think I would want to use just plain PHP and it seems like the frameworks that are popular nowadays kind of abstract over all that stuff anyway. In practice I don't think it makes much of a difference.
