
Can you use PHP without frameworks nowadays? - cfontes
http://css.dzone.com/articles/can-you-use-php-without
======
cletus
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_.

~~~
emilsedgh
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.

~~~
drdaeman
> Can you do a website in plain ruby as easily?

Don't know about Ruby, but as for Python - yes, you can. There is Python
Server Pages in mod_python, which are similiar to mod_php.

However, mod_python is ugly (in a same way mod_php is), so it's generally
frowned upon and considered to be Bad Thing.

~~~
zeemonkee
It's not just ugly, it's unmaintained.

~~~
krakensden
There's always mod_wsgi and writing a raw wsgi app- which honestly, isn't
particularly hard or bad.

------
trustfundbaby
> 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)
    

Things like that, I bet, slow its adoption.

~~~
phatbyte
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.

~~~
masklinn
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).

~~~
trustfundbaby
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.

~~~
masklinn
> And you know what? ... thats okay.

I fail to see how being a hypocrite is OK.

------
raganwald
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._

~~~
noodle
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.

~~~
raganwald
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.

JM2C, YMMV, &c.

 _p.s. I forgot to confess my own sins:_

<https://github.com/unspace/faux>

------
zdw
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.

~~~
stdbrouw
"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...](http://blog.ianbicking.org/2008/01/12/what-php-deployment-
gets-right/)). But for an application of any complexity, really, you'll have
more important stuff to worry about.

~~~
randall
For the noobs, can you add the word "like" and some descriptive stuff to that
last sentence?

~~~
danielh
He already did:

 _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.

------
chaffneue
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.

~~~
soulclap
PHP's docs suck? Seriously?

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.

------
pavel_lishin
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.

~~~
pilif
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)

~~~
Vivtek
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.

I speak from experience.

~~~
pavel_lishin
I'm literally living the experience right now.

------
DCoder
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.

~~~
soulclap
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.

------
nicpottier
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.

~~~
smharris65
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.

------
f1gm3nt
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.

------
arnorhs
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.

------
neovive
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.

------
noodle
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

------
bartl
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...](http://coderepos.org/share/browser/lang/php/SQL_Abstract/trunk/lib/SQL/Abstract.class.php)
\- 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.

------
soulclap
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.

~~~
bluesnowmonkey
You hit the nail on the head.

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.

~~~
soulclap
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.

------
giberson
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.

~~~
jmilloy
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?

~~~
qqqq2010
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.

~~~
giberson
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.

------
dgavey
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...](http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html)
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.

------
vlucas
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.

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

------
pdenya
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.

------
Jach
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.)

------
methodin
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.

------
tluyben2
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.

------
Limes102
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.

~~~
tintin
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.

~~~
rimantas

      > Just use Apache/IIS/other as controller.
    

You must have some really interesting understanding what controller is…

~~~
lftl
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.

------
benburleson
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).

------
drm237
> 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.

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

------
decasoft
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?

~~~
thaumaturgy
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.)

~~~
pzb
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?

~~~
DCoder
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...).

------
henryw
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.

------
catshirt
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.

------
phatbyte
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 ?

