It's definitely not a satire. They are some valid points. It's not against using frameworks. I think it's more about finding the right solution for the problem.
What I take from is not to use PHP, which I do as it pays the bills, but why would anyone choose it for a new project baffles me. This article doesn't help it.
I love PHP. It feels like a complete toolbox to me, whereas other languages like Python or Ruby feel like I'm buying an entire Home Depot for every project. Sometimes you need the whole store. Most times I don't.
I think the OP has some good points about reconsidering the standard answers that everyone gives to questions when asked. There are no silver bullets in web, but many things sure are treated like them.
Maybe there are projects where PHP isn't right. There are probably tons. But that doesn't mean that it's always wrong. PHP is what got me into making web things in the first place. I loved (and still love) how utilitarian it can be.
But perhaps that's where I differ from most people. I see myself as someone that makes web stuff. Most seem to see themselves as app creators or system builders. And they probably are. Sure, I do that too when the time comes, but if most of the time I'm building a front-end to a CMS, I'm hardly "engineering" anything. I'm mostly just trying to make specific art for other people.
Anyway, I don't understand why PHP would immediately be ruled out from this article. It feels like the JavaScript of the server-side world to me. Use as little or as much as you want. You can do awful things with it, but also wonderful things.
Well I certainly agree with the right tool for the right job. And PHP has some roles. My point was more about the article, which would, imo, put programmers off PHP with its contrariness and smugness.
I just skimmed the website, and I am still not sure if it's meant seriously or if it's some kind of joke?
Feels a bit contradictory eg. "dont use framework" vs "make software secure by default". Isn't a security one of the gains of using frameworks, beside other things? You would need to be a security expert to cover all potential security issues when writing something from a scratch.
Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away
Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
PHP is a hammer, blaming the hammer is silly when the person using it might now know how to swing it safely.
PHP (the interpreter) used to be filled with bugs, design flaws and incoherences. It got better lately, but IMO it still caries a huge mess of legacy stuff that shouldn't even exist (mysql_real_escape_string anyone?)
In this case, both the hammer and the hammer's user can be blamed.
Another is finally giving us a null coalescing operator, which is a solution for a constant pain point in dealing with raw PHP POST and GET parameters.
This is the problem I have with PHP. 15 ways to do something seemingly simple, and only one obscure way is correct (What's PDO::ATTR_MODE ?) And why does PDO try to emulate prepares ?
> Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
It got a bad name due to the weird nature of PHP which is still a template engine , no matter how much features you had on top. It's like developing webapps in pure HAML, Jinja or Handlebars.
PHP also has a lot of bad design language wise, due to the incompetence of its creator and early maintainers when it comes to language design.
Template engines are one of the more ridiculous inventions on the web, if you think of it. Doubly so if you have them in PHP, which is a perfectly good template engine - sure the syntax could be better, but the popular templating engines are even worse at any but most trivial tasks. They all start as an attempt to remove the possibility of writing meaningful code in them[0], and then grow cruft until they become Turing-complete due to the needs.
The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings.
I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level.
[0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.
I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.
PHP actually is a bad templating engine for HTML because it doesn't have a feature to convert special characters to HTML entities by default. It is easy to forget a call to htmlspecialchars() (especially for beginners) so the code gets vulnerable to XSS.
That is why you should prefer Twig or other templating engine with autoescaping.
> They all start as an attempt to remove the possibility of writing meaningful code
I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/
Nevertheless, I used DOM/libxml on the server side in PHP/C, since 10 years ago, and was happy about it. It avoids all the other the template issues (balancing open/close tags, etc.) very well.
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?".
Twig does not require you to write escape so you can have to write just
{{ var }}
That is a big difference because beginners always forget about escaping.
> Nevertheless, I used DOM/libxml on the server side in PHP/C,
There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.
Not that much bloated. And it can be quite readable if done well. You also don't need to learn peculiarities of for loops or macro language in a given templating system. The host language is it's own macro language with all the features you already know, and not limited to whatever template language authors decided to implement.
Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction.
Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree.
It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.
PHP is pretty objectively bad. For every thing PHP does decently well, something else does it better.
Except for this one weird trick: PHP absolutely bulls-eye nothing-but-net nailed deployability before deployability was even a word. In 2000, you could download an installer that set up Apache, MySQL and PHP on your Windows box (and it worked, first time and every time), you could fire up Notepad and 15 seconds later look at "Hello World" in your browser. Then you could upload that PHP file to a web hotel at $10/month and the world could see that same Hello World perhaps 10 minutes after that.
Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
That's why PHP is so popular.
1: in zero-to-one deployability for a new user -- the full development and deployability experience just a tiny bit up the learning curve is orders of magnitude better.
FWWIW Ruby is my favourite language, but it's nowhere near being as beginner-friendly for web development as PHP. This is mostly because PHP was designed as an "embedded" language from the grounds up, and by the fact it's so widely supported by hosting providers. Most hosting providers have no support for Rails (or general rack-based applications); most that do, offer patchy support, though.
Furthermore, I remember a few years back, Ruby was a hassle to set up, especially on Windows.
There are more popular and worse languages, for example Javascript:
- no classes (so people end up emulating them: Backbone has methods to emulate class declaration and class inheritance)
- no type hinting. You cannot specify function argument type or return type. It makes code harder to read and to maintain.
- too forgiving. You can divide by zero or mistype a property name and get no error. You can add arrays to strings. It makes bugs harder to find.
- no coding standard. Everyone uses whatever style they like
- no single modules standard
- no syntax for asynchronous operations
- difficult to install XML library on Windows (you need to setup a Visual Studio to compile binary modules)
> Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
You have to learn Linux and command line to use Ruby. No wonder it is more difficult for a newbie. Deploying and running an application is more complicated in Ruby. Also with long-living applications it is easy to get a memory leak.
But recently PHP started to depend more on CLI tools too (installing and using composer might be not easy for people who got used to GUI and don't understand concepts like "working directory").
> "web developers" with no formal programming education
I know developers who couldn't afford a "formal programming education" or couldn't/didn't go for various reasons, and they'd blow most "formally educated" developers out of the water. I think the word "formal" is surplus here.
> stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
This holds true for anything in life, really. Anyone who uses a tool which they don't understand will sooner or later make a mistake with that tool, and keep making mistakes.
WARNING: The next might be anecdotal, so YMMV. I used to write a lot of code in PHP (and I am grateful, because it is partially responsible for introducing me to the world of programming), but I slowly moved away from as time passed.
The main problems with PHP (apart from some interpreter issues/design decisions which I won't cover, because there's an abundant amount of that online already) are the fact that:
1) it probably has the lowest entry barrier, with near-instant gratification and
2) there is an insane amount of online tutorials, blog posts, courses and even "books" created by people who *think* they understand programming (and PHP), but actually don't.
Web development is not any more trivial than system development, or any less complicated. This probably goes for any type of development.
To be proficient in either, you need need to cover a very wide range of domains, but PHP resources makes you feel like web development is trivial and easy. Anyone who assumes web development is trivial doesn't really know shit about web development (excuse the language).
tl;dr: I mostly agree with you that PHP's design decisions aren't the only problem bad PHP code exists, and that people who use PHP are largely to be blamed for their own mistakes.
Of course I did not want to generalize and stereotype
Yes PHP makes it easy for ANYONE to stumble into scripting/programming
But IMHO that is a good thing, the world needs more people getting into programming, if they make mistakes so be it, learning from mistakes is a good way of learning anything.
Coming from a C background I used to hate PHP as it's inconsistent and flaky to the point of schizophrenia. Same applies to library naming. It positively encourages bad design and inconsistency. C wasn't and didn't.
Nearly all PHP I came across was the mess of some self-taught stumbling way beyond the point they should have been screaming for help, and going back to photoshopp. The docs don't exactly help here (may have changed, it's been a few years) as the apparently helpful comments on each feature aren't moderated in any way and are frequently unhelpful or plain wrong - but they're left to encourage the unwary.
I don't disagree it's perfectly possible to produce decent code with a good coder, and good principles applied to the project. I've seen some very clean looking PHP, and OO classes. That's been because they know the problems of the language and have been careful around such areas, or tried to avoid them entirely. I've worked on a couple of PHP based projects where I couldn't say a word against it as they'd used it well from the start.
We are where we are, but I would have been happier if the tool most often used by "web developers" stumbling in was a little more constrained and consistent about it.
You don't have to be a security expert in general, but you should aim to be one in the language you use, or do you intend to blame the framework everytime the shit hits the fan?
Being married to a framework is arguably worse than using separate, isolated and composable libraries to handle the equivalent things. You can fight architectural problems of a library easily, but not when there's one inside a framework and between its internal components.
I disagree. The odds of a grab-bag of small libraries by different designers who may or may not be actively maintaining them working well together is much smaller than the likelihood of a framework's components working together. And besides that, familiarity with the framework means you are able to understand its limitations and how to work around them.
You may be drowning in the kool-aid. It is very easy to write tiny secure code in PHP without a framework. Of course if you're building a social network, then it will run into some of those potential security issues. But for most of the small problems you're using PHP to solve, you really don't need to be a security expert as long as you're not piping user input directly to your database or OS.
It's kind of the point of the whole page - you don't need a massive general framework to solve your specific problem. Maybe read the whole thing instead of just skimming it.
No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workflow is nicely designed.
And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it.
Most custom PHP site I encounter are full of gigantic holes.
And then other developpers comes in, and have to learn how to use your non standard code, that is unlikely to be half as well written, tested or documented than standard solutions.
Of course custom code has also a cost, which means doing all that, even not very well, will take a toll on the budget, which you can't spend on other security aspects. All that while security is generally the last item on the budget list.
I think RyanZAG was referring to solving one small problem with a PHP script. That does not necessitate a web page or any of the security mechanisms you suggest.
You often do though: as in, if each independent problem was handled by a microservice PHP script, it would just be a 50 line script.
But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.
1.- Massive project where you're not using 75% of the framework.
Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working.
And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need.
Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller
2.- Separate parts stuck on a massive project
Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works.
3.- Those microservices may not follow a standard.
While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily.
On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).
If its under 50 lines of code for some simple processing, I don't think another developer who comes in would have much trouble. Of course if that 50 lines of code is now 250 because it tries to get around a framework, then instead of finding a PHP developer to help out on the code, you now need a $framework developer.
Basically, don't use a framework unless you really do need all the features it gives you. Don't just pick a framework and try to cram your code into it for the sole purpose of using a framework.
> If its under 50 lines of code for some simple processing
It doesn't matter how much lines you write. It has nothing to do with the number of lines but the functionalities and how many developers review that piece of code. Furthermore more a third party codebase is usually the code you don't have to test. You keep on talking about frameworks like it's a bad thing, but all frameworks are not equal in size nor features.
You still don't need a framework for that. Just use composer to install a bunch of well-tested, feature-rich, but fully independent packages. Start your script with
Don't forget to understand how/why/what those other packages do.
Including a package based on the contents of its packagist description alone is basically like reading the ingredients for a pizza and then eating a bag of flour.
> And then other developpers comes in, and have to learn how to use your non standard code
If you use a framework, new developers coming in often have to learn how to use it as well.
I've never hired a developer who didn't know how to use PDO prepared queries, which are the standard in my code base. Built into the language, escapes no matter what database you use, etc.
Good developers know how to write secure PHP code without a framework. They don't necessarily know how to use a random framework.
Bad developers will at some point take variables from a $_POST/GET array and use them unwisely regardless of whether you have a framework.
> It is very easy to write tiny secure code in PHP without a framework
Actually it isn't, like at all. A open source framework will always be more secure than the code you "easily write", because a larger pool developers can review,audit,test and fix that code.
Sure, the framework code will be more secure. But you still need to solve your problem and your framework isn't going to do it. So you have to write code.
The code you do write is going to be more secure if you know what's going on. If it's on top of a billion line framework, you might accidentally break the security without even realizing it. No legions of framework developers reviewed, audited, tested or fixed your actual code.
If you marry yourself to a single framework you remove a lot of degrees of freedom from PHP (which might be good or bad depending on the case) and introduce a set of rules that might or might not all be good for you.
It might save you time, initially. But at some point you will have to sit down and learn what the framework is actually doing behind the scenes (is it really secure? why is it so slow? I really need to implement this obscure, unsupported by my framework, thing), and you might not be so happy about your choice. Thinking about this ahead of time will save you headaches in the long run.
Think of PHP as sandbox programming. Such an open language, there is a lot of freedom, so many ways to achieve a specific result. The takeaway from the article is that "always do X" shouldn't be a thing, considering a) the vast possibilities and b) your purpose. Frameworks might be too much bloat, patterns should happen naturally, not forcefully. Security should be paramount, but it shouldn't be a blackbox behind third party code, you should be able to explain how you are protecting your users. Etc.
This is not a "don't use a framework/standards/etc" rant. I see it as a reminder to double-check if the current... trends/standards? match your actual needs and wants.
>Isn't a security one of the gains of using frameworks,
That depends on the scale of what you're building. Generally I would agree with you, but if you building some small, something that would only ever use a small subsection of whatever framework you pick, then you could end up having more issues than if you didn't use a framework.
Just because you aren't using parts of a framework, doesn't mean that security issues in the framework won't affect you.
Let's say your application only ever needs to do one or two queries to a database. It's going to be a whole lot easier for you to lock those two queries down, than securing an entire ORM.
You can also build horribly insecure applications with a framework. A framework does not absolve you from thinking, which seems to be the point the author is making.
There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start.
You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems".
It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You do need to know what you're doing.
The jack of all trades is the master of none. Almost no generalist is going to be good enough to properly handle all security concerns. I like knowing my framework is constantly upgrading password handling, XSS attack prevention and things I haven't even heard of yet. The fact you can build insecure things in a framework isn't an argument against it and why would someone who builds a horribly insecure app in a framework produce a better result without using one?
They probably wouldn't, but that's neither something I said, nor is it the article's premise.
However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug?
Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first find the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly.
The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.
> You can also build horribly insecure applications with a framework
"You can also find sober drivers that cause accidents". Of course, but it doesn't invalidate the fact that drinking and driving is a bad combo and puts you and others in greater danger statistically. It's sort of similar here.
Most of security threats a small project encounters are very low-effort and concentrate around automatic checking for known exploits in widely used technology. Your site will be probed for known vulnerabilities a lot; but probability that somebody will actually invest his time in searching for SQL injections in your custom code is much lower.
I generally agree with the view of keeping your application simple and not using big frameworks but after seeing so many PHP programmers write spaghetti and insecure code, I pretty much recommend frameworks now. You can say the problem is not with writing PHP without any framework but with the programmers, the problem lies with the low barrier for entry into PHP. Frameworks atleast teach you how to make your code modular and make your application secure (atleast sane defaults).
Then again, most frameworks are more comparable to cars than tanks and people use cars all the time to pick up kids at school even if they could just walk.
Convenient you know and less chance of getting mistaken for a hipster :-]
If every project had unlimited budget and only quality developers, this site would be a little bible. The reality is much different - communities exist so we can stand on the shoulders of our peers :)
I don't think it's saying exactly that. One should think up a solution first, then see if one needs patterns to fit that solution into the code base in language of choice. PHP certainly doesn't need all of Gang of Four recipes due to dynamicity and other factors.
So the author considers following PSR guidelines beyond 1 and 2 to be "the wrong way"?
PSR-4 is the currently accepted best practice for autoloading and while it "may [have] a direct effect upon how you code your software," it's the optimal approach for 99% of projects I've encountered.
Following community interoperability guidelines is what allows developers to move away from monolithic frameworks and compose projects based on the packages they need.
> currently accepted best practice for autoloading
According to who? FIG?
Are you aware that php has a built in auto loader that supports namespaces and is written in C?
> compose projects based on the packages they need.
Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development, where you end up with 50 "micro-frameworks" or "utility libraries" each of which depends on a further 20 other libraries.
I have some issues with this site but it's right that the FIG is a joke, and anyone who claims its "best practice" is not paying attention.
According to the vast majority of authors of the most widely used and tested PHP libararies.
> Are you aware that php has a built in auto loader that supports namespaces and is written in C?
You mean the autoloader builtins that composer uses under the hood already? This is better than a 1 line include how exactly?
> Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development
I don't understand what you're saying here, everyone should be writing their own libraries from scratch? It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
> According to the vast majority of authors of the most widely used and tested PHP libararies.
So, FIG.
"Group of developers say that groups' work is the best. News at 11."
> You mean the autoloader builtins that composer uses under the hood already?
No, spl_autoload is a working namespace aware autoloader. Composer uses a bunch of userland code.
> I don't understand what you're saying here, everyone should be writing their own libraries from scratch?
Did I say that? I've seen, multiple times the negative consequences of the current fad to rely on 25 separate, single-purpose 3rd party Libs, all of which are basic functionality that a well thought out library would give you, but with the added "bonus" of each relying on 20 other libraries to do basic things.
> It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
Do the vast majority of developers know that? Because the ones I've had the "pleasure" of working with, definitely don't.
So if I was starting a new project now, I shouldn't use a framework or any pattern too strictly, so.. what do I do? Following this logic will give me spaghetti code and reinvented wheels. If there are some basic patterns to follow they should be included here.
My feeling is I should just start coding with whatever I know and not bother getting involved in arguments about the underlying language. Time is money friend!
The problem is that companies that don't use frameworks end up re-implementing their own as complexity grows, and of course usually do so extremely poorly. No matter what, for any non-trivial application, you DO need a framework - the choice is either to use an existing one or to implement your own. The big advantage of existing ones, in my view, is that they are well documented and everybody can learn them. That pretty much never happens with bespoke frameworks.
I do not want to be mean, but I honestly feel there is no 'right way' in case of PHP. There are communities that care about 'doing it right' and there are some that want just to 'get the job done'. I prefer the former, PHP always seemed to prefer the latter.
This is a massive overgeneralisation of a humongous amount of people and man-hours of work. Why do you feel this? Do you have anything to back up this statement?
Anecdotally speaking, I'm a Senior Software Engineer working with Go and PHP.
We use Go when working on performance critical code, because for us that's where it excels.
We use PHP when we need simple interoperability with the legacy Magento site our company runs and for jobs like running a CSV importer or some other oft-visited-task. We both get the job done and care about doing it right. You can write some truly beautiful code in PHP if you have the correct level of patience, process and experience behind you.
99% of people who get paid to write PHP do not have the requisite level of patience, process, or experience to write a fibonacci method let alone write "truly beautiful" PHP.
It's really easy to make up statistics on the spot with absolutely no source.
I very much doubt that people would be getting paid to write any code if they couldn't implement a single for loop in their primary programming language.
PHP was the first language I ever used professionally. The code I wrote - the code every single one of my colleagues wrote - was atrocious. We were paid bottom dollar ($30k in 2008) to write absolute shit code. The PHP community in my area was the same. All newbies, all paid barely more than a fast food manager, all writing code that could be taken down by a HS student with Fiddler.
I'm sure different experiences exist, but the majority of folks who I speak to have experiences that match mine very closely.
PHP is so vast that it's a ghetto, the rich uptown area, a sprawling suburban middle class, and more.
I share some of your experiences - I'm disturbed by how easy it is for people without basic coding knowledge to make money "building php websites". But I also see and run in to a large number of people who can do fantastic PHP code (testable, documented, clean, modular, etc).
One thing I've noticed is that most of the people who can do good PHP code (at least in the sense that it's not crappy) have also worked in other languages/tech, either before or during their PHP work. I know the exceptions, but for the most part, someone's PHP code quality is higher if they've done more than just PHP.
And since then tools such as Composer and Symfyony3 have been released. It's been almost 10 years. Hell, even Magento2 isn't that bad, if you can look past the awkward dependency injection they're in the process of fixing.
PHP in 2008 is very different to PHP in 2016.
PHP frameworks in 2008 are very different to PHP in 2016.
PHP developers in 2008 are very different to PHP in 2016.
> Just because those tools exist doesn't
> mean people use them.
But, oh, they do! At least there in most of the jobs you will deal either with Symfony or with Laravel.
> here were decent libraries and high quality code back in
> 2008 (and 2000) but people didn't necessarily use them.
Please, name a couple from each year. PHP started to mature since PHP 5 and that was released in 2004. While you could have working and tolerable code before that the language was lacking features for high quality code. Maybe if you reframe that as "high quality given the limitations" I'd accept that. But I am seriously curious what would you consider high quality PHP libs from 2000.
My experience mirrors yours exactly but with one difference - we were using .NET (C# specifically).
I'm now a professional .NET contractor (among other things) and looking back at the code we wrote 7 years ago terrifies me. Thankfully I'm not responsible for maintaining it anymore.
I suppose the point is that incompetence is language-agnostic. :)
a "single for loop" and a "fibonacci method" are different enough.
there are loads of people who take money for working in PHP, and they're closer to pc86's view of things than yours. I wouldn't say "99%" but... there's a lot. A LOT. I've run (and attended) several local tech meetups in my area, and ... there's a huge amount of technical talent, but also a surprising number of people bumbling around with wordpress, drupal and other systems. They generally don't have a clue what't they're doing with respect to PHP code, but they make a living modifying themes by cut/paste stuff from forums.
Here, fibonacci implemented in a single for loop (obviously, there's cruft in there to modify the array but there's no need for us to be facetious). Feel free to wrap function call around it if the procedural nature makes you feel icky.
I'm not sure why you posted code here - I don't think the possibility of this code being written was ever in doubt.
Personally, I already said I don't think 99% is accurate, but... we'd have to define terms.
"PHP developer" - is that different from someone who modifies (or creates) PHP code as part of their job to earn a living? Maybe they're just "PHP workers"?
The very notion of "array_shift" and "array_push" is foreign to a non-trivial amount of PHP workers.
The word fibonacci is foreign to a hell of a lot of people who make their living in code.
I don't think you interact with beginners/amateurs enough to understand where pc86 was coming from.
If you describe fibonacci in english, gave some working parameters, I would be willing to bet 15-20% of people who self-identify as "PHP developers" (and get paid a wage for it) would struggle and ultimately fail that test above.
I still see code (not a lot, grant you) where people have not understood what passing a parameter to a function call means, and instead the first line of each function call is a string of "global $foo" stuff.
PHP has been to me and continues to be the most stable platform to build websites upon. Development and deployment are extremely simple, it is rich in functionality and if you know what you're doing, you can write just as reliable and secure code as you can in any dynamically typed language.
I didn't read it all but some people are do dogmatic about things it is stupid. I have dealt with plenty of co-workers who read some book and promptly beat everyone with it.
PHP community had always been anti-frameworks and anti-libraries. I worked at company where use of third-party libraries was entirely forbidden on most projects. I think it's because:
- Quality of PHP frameworks is low (at least it was last time I used it)
- PHP parses and evaluates whole libraries and framework code on each requests. There's proprietary commercial (lol!) software to enable at least caching of bytecode
- Packaging just does not work (Pear, now there's Composer, not tried it, seems that it works)
Overall, last time I used PHP i had sense of its community mostly being nihilistic and preferring cowboy programming. It's straight opposite to Java where you will be shamed for not using dependency injection and EJBs for page visits counter. In PHP world you are considered insane misfit if you're writing tests.
For some things advice to just code and don't use unnecessary libs is useful. Recently I had that php/cgi feeling when I worked on small microservice in clojure: no OOP, no MVC, no ORM, no templates, no separating each 10 lines of code to module, just take Ring request and return Ring response which are simple associative arrays. This was a refreshing feeling.
The biggest problem in the modern PHP community is that you will be shamed for not using DI for a page counter so i don't know what you're talking about.
Paul Graham's quote in "Design Patterns" section actually says nothing or the opposite of what the author is trying to say - Paul says that when he's seeing in the code things (shapes <<of code>>) that repeat themselves, it's an indication to him that he's missing some macro definition that would build this shape for him so he doesn't need to repeat himself by manually creating it all the time - that he can reuse it (as macro).
How does it relate to design patterns? Does it say not to use them? Absolutely not. It says the opposite, if anything - to recognise patterns in your code. "Design patterns" is just an idea that if you see your patterns repeating themselves (some of your macros tend to be very similar in different projects) then you should give it a name. This way when you explain system to your colleagues it's easier to communicate.
IMO one of the key missing points here that is not really considered, is that when you use a well documented and relatively mature framework, it greatly simplifies some of the non-programming related aspects of software development, particularly with regard to getting new developers up to speed, and ensuring that even your junior-most developers are able to contribute without having to become heavily acquainted with your specific implementation of authentication, file uploads, routing, etc.
Well, I always write a command line (CLI) program first, without worrying at all, about what kind of user interfaces (UI) I may do later on.
Frameworks do it the other way around. They generate a skeleton for a web user interface or a mobile app, and next, the real program gets unidentifiably shoehorned in.
There are so many different ways to call a program function: by the user, by one of your own scripts that does it in batch, by an external program through an API, through a web user interface, by a mobile app, by a desktop app, ...
Isn't the most stupid way of building a program, to shoehorn it into a web user interface? It pretty much guarantees that you will have to implement the same logic many times all over again. That kind of applications can never be consistent.
Furthermore, my CLI programs are trivially easy to containerize properly with tools like docker. How can you do that with a monolithic framework monster?
Is it me or is the author confused about the distinction between a library and a framework?
To me, a framework implies inversion of control: you don't call the framework's code; the framework's code calls your code.
Granted, he skirts the issue with phrases like "A framework is a system that helps you build software, but at the same time it forces you to work within the limitations and restrictions of the framework itself", but this describes what a framework achieves, not what it is.
Call me pedantic, but this I find this indicative of poor understanding, and this article raises a number of red flags along these lines, such as this gem:
>PHP on the other hand was created from the beginning by Rasmus Lerdorf as a set of tools written in C that would enable you to easily and quickly develop dynamic HTML. As such PHP was, and still is, a framework in and of itself.
Uh... what?
Maybe I'm overstepping my bounds, but this article is furthering certain stereotypes about PHP-programmers.
I don't think it's murky, I think it's contextual. Code can be used as a library (i.e.: I call it), or code can be used as a framework (i.e.: it calls me).
Some code can be used either way. Sure it's semantic, but meaning is rather important...
I kind of get what he is saying but he is saying it very badly I believe Jeffrey Way the same things a lot better.
Yes you don't need a framework all the time you don't need to do OOP all the time or follow design patterns all the time but the cases in which you don't need to do that are edge cases that very few programmers run into.
Also if you think PHP is a framework then it must be the worst framework ever designed. Libraries exist precisely because they were required to smooth out the inconsistencies and insanities of the underlying language tools.
A framework is just a collection of libraries wove together with some sane default ways of doing things. Some even allow you take them apart and customize them but they give you a good starting point.
If the way the framework does things is not good for your requirements you can try another and only if you are absolutely certain none of them do the job should you roll your own because once you do the barrier to entry for someone new to the code base will be that much higher.
The only thing I do agree with is that security should be a consideration in the development process but here we get back to the fact that a tried and tested framework has already dealt with the most common security issues and as long as you don't do something stupid in your own code you should be OK.
I agree that OOP and frameworks aren't necessary in principle. I vehemently disagree with the notion that they aren't needed in practice for PHP.
I further contend that a PHP programmer advocating against the use of frameworks who doesn't show a clear understanding of what they actually are is not to be trusted. I even go out on a limb to claim that this is representative of the ills of the PHP community at large. That last part, I willingly concede, is debatable and ultimately beside the point :)
To return to the crux of the argument -- that frameworks are not necessary in principle -- I would like to add that this assumes a well-designed standard library. I don't use frameworks with Go, but I sure as hell use them with PHP because the latter is an absolute minefield.
That someone advocating pragmatism would miss this point is astounding. My jaw has dropped and shattered to the floor. How can you rail against principled approaches to software design (a strange position to take, independently of the current debate) only to get hung up on the theoretical feasibility of writing PHP without a framework?!
It's further bewildering that the author would advocate a pragmatic approach to building software, yet neglect that frameworks offer a pragmatic solution to the security concerns that plague PHP. It's almost as if he doesn't understand the terms he's using!
> Is it me or is the author confused about the distinction between a library and a framework?
I don't think so. I agree with your distinction between a library and framework. I think he is talking about frameworks like he says, and his criticisms are indeed applicable to frameworks.
I think he accurately identifies some of the pitfalls of framework use, but there are pitfalls of non-framework use too, some identified in this thread, which can be just as bad or worse. With a good framework in skilled hands, I'd rather have the framework. Depending on what I'm doing.
For some things I might might use Sinatra for in ruby, I might just use straight PHP. Maybe. For things I'd use Rails for in ruby -- I'd use a framework in PHP too.
It is near impossible to write "Modern" PHP and achieve good performance.
On every request, PHP reads and parses every file that is referenced somehow. It is in direct contradiction to the language constructs the PHP itself provides - especially Exceptions, Interfaces and Inheritance.
People want to use these features, because they help design better systems, where the concerns are separated, and features are plugins instead of hardcoded all over the place.
Unfortunately, the required files for a request can pile up quite quickly, to the point where bytecode cache does not help, serving multiple requests per PHP load does not help, prewarming cache for frontend such as Varnish does not help, memory usage is over the roof because of trashed heap memory.
So, to sum up, the author here is right: this is insanity, until PHP provides a module system that can handle PHP abstractions.
>>> The wrong way: Always use a framework on top of PHP
I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many people didn't take this advice (including the teenager me).
It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Yes yes I know there are exceptions and all but, in general, that's truth. Same with frameworks. If you don't use one, you end up writing a poor one, unless all you need is a page that outputs a result of a single SQL query, or something equally trivial.
I've seen plenty of 10k+ LoC applications with home made frameworks, poorly replicating open source ones, just because.
>>> In the world of Python and Ruby building websites from the ground up is tiresome because neither Python nor Ruby was originally created to build websites. As a result general purpose frameworks such as Django and Ruby on Rails quickly became popular for building websites in these languages.
RoR, Django became popular because it's so simple to build basic CRUD apps, which most of the applications are. Most of the stuff is done for you. Can't say the same about plain PHP. The author largely ignores the reasons why the mentioned frameworks became popular.
Yes, you could make a well engineered solution from scratch. But chances are that you will not, time constraints being one of the reasons.
You make a fair point. I've seen this happen before and after a while, projects that have essentially turned into a poor framework, plus the application, can become somewhat of a pain to maintain.
PHP has come a long way in the past few years and the amount of open source packages has become huge, especially since the adoption of composer. I think with that in mind, it is now easier to build and maintain PHP applications without a framework as such, but just with the components you specifically need. Like yourself, I haven't actively been working with PHP for a while either. But it's been interesting to watch what's been happening with it and it's community.
I know what you mean, I once worked on a project which similar to what you describe, the problem in these instances is when the people involved in the creation of the project are no longer involved in the maintenance of the project so the project veers away from the implemented standards and becomes a smorgasbord of badly-integrated composer packages.
That's one of advantages of frameworks - applications using them are somewhat standardized. They have similar structure, you instantly know what's the typical way to save or fetch a database record, etc. Sometimes you can do a bit better by gluing libraries, etc together, sure. But it's rarely worth the trade off.
That was where I stopped as well. I moved from PHP to Django about 9 (wow) years ago because I was reinventing my own ORM and very poor reusable web component set but didn't see something like RoR in the PHP world (there were some early ones but they weren't that appealing at the time). To say PHP is equivalent to Django, RoR or any of the very nice PHP equivalents is . . . I don't get it and thought maybe this was parody of parody.
> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one.
Whereas, often, if you do use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in their documentation that a specific and entirely innocuous-looking schema option causes the ORM to produce a query containing a Cartesian join.
You can use an ORM. Or you can write SQL, work with arrays, and keep your code and data separate. None of that is terribly difficult, and you are responsible for the results no matter what you do. If you can't trust yourself not to get basic things right, you have problems at a level that no library will solve.
The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something.
This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support.
ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM.
ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.
So not using an ORM is bad because you then need to understand the code in detail, but even though using an ORM is good, you then need to understand the code in detail. Gotcha.
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.
ORM doesn't save you from understanding how code works. It is not a tool to avoid learning SQL or UnitOfWork pattern.
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.
Magento is a horrible app with one of the worst ORMs in existence. You've clearly never used it if you're touting it as an example of what to do. Because Magento is a laundry list of what not to do. ORM, EAV, XML config. Drupal may not be the greatest app out there, but it is leaps and bounds ahead of Magento. In fact, it's hard to find anything as shitty as Magento.
Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for anything, not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See:
http://solnic.eu/2015/09/18/ditch-your-orm.htmlhttp://seldo.com/weblog/2011/06/15/orm_is_an_antipattern
and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.
I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities).
The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around.
It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them.
He writes:
> There is no User but it’s very likely there is SignupUser.
And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them.
I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them.
I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects.
The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code).
I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there.
> And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others
You...really can't think in any paradigm other than object-oriented everything, can you? I mean I guess it works for you and that's great but please stop you're really scaring me now.
> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one.
Or you don't, instead you take the time to explore the concepts behind RDBMSes and learn good schema design, how to write good SQL, and so forth. And in the process end up with a high performance database and platform.
This is awesome, thank you! PHP may have started out as a "set of tools", but it evolved into a complete language. Like any programming language, you can write sloppy code or elegant code in PHP - with or without a framework.
Languages are foundations on which frameworks and design patterns can be built to solve common problems. The trap that we fall into is trying to fit all of our problems into those common ones that frameworks and design patterns solve. This leaves potential edge cases that become bigger problems.
PHP can be has hacky or as elegant as you make it. The versatility of that makes it a great utility. It also makes it very approachable. This is a big contributor to why it runs a big part of the web.
193 comments
[ 10.5 ms ] story [ 298 ms ] threadLoved the opening paragraph though
I think the OP has some good points about reconsidering the standard answers that everyone gives to questions when asked. There are no silver bullets in web, but many things sure are treated like them.
Maybe there are projects where PHP isn't right. There are probably tons. But that doesn't mean that it's always wrong. PHP is what got me into making web things in the first place. I loved (and still love) how utilitarian it can be.
But perhaps that's where I differ from most people. I see myself as someone that makes web stuff. Most seem to see themselves as app creators or system builders. And they probably are. Sure, I do that too when the time comes, but if most of the time I'm building a front-end to a CMS, I'm hardly "engineering" anything. I'm mostly just trying to make specific art for other people.
Anyway, I don't understand why PHP would immediately be ruled out from this article. It feels like the JavaScript of the server-side world to me. Use as little or as much as you want. You can do awful things with it, but also wonderful things.
But speaking of boolean logic, negating "always use a framework" does not yield your interpretation.
Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away
Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
PHP is a hammer, blaming the hammer is silly when the person using it might now know how to swing it safely.
In this case, both the hammer and the hammer's user can be blamed.
One great example is the removal of the mysql_real_escape_string function. http://php.net/manual/en/function.mysql-real-escape-string.p...
Another is finally giving us a null coalescing operator, which is a solution for a constant pain point in dealing with raw PHP POST and GET parameters.
The full "new features" list of PHP7: http://php.net/manual/en/migration70.new-features.php
The change log of PHP7+: http://php.net/ChangeLog-7.php
https://github.com/paragonie/airship/blob/8b7edde11b5b57fcb4...
See also: http://stackoverflow.com/a/12118602/2224584
It got a bad name due to the weird nature of PHP which is still a template engine , no matter how much features you had on top. It's like developing webapps in pure HAML, Jinja or Handlebars.
PHP also has a lot of bad design language wise, due to the incompetence of its creator and early maintainers when it comes to language design.
The correct way is to use Twig for your templates
PHP is alot more than a "templating engine" if thats all you think of it then that is your choice
The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings.
I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level.
[0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.
I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.
That is why you should prefer Twig or other templating engine with autoescaping.
> They all start as an attempt to remove the possibility of writing meaningful code
I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/
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?".
> Nevertheless, I used DOM/libxml on the server side in PHP/C,
There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.
Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction.
Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree.
It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.
Except for this one weird trick: PHP absolutely bulls-eye nothing-but-net nailed deployability before deployability was even a word. In 2000, you could download an installer that set up Apache, MySQL and PHP on your Windows box (and it worked, first time and every time), you could fire up Notepad and 15 seconds later look at "Hello World" in your browser. Then you could upload that PHP file to a web hotel at $10/month and the world could see that same Hello World perhaps 10 minutes after that.
Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
That's why PHP is so popular.
1: in zero-to-one deployability for a new user -- the full development and deployability experience just a tiny bit up the learning curve is orders of magnitude better.
Furthermore, I remember a few years back, Ruby was a hassle to set up, especially on Windows.
- no classes (so people end up emulating them: Backbone has methods to emulate class declaration and class inheritance)
- no type hinting. You cannot specify function argument type or return type. It makes code harder to read and to maintain.
- too forgiving. You can divide by zero or mistype a property name and get no error. You can add arrays to strings. It makes bugs harder to find.
- no coding standard. Everyone uses whatever style they like
- no single modules standard
- no syntax for asynchronous operations
- difficult to install XML library on Windows (you need to setup a Visual Studio to compile binary modules)
> Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
You have to learn Linux and command line to use Ruby. No wonder it is more difficult for a newbie. Deploying and running an application is more complicated in Ruby. Also with long-living applications it is easy to get a memory leak.
But recently PHP started to depend more on CLI tools too (installing and using composer might be not easy for people who got used to GUI and don't understand concepts like "working directory").
I know developers who couldn't afford a "formal programming education" or couldn't/didn't go for various reasons, and they'd blow most "formally educated" developers out of the water. I think the word "formal" is surplus here.
> stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
This holds true for anything in life, really. Anyone who uses a tool which they don't understand will sooner or later make a mistake with that tool, and keep making mistakes.
WARNING: The next might be anecdotal, so YMMV. I used to write a lot of code in PHP (and I am grateful, because it is partially responsible for introducing me to the world of programming), but I slowly moved away from as time passed.
The main problems with PHP (apart from some interpreter issues/design decisions which I won't cover, because there's an abundant amount of that online already) are the fact that:
Web development is not any more trivial than system development, or any less complicated. This probably goes for any type of development.To be proficient in either, you need need to cover a very wide range of domains, but PHP resources makes you feel like web development is trivial and easy. Anyone who assumes web development is trivial doesn't really know shit about web development (excuse the language).
tl;dr: I mostly agree with you that PHP's design decisions aren't the only problem bad PHP code exists, and that people who use PHP are largely to be blamed for their own mistakes.
Yes PHP makes it easy for ANYONE to stumble into scripting/programming
But IMHO that is a good thing, the world needs more people getting into programming, if they make mistakes so be it, learning from mistakes is a good way of learning anything.
Nearly all PHP I came across was the mess of some self-taught stumbling way beyond the point they should have been screaming for help, and going back to photoshopp. The docs don't exactly help here (may have changed, it's been a few years) as the apparently helpful comments on each feature aren't moderated in any way and are frequently unhelpful or plain wrong - but they're left to encourage the unwary.
I don't disagree it's perfectly possible to produce decent code with a good coder, and good principles applied to the project. I've seen some very clean looking PHP, and OO classes. That's been because they know the problems of the language and have been careful around such areas, or tried to avoid them entirely. I've worked on a couple of PHP based projects where I couldn't say a word against it as they'd used it well from the start.
We are where we are, but I would have been happier if the tool most often used by "web developers" stumbling in was a little more constrained and consistent about it.
It has a C-style syntax, but similarities almost completely stop there. Especially in modern OO PHP.
It's kind of the point of the whole page - you don't need a massive general framework to solve your specific problem. Maybe read the whole thing instead of just skimming it.
And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it.
Most custom PHP site I encounter are full of gigantic holes.
And then other developpers comes in, and have to learn how to use your non standard code, that is unlikely to be half as well written, tested or documented than standard solutions.
Of course custom code has also a cost, which means doing all that, even not very well, will take a toll on the budget, which you can't spend on other security aspects. All that while security is generally the last item on the budget list.
But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.
1.- Massive project where you're not using 75% of the framework.
Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working.
And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need.
Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller
2.- Separate parts stuck on a massive project
Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works.
3.- Those microservices may not follow a standard.
While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily.
On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).
Basically, don't use a framework unless you really do need all the features it gives you. Don't just pick a framework and try to cram your code into it for the sole purpose of using a framework.
It doesn't matter how much lines you write. It has nothing to do with the number of lines but the functionalities and how many developers review that piece of code. Furthermore more a third party codebase is usually the code you don't have to test. You keep on talking about frameworks like it's a bad thing, but all frameworks are not equal in size nor features.
Including a package based on the contents of its packagist description alone is basically like reading the ingredients for a pizza and then eating a bag of flour.
If you use a framework, new developers coming in often have to learn how to use it as well.
I've never hired a developer who didn't know how to use PDO prepared queries, which are the standard in my code base. Built into the language, escapes no matter what database you use, etc.
Good developers know how to write secure PHP code without a framework. They don't necessarily know how to use a random framework.
Bad developers will at some point take variables from a $_POST/GET array and use them unwisely regardless of whether you have a framework.
Actually it isn't, like at all. A open source framework will always be more secure than the code you "easily write", because a larger pool developers can review,audit,test and fix that code.
The code you do write is going to be more secure if you know what's going on. If it's on top of a billion line framework, you might accidentally break the security without even realizing it. No legions of framework developers reviewed, audited, tested or fixed your actual code.
It might save you time, initially. But at some point you will have to sit down and learn what the framework is actually doing behind the scenes (is it really secure? why is it so slow? I really need to implement this obscure, unsupported by my framework, thing), and you might not be so happy about your choice. Thinking about this ahead of time will save you headaches in the long run.
Think of PHP as sandbox programming. Such an open language, there is a lot of freedom, so many ways to achieve a specific result. The takeaway from the article is that "always do X" shouldn't be a thing, considering a) the vast possibilities and b) your purpose. Frameworks might be too much bloat, patterns should happen naturally, not forcefully. Security should be paramount, but it shouldn't be a blackbox behind third party code, you should be able to explain how you are protecting your users. Etc.
This is not a "don't use a framework/standards/etc" rant. I see it as a reminder to double-check if the current... trends/standards? match your actual needs and wants.
That depends on the scale of what you're building. Generally I would agree with you, but if you building some small, something that would only ever use a small subsection of whatever framework you pick, then you could end up having more issues than if you didn't use a framework.
Just because you aren't using parts of a framework, doesn't mean that security issues in the framework won't affect you.
Let's say your application only ever needs to do one or two queries to a database. It's going to be a whole lot easier for you to lock those two queries down, than securing an entire ORM.
If it's a competent ORM then it shouldn't even expose any way to not use prepared statements, for example.
There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start.
You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems".
It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You do need to know what you're doing.
However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug?
Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first find the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly.
The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.
"You can also find sober drivers that cause accidents". Of course, but it doesn't invalidate the fact that drinking and driving is a bad combo and puts you and others in greater danger statistically. It's sort of similar here.
(Anyone close to familiar with tanks will know it will take quite some effort compared to any of the smaller alternatives ;-)
Then again, most frameworks are more comparable to cars than tanks and people use cars all the time to pick up kids at school even if they could just walk.
Convenient you know and less chance of getting mistaken for a hipster :-]
My favorite is "The wrong way: Thinking of patterns when solving problems." -- textbook reinventing the wheel / NIH.
PSR-4 is the currently accepted best practice for autoloading and while it "may [have] a direct effect upon how you code your software," it's the optimal approach for 99% of projects I've encountered.
Following community interoperability guidelines is what allows developers to move away from monolithic frameworks and compose projects based on the packages they need.
According to who? FIG?
Are you aware that php has a built in auto loader that supports namespaces and is written in C?
> compose projects based on the packages they need.
Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development, where you end up with 50 "micro-frameworks" or "utility libraries" each of which depends on a further 20 other libraries.
I have some issues with this site but it's right that the FIG is a joke, and anyone who claims its "best practice" is not paying attention.
What are you referring to?
[1] https://secure.php.net/manual/en/function.spl-autoload.php
According to the vast majority of authors of the most widely used and tested PHP libararies.
> Are you aware that php has a built in auto loader that supports namespaces and is written in C?
You mean the autoloader builtins that composer uses under the hood already? This is better than a 1 line include how exactly?
> Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development
I don't understand what you're saying here, everyone should be writing their own libraries from scratch? It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
So, FIG.
"Group of developers say that groups' work is the best. News at 11."
> You mean the autoloader builtins that composer uses under the hood already?
No, spl_autoload is a working namespace aware autoloader. Composer uses a bunch of userland code.
> I don't understand what you're saying here, everyone should be writing their own libraries from scratch?
Did I say that? I've seen, multiple times the negative consequences of the current fad to rely on 25 separate, single-purpose 3rd party Libs, all of which are basic functionality that a well thought out library would give you, but with the added "bonus" of each relying on 20 other libraries to do basic things.
> It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
Do the vast majority of developers know that? Because the ones I've had the "pleasure" of working with, definitely don't.
Anecdotally speaking, I'm a Senior Software Engineer working with Go and PHP.
We use Go when working on performance critical code, because for us that's where it excels.
We use PHP when we need simple interoperability with the legacy Magento site our company runs and for jobs like running a CSV importer or some other oft-visited-task. We both get the job done and care about doing it right. You can write some truly beautiful code in PHP if you have the correct level of patience, process and experience behind you.
I very much doubt that people would be getting paid to write any code if they couldn't implement a single for loop in their primary programming language.
I'm sure different experiences exist, but the majority of folks who I speak to have experiences that match mine very closely.
PHP is a ghetto.
I share some of your experiences - I'm disturbed by how easy it is for people without basic coding knowledge to make money "building php websites". But I also see and run in to a large number of people who can do fantastic PHP code (testable, documented, clean, modular, etc).
One thing I've noticed is that most of the people who can do good PHP code (at least in the sense that it's not crappy) have also worked in other languages/tech, either before or during their PHP work. I know the exceptions, but for the most part, someone's PHP code quality is higher if they've done more than just PHP.
That's how most quality frameworks for PHP were born, by folks having used other languages.
That being said, I find Symfony3 to be very decent. I was surprised by the quality of its documentation.
PHP in 2008 is very different to PHP in 2016. PHP frameworks in 2008 are very different to PHP in 2016. PHP developers in 2008 are very different to PHP in 2016.
There were decent libraries and high quality code back in 2008 (and 2000) but people didn't necessarily use them.
It's arguable somewhat easier today, but that's a relative term.
If you're FTPing code from BBedit or Dreamweaver up to your godaddy shared hosting and clicking buttons in cpanel... composer/symfony won't help.
All judgements of quality are relative to the capabilities of the tech/lang/platform at that time.
I'm now a professional .NET contractor (among other things) and looking back at the code we wrote 7 years ago terrifies me. Thankfully I'm not responsible for maintaining it anymore.
I suppose the point is that incompetence is language-agnostic. :)
there are loads of people who take money for working in PHP, and they're closer to pc86's view of things than yours. I wouldn't say "99%" but... there's a lot. A LOT. I've run (and attended) several local tech meetups in my area, and ... there's a huge amount of technical talent, but also a surprising number of people bumbling around with wordpress, drupal and other systems. They generally don't have a clue what't they're doing with respect to PHP code, but they make a living modifying themes by cut/paste stuff from forums.
Personally, I already said I don't think 99% is accurate, but... we'd have to define terms.
"PHP developer" - is that different from someone who modifies (or creates) PHP code as part of their job to earn a living? Maybe they're just "PHP workers"?
The very notion of "array_shift" and "array_push" is foreign to a non-trivial amount of PHP workers.
The word fibonacci is foreign to a hell of a lot of people who make their living in code.
I don't think you interact with beginners/amateurs enough to understand where pc86 was coming from.
If you describe fibonacci in english, gave some working parameters, I would be willing to bet 15-20% of people who self-identify as "PHP developers" (and get paid a wage for it) would struggle and ultimately fail that test above.
I still see code (not a lot, grant you) where people have not understood what passing a parameter to a function call means, and instead the first line of each function call is a string of "global $foo" stuff.
- Quality of PHP frameworks is low (at least it was last time I used it) - PHP parses and evaluates whole libraries and framework code on each requests. There's proprietary commercial (lol!) software to enable at least caching of bytecode - Packaging just does not work (Pear, now there's Composer, not tried it, seems that it works)
Overall, last time I used PHP i had sense of its community mostly being nihilistic and preferring cowboy programming. It's straight opposite to Java where you will be shamed for not using dependency injection and EJBs for page visits counter. In PHP world you are considered insane misfit if you're writing tests.
For some things advice to just code and don't use unnecessary libs is useful. Recently I had that php/cgi feeling when I worked on small microservice in clojure: no OOP, no MVC, no ORM, no templates, no separating each 10 lines of code to module, just take Ring request and return Ring response which are simple associative arrays. This was a refreshing feeling.
That said, in terms of timeline, PHP has gotten better as a whole since then.
How does it relate to design patterns? Does it say not to use them? Absolutely not. It says the opposite, if anything - to recognise patterns in your code. "Design patterns" is just an idea that if you see your patterns repeating themselves (some of your macros tend to be very similar in different projects) then you should give it a name. This way when you explain system to your colleagues it's easier to communicate.
Frameworks do it the other way around. They generate a skeleton for a web user interface or a mobile app, and next, the real program gets unidentifiably shoehorned in.
There are so many different ways to call a program function: by the user, by one of your own scripts that does it in batch, by an external program through an API, through a web user interface, by a mobile app, by a desktop app, ...
Isn't the most stupid way of building a program, to shoehorn it into a web user interface? It pretty much guarantees that you will have to implement the same logic many times all over again. That kind of applications can never be consistent.
Furthermore, my CLI programs are trivially easy to containerize properly with tools like docker. How can you do that with a monolithic framework monster?
To me, a framework implies inversion of control: you don't call the framework's code; the framework's code calls your code.
Granted, he skirts the issue with phrases like "A framework is a system that helps you build software, but at the same time it forces you to work within the limitations and restrictions of the framework itself", but this describes what a framework achieves, not what it is.
Call me pedantic, but this I find this indicative of poor understanding, and this article raises a number of red flags along these lines, such as this gem:
>PHP on the other hand was created from the beginning by Rasmus Lerdorf as a set of tools written in C that would enable you to easily and quickly develop dynamic HTML. As such PHP was, and still is, a framework in and of itself.
Uh... what?
Maybe I'm overstepping my bounds, but this article is furthering certain stereotypes about PHP-programmers.
Some code can be used either way. Sure it's semantic, but meaning is rather important...
You probably are. You'd make a better case if you were actually discussing http://www.phptherightway.com/.
Yes you don't need a framework all the time you don't need to do OOP all the time or follow design patterns all the time but the cases in which you don't need to do that are edge cases that very few programmers run into.
Also if you think PHP is a framework then it must be the worst framework ever designed. Libraries exist precisely because they were required to smooth out the inconsistencies and insanities of the underlying language tools.
A framework is just a collection of libraries wove together with some sane default ways of doing things. Some even allow you take them apart and customize them but they give you a good starting point.
If the way the framework does things is not good for your requirements you can try another and only if you are absolutely certain none of them do the job should you roll your own because once you do the barrier to entry for someone new to the code base will be that much higher.
The only thing I do agree with is that security should be a consideration in the development process but here we get back to the fact that a tried and tested framework has already dealt with the most common security issues and as long as you don't do something stupid in your own code you should be OK.
I further contend that a PHP programmer advocating against the use of frameworks who doesn't show a clear understanding of what they actually are is not to be trusted. I even go out on a limb to claim that this is representative of the ills of the PHP community at large. That last part, I willingly concede, is debatable and ultimately beside the point :)
To return to the crux of the argument -- that frameworks are not necessary in principle -- I would like to add that this assumes a well-designed standard library. I don't use frameworks with Go, but I sure as hell use them with PHP because the latter is an absolute minefield.
That someone advocating pragmatism would miss this point is astounding. My jaw has dropped and shattered to the floor. How can you rail against principled approaches to software design (a strange position to take, independently of the current debate) only to get hung up on the theoretical feasibility of writing PHP without a framework?!
It's further bewildering that the author would advocate a pragmatic approach to building software, yet neglect that frameworks offer a pragmatic solution to the security concerns that plague PHP. It's almost as if he doesn't understand the terms he's using!
I don't think so. I agree with your distinction between a library and framework. I think he is talking about frameworks like he says, and his criticisms are indeed applicable to frameworks.
I think he accurately identifies some of the pitfalls of framework use, but there are pitfalls of non-framework use too, some identified in this thread, which can be just as bad or worse. With a good framework in skilled hands, I'd rather have the framework. Depending on what I'm doing.
For some things I might might use Sinatra for in ruby, I might just use straight PHP. Maybe. For things I'd use Rails for in ruby -- I'd use a framework in PHP too.
This website should be taken down. Wanna be back to the 2000's, are we?
On every request, PHP reads and parses every file that is referenced somehow. It is in direct contradiction to the language constructs the PHP itself provides - especially Exceptions, Interfaces and Inheritance.
People want to use these features, because they help design better systems, where the concerns are separated, and features are plugins instead of hardcoded all over the place.
Unfortunately, the required files for a request can pile up quite quickly, to the point where bytecode cache does not help, serving multiple requests per PHP load does not help, prewarming cache for frontend such as Varnish does not help, memory usage is over the roof because of trashed heap memory.
So, to sum up, the author here is right: this is insanity, until PHP provides a module system that can handle PHP abstractions.
I suspect you're being downvoted because we have this: https://getcomposer.org + https://secure.php.net/manual/en/language.oop5.abstract.php
You probably haven't even used opcache.
I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many people didn't take this advice (including the teenager me).
It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Yes yes I know there are exceptions and all but, in general, that's truth. Same with frameworks. If you don't use one, you end up writing a poor one, unless all you need is a page that outputs a result of a single SQL query, or something equally trivial.
I've seen plenty of 10k+ LoC applications with home made frameworks, poorly replicating open source ones, just because.
>>> In the world of Python and Ruby building websites from the ground up is tiresome because neither Python nor Ruby was originally created to build websites. As a result general purpose frameworks such as Django and Ruby on Rails quickly became popular for building websites in these languages.
RoR, Django became popular because it's so simple to build basic CRUD apps, which most of the applications are. Most of the stuff is done for you. Can't say the same about plain PHP. The author largely ignores the reasons why the mentioned frameworks became popular.
Yes, you could make a well engineered solution from scratch. But chances are that you will not, time constraints being one of the reasons.
Sorry, couldn't read further than that.
PHP has come a long way in the past few years and the amount of open source packages has become huge, especially since the adoption of composer. I think with that in mind, it is now easier to build and maintain PHP applications without a framework as such, but just with the components you specifically need. Like yourself, I haven't actively been working with PHP for a while either. But it's been interesting to watch what's been happening with it and it's community.
Whereas, often, if you do use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in their documentation that a specific and entirely innocuous-looking schema option causes the ORM to produce a query containing a Cartesian join.
You can use an ORM. Or you can write SQL, work with arrays, and keep your code and data separate. None of that is terribly difficult, and you are responsible for the results no matter what you do. If you can't trust yourself not to get basic things right, you have problems at a level that no library will solve.
This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support.
ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM.
ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.
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.
The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around.
> http://solnic.eu/2015/09/18/ditch-your-orm.html
It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them.
He writes:
> There is no User but it’s very likely there is SignupUser.
And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them.
I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them.
I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects.
The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code).
I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there.
I also have read this article http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQ... ).
You...really can't think in any paradigm other than object-oriented everything, can you? I mean I guess it works for you and that's great but please stop you're really scaring me now.
Or you don't, instead you take the time to explore the concepts behind RDBMSes and learn good schema design, how to write good SQL, and so forth. And in the process end up with a high performance database and platform.
PHP runs a lot more. Over 80% according to w3techs.
Here's a sober reason why to use a framework http://symfony.com/why-use-a-framework.
Languages are foundations on which frameworks and design patterns can be built to solve common problems. The trap that we fall into is trying to fit all of our problems into those common ones that frameworks and design patterns solve. This leaves potential edge cases that become bigger problems.
PHP can be has hacky or as elegant as you make it. The versatility of that makes it a great utility. It also makes it very approachable. This is a big contributor to why it runs a big part of the web.