Re: Zend Framework...where to start? -- don't.

On Wed, Jan 14, 2009 at 6:17 PM, Paul M Foster <paulf@quillandmouse.com>wrote: > 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 > > I agree heavily on the file opening part. I hate having to look through a stack trace of 20 or 30 just to track down why an exception was thrown. We are working on moving our entire framework into less files and more of a core set of files that handles a lot of tasks. -- Kyle Terry | www.kyleterry.com