I'm optimistic that it's possible to write PHP applications / website backends without a framework. With that said, I've never been fortunate enough to see that first hand.
Then again, as soon as the "cruft" and annoyances that generally come with a php script-per-endpoint approach are gone, maybe it's not an existing 3rd party framework that was plugged into the site, but it's probably a "framework" by some interpretation of the word nonetheless.
If you haven't tried it, I would highly recommend giving Silex a try.
To paraphrase Churchill, what I called classic PHP style is the worst form of PHP programming, except for all the others that have been tried from time to time.
The creator of PHP, Rasmus Lerdorf, recently said that "all PHP frameworks suck," and his gave reasons for that opinion: http://www.phpclasses.org/blog/post/226-4-Reasons-Why-All-PH.... Elsewhere Rasmus has described his preferred style of PHP programming, which is pretty much what I described in my article.
It wasn't my intention to damn all PHP frameworks, or the MVC model, though in my own work I agree with Rasmus. I do maintenance programming and the more I run into MVC-style framework-based PHP apps, the more convinced I am that those apps are actually more fragile and harder to understand and maintain than some of the worst PHP spaghetti code I've worked on. I don't think that's because the frameworks themselves suck. I think that's because the framework and MVC model force the programmer to scatter related bits of code and data in too many places, obscuring the relationships and the flow of control. Some people delight in this complexity (perhaps believing it is more ideologically OOP pure). From a maintenance point of view it's a pain.
I do php and have done php. The code I've worked on hasn't used a framework. I tend to like using the templating engines (twig/smarty) to separate my html from my logic.
I also find by separating the logic into classes it becomes much easier to test.
Zend and Symfony make resuable components that you can use without using their whole framework. The fact that frameworks exist with the same name as the components makes looking up documentation on these hard
How about using another language to write php code? Without hesitation, the language would also be using one of the PHP frameworks/styles/approaches, which sucks. Could you advise me on this Haxe-to-PHP expedition - https://news.ycombinator.com/item?id=9111742 ?
5 comments
[ 5.0 ms ] story [ 26.0 ms ] threadThen again, as soon as the "cruft" and annoyances that generally come with a php script-per-endpoint approach are gone, maybe it's not an existing 3rd party framework that was plugged into the site, but it's probably a "framework" by some interpretation of the word nonetheless.
If you haven't tried it, I would highly recommend giving Silex a try.
http://silex.sensiolabs.org/
The creator of PHP, Rasmus Lerdorf, recently said that "all PHP frameworks suck," and his gave reasons for that opinion: http://www.phpclasses.org/blog/post/226-4-Reasons-Why-All-PH.... Elsewhere Rasmus has described his preferred style of PHP programming, which is pretty much what I described in my article.
It wasn't my intention to damn all PHP frameworks, or the MVC model, though in my own work I agree with Rasmus. I do maintenance programming and the more I run into MVC-style framework-based PHP apps, the more convinced I am that those apps are actually more fragile and harder to understand and maintain than some of the worst PHP spaghetti code I've worked on. I don't think that's because the frameworks themselves suck. I think that's because the framework and MVC model force the programmer to scatter related bits of code and data in too many places, obscuring the relationships and the flow of control. Some people delight in this complexity (perhaps believing it is more ideologically OOP pure). From a maintenance point of view it's a pain.
I also find by separating the logic into classes it becomes much easier to test.
Zend and Symfony make resuable components that you can use without using their whole framework. The fact that frameworks exist with the same name as the components makes looking up documentation on these hard