I had to do some PHP 2-3 years ago. I had always had a negative view of PHP prior to that despite knowing almost nothing about it, which I think is a not uncommon experience.

Anyway, there are lots of things that offend people about PHP that are basically inexcusable: like the inconsistency in parameter order (needle, haystack or the other way around?) and the inconsistent use of underscores in API method calls.

But all of that is just noise. Use something like PHPStorm, Netbeans, Komodo or whatever and it'll tell you the right order or if the function doesn't exist (I know some people are still in love with their raw text editors; I'm not one of them). And you learn quickly enough the right names and orders.

One thing I love about PHP is the simplicity of it. Edit the file, save, refresh in the browser. I love this short feedback loop. It was a refreshing change from doing Web apps in Java (for example), which added a compile/build/package step in between.

After doing this I investigated the common frameworks (CodeIgniter, Kohana, Zend, etc) and frankly I was horrified.

These things are so hideously overcomplicated. It's like a zealous Java programmer tried to recreate "Super-Struts" in PHP in a devilish plan to destroy all of the advantages of PHP while leaving a lot of the negatives.

The number of times I got bitten in the ass or just wasted time trying to figure out how the "magic" in Zend worked was infuriating.

Take something as simple as a controller. This is stupidly easy to implement yourself that any sort of generic framework is just going to bring you pointless crap you don't care about to the stuff you do by a factor of probably 10:1.

The ORM side was even worse. Java is kinda built for ORMs. It has stateful Web containers. PHP isn't (and doesn't).

The one bright spot I found was templating. It is common to say "why use a templating language with PHP when PHP is a templating language?" and you have an entire valid position. I too have said this.

