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.
I agree completely and my experience/progression through the years was exactly the same as yours.
I didn't end up using Zend, but I've always looked at the various frameworks and "stole" some of the ideas and applied them to my own.
I do believe developers that say you don't need a framework simply haven't created very many different projects - OR - They've been using the wrong framework.
Question - should I shoot straight for a framework, or develop some small sites "from scratch" first to get a feel for php before diving into a framework?
You know, I was nodding my head as I read the OPs progression. The first programming I ever tried was Rails (it's the hotness, why not dive in!). My problem was that it was magically solving problems I didn't know I had.
I would strongly argue for (if you have time) experiencing the progression of web dev to its current state from the ground up. Understand WHY templating is useful. Understand that most basic CRUD controllers have the same methods, and the schema underneath is setup the same way. Doing some things the 'hard' way I found made it much easier to understand the reasoning behind today's most modern frameworks. I understood their benefits.
The truth is, despite my reply suggesting going straight to framework, going the from scratch is good if you're able and are willing to invest the time. But if you've got work to do, some times you need to learn as you work rather than learning first. Its in those cases that I recommend the framework route--with the caveat that you accept that theres a reason for the framework's complexity. Don't bulk at it, realize that its there for reasons you may not understand.
Luckily you'll gain "from scratch" experience even through the framework route anyways, since it naturally comes when you have create things that expand the scope of capability of your framework. Even when you are simply extending base classes of the framework, your addressing and solving problems that the base framework doesn't answer.
First and foremost, evaluate what you need/want to accomplish.
Don't start with a goal like "I'm going to create a web site"--it is vague, and has no direction. Write down all the pages on the site that you plan to implement. An about page, a news page, a member directory, a community platform [via forums/comments], a link exchange.
Then, write down some more specifics about each of those components. For an about page, are you going to provide an address? A map? A Google map? For a member directory, how will members sign up? What information will they provide? What information will you display? How will you paginate the list? Will it be sorted? Will it be user sortable? For community components, is posting anonymous? Does it require membership? Do comments have tree hierarchy? Are their portraits? signatures? can you edit, or delete? How are posts managed and moderated?
These are all features and functionality that require absolutely no coding knowledge to answer.
Now ask yourself "Do I have any idea where to start?"
If you have an idea, then imagine implementing it from that starting point. What will you code? How will you handle working with data? How will you handle layouts? How will you handle dynamic content? How will you implement feature A, feature B, so on. If you can clearly visualize the components that will be necessary then you can go down the "from scratch" pathway. But if you can do this, you're not a beginner. If you're not a beginner, you'll realize there is no reason for you to waste time rewriting a basic web site platform and database access layer. Instead you'll want to pick some pre-supplied boiler plate, either a framework or perhaps an already provided content system like WordPress. So, pick a framework.
If the answer is no, then you've gotta face facts--you've got some learning to do. If you decide to go down the "from scratch" path, then you'll have to learn how to implement a basic website before you even get to all the cool stuff you want to implement. And if you want to go down the framework path, then you'll have to learn how to use the framework to get a basic site setup. However, the difference is with the framework path, you'll only have to learn it once. You'll always use the same boiler plate for the start website and be able to work on the cool features right away. Were as with the from scratch method, you'd always have to reconsider how to layout the initial basic site platform. You'd probably end up using the same methods, but you'd have to completely rewrite your code base since it wont be likely you created robust reusable code the first time around.
Go the framework route. Look at some frameworks. Read as much as you can on a couple different frameworks. Then read over each frameworks walkthrough guide for the framework. You don't have to follow it--just skim it. Then, go with your gut. Regardless of if you completely understood what was going on in the walkthrough or not at all, pick a framework that your gut says "this one will probably be easier". Then, do the walk through, create a junk site in your development environment and completely follow the tutorials to get up and started. Then, find some random tutorials on the web regarding your framework to implement and follow--even if they have nothing to do with your list of goals. All you are concerned about is getting familiar with the framework. If you cant find any tutorials to follow, sorry you picked the wrong framework--backtrack pick another framework and try again. After you've spent a few days playing with your test site, start your real site project. Get the bare minimum site up. Now you are ready to work. Pick a component of your goal list--single it out and isolate the bare minimum features of that component and figure out how to implement it. Ignore the forest and focus on the tree, er task at hand. Then repeat until you've achieved your goal.
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.