On Mar 11, 2009, at 11:36 AM, jim wrote:

Jason itemizes my experience exactly. I have been in this game for
quite some time now and while I have done *some* work in frameworks,
mainly as proof-of-worthiness, the vast majority of my work has been
done manually.

I have done some testing of processes/systems by writing one by hand
and utilizing a framework and the one written by hand was *always*
faster at run time, which is always a critical issue for me. I'm all
about the speed.

You are on a PHP email list, it seems unlikely that speed is your only criteria :-) I like trying to make PHP go faster too, but it's far from the fastest possible way to serve up content on the web.


Another argument is dev time. For me, I can see how a framework might
speed up development for someone just starting out or who has only
worked within frameworks, but once someone like me has built a large
enough library of their own, the differences in dev time are
negligible-to-non-existent. As an aside, I was once a
proud-badge-wearing type of coder that "only used a plain text
editor", but have long since cone to appreciate a really good IDE as a
solid development tool that increases productivity.


Sounds like what you are saying is the you already have your own library/framework that you are quite happy with. That doesn't some how make every other library/framework out there bad/wrong/evil/etc. Picking on specific features/implementations/techniques/etc in framework or library is fine, I think trying to dismiss the whole concept of libraries/frameworks from the start is bogus at best.

Looking at a lot of my work, which focuses on WordPress, it's essentially become a library/framework for many of things I do.


Going back to execution speed and how that is so important to me, I
would like to reference a really fascinating article that benchmarks
framework speeds. It's really astounding how much slower - even the
fastest frameworks - make a system run. Check it out:
http://is.gd/JGn


Another aspect to keep in mind in this area is ease of scalability. (Resisting the urge to harp on the fact that many of his tests include DB access) According to those test results CodeIgniter would top out at 10.2 million requests a day, if your app doesn't use a DB. If your average page as 20 loadable elements on it (recent studies show that number is closer to 50 today) then you down to the 510k page view per day range. Reality is it's much lower than that, especially once a DB is involved. Exceed that and you have to look at scalability issues.

There are certain techniques that a library/framework can employ that will make scaling easier or harder. Some of these will vary depending on exactly which bottlenecks you are ok with and which ones you aren't. But the techniques generally aren't new, but people are finding out new/different ways to implement/tackle these problems.

The ideal world is page views that load fast, powered by a setup that can scale up when needed.

--
Joseph Scott
[email protected]
http://josephscott.org/





_______________________________________________

UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net

Reply via email to