On Wed, Jan 14, 2009 at 01:39:02PM -0800, Daevid Vincent wrote:
Not to start a Holy War (as these "to framework" or "not to
framework"
debates often turn into), but I personally had a horrible
experience
with
using frameworks. I was forced to use Symfony at my last job and
it
was so
cumbersome and slow to do even the simplest things. The whole MVC
thing
can be overkill. Plus the learning curve can be quite steep.
Then if
you
want to hire other developers to work with you, you have to
train them
and
let them ramp up on not only the framework but also your core
project
too!
More wasted time.
The pages are significantly slower than straight PHP by orders of
magnitude: [1]http://paul-m-jones.com/?p=315
What a great link! I've never seen this kind of comparison before.
HTML
is 70% faster than straight PHP, and the frameworks (even
codeigniter)
deliver less than 20% of the performance of straight PHP.
The basic problem with frameworks is they try to be one thing
for all
people. This carries a lot of baggage with it. There's a lot of
crap
you
end up pulling in that you don't want/need. Plus if you want to
deviate at
all, you either have to roll your own, or sometimes you simply
just
can't.
They seem attractive with all their plugins and stuff, but
honestly,
rarely do the plugins do EXACTLY what you want, the way you
want. It
might
be as simple as trying to change the look/feel of a button or
something
and you'll find out that you can't -- so now you have this website
that
has this section that doesn't look like the rest of your site.
And if
you
find a bug, you have to try to either fix it yourself and then
keep
those
changes migrated into new updates, or submit it to the developer
and
hope
they implement them (and trust me, you can submit to them and have
them
rejected for all sorts of lame reasons -- even though the work has
been
done and you're using it!)
I advise against it. Just follow good practices and use thin
wrappers
and
functions. Don't get all OO googlie eyed and try to over-
engineer and
over-OO the code. OO is great for some things (like a User
class) but
don't start making some OO page renderer or form builder. Don't
fall
into
the DB Abstraction trap either -- just use a wrapper around your
DB
calls
(see attached), so you can swap out that wrapper if (and you
almost
never
do) you change the DB. Don't be suckered by something like
QuickForms
--
you WILL run into limitations that you can't get around and are at
their
mercy. Don't buy the hype that DIV's are the magic bullet and
TABLEs
are
"poor design" -- Tables are still the best and most ubiquitous
way to
align things in a browser agnostic way (including mobile phones,
etc.)
and
to layout forms.
I agree and disagree. I agree there's waaay too much herd mentality
in
the programming field. (Fortunately, Linus Torvalds didn't listen
to the
academics who insisted that microkernels where THE WAY, or we
wouldn't
have Linux today.) OO is nifty for some things, but it's certainly
not
the "fountain of reusability" it was originally promoted to be. And I
also agree about tables versus CSS. I can render a page very
precisely
with tables that would take me hours to get right with CSS. And I
really
don't give a crap about what "experts" say about anything. I find
"experts" to be wrong much of the time.
OTOH, I just finished writing about 80K lines of PHP/HTML, all by
hand,
no OO, no classes, no nothing. Each page in one file, except for a
few
helper functions in a couple of common files. I wouldn't want to go
through that again. I've opted for a framework on rewriting this
code,
just to cut down on the number of lines of code I have to manually
write. But I built my own framework, which doesn't call in 20 files
for
each page load. Very compact. Probably not suitable for every kind of
project, but it works for this.
Incidentally, I would differ from the reviewer in the link above
only in
this respect: He maintains that every line of code adds time. While
this
is true, I believe it's the number of files which have to be opened
which drags down framework numbers the most. When I wrote C code, the
CPU would blaze through the actual code, but file opens and reads
consumed far more time than in-memory code execution.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
