On Wednesday 14 January 2009 23:39:02 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: http://paul-m-jones.com/?p=315 > > 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've not used Zend myself, so I can't say for certain, but the above > tenements I think would still hold true. I guess I would trust the Zend > one the most given they actually make PHP, but at this point in time, I > would never choose to use a bloated framework. Then again, I write > enterprise level and very custom applications (Saas) so maybe this > doesn't apply if all you're trying to do is make yet another Blog or > Photo-album or personal/corporate website or something generic/basic. > I've been coding nearly 20 years and founded several $MM companies. > That's my take (or rant depending on how you look at it). > > Daevid. > http://daevid.com > Hell, yes, signed to from start to end. After RoR, PHP guys (including Zend) goes nuts. Every one eat his brains to develop RoR like Framework. I wish to see fixed function parameter names, option orders, easy and strong input validation in PHP 6. And they give full effort to generate Zend Framework. Then what? It still harder than Ror... Hell yes, Compete own community. teh best way to spend your resources... Sancar Saran
