Why learn frameworks when you can build everything from scratch and become a true carpenter ("building software using general purpose frameworks doesn’t make you a coder or a programmer any more than putting together a pre-built house makes you a carpenter").
"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 :)
> 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.
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#?
> Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often
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.
> 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
I wrote a very large PHP application around that era.
You are absolutely correct. Even I have a hard time maintaining that code.
> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things.
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.
>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.
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:
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.
More often than not, when I have inherited a project built on a common PHP framework the documentation and community knowledge available is limited because the framework used is, most commonly, not the latest version. So you are basically wading through the tall grass of online resources trying to ascertain what knowledge applies to what version, which for some frameworks can differ tremendously between major releases.
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.
I wonder why this mentality only exists with web devs. Everywhere else, someone writing software is considered normal, not some scary problem. 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.". It is just normal. Perhaps the low barrier to entry and corresponding low average experience of web developers plays a part in this mentality.
Because 99% of web dev code is the same stuff and 99% of the time it doesn't need to be rewritten. You don't need your own implementation of URL rules, user authentication and roles, testing suites, database driver or ORM, request parsing, csrf protection, session handling....
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).
This whole argument is based on two false assumptions. One, that shitty broken web frameworks like cakephp and zend are "well known, well documented project with thousands of eyes fixing bugs and adding features" rather than the horrible messes they actually are. And two, that web apps are the only software to share any common aspects. Every lame VB+Access app I ever saw had more in common than two randomly chosen web apps. Yet nobody needed a "framework" to enforce worst practices and ensure that everything was done inefficiently and unmaintainably.
Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO.
> 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?").
Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? 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).
>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?
>My point was frameworks are functionally no different than a large complex library
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.
"I wonder why this mentality only exists with web devs [...] Nobody sees any other kind of application [...]"
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 think you're right that the propensity of non-technical organizations to try and hire unqualified people at below market rates leads to a particular problem in web development.
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.
I think some of it has to do with the languages involved. I find the type systems of C/C++/Java to be helpful in figuring out what a piece of code does, as compared to the type systems of Python/PHP/Ruby where it's more difficult to tell what a variable contains. Frameworks help solve this problem because you can infer what type of data you've got by looking at what method it's coming from and where it's being used.
Not sure why you think it doesn't happen in other fields. Every time I spoke with a software developer, they were constantly cursing the architecture of the code they had to dealt with.
> 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.
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.
The underlying issue is that PHP is bad at frameworks and because of that there are dozens of them. If there was one, clear, dominant framework it would be one thing...but there's not so investing in using any particular PHP framework is just about as risky of a proposition as rolling your own.
This is likely more an artifact of the PHP community and philosophy being focused on ease of use and deployment, circa early 2000's.
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's true. One of the things that I find particularly interesting is the response to this with PHP vs that of Go. As I've picked up Go, the distinct impression that I've gotten is one of total anti-framework with the idea of just pulling in the parts you needs for what you're doing. Even a general disdain for using anything that isn't in the stdlib.
That seems exactly what what is being advocated for here but with PHP and Composer instead yet the response is reversed.
>>> 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.
> 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.
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.
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.
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.
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.
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.
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 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!
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...
> 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.
PHP is the very different from development in C# or Java. Anyone from those backgrounds pretty much automatically hates it. PHP will punish you hard for designs that would be fantastic in .NET or Java.
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).
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.
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.
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.
> 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.
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.
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).
> 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.
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.
>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.
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.
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?
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.
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 :-]
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.
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.
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. :)
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.
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.
The usage of that Paul Graham quote is hilarious. The author misses the point entirely! Graham uses the word pattern to describe a repeated piece of code that matches a pattern. And it's a sign of trouble: a violation of the DRY principle. Nothing to do with design patterns really. Are all the other quotes used as unsuitable, we don't know.
No, the author does not miss the point - though I assume he may not understand it fully. The quote is written in context of Lisp macro facilities, which let you DRY your code from a lot of things, including GoF-style design patterns. So e.g. if you see yourself using "Memento pattern" (or whatever) in many places in your code, writing the same kind of methods doing the same thing everywhere, you should consider writing a macro that'll do that for you instead. That is, if your language lets you do that. Design patterns really start where the language's ability to abstract ends.
No, I don't think so. That's not a critique towards design patterns. It's critique towards ANY CODE THAT IS REPEATED. If I use a certain design pattern once in my code, I didn't repeat anything. Macros don't remove the design pattern, they just allow me not to repeat myself.
You rarely use design patterns only once in a project. And while this quote does not cover it, you can also use macros to better communicate that one-off design pattern instance - instead of identifying a pattern by noticing a set of familiar methods or a typical inheritance graph, the person reading your code can just see the the macro invocation and know he's dealing with a particular design pattern here.
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.
I don't think there's such a problem really. We all try to fit the problems we encounter in designing software into a bunch of knowledge that we know. That bunch might be a set of design patterns. There's nothing wrong with that. Sometimes they fit perfectly and sometimes they don't. Sometimes the software we produce is not perfect.
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.
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.
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.
The entire argument could be reduced to: "be informed, and make good decisions" which is a very banal statement that could be applied to almost every endeavor in life. Because PHP makes it so easy to be productive without being informed you run the risk of unknowingly making bad decisions. There is an exhortation to use frameworks so that if you aren't informed you at least get the guide rails / hand-holding / best practices that the framework imposes on you.
This is why I don't use Cocoa to write iPhone apps, or Swift, but ARM assembly. True carpentry! Jesus was a carpenter too, and God spoke the machine code of the universe.
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 :)
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.
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!
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.
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.
Between composer and symfony and php 7 I would say PHP is ahead of both ruby and python communities in terms of code quality, perfomance and ease of deployment.
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.
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.
It's rather a shame that the author of this site has chosen to be anonymous; I should like to understand why they choose to reject a number of points generally considered best practice in software engineering, regardless of programming language: patterns; frameworks; library reuse; standards bodies etc.
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.
At over a dozen PHP jobs in over ten years, I've never seen a real application without a framework be anything but fucking garbage.
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.
We don't have to reinvent the wheel everytime we create apps or any product using framework. Like imagine , When my every product needs login / register mechanism , i would look for something that is really fast, secure and may/may not have better approach of doing that.
So, framework are basically to speed up work in same elegant way the others are doing.
"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 :)