PHP the Wrong Way
phpthewrongway.com
phpthewrongway.com
"These people [framework creators] seems to be infatuated by the though of having other people follow their “way of doing things”, becoming some kind of PHP community leaders, and having other people use their latest “hip” Open Source tools..."
How lame of these people.
The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry.
On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely.
I'll be having his "way of doing things" for dinner whether I want it or not, the only difference is that I won't have a community of other people in the same situation.
This aspect isn't addressed by the author at all, although he found just enough time to provide us with a psychological analysis of framework authors and their narcissist motivations :)
Your premise - on which you based a slightly convoluted ad hominem, implying lack of professional experience on my part - is false to start with. While I did have some PHP experience, I'm not really a web dev. I'm a mobile (Android) and desktop (Windows) developer. Having said that, with web applications you typically have more moving parts and layers to integrate than in case of a client app.
I can buy a book on Django/Flask/Symfony/Spring/Express. I can't buy a book about your homebrew 30k LOC "non-framework" which does all the same things plus an additional customized CRUD layer.
> Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided."
If a large majority of the code you've been given to maintain could instead be handled by well known, well documented project with thousands of eyes fixing bugs and adding features, you would probably say the same thing.
Imagine inheriting a java codebase of a simple POS system with a UI. Except instead of using Swing or AWT or I don't know what else, the entire UI is custom written in OpenGL. And instead of using any of the standard sorting or ArrayList implementation, they write their own, which are similar, but not identical (and often have 0 tests).
But I think people programming other types of software have structure that comes from elsewhere. For example, if you write plain Android or iOS apps, in may ways there's a kind of standard app architecture that's just used and taken for granted. Sure, it can be muddled, but only so much for the most part. And the same is largely true for desktop applications, too, when they're built with IDEs that impose structure or even things like Unity.
The thing that's extra weird about this is that most web apps have to reinvent the wheel in ways that desktop software doesn't.
> Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.".
Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is very likely to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").
No, why would it? What HTTP client framework am I supposed to be wishing they used?
>Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain?
No? What does that have to do with anything?
>Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).
Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?
I wasn't under the impression we should be limiting this to frameworks. What's the difference between a framework and a library for the purpose of this discussion? I think they are functionally equivalent. I was clear to equate it to crypto originally, which doesn't really make sense when viewed as applying to frameworks only. We're a couple comments removed from that, I thought that wasn't in question. Same with an HTTP client. Frameworks don't event necessarily implement clients. I'm addressing NIH syndrome, and I don't think frameworks really deserve special consideration in any way.
> Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?
See above. And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?
The discussion is entirely and solely about frameworks..
>What's the difference between a framework and a library for the purpose of this discussion?
Wikipedia exists.
>See above
Above what? Nothing you said above answers my question.
>And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?
Because it has absolutely nothing to do with anything I said, like I clearly stated.
That said, I'm not entirely happy with the way the tone of this conversation is heading, so I'll excuse myself now.
You'll have to forgive me for not guessing that given that nothing in your post came anywhere close to even suggesting anything of the sort. I am limited to reading what you write, and can not read your mind.
Yes, frameworks are different from libraries. Boy, that was productive.
Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often.
Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. Whether or not it's easy depends on the quality of code and documentation. Given equal size of the code that does the job, reasonably written framework-free code is probably going to be easier to understand, because it doesn't have external dependencies.
I never understood why after years of dealing with dozens of competing and rather poorly constructed web frameworks in Java, PHP and now JavaScript people still believe that those things have some kind of inherent value. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?
I don't think this is true.
If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours.
If you're learning one person's approach, you have exactly one person you can ask about it: Greg. Who might quit, or go on paternity leave, or get hit by a bus. If you're lucky, you might also have some coworkers who understand parts of that system.
You're assuming that learning the framework will make understanding actual workload code completely effortless. In non-trivial applications this is never the case. You still have to understand... stuff like this, for example:
http://mikehadlow.blogspot.com/2010/04/custom-aspnet-mvc-mod...
When someone writes code from scratch the quality of the code depends on their ability. When someone uses a framework the quality of the code depends on their ability, the quality of the framework and fitness of the framework for a particular problem.
If the developer is not very experienced but sufficiently disciplined, and the framework is well-designed and fits the chosen task well, than yes, you end up with better code. If any of those conditions fail, the code is usually just as bad or worse than vanilla.
You can't make things foolproof. Fools are very clever.
this is like gospel.
I think this is just confirmation bias - you won't notice all the times you are not fighting the framework, but you do when you are.
> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things
Only if "some person" is real fastidious with documentation, StackOverflow answers and tutorials. You aonly have to learn Laravel[1], but catching up with Greg/Peter/Jane/Paula's framework at every new job will get old fast.
> Remember Struts, anyone? PHP Nuke? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP?
Those projects were fantastic for their time. Let me put it this way - I would rather maintain something that used those projects and not some custom solution written by a nameless developer in the same era. At least PHP Nuke had (I'm hoping) a clear migration path to PHP v4 and v5 and you won't have to do it manually.
1. Or any other framework
I wrote a very large PHP application around that era.
You are absolutely correct. Even I have a hard time maintaining that code.
Many developers love a particular framework and they use it as often as possible and it works well for them, one reason being that over time they become familiar and accustomed to it's strengths, patterns, flaws and idiosyncrasies. But I personally find no pleasure in having to familiarize myself with a crusty old framework that I will never touch again in my career versus well-organized vanilla PHP.
Consider that Ruby has a few dominant frameworks--like Rails--built on a language with read-hostile features like monkey patching. Unlike Python Ruby often has many ways of doing things, and that's reflected in community gems. (EDIT: swipe-typing fail.)
Regardless, there has been some coalescing around more modern PHP frameworks like Laravel recently.
That seems exactly what what is being advocated for here but with PHP and Composer instead yet the response is reversed.
You're at his mercy if he used a framework, too. There's nothing to require that he used it in a sensible way. The only difference is that now you get to discover the innermost details of the framework, too, at the same time you're trying to figure out what Greg was doing, and you also get to figure out which is which.
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.
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.
It's also very different than Perl or Python. It tries to be specific to the web and that makes a lot of oddities that the more general languages do not have.
OTOH you can make a fantastic design in PHP. It's just that there are very few people who know how to do that. Frankly, because it's not taught... anywhere.
So, yeah, as much as I've learned how to use PHP (through 11 painful years), it's really hard to figure out how to use correctly. It's possible.
The ideal PHP design (currently) is a hybrid between OOP and straight script that will look bizarre to anyone from, well, any other background. As others have mentioned you have to be very careful not to load too much into memory or you will come crashing down fast.
I still use it, because now I know how, but, ironically, I wouldn't recommend it. It's so very different from anything else that I don't know that the skills transfer well to other languages (other than straight-up problem solving).
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.
include 'vendor/autoload.php';
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.
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.
(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 :-]
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.
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.
> Just because those tools exist doesn't
> mean people use them.
> here were decent libraries and high quality code back in
> 2008 (and 2000) but people didn't necessarily use them.
All judgements of quality are relative to the capabilities of the tech/lang/platform at that time.
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.
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.
$iterations = 50;
$numbers = [1,0];
for($i=0; $i<$iterations; $i++) {
array_push($numbers, $numbers[0] + $numbers[1]);
array_shift($numbers);
echo $numbers[0];
}
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.
Here's a sober reason why to use a framework http://symfony.com/why-use-a-framework.
Design patterns aren't bad per se, even if they imply some problems with language's capabilities to abstract - because they shift an abstraction from code to programmers' shared knowledge. The problem is with what I would call "design-pattern-driven development" - attempting to fit your problem into the bunch of design patterns you know. It's unfortunately very common.
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.
Loved 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.
My favorite is "The wrong way: Thinking of patterns when solving problems." -- textbook reinventing the wheel / NIH.
PHP runs a lot more. Over 80% according to w3techs.
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.
This website should be taken down. Wanna be back to the 2000's, are we?
There are some minor drawbacks in the core language, nothing compared to the python 2/3 split and all the virtualenv and packaging mess, and the sub-par arhitecture of rails (as far as i heard).
Mind you this is limited to web development, php does not shine in any other field.
People FTPing their code to a server or writing code in pure (probably sub-optimally designed) PHP beyond trivial scripts and web pages are not representative of the PHP community at all. At least not in europe.
- 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.
This unfortunately sounds like the cry of a programmer who has worked on their own for years suddenly encountering the requirements of working with a team of coders.
Garbage. You know it's going to be garbage when some idiot tells you not to use a framework but is too fucking stupid to realize that if you don't use one, you have to write one yourself. Every single time. And PHP as a framework itself? Please. PHP is a horribly shitty framework itself for any app that's going to be more than a couple hundred lines of code. It's only with a proper framework on top that it becomes a proper web development platform (some may argue otherwise but their ignorance can be safely ignored). But I assume the author has never written anything more than a demo app, so yeah, if you're writing short scripts under 500 lines, don't use a framework. If you're writing real apps, don't listen to idiots like this author. This isn't PHP specific. There's nothing that makes PHP different from Ruby or Python. Appeals to PHP having been developed for the web are idiotic because while true, it's irrelevant due to the poor quality of PHP < 5 and especially PHP < 3. Yes, it was specifically developed for the web poorly and we've been fixing that ever since. If the author wants to use PHP 2 or 3 (or whatever the fuck they were called), that's one thing, but to pretend that coding in PHP 2/3 style is what makes proper apps these days is fucking insane.
So, framework are basically to speed up work in same elegant way the others are doing.