
PHP the Wrong Way - rbanffy
https://phpthewrongway.com/
======
lol768
Sure, let's throw the framework out of the window along with its built-in CSRF
protection, sensible security headers, templating language (which escapes
input properly by default) and well-defined interfaces which enable me to e.g.
access Request information. What could go wrong? For 99% of web applications,
you probably need these things.

I hate working on codebases that have been built without a framework. There's
rarely any proper organisation of code. The quality of the code that the
developer has rolled themselves is usually poor. At least if folks use
something like Symfony or Laravel it's harder for them to shoot their foot
off.

~~~
tzs
> At least if folks use something like Symfony or Laravel it's harder for them
> to shoot their foot off

I'd like to consider giving Symfony or Laravel a try, but at work we run
Debian and stay with a given release until it is near the end of extended long
term support.

Laravel's oldest release that is still supported is 5.5 LTS, which requires
PHP >= 7.0.0. The next oldest still supported is 6 LTS, requiring at least
7.2.0.

We're on Debian 8, Jessie, which is on extended long term support until 2022.
It has PHP 5.6.29, so no Laravel for us. Even if we were on 9, Stretch, which
has PHP 7.0 and so could use Laravel 5.5 now, Stretch is on long term support
until 2022 and will be on extended LTS for probably a couple years after that,
we'd run past Laravel's LTS.

Heck, even if we were on the current Debian, which is 10, Buster, which has
PHP 7.3, it is not clear we could use Laravel. Laravel only does security
fixes for 3 years on LTS releases. Buster has Debian support until 2024, LTS
for a couple years after that, and then extended LTS for a couple year, so it
will be past the end of security patches for the current Laravel before it
even reaches LTS.

So unless I can be sure that the next LTS release of Laravel does not raise
the PHP requirement past 7.3, Laravel is out of the running.

(But wait...what about
[https://packages.sury.org/php/](https://packages.sury.org/php/) which is a
package repository maintained by one of the main Debian PHP packagers where he
packages newer PHP for older Debian? That's close enough to the official
packages that I could probably convince the IT folk to add it. Alas, he only
packages for older Debian until they go out of LTS. If you stick with it
through extended LTS, you are out of luck).

With Symfony, 3.4 is the oldest supported release. That requires at least PHP
5.5.9, so will work on Jessie or later. However, 3.4 support ends in a couple
months. That will leave all supported Symfony requiring at least 7.1.3 which
means you have to be on Buster. It looks like they have a similarly short LTS
support life as Laravel, so even if you are on Buster today, there doesn't
seem to be any good reason to believe that there will still be a supported
Symfony that works there at the end of its regular support lifetime, let alone
that one that can take you into Buster's LTS or extended LTS.

Debian is the only Linux distribution for which I've looked at this in detail,
but a brief look at others suggests that the situation is similar for Red Hat,
and maybe Ubuntu.

~~~
conradfr
That's more a problem with the way you workplace operates, as even the php
organization doesn't support versions < 7.2 (and more realistically < 7.3).
You're kind of in a no-win situation.

~~~
tzs
Debian LTS for a given Debian release provides support for whatever packages
came with that release even if the upstream does not. They are still patching
PHP 5.6 on Jessie and 7.0 on Stretch. There was a 5.6 update on Jessie last
month.

See [https://security-tracker.debian.org/tracker/source-
package/p...](https://security-tracker.debian.org/tracker/source-package/php5)
for a list of all Debian's PHP 5 patches. The latest dozen or so are all less
than a year old.

~~~
conradfr
That's great for legacy projects but not realist for new or active projects
running on modern frameworks.

~~~
troyvit
I think you just said what OP said, but backwards. They have a long-running
stable system that works great, but because the frameworks require versions
that are more bleeding edge they aren't going to get them. I think frameworks
that always target newer versions of their base language are limiting who will
use them.

------
87zuhjkas
Don’t solve a problem that doesn’t exist. I find this article is against
behavior, principles and thoughts that only very few developer have, its
against extremism by formulating anti-extremism statements. But the anit-
extremism statements form a kind of extremism on its own.

> The wrong way: Always use a framework on top of PHP.

If a dev is very knowledgeable with e.g. laravel, then let him use this
framework as he wishes.

> The wrong way: The religious following of rules and guidelines.

If a dev team commits on a set of rules and guidelines and enforce them
throughout all their projects, then let them do so.

> The wrong way: Always use object-oriented programming.

If a developer only knows how to program with this kind of programming
paradigm (or chooses so), then this is fine too. Don't force him to learn
other paradigms. There is no "wrong way" and no "right way" because
programming is not black or white.

~~~
Keloran
the problem is that its fine if your doing this on your own

its when you force that mentality on others because you don't know how todo it
a different way that's wrong

e.g. If I only use Laravel why should my decision of only using a larval
dictate that the next project has to be done in laravel, it might be something
that can be done in 50 lines of code

But I only use laravel, there for you have to use laravel to solve the problem

~~~
tutfbhuf
> its when you force that mentality on others because you don't know how todo
> it a different way that's wrong

All decisions you make might be forceful for others in collaborative work.
It's also forceful when you have to work on a project that does not use any
framework.

------
tylermenezes
The author goes on about

> The danger of extremism

And then in the very next section makes this statement:

> Many of today’s programmers completely ignore the fundamental principles of
> sound programming and they spend a large amount of time fantasizing new
> layers of complexity in order to appear more clever, more cool, and more
> acceptable by whomever they regard as their peers.

A 100% completely accurate view. Nope, the author is definitely not an
extremist.

~~~
vivekd
I would say that's the best takeaway from this article, not use a framework or
don't use a framework, but don't let yourself lapse into extremism. I noticed
in node people run to libraries or frameworks for everything and the "don't
reinvent the wheel" principle is taken to the extreme even when existing
solutions are less than optimal. We don't want to be at that extreme but we
also don't want to be at the extreme of avoiding frameworks altogether.

------
severak_cz
I am not big fan of PHP frameworks. But there is a thing - you are either
using framework or inventing one.

Currently I am using homemade sort-of-framework for my pet projects. It has
one big advantage - there is no need to learn API from external documentation
as I am building it along my needs. I also learn a lot about reinventing
wheels.

~~~
nkozyra
> you are either using framework or inventing one.

I disagree, unless you consider using a language to be inherently creating a
framework.

Frameworks are generalizations, intended for flexibility. Their abstractions
exist, typically, to shield a developer from the lower level stuff.

If you're writing plain ol language of choice code to do a specific thing,
it's none of that. People can look at your code and see, oh, he's using built
in cookie management and headers and standard language database calls.

It's readable, non abstracted code.

~~~
justanotherc
Maybe, but non-abstracted code is not DRY, becomes difficult to maintain, and
is time consuming to write.

So a good programmer will start to abstract those things, and at that point
you're going down the road of creating your own framework.

~~~
nkozyra
Employing DRY does not mean a framework. Reusable functions do not implicitly
suggest a framework.

I think you're defining it way too broadly.

------
fomine3
For who unaware: PHP The Right Way
[https://phptherightway.com/](https://phptherightway.com/)

~~~
codethief
This should be further up, for proper context.

------
ivanhoe
I'm more than capable to write vanilla PHP projects, I did it for years, but
why in the world would I want to do it nowadays? Who in their right mind would
write everything from the scratch every single time, when at least half of all
code on web projects is boilerplate repeated over and over? And if you don't
write it from the scratch, and use instead some libs glued together by some
copy&pasted boilerplates and you probably have some template engine too...
well, guess what, it's a framework... just no one else beside you knows how to
use it and it's probably buggy and not properly tested and missing tones of
handy features...

------
CM30
The point about frameworks is something all developers and software engineers
need to realise, about all programming languages and domains.

Use what you need to use, in a way that makes the code easier to read,
shorter, etc. A simple brochure site with little in the way of interactivity
doesn't need to be built in React or Angular. A one page portfolio site
doesn't need Bootstrap, and even many bigger ones don't need to import the
entire framework.

What's best practice for Google and what's best practice for a small widget
manufacturer in the middle of nowhere are likely not the same.

That's basically the lesson behind all of these points to be honest. Use
what's right for the project instead of taking a list of rules as gospel and
overcomplicating things to hell.

~~~
sanderjd
It is not as simple as this because of the time component of software
engineering. It is necessary to both use what's right for the project in the
moment and to use what's right for the project's future evolution. Of course
you rarely know for sure what that evolution will look like, but if a group of
people think a project is worth working on, they probably think it will live
and continue evolving for awhile, in which case it is necessary to make
choices aimed at supporting that evolution. It is very often the case that a
framework is not "what's right for the project" in the moment early on, but it
is usually the case that it is what's right for the project to evolve. The
alternative is for a newly invented framework to be built up over time, and
this is not a good use of time and often results in a mess.

A framework always feels silly when you're just doing some fairly simple thing
once. But if you anticipate doing similar things tens or hundreds of times, it
is usually worth the cost up front to avoid reinventing wheels later.

------
tehbeard
> Many industries demand highly scalable, run-time critical, and cost-
> effective software that simply cannot be developed using these standards of
> the PHP-FIG.

Genuinely curious of real world examples of this.

I don't treat PHP-FIG's word as dogma; But to my mind several of the PSRs that
came from them enable scalable, cost effective software to be written.

------
Theodores
Too many frameworks and layers of cruft make it so that a project is no longer
something that is economically viable to work with.

Case in point: Magento2.

Developers for this in the Anglosphere have found better jobs so it now
becomes a matter of outsourcing to other not-so-first-world places to get work
done. If only they had kept it simple and not gone for every framework
imaginable then it might be something that people not desperate for money
would want to work with.

------
dgb23
This seems to be mostly a rant against OO and frameworks, which is fine but
also geared towards developers who are already familiar with these concepts
and have enough experience to assess them.

~~~
onli
I don't think that's fair, it's not a rant and not specifically targeting OO
and frameworks. It's targeting that mindset of modern PHP = PHP with a lot of
unnecessary abstractions. Even when you have some experience that can get to
you.

I am involved in a legacy PHP project from the early 2000s. The code is as you
would expect, maybe a little bit better because the programmers involved were
pretty capable, but it is code visibly evolved by first targeting PHP 4 and
only then 5. For quite some time I thought that modernizing it thoroughly
would be the way to go, just that it'd be too much work. Then in my day job I
got confronted with a modern PHP project. Using a framework of course, written
like it was Java. It was horrible. Abstractions everywhere, impossible to
follow the code without getting into the details of the framework, thus very
hard to make changes. That experience confirmed the decision we made with the
other PHP project of only modernizing it carefully, putting the HTML in a view
layer and stuff like that, but staying away from the framework trend.

So this article seems spot on to me and something that can give useful input
to other programmers.

~~~
arkh
DTO everywhere and interfaces with only one implementation? And Domains.
Because after reading 2 blog posts we're now doing Domain Driven Design!

~~~
onli
That sounds like a different kind of pain ;) In my case it was just
abstraction everywhere. Want to change one element on a site? Edit these 6
controller classes located in different subdirectories without any sense or
order. Then find the template, just that there is no clear template, just PHP
objects emitting HTML, JS and CSS code, so back to searching through the code.
Oh, defining new functionality? Good luck finding out how to register it.

It was just a ridiculously confused "MVP" pattern application for what
amounted to a simple web app.

------
keb_
To the author's credit, I have experienced this boogeyman during my time in
the PHP world. There have been a couple of times on SO or reddit where my
questions were met with a "why don't you just use Laravel?"

My most memorable experience was during the interview process for a company
that used PHP for their backend. I attempted to solve the take-home assignment
using a couple of libraries (some Symfony components). An overarching
criticism of my work was "you should have used a framework" and "always use
pre-existing packages rather than write your own." The reasoning was that
popular packages are vetted and tested by the PHP community.

I understand _why_ they believe this. I also find it astounding that PHP
developers distrust vanilla PHP so much (and likely for good reason).

------
jt2190
I would like to offer a different perspective, that might help us escape from
this crude binary thinking.

Instead of thinking of “ _my_ code that I wrote is simple and good and true”
and “ _their_ code is over-engineered and complex and terrible”, choose to
“adopt” third-party code: Treat it like it’s yours to understand and maintain.

Doing this, you’ll get a much better sense of how the “other” code handles
things like error handling, security, stability, upgrades, etc., and more
importantly, whether your point of view on these topics is in alignment with
the maintainers of the third-party code you’ve adopted.

~~~
trey-jones
Absolutely, understanding the source of libraries that we're using is great,
but the reason most folks might elect to use a framework is "to save time".
And reading (and understanding) code takes time. For probably my first 5 years
in this industry I found reading code in other peoples' libraries extremely
tedious. Don't get me wrong - I think reading code from a better programmer is
one of the best ways to get better. But I found it very difficult at first.

You can even see it in a lot of the comments on this topic. Things like: "I
like rolling my own code so I don't have to learn someone else's API." I think
that's typical of a less experienced dev that already feels overwhelmed by all
the other technologies that they have to learn. Dunning-Kruger and all that.

Better tools, and some practice and experience have made it easier, but when I
ask a less experienced dev to read someone else's code I do try to keep in
mind how it was for me early on.

~~~
jt2190
> [T]he reason most folks might elect to use a framework is "to save time".

Cool! So now we’re expressing something we _value_ , and we can evaluate third
party code and our own against that value.

> Understanding the source of libraries we’re using is great...

Again, we may _value_ that, we may not.

“Treat it like it’s yours to understand and maintain” does not mean eagerly
read all of the source. It means that you should act like you’re also
responsible for the code’s maintenance, whatever that is and to the best of
your abilities. Because it _is_ a part of your app when you use it.

------
uses
Not sure who this is for. The people advanced enough to be questioning
architectural convention already know that "using a framework" isn't the right
answer 100% of the time always and forever. The people who are just starting
out really should focus on learning The Right Way first, and then, after that,
far after that, they can start Reinventing the Wheel Because They Know Better.

------
danielbarla
As someone who frequently prefers to "roll their own" code for _simple_ things
rather than import complex 3rd party dependencies, I have to ask: is the world
of web development - with all the implied focus on security - really the right
place to start encouraging people to create their own frameworks?

~~~
jkoudys
Odd that the author ends on saying to make apps secure from the start, when
this is often the intent in using bulkier frameworks to do "simple" things.
It's also odd to criticise abstraction on abstraction since that's what
literally all computer programming is. The simplest and least abstracted
approach would be running SQL directly.

~~~
danielbarla
I guess the author is arguing that we currently over-abstract, which is quite
possible. At the end of the day, it will always be some kind of balancing act.

My point is that web applications are, at least from a security standpoint
(but also some others) anything but simple, and I'm fairly sure most attempts
at creating a focused, lightweight, custom framework are littered with
security issues. There are counter-examples in both directions, but this is
just my general experience; people who know all the pitfalls you would have to
avoid also don't generally want to try to implement all that by themselves.

------
mnm1
Most engineers are not qualified to build an app without a framework with an
architecture that is well thought out and code that is well written and
documented. I've never seen a custom framework meet any of these requirements.
I've never seen one with proper documentation. Sure, if you want your
colleagues to hate you and think of you as an idiot junior coder who shouldn't
be in this business, write your own framework from scratch instead of actually
doing something to move the business forward. A competent manager would fire
such a stupid engineer for not contributing to the company and wasting its
time not just in developing garbage but possibly many years into the future if
the rest of the team is dumb enough to use said garbage.

------
gertrunde
From when this was posted a few years ago [August, 2016]:

[https://news.ycombinator.com/item?id=12318615](https://news.ycombinator.com/item?id=12318615)

------
ryan-allen
I agree with the sentiment but I don't agree with the language/runtime that is
PHP.

There are many, many more superior options when it comes to general purpose
'no-framework' styles.

~~~
marinabsa
Is there another programming language one can use for web development without
a framework? Genuine question, I always thought that's PHP only advantage.

~~~
megous
I guess anyhting that can read environment variables and write to stdout. :)

~~~
ptr
Exactly, CGI
([https://en.wikipedia.org/wiki/Common_Gateway_Interface](https://en.wikipedia.org/wiki/Common_Gateway_Interface))
was a thing once.

~~~
megous
It's still a thing. For example with cgit.

------
TOGoS
I clicked hoping that it would start with

    
    
      1.  Turn magic quotes on
    

but actually it's about religious use of (popular) frameworks and design
patterns. Which I might actually agree with (people at my old job were always
trying to get me to use Kohana, and then Laravel, and I hated them both and
still don't understand why people like that kind of thing), but not in the
mood to get riled up about it today. Fight the good fight, phpthewrongway
people.

~~~
Supermancho
Kohana didn't have the Laravel-specific-scripts necessary to "properly" extend
and configure the framework. It was basically CakePHP underneath (FuelPHP is
the current generation?). Laravel on the other hand uses all kinds of magic.
Having been through Symphony, Zend, etc Laravel just seems like more of the
same over-engineering. I don't understand the popularity.

------
Jedd
I've seen this quote a few times over the years:

> All general purpose PHP frameworks suck!

> – Rasmus Lerdorf

Rasmus said this an awfully long time ago - 2013 or earlier?

Truth of the statement (then or now) aside, Rasmus was a C programmer long
before he was a PHP programmer, which presumably strongly informed this
position.

~~~
trey-jones
It's a subjective quote, but I tend to agree with Rasmus in 2020. My
experience with PHP Frameworks is largely CakePHP (starting with version 1 and
ending at about 3.2), though I've dabbled in pretty much all the big players
over the years. We started moving away from PHP frameworks around 2015 (and
PHP, mostly) and I don't regret it. Here are some reasons why:

1\. _Maintenance_ : We support a mostly successful ecommerce application that
was launched on CakePHP2 in 2012. These guys, like many of our clients (and
yours too!) are stingy and while we've worked consistently on the site since
then, upgrading to a newer version of CakePHP is a non-starter (Cake 3 was a
total rewrite). As you may know, PHP in 2012 was a different world and we're
stuck in it. I've just found out that CodeIgniter 4 is also a total rewrite.
Sure CodeIgniter 3 is still supported, but for how long?

2\. _Deployment /Dev environment_: It's possible that we just weren't doing it
properly, but I have a large non-framework PHP cli app and several Go/Angular
apps that move seamlessly between dev, staging, and production with very
little human intervention. It always seemed more complicated with PHP
frameworks.

3\. _Too much stuff_ : Basically the same argument as the article makes: Why
should I use Cake\Network\Http\Client when I could just use Guzzle? Why does
this ORM produce 30 unnecessary queries per request? Why in God's name would I
use this "Helper" class to generate a <p> when I could just write HTML?

4\. _It 's slow_: As always, slow is a relative term, and PHP frameworks are
relatively slow. Because there's too much stuff mostly.

The maintenance point is the most critical. Most of these frameworks last ~5
years between total rewrites. I'm sure there are exceptions. Laravel seems to
have risen to the top, and might not have this problem. If you expect your
application to have a lifetime of less than 5 years, then maybe it's OK. 5
years seems like a long time when you're just getting started. Ten years
later...

~~~
Jedd
All true and good points.

I last used PHP a decade or so ago, and heavily relied on CodeIgniter
framework. They had a good, tight feature set, and a fantastic community.

The fact it's now mostly gone kind of speaks to your point, though it may just
be that PHP's marketshare overall has dropped so much that there really isn't
sufficient energy to keep more than a couple of frameworks alive.

------
zach_garwood
This article should be renamed "Look at All the Strawmen I Made Up!"

------
unscaled
I think I agree with many points (especially avoiding frameworks and patterns
when you don't need them), but even though this manifesto is warning against
extremism, it makes some points that seem extreme for me.

For instance, it's Paul Graham: > When we try to improve ourselves, and in
this case more specifically our code, we sometimes get hung up in the
philosophy of a particular pattern or idea and tend to forget to think
practically.

>> When I see patterns in my programs, I consider it a sign of trouble. The
shape of a program should reflect only the problem it needs to solve. Any
other regularity in the code is a sign, to me at least, that I’m using
abstractions that aren’t powerful enough - often that I’m generating by hand
the expansions of some macro that I need to write.

But it seems like the author is misunderstanding pg. pg is claiming that if a
pattern (of any kind - whether it's a "GoF-approved" design pattern or not)
keeps repeating in your code, your code is not abstracted enough — either
because you're not using the right abstraction for the job, or (what will be
inevitable in a language like PHP) because _your language_ is not powerful
enough.

The solution presented by this article is just: "Do not always use patterns"
\- but it doesn't clarify which patterns you should use. But Paul Graham is
saying something much broader than that: design patterns are just a type of
pattern, and patterns of any type should not be repeat. Essentially, this is a
strong version of DRY that considers any generalizable patterns as repetition.

> Later, procedural programming was derived from structured programming.
> Procedural programming is based upon the concept of “procedure call”. A
> “procedure call” is just another name for a “function call”.

I'm pretty sure it's the reverse.

Following this we get a justified criticism of OOP (although we should be
clear here: this is mostly the bastardized Java brand of OOP). And there we
get another quote from pg (who I assume was criticizing the very different
CLOS and its necessity in a Lisp-family language).

Then this bit ends again with the suggestion "Do not always use object-
oriented programming". I can't agree more with that, but alternatives should
be provided. When should I avoid OOP, and when OOP would be good (the source
for pg quote is actually followed by a recommendation for Common Lisp)? What
should I be using instead?

The funny thing is that I probably agree with the intent behind this
manifesto, but I can't ask any PHP programmer to reconsider their best
practices following this. Since the rationale is not presented clearly enough,
and no guidelines or alternatives are defined - or even proposed - it won't
help to convince a lot of programmers from my experience.

