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.
One of php's main advantages is the availability of many options.
You have the option to do web apps in plain php.
You have the option to do web apps in many mature frameworks.
Languages like ruby and python lack this. Can you do a website in plain ruby as easily?
How many mature ruby web frameworks are there in ruby?
There are many in php. Zend Framework, Agavi, Kohana, CodeIgniter, Prado, Yii, Symfony and many others.
Of course some stuff in php suck hard. I would personally love an string-object to replace all the stupid str_*() functions, but php is in the right direction of adding features. (My last issues are fixed by 5.3's late static bindings)
And im surprised how php community quickly adopts changes. PHP 5.3 breaks compatibility but i see more people using it everyday.
I think despite all the negativity, PHP is going to stay for long-term.
I've written websites in plain Ruby, as CGI scripts running on Apache. I actually find this easier that PHP, as Ruby doesn't have nearly as many weird inconsistencies. I think I'm pretty unusual in being one of the few Ruby programmers who didn't immediately begin with learning Rails.
Ruby with Passenger can be used for a simple website. Throw in Sinatra with Datamapper or ActiveRecord and you've got a lightweight setup - with better options for string manipulation than PHP :)
"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."
This is true for all frameworks in all languages. Instead of doing the Unix thing and providing well-behaved libraries that do one thing well, people build a pile of opinionated spaghetti. To quote HN user mahmud:
Everytime I tried to use any of these PHP frameworks, I got frustated because they demand you to be stucked inside the "convention over configuration" and you can't do anything more complicated into your code without having to read a lot of docs about how to make something outside the "normal code". You always have to inherit you controller from something else.
While I agree about the Zend framework, Symphony and others trying too hard to be full of features, frameworks like Code igniter are really light. Sure for some very very basic projects it might still be too much, but for an actuel interactive websites chances are higher of it missing features than having too many ...
Can you give an exemple of something it does by default that is "pointless crap" ?
Pointless crap is subjective. Zend_SOAP, I imagine, would for many be considered "pointless crap", but having it available means I don't have to go looking for a SOAP library when I need it to interface with a gateway.
People always confuse features with bloat. Disk space is cheap, and these frameworks aren't hurting things by having additional features.
Now, complexity I can get behind, but stop relating complexity to weight or bloat. CI is less complex than ZF because it does substantially less. It requires developers to do more to accomplish the same tasks ZF developers can do a lot faster. However, it takes a lot more work to get to that point.
Personally, I'm glad we have these choices. We can choose the right tool for the job. =)
Really about Zend? We use Zend Framework extensively and find that while we can roll our own (and I certainly have), it is a well-documented MVC framework that provides a decent foundation for our applications. Zend probably only solves 10% of our issues - the remaining 90% are very application-specific logic.
As for the edit/compile/deploy/run cycle in Java web app development, the Play Framework pretty much reduces that to just edit/refresh. It's really amazing.
I've done two projects with Play and both development cycles are extremely fast.
> 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 ...
Your post ? Genius.
That's exactly what I think. Most of the people who hate frameworks are those who don't appreciate or just love to reinvent the wheel everyday.
Or they built their own framework over the years and either refuse to accept it or refuse to part with it (so they tell you frameworks suck and they only use their own code).
And you know what? ... thats okay.
I think a lot of people just turned off by the whole
"Frameworks are the right way to program, and if you aren't doing frameworks then you're doing it wrong!" attitude of some in the community.
I think if you let people be, they'll eventually find their way to these frameworks because the amount of time and effort they save you is just too hard to ignore, once you get to a certain point.
Yeah, I agree fully. The guy who wrote this article appears to be completely oblivious to CodeIgniter, which is a very, very lightweight framework. I just recently revisited an old CI site I made months ago and it only took about 5 minutes to relearn the whole structure of the site. My controllers are thinner and more beautiful than supermodels, my views are extremely light and logically distributed, and my models are the only places (aside from my JavaScript) where I make reference to any data. When your controllers have one line that gets AJAX data, another line that determines if it's a new item or an existing one, and one more line to die() off the direct result of my model call...life becomes a hell of a lot easier and coding an application becomes an exercise in beautiful abstract thought instead of tedious tinkering.
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.
i disagree with that type of rant. using a framework isn't about "making it easy" and "hiding the details". or at least, not to me. its about not having to mess with the details. repetitious, abstractable details waste time and energy.
its why we don't typically code in assembly. its a waste of time, and you generally have faith that whatever statement you write in, say, C gets translated correctly and efficiently down in to assembly.
I think it very much depends on what gets "abstracted away." If a library provides sensible defaults, or does some convention over configuration, it helps me ignore the inessential. And my knowledge is portable to other frameworks, I still understand the underlying model, I just don't have to mess with the details.
In this we agree.
But if a frameworks provides an abstraction that isn't isomorphic to the underlying model, I end up learning a non-portable technology that is useless when I step outside its cozy implementation.
For example, ORMs that hide SQL from me. Messing with SQL syntax may be inessential, but working with actual relations is my job, and not knowing how to use a database is counter-productive.
I think it mostly comes down to an individual programmer's style. "Glue programmers" will tend to prefer frameworks; other programmers won't.
I, personally, can't stand any of the PHP frameworks, or code frameworks in general. I hate having to get to know their individual quirks. I hate having to spend a lot of time getting accustomed to some other programmer's mindset and approach to problem-solving. I passionately hate those rare instances where I find an actual bug in someone else's framework; since I didn't write it, I probably had to spend a lot of time first assuming it was a problem in my own code, and then tracking the bug all the way into the framework until I found it. Cognitively, even though that doesn't really happen all that often, it's powerful reinforcement against using frameworks. In PHP's case in particular, I really don't see the point of frameworks, since it's such a high-level language to begin with. Why even bother having your own database classes when you have PDO, for example?
But, as a practical matter, I realize that programmers that do invest the time to familiarize themselves with certain frameworks tend to be a lot more productive than I am.
The Django Book (http://www.djangobook.com) starts with these details (except for the the dispatcher stuff), then shows you how to cut down the boiler-plate code using django.
The book I read on TurboGears was similar, IIRC.
You start with the basics, use the framework to speed up monotonous stuff, then drop back to the basics when you need to do heavy lifting.
What he's actually talking about is a matter of preference. He almost completely misses the point of using a framework to not reinvent the wheel when you like the way the wheel's invented in this framework.
Some like plain HTML, some perfer HAML, some generate DOM tree, some like to have "components" and "controls" - and they're all equally right in their views. The same holds for SQL vs ORM.
Some frameworks hold TMTOWTDI views, when you could do things in a way you perfer. Other frameworks insist that there's one and only one proper way of doing things (in given framework).
"PHP is stupidly simple to deploy compared to most other technologies" That's true, but it stops mattering for more complex sites where you want easy rollbacks to previous versions if a deploy went awry, separate static media serving (because it's faster), load balancing and the like.
Nobody will dispute that PHP has by far the best deployment story if you need to quickstart something (see http://blog.ianbicking.org/2008/01/12/what-php-deployment-ge...). But for an application of any complexity, really, you'll have more important stuff to worry about.
easy rollbacks to previous versions if a deploy went awry, separate static media serving (because it's faster), load balancing and the like
Other things that come to mind are database migrations, running tests before deployment, pushing code to multiple servers etc.
It is probably a good idea to automate all these tasks.
Yes, with an application server you might have to reload the code, but it doesn't really matter, because thats just one step of your automated deployment.
And if you use an opcode cache you probably have to restart the server with PHP anyway.
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.
I think the php.net docs outshines the available official documentation for all other languages I've worked with, especially because of the user comments on all the functions. Sure, some of them are outdated but they've saved me from not-so-obvious pitfalls or provided a nice starting point for helper functions more than a few times.
Don't want to front or anything, just wondering why you don't like the docs. I agree there could be better documentation for the classes that PHP and the SPL provides though.
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.
but if you have written the framework, you don't need to go anywhere for help.
You just fix the problem because now that you have written it and it's tailored to your application, you have a pretty good idea of the problem and how to fix it.
This means that you can progress more quickly and that your project doesn't get littered with "workarounds" for "bugs" in the framework (i.e. hacks around stuff the framework hides for you or you don't know how to access)
Until you do something else for a few months and come back to realize that instead of there being only a single person in the world who understands your homebaked framework, now there are none at all.
> but if you have written the framework, you don't need to go anywhere for help.
Sure, if you're a genius who knows how to solve every problem, can keep the entire codebase in your head, and remember every change you - or someone else on your team - has made.
I'm doing some contract work for an old employer that uses a home-built framework that I've worked on and improved extensively. I'm betting it'll take me another hour to truly catch up on the ol' codebase enough to actually write something useful. And if I have a question about something? Well, I hope my old coworker has been keeping up with things enough to remember the answers that I've forgotten.
"but if you have written the framework, you don't need to go anywhere for help." Never had to come back to an old project or a part of an active project you haven't touched in ~6 months? I spend a fair amount of time figuring out why the hell I did X or Y a year ago, even with source code docs, narrative docs and tests. I don't think I'm the only one.
Not only that, but your team has somewhere to go for help other than you.
So many of the "do it yourself" comments are so clearly written from the one-man shop perspective. No thought of working in a team environment.
Drop 5 Rails programmers into a team and they're going to be a lot more productive than 5 guys arguing about how to do their own framework.
When you're trying to bring something to market or deliver something to a client, bitching about how routing should work when there's a ton of functional and tested ones to choose from is a big fat waste of time. Choose one and get to work.
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.
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.
Yii is indeed very powerful, especially if you take advantage of the 'magic' and generators for form output and handling. I've only spent a few days with it though as that particular project fell through.
Not sure if I'll ever go back to it as I am not really a fan of the syntax and it took me quite long to find out how to do certain things in the given online docs. Might be just me though and really, the first thing I'd say about Yii is that it has got a lot of 'power' under the hood, more than any other available stable PHP frameworks I have seen. Symfony is probably the only other one in that league.
> Sure you can, but why would you want to? Reinventing the wheel is not fun.
Reinventing the wheel is not the opposite of using a framework. Remember the "favor composition over inheritance" principle? It applies here. Compose libraries rather than inheriting from a framework.
It just happens that PHP has a plethora of frameworks and a dearth of libraries.
Have you used symfony? Yii is one of the few I have not had the pleasure of working with and would be interested to see how it stacks up against symfony. Seems like they both have similar features.
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.
Can you explain how using Zend Framework automatically helps you with XSS? I do not believe Zend Controllers or Views automatically escape input or output.
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.
> 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
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.
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.
When I'm coding and hit some need like CSRF protection, I think, "I need a library to do CSRF protection," not, "I need to switch to a framework that includes CSRF protection."
Unfortunately, there's not a good mechanism like RubyGems for distributing/discovering PHP libraries. PEAR isn't it. It has too much stuff that's either unmaintained or dangerously unstable. I don't know what happened there. Maybe the coding standards and general bureaucracy involved in creating PEAR packages drove out innovation.
I haven't had a serious look around the PEAR libraries in ages, mainly because I don't want to have classes like their own 'Error' class around in my code at all.
Regarding distribution I was hoping that .phar files would become the new standard but I haven't seen a single .phar file around. Definitely agree that a central place to discover libraries is really needed as well.
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.
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.
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 have to agree with you. I'm using PHP for over 10 years now and I never needed a framework. Sometimes a little class or function is convenient but that's about it. Even for very big projects. Just use Apache/IIS/other as controller.
He didn't elaborate but it's a valid point in the PHP world. Most of the PHP frameworks implement a front controller that all application requests are sent through, but for a lot of applications this isn't necessary in the PHP world. There's no reason not to simply divide your application into separate files and let your webserver call the right file. Particularly interesting is how similar mod_rewrite is to many framework's routes type implementation. You can practically stick the same config in .htaccess and just let Apache handle it.
For a lot of simple applications my "controller" consists of:
if($_SERVER['REQUEST_METHOD'] == 'POST') {
// do my validation and any work needed then the redirect
} else {
// display the resource
}
You might still call that a "controller" but it's pretty different than what most of the frameworks call a controller, and we've pushed the task of routing the request to the right piece of code off to Apache.
From Wikipedia: A controller accepts input from the user and instructs the model and viewport to perform actions based on that input. Well ofcourse there are differences, but your webserver reacts to input from the user (a request) and tells the server which code to execute.
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.
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?
So if I request '/../../../etc/passwd' on one of your sites, it won't work? (Just curious. I've found it really hard to get chroot'd php/apache working in all but the simplest of use cases.)
You shouldn't need to chroot apache to avoid serving /etc/passwd. I have never worked on a site with chroot'd Apache, and have never run into these kind of issues.
Are you setting your Apache configuration to only allow reading certain directories?
It's not just Apache you need to configure - PHP ignores Apache's directory access configurations entirely, you need open_basedir and preferably something like suPHP.
Disabling shell functions (system, exec, etc.) is also a good idea, unless the application itself requires them (e.g. if the host is too stupid/lazy to have the imagick extension installed and tells you to call /usr/bin/imagick instead...).
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 ?
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.