On Thu, 2009-01-15 at 13:52 -0500, Sam Stelfox wrote: > Daevid Vincent wrote: > > > > > The pages are significantly slower than straight PHP by orders of > > magnitude: http://paul-m-jones.com/?p=315 > > > > http://www.codinghorror.com/blog/archives/001198.html > > I know this blog isn't specifically about PHP but he makes a good > general point that can be applied to this conversation very well. > > For those who don't want to read the article it's about the cost of > time spent programming vs hardware. Even if a framework will run > slower than raw HTML or a simple PHP page on it's own, if that > framework saves you a significant amount of time developing, and the > server your running the application on isn't as responsive as you > like, maybe it would be cheaper just to add another server and load > balance the two. A lot of frameworks include stuff exactly for load > balancing making your whole application a lot more flexible and able > to withstand a lot more growth without you having to write any extra > code.
That sounds great in theory, but the reality is harsh and disappointing. That was my biggest problem with Symfony -- not raw speed of page serving (although it is slow and you can see/feel it. and we did have 5 servers: load balancer/web1/web2/masterDB/slaveDB) -- but the overhead of creating a page. Learning the framework took significant time. Learning it well enough to be productive in it took even more. There is a difference from reading a book and understanding the concepts vs. sitting down and creating something that you don't have an example for. That takes a lot of research, document reading (and symfony's documentation SUCKED -- maybe I'm just spoiled by php.net), asking questions on the email list, waiting for replies, running into limitations *in* the framework or WORSE yet, BUGS *in* the framework. Then just to do the simplest of things you have to extract it into this MVC architecture and ORM and do you use a partial or some other mechanism. Then you have to pass arrays of parameters and objects around. Then there are NEW "reserved" words that the framework has. Pages that I could have written (and written very well, clean, maintainable and scalable) in an hour were now taking hours or more because of all the routing, models, views, controllers, yaml, schema, scripts to rebuild/generate, etc that needed to be setup. I don't disagree with the concept of a framework. I think it has an intrinsic value and would love to see them evolve and improve. My problem is with the current state of affairs. The bulk. The bloat. The bugs. The limitations. Ignoring Joe Blow and his blog or photo album or some other stupid "who gives a $hit about it" website -- the way I see it, there are those that want a framework to save them time to get a site up quickly... a prototype lets say. So great, they're wonderful for that. Symfony does some magic to create the "CRUD" for admin backend pages automatically even. But now you have a site up and you want to start building upon it -- you're stuck with this cruft and bloated framework "forever" now. OR you have to re-build it from scratch all over again. The other kinds of people are those who are writing a serious SaaS or other enterprise/significant-money-and-time-involved site. They are going to want all kinds of control and customization and optimization of the code and database. Once you start getting into 100k or 1M+ rows and joins, ORM fails miserably, so then you have to "optimize" by doing raw SQL -- and once you've done that, you loose the (perceived) benefits of the ORM -- so why bother with that layer in the first place. Just use a hybrid base class (as I posted) and get an Object with all the benefits of SQL too. Ignoring that, so you want some feature. Great! You go hunt and find a plug-in to save you weeks of work -- guess what? It is NEVER going to do EVERYTHING you want it to do. So now what? Do you modify the plugin (and forever merge those changes back with new updates)? Do you try to extend it somehow if even possible? Or do you just write your own? Probably you will write your own -- so again, what did the framework save you? At my last company, we wanted comment sections, blogs, photo albums, voting, ranking and all sorts of other "common" features. Well, if you didn't have your database in the way they needed it, or your layout the way they had it, or whatever other idiosyncrasy required, it was barely usable and often unusable. Finally once you start using a framework for everything, it seems people forget how to do anything outside of it. At my last company, they had no concept of straight SQL which improved a news section with 100k rows to parse from minutes to seconds. They didn't know about include() which we used to automate the menu system for sub-sections and was impossible to do (the way we wanted to do it) with the framework due to scoping issues. The worst example was this script that had to update various tables (news, videos, etc.). So the developer, in true MVC/ORM fashion would load each row as an ORM object, $this->setFlag(true);, $this->save(); !!! when a simple "UPDATE foo SET flag = 1;" would have done it in one statement. His script took literally HOURS to run and mine took under a minute. They had tunnel vision and Symfony was all they knew. [insert previous rant about having to then find developers that KNOW symfony too] Anyways, as I feared, this is starting to devolve into a conversation that is probably going to go nowhere. To each their own. If you love frameworks, then great. I only tried to share my personal experience (with Symfony, not Zend BTW) and beliefs and perhaps save someone else the pain of framework-entanglement. If you had a better experience, i'm happy for you and by all means please post. I would love to see a trend of, "OMG guys! have you tried this framework? it is awesome! I wrote my entire company's site in only 5 lines of code and it loads in a microsecond and can read my mind so I don't even have to click a single button to get what I want..." (maybe we're not quite there yet?) :-)