That being said, I found Smarty to be incredibly useful just from the point of view of caching parts of the page and creating my own plugins/extensions for tasks that were common to me. Smarty had other issues like I wasn't completley fond of it's caching model and the speed, prior to Smarty 3 at least (which I've never used), was also questionable.

But despite all that I liked it a lot.

So can you use PHP without a framework? Sure you can. Not only that, I'd highly suggest it if you know what you're doing.

> Summing it up, a framework tries to save you work by make you define an overly complex configuration, that has to accomodate every possible use case.

I was disappointed that the author constructs his arguments against frameworks by using Zend, and Zend alone... when there are things like Symfony, Cakephp (which I'm a fan of) and Code Igniter. It is what allows him make a generalization like the one above that is flat out wrong for frameworks like codeigniter and Cake.

I've been a PHP guy for many years (still am) and I know that as you program more and more in PHP, you come up with a way of doing things that eventually become your own sort of framework ... so the people that really appreciate frameworks are more experienced developers (no insult to newbs) because they can more easily recognize all the problems that these frameworks solve for them ... to newer programmers it looks like bureaucracy, magic and stuff that gets in the way of them actually expressing their ideas in code.

I know. I was one of those guys.

So yeah ... You can use PHP without frameworks and if you like doing that, then keep doing it ... however, I would advise any PHP developer to keep an eye on the major frameworks and keep evaluating ways that they can save you time and effort as you take on more complex applications with bigger and better teams (yes ... you actually get to develop code with other people as you take on bigger projects).

PS: My only complaint with the PHP framework I like ... CakePHP, is that it can be a bit slow and the documentation can be truly horrendous ... to where you have to go digging around in the source code to figure out the things you can put in the $options array in a call like this ...

    checkbox(string $fieldName, array $options)

I really liked this article. It generalizes very well, and dovetails neatly with Aaron Griffin's excellent rant:

https://bbs.archlinux.org/viewtopic.php?pid=147321#p147321

As he says so well: Rails/Django/Turbogears/etc etc - Frameworks overly designed to "make it easy" while "hiding details" and "providing event based functionality". I got news for you.... these "details" that are hidden, they're less complicated than these frameworks.

One of the attractions of PHP is that you can use it as much or as little as you need.

Have a static site that needs one page with dynamic content? Just make that one page PHP, and do whatever you need.

Need a basic caching/templating engine? Smarty.

Need a basic linear blog? Hack something with Wordpress.

Need a more complex site with categories and plugins, that fits into a wide community? Drupal.

Need to have full control over how the thing works? Use something like CodeIgniter or Cake.

Lots of options out there, and PHP is stupidly simple to deploy compared to most other technologies.

I think there's a few huge positives about using a framework that outweight the cons. He's right about singletons and other anti-pattern oversights and he's right about bloat and performance hits over inline mysql_query(), but here are the reasons I won't be going back to php direct for any project I expect to scale.

* My home rolled framework has no docs. I will have no idea what my mindset was 3 years from now and I'll have nothing to look up but a few one liner method descriptions. No thanks.

* As Cal Henderson said in his I hate Django talk, 90% of the framework is right and speedy to develop on - hacking around the stuff that's wrong takes time, but few people even get there in their projects.

* PHP sucks (You're still okay, php). PHP's docs suck. Save yourself the time and pain of learning poor functional design tips on php.net, almost any framework now will help you to separate concerns of your project. Best practices are not PHP's strong point - Have a look at almost any web designer's "well made" code and you'll see that PHP simply doesn't teach SoC.

* You usually get XSS, SQL injection and CSRF protection in a framework. nuff said.

* Unless database mapping is what you know and do for a living, the database abstraction layer that you build will not be as good as the ones that already exist. It's a rule.

I used to be a stubborn framework hater, but after using a framework for a few projects, I'll never be back unless there's some impossible performance or disk space consideration. Pick one and learn to love it.

What's the difference between getting locked into a framework someone else developed, and getting locked into your own framework that you end up having to develop?

At least with something like CodeIgniter, you can go elsewhere for help.

Sure you can, but why would you want to? Reinventing the wheel is not fun.

A colleague pointed me to Yii Framework [1] a couple years ago, and I stopped looking for alternatives. Don't see any reason to invent my own frameworks, since Yii has practically every feature I could want already implemented and, more importantly, well tested. In those rare cases when I need to customize or extend something, it's fairly simple to do so, since the code is well documented and organized (though the authors seem to be suffering from a severe allergy to whitespace...).

Controllers with access control rules and filters? Check.

Autoloading? Check.

Caching with support for multiple mechanisms (file cache, db cache, eAccelerator, MemCache, XCache, Zend Data Cache)? Check.

DB layer based on PDO? Check.

ActiveRecord? Check.

Mass attribute assignment to Active Record, complete with validation and allowed/forbidden attribute configuration)? Check.

Named scopes? Check.

Multiple database engine support (MySQL, MSSQL, Oracle, SQLite, PostgreSQL)? Check.

Testing environment? Check.

CLI mode? Check.

I18N support? Check.

Plain PHP views with simple HTML escaping and HTML construction? Check.

Event raising and handling? Check.

[1] http://www.yiiframework.com/

Edit: However, no framework can take away the programmer's stupidity. My former colleague used another framework that has decent support for parametrized queries and still concatenated his SQL from raw user input and printed data into javascript variables by simply wrapping it in '' with no escaping... So glad all of his code has been retired.

I don't know, seems like every site that doesn't use a framework is fantastically vulnerable to various hacks.

Let's face it, it is hard, really hard, to lock down every last vector of attack in anything but the most trivial web app. SQL injections are old hat, but even the big dogs get XSS vulnerabilities wrong. Using an established framework helps in making sure you don't make idiotic mistakes.

The article also goes on about 'lock in' here and there. What you call 'lock in', I call a shared understanding on how to do things, letting me understand other's code and collaborate more easily. I can look at any Django project and understand what's going on in a minute or two, because it is a standard. I doubt I can say the same for your custom PHP site, even if it makes perfect sense to you.

I've been working with php for about 10 years now. I have to say that I really enjoy frameworks. They make my job a lot easier. Before I started using frameworks I already built one of my own without realizing it.

To start off with I had my own classes to make tasks a little easier. Most php applications deal with a database of some sort, because of that I created a database class that helped me connect to a database and get the information I need. Same with templates. I used smarty since I didn't see a need in making my own. I had my own directory structure and config files for everything. When I was working on a site that needed something was usually when my 'framework' got updated.

Then I started reading about frameworks. I have used most frameworks in one way or another. The one that I prefer over other php frameworks is symfony (symfony-project.com). Why? They use doctrine as an ORM. They already have best practices built in. It's not as 'bloated' as other frameworks. Take CodeIgniter for example. Then go take a look at Kohana (which is a stripped down version of it). Once version 2 comes out they will have PHPUnit bundled with it. They use existing open source software instead of reinventing the wheel and making one for that framework only.

What is the benefit to you as a php programmer to use a php framework? There are a lot of things to take into consideration when creating a web application such as security. Are you escaping user input before you use that input in a MySQL query? What about user session management? There is more to consider, but hopefully you should get the idea. You start to see yourself repeating the same code after awhile so you start making classes or functions that make your job easier.

Should you use php without a framework? You can, but you will essential be creating your own after awhile. IMO it's best just to research a few different ones and find the one that best suits your needs since you can leave the framework development to other guys while you focus on creating a site. For me, symfony best fits my needs. Others may want to check out CakePHP or other frameworks. I never cared for Zend Framework, but use the zend library.

Whatever your taste in ORM mappers, templating, localization and other "magic", you can get away without a framework, but you will (in one way or the other) need to do all of the following:

- Define/create some controller or structure in how URLs map to different scripts/functions etc. That includes some "system" that you use (even just remembering) for where each app executes.

- Handle output and page parsing. If you want errors and other messages to always appear within your template and not before even the starting <html> tag or if you need to be able to set cookies or send other headers() before the output you will need to control output buffering (using ob_XX() functions)

- Authentication. Most (99%?) web apps need a user to be able to login. You can roll your own in this regard, but that will take skill and careful planning. You need to be able to specify which parts of your controller are available to which users, etc.. this can start getting complicated real soon.

You can roll your own, but you will actually be rolling out a framework.

So just realize you're not choosing between using a framework or not using a framework - you're choosing between using your framework or somebody else's.

I find that the most useful frameworks provide conventions for structure and code organization along with pre-built libraries for most common functions (DRY). I avoid frameworks that make it overly difficult to deviate from these conventions when needed and those that make it difficult to override built-in functionality. The best frameworks are the one's that realize early on that they cannot solve every every problem and edge case.

For PHP, I prefer to use Kohana. It has a nice structure and does just enough, while maintaining flexibility.

i disagree with this part of the conclusion:

> Summing it up, a framework tries to save you work by make you define an overly complex configuration, that has to accomodate every possible use case.

i use codeigniter specifically because it relatively simple to use, lightweight, and easily configurable.

can you use php without frameworks? sure. but in the end, it saves you development time. its not like the code you cut to replace the framework is going to be that much less buggy

Yes you can... Sort of.

I use php-form-builder-class (http://code.google.com/p/php-form-builder-class/) which is a beautiful library to build and validate web forms; and a port of the Perl module SQL::Abstract (http://search.cpan.org/perldoc?SQL::Abstract - roughly the most used library to build SQL from data structures in the Perl world) to PHP (http://coderepos.org/share/browser/lang/php/SQL_Abstract/tru... - docs in Japanese, but if you know the Perl version it's pretty straightforward), and that, when complemented with some glue code in a small library of my own, is about all I need to build a CRUD in webforms, in no more than a few dozen lines.

Is this a framework? It does what a framework does, but it's a set of libraries, not a framework. You still lay out the basic program structure.

Is this all you need to build a web app? Well for most applications, in my experience, it sure goes a long way. The rest that you have to do is pretty straightforward.

You can definitely use PHP without frameworks.

What really sucks about PHP though is that most of the quality code lives inside frameworks. While it's rather easy to include parts of Zend Framework in your own code/other frameworks (it almost always comes with some bloat due to dependencies though), nearly all other frameworks' parts are impossible to 'extract' and re-use them elsewhere.

Every time I read about a new useful and slick Ruby gem that's properly tested and can be used with or without every available Ruby framework, it's making me sigh.

I wish the PHP world was like that as well and people would just build more 'libs'. If you're stuck on a PHP version below 5.3, you won't even find a powerful implementation of ActiveRecord. And no way I am going to include a bloated powerhouse like Doctrine in a project that basically only consists of five to ten files when I am only looking for a convenient way to do some basic CRUD stuff.

Don't get me wrong though, PHP has been my primary programming language for the past years but the lack of good libraries that you can just use and drop in is really a problem. And the ones that are available are hard to find, hidden away in random blog posts and github repos.

Of course you can.

But in my experience, frameworks are a natural progression of good coding.

My first several dozen websites were "from scratch" without any boiler plate code. Every page was it's own PHP file, every page had its own HTML hard coded inside of it--the layout of the site repeated dozens of times. Then I said, this is really dumb! If I want to change an element of the layout I have to edit all these pages every single time. I wish I just had a single file to edit... So my next revisions where every page again it's own PHP file, but this time the HTML layout was split into header / footer HTML and I used handy require methods. Ahah! So much time an effort saved in upkeep--yay. Then I was like, "Wow, theres a lot of similar code needed at the top of every file--stuff to get all my classes included, stuff to setup my database properties, etc. Man I wish I could do all that in one file and just maintain that.." So I did just that, from then on I started coding my sites with a bootstrap PHP file, a single include at the top of every page to set everything up, and the rest of the page handled area specific code.

Thats how my own personal experience with PHP kept evolving, I kept realizing inefficiencies and coming up with patterns to alleviate those lacking areas. I ended up coding simple switch case index pages that would call defined functions that represented web pages. I even created my own template classes that would load a file and replace keywords in it with parameter values. I had naturally tended towards controller driven websites, using the MVC pattern on my own without ever having actually known that it was the Model View Controller pattern. To me, it had become just the obvious way to do things. Of course my own implementations where rough, and not reusable, they were flawed with limitations.

Eventually, I decided to look into frameworks--luckily it was at that time that Zend framework was coming into it's own. It was at version 0.7. I started reading the documentation and I was blown away because I kept seeing all these features that it provided and they were features that ran parallel with my own development designs. The framework had been what I was looking for, a polished implementation of a development paradigm that I had intuitively developed on my own. The thing about the framework code base is that it is designed with a text book like knowledge of solidly defined patterns. That's what freed it from all the flaws and limitations of my own implementations. Instead the framework solutions were abstracted, and brimmed with potential of being augmented and extended--allowing them to be robust enough to fulfill typical use cases and yet capable of being molded to fit special needs and requirements.

To me, it seems like when ever there is a framework article with a mostly con attitude, I can't help but think the article is being written from the perspective of someone who has not fully been through the "from scratch" phase. More likely, they started with frameworks. It's easy to understand why there would be such a jerk neck reaction when abruptly approaching a framework without a from scratch background. Without the background, all the robustness, all the complexity, there is no frame of reference for it. Such people don't comprehend the need or usefulness of those solutions. Instead, they have this preconception that frameworks "claim to do everything" and yet for some reason you have to actually code and implement special cases so why bother with the learning curve in the first place if you were going to have to come up with your own solutions. So often I have to reiterate that frameworks don't do everything--they aren't suppose to, they cant! They are the boiler plate, they are the starting point. They take care of the simple basic things that way you can devote your time to addressing the interesting, hard stuff. It may feel like it wastes more time than it saves--but thats just because you have to learn it first. Obviously theres a learning curve, obviously theres an initial time investment. The point is, after that initial investment there is so much payoff. Of course your first site, and your first framework are going to be hellish on effort. But your 3rd, or your 4th you'll have a basic site up and running in 2 minutes and be free to spend the rest of your time working on the unique core features that will make your site glorious and awesome.

The god awful truth of it all, is that web development really isn't easy. There is no magic wand to wave that will grant you the perfect site from a wish. There is no ultimate does everything tool that requires no skill to use. There is, and always will be a time investment required. Smart, successful developers will invest that time requirement into understanding and utilizing frameworks--that investment will be fruitful and multiply.

This discussion reminds me of an article Derek Sivers wrote about switching back to PHP from Rails. http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit... Basically he states that programming in PHP using the rails mindset (but no framework) saved him mountains of time. I think the MVC idea is great but I also agree that frameworks are over encompassing beasts that can add more functionality than you need to a project.

I keep being attracted by the thought of using a framework but they always seem to over complicate things. I like using SQL and I feel hand tied when frameworks hide that functionality away.

I think a better question might be "Can you program in ANY language without a framework nowadays?". The web is SO much more complicated than it was even 5 years ago.

Now web developers have to worry about mobile resolutions and layouts, APIs and access keys, whether or not they're implementing REST correctly, allowing users to sign-in with 3rd party services and oAuth, whether or not to go HTTPS only, etc. The list just goes on and on, and will continue to grow even larger as more technologies and ways of consuming information emerge.

I have been starting all new projects (PHP, Ruby, and even Javascript) with some sort of framework for more than 5 years now. It's the only chance I have at keeping up with user demands.

Old but still true (by the the creator of PHP): http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC...

undefined

After working with several PHP frameworks i now work with one that I rolled that doesn't include a lot of the automagic functionality that I find so frustrating in the major frameworks.

I have a simple MVC setup (simple is the key word, the router function is less than 80 lines) a DB abstraction class and a default class that models extend.

Regarding being able to bring people in, it's only helpful to use a framework if the person you're bringing in is already familiar with that framework, otherwise it's a detriment in most cases.

I have my own micro-framework I made for bigger projects since I can't stand any of the main ones (though I've heard good things about Yii, that's probably where I'd go if I felt mine was inadequate). As with most things, the context of what you're doing matters. I'd guess most websites don't really need a framework, though once you start doing REST-y stuff that's when you should probably look into it. (Plus you get nice looking URLs for free when you go down the any-size-framework path.)

I don't like larger frameworks because they force you to code in a particular manner which almost always deviates from the rest of the code I write.

Personally I prefer to use very small libraries that solve a specific need. TWIG for templates, for instance (used to roll my own). Limonade for a route controller etc... Then all I have to do is "glue" them together with minimal effort. Simple, effective and a low learning curve - can't really get much better than that.

You can, but you wouldn't probably, like you wouldn't use Python / Ruby without frameworks. You can 'easily' code things from scratch, but you'll forget a lot of (trivial) features or have tons of bugs in things which are supposed to work. It'll take most people longer (while delivering worse quality) to get it done without a proper framework than with, even though a lot of programmers think they can do better on their own.

I never use frameworks... I don't really see the point. Most of the time it's just a few SQL queries and a few if statements.

A couple years ago I wrote http://fuelog.com from scratch in PHP. It wasn't a terrible experience, but now I'm not even interested in maintaining or updating it.

I think it's a perfect candidate for a Google App Engine project and might migrate it (when I get some free time).

> Summing it up, a framework tries to save you work by make you define an overly complex configuration, that has to accomodate every possible use case.

I guess if all you looked at was the Zend framework you would have this opinion. It's incredible inaccurate to say this about all frameworks in general though.

I really only use templating and a DB class. Seems like one doesn't need much more.

Many of my affiliate based site don't use any frameworks. Just a couple of php lines to get the data and voila. It really depends of your needs. In this case, there is not even security needs...! Why bother?

You don't have to use something as heavy as the Zend Framework. There are light frameworks like Code Igniter. I usually just code up my own simple MVC with a custom DB class that I re-use.

lithium for php and connect for node are great examples of frameworks that only get in your way when and how you ask them to. yes, i realize these two are very different frameworks, but the point remains.

the benefit is that these frameworks provide you the tools to build what you want and how- rather than trying to create a one size fits all framework. even though lithium is mvc for instance, it can be componentized for your needs.

the consequence is somewhat less learning curve, and more importantly significantly less bloat.

I don’t know if it’s just me, but every time a new framework hype arrives you get all this discussions between people who say wonderful things about it, and people who just hate them, or simply don’t care.

As a professional web developer for almost 9 years and a web/internet enthusiast for, well…almost my entire life, I’ve came across with a lot of different ways of doing things. I remember when some people said “man, you gotta learn Flash/JAVA, it will be the end of HTML for good”, I think Apple is laughing at them right now. Oh, and I never really learned flash, except for some little AS script skills. Point being is, technologies come and go and you either learn them or reject them. At the end of the day it’s really up to you. Do you really want to kill a bird with a bazooka , or an elephant with a mouse trap ?

Today however, language frameworks are the ones in the spot light, you have, Ruby on Rails; Django; Kohana, etc.. and some people just simply refuse to use it. Why ? Well, some of them argue that in order to become a really programmer you need to know how to create a framework, you have to know how things are done. You can agree with them, in fact, if you are learning a new language, doing things from scratch can really help you. Or can’t ?

It depends, are you a very good programmer ? Or a lousy one ? If you are a lousy one, chances are you will not learn anything by creating a framework, in fact it will even make you a worse one. Why ?

Well, a framework is a very overwhelming piece of software, it’s like building a factory for creating not just one type of product but a lot of different ones. And if the factory is not correctly build, your products will not be good, or worst case scenario, your factory won’t fit your needs in a long run. Besides, most of this custom frameworks are created by one person, which leaves them with a lot of stuff to think of, while open source can be contributed by many, and so it can get more stable much faster. And don’t get me started on bugs and security. Also, the fact is, if you don’t comment or document your code in a year or two you will not know what your code is actually doing, and then you start to think of creating a new one from scratch.

I’m against creating a custom framework without being Open Sourced. Nothing against custom code of course. But call it whatever you want, but building custom code should meet a very specific purpose. Look at Facebook for instance, they’ve created their own app, hell, they even created their own PHP compiler, but because they really need it. On the other hand you have Twitter with almost 7TB of tweets per day, and they are running RoR (Or were at least). So what’s your purpose for creating your framework ?

In fact, I believe most of people who create custom frameworks for their own are unexperienced programmers. Why ? Most of the professionals programmers I know use or learn a framework, not because they don’t know how to code, but because they’ve all done what the framework does, and we are sick reinventing the wheel every time. Been there, done that, got the t-shirt. So why waste more time creating it ? Why not just use that time to create something meaningful, instead of worrying about ORM, Cache, template, form validations, etc. It’s old and it’s boring. I could that if I wanted, but I don’t have to, it won’t add any more value to me as a programmer.

If you need something more specific that a framework can’t do, do it yourself, nothing wrong about that, this is where you will learn something, because you never done it.

At the end, I believe that the good programmers who create their own framework are afraid of just letting go. Are afraid of stopping to worry about specific issues that their users won’t even know it’s there, like core code. It’s like they need to do that from bottom up, in order to believe that they are the hardcore-kick-ass-coders.

So, do you still need to create your own framework ?