PHP the Wrong Way

    
    {{ var | escape }}

A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP.

Though, some coding customers don't know what to make of it. Some people have trouble with not being able to see HTML in the code, because "where do I paste my Google Analytics code?".

No, why would it? What HTTP client framework am I supposed to be wishing they used?

Less flippantly, I've never actually used an ORM in a typed language, and I suppose it's plausible the concept offers benefits there which aren't available elsewhere, especially if arrays of mixed type aren't permissible. It sounds like your perspective comes from heavy, perhaps exclusive, experience with such languages. Certainly I'm not sure where else one might get the idea that the ORMless style "works well only with tiny applications written by a single person", or "in a large application you have to use objects and therefore ORM".

That said, what I've seen of the pervasively object-oriented model and how it's used in general leaves me with severe doubts about its value - it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. You end up with your application state torn into tiny shreds and scattered to the wind. Perhaps that's easy to reason about for some. I have not found it so.

But it has other advantages: you can use objects for your models, you can use lazy loading and relations between models, you don't have to save modified entities explicitly. So it helps to avoid writing low level code for saving and loading data from a database. You don't have to write routine methods like "get something by id", "get tags for post" or "update a field in a table".

> it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes.

That might be over-engineering. OOP doesn't require you to use every single pattern from a book or build multilevel hierarchies of abstract classes. Abstract classes and interfaces might be necessary when you try to build reusable libraries or components but you don't have to use them inside a monolith application.

But you need to learn things like single responsibility principle so you can divide complex tasks into smaller parts. You have to remember that your code will be maintained by other people so it needs to be easy to understand without searching through all the codebase and hard to break.

And whatever approach you use when you have an application with large codebase written by many people it will be complicated anyway. OOP can help you to organize this code.

> ORM in a typed language

PHP is not statically typed language but you can use type hints for functions. So if you have an argument with a class name specified you can quickly look up what properties and methods the object has (and your IDE will suggest autocomplete options). And you cannot have any such information if the argument is an array.

I used to work with large applications written using "SQL and arrays" approach and they were bad. I had to spend most time figuring out what kind of array is passed to some function and how it is used to display something on a page. And it is hard to check if you don't break something by removing or changing a single element in that array. That is why I think this approach is not scalable beyond small applications written by a single developer. It has no relation to whether mixed arrays are allowed in a language or not. You can get same kind of code if you misuse collections in Java or C# or maybe Go.

You can look at Drupal if you need an example of complex open source application with those problems. It passes a lot of arrays around that are not even documented anywhere. And as an example of OOP application you can see Magento. It is large and very customizable so they had to use different abstractions.

Garbage. You know it's going to be garbage when some idiot tells you not to use a framework but is too fucking stupid to realize that if you don't use one, you have to write one yourself. Every single time. And PHP as a framework itself? Please. PHP is a horribly shitty framework itself for any app that's going to be more than a couple hundred lines of code. It's only with a proper framework on top that it becomes a proper web development platform (some may argue otherwise but their ignorance can be safely ignored). But I assume the author has never written anything more than a demo app, so yeah, if you're writing short scripts under 500 lines, don't use a framework. If you're writing real apps, don't listen to idiots like this author. This isn't PHP specific. There's nothing that makes PHP different from Ruby or Python. Appeals to PHP having been developed for the web are idiotic because while true, it's irrelevant due to the poor quality of PHP poorly and we've been fixing that ever since. If the author wants to use PHP 2 or 3 (or whatever the fuck they were called), that's one thing, but to pretend that coding in PHP 2/3 style is what makes proper apps these days is fucking insane.