Why learn frameworks when you can build everything from scratch and become a true carpenter (<i>"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"</i>).<p><i>"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..."</i><p>How lame of these people.<p>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.<p>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.<p>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.<p>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 wrong way: Always use a framework on top of PHP<p>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).<p>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.<p>I've seen plenty of 10k+ LoC applications with home made frameworks, poorly replicating open source ones, just because.<p>>>> 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.<p>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.<p>Yes, you could make a well engineered solution from scratch. But chances are that you will not, time constraints being one of the reasons.<p>Sorry, couldn't read further than that.
Is it me or is the author confused about the distinction between a library and a framework?<p>To me, a framework implies inversion of control: you don't call the framework's code; the framework's code calls <i>your</i> code.<p>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 <i>is</i>.<p>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:<p>>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.<p>Uh... what?<p>Maybe I'm overstepping my bounds, but this article is furthering certain stereotypes about PHP-programmers.
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.<p>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.<p>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.<p>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.<p>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.<p>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.
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).<p>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).
So the author considers following PSR guidelines beyond 1 and 2 to be "the wrong way"?<p>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.<p>Following community interoperability guidelines is what allows developers to move away from monolithic frameworks and compose projects based on the packages they need.
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 satirical right? Unless you're building something super trivial, a framework is the way to go. You end up reinventing the wheel anyway.<p>Here's a sober reason why to use a framework <a href="http://symfony.com/why-use-a-framework" rel="nofollow">http://symfony.com/why-use-a-framework</a>.
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.
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.<p>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.<p>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 :)
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.
There is a grain of truth in what they're trying to say, but the conclusions are outright misguided.<p>My favorite is "The wrong way: Thinking of patterns when solving problems." -- textbook reinventing the wheel / NIH.
It is near impossible to write "Modern" PHP and achieve good performance.<p>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.<p>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.<p>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.<p>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.<p>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).<p>Mind you this is limited to web development, php does not shine in any other field.<p>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:<p>- 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)<p>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.<p>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.
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.<p>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.
<i>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.</i><p>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 <i>poorly</i> 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.<p>So, framework are basically to speed up work in same elegant way the others are doing.