In his new post Michael Kimsal shares some of his thoughts about framework benchmarking especially in the context of speed.

I’ve followed the techempower benchmarks, and every now and then I check out benchmarks of various projects (usually PHP) to see what the relative state of things are. Inevitably, someone points out that “these aren’t testing anything ‘real world’ – they’re useless!”. Usually it’s from someone who’s favorite framework has ‘lost’. I used to think along the same lines; namely that “hello world” benchmarks don’t measure anything useful. I don’t hold quite the same position anymore, and I’ll explain why.

He goes on to talk about the purpose of using a framework and what kind of functionality they should provide. The usefulness of a framework is measured in what tools it provides and how easy it makes them to use. Benchmarks are only about speed, performance and overhead.

What those benchmark results are telling you is “this is about the fastest this framework’s request cycle can be invoked while doing essentially nothing”. [...] These benchmarks are largely about establishing that baseline expectation of performance. I’d say that they’re not always necessarily presented that way, but this is largely the fault of the readers.

He refutes some of the common arguments about increasing performance of an application using a framework (like "just throw hardware at it"). He points out that, even with other improvements, it may come to a point where your framework of choice has become too slow and you need to move on. Think about maintainability too, though, and what you're switching from or to when considering making a move.

In this post over in the /r/PHP community of Reddit.com, there's a question about frameworks. The original poster wonders about the purpose of a framework and if they're a requirement to build any kind of application that's "worthwhile".

I read posts here from time to time, and Laravel and Symphony are mentioned a lot here, and I always get the impression that it is a must to use a framework, to build something worthwhile. A little background on myself is that I've always approached development in a cowboy coding style where I just code. I've made a system where I use the basic mysqli object in PHP for database interaction, and I use Smarty templating system to output the html/css/js. I build my own classes based on what the customer is asking for, and then obviously I make the controller pages calling the classes I made - manipulate the data and output to smarty. What would Symphony help me with - that would be hard to accomplish regularly?

Plenty of answers and opinions are shared in the comments of the post, ranging from:

• Encouragement for Symfony2 and the development speed it accommodates
• Building a project without a framework
• The benefits and downfalls of using MVC and other design patterns you may not fully understand
• A definition of what a "framework" means outside of the world of MVC

There's also a consensus among several of the posts that one of the major benefits of a framework is to provide an overall decrease in the time to market with the handy features and things it provides out of the box. What do you think? Head over and post some thoughts of your own about frameworks and where they fit in your development.

Jacob Santos has started a series of posts to his blog that focuses on the use of the opcode cache and language features in your applications.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn’t flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

Jacob Santos has started a series of posts to his blog that focuses on the use of the opcode cache and language features in your applications.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn’t flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

On the KillerPHP blog today, there's this new post that asks the question of when the choice should be made to use interfaces and why they should be used instead of classes in your code. It's an article/podcast, so for the full effect, grab the audio here.

The post itself are really just notes to support the content in the podcast, but they provide plenty of information by themselves. They talk about what interfaces are, include examples of both them and a class (showing how they differ) and an example of a class using and interface (dog implementing animal).

There are also a few other notes there at the bottom mentioning the purpose of interfaces, which one to choose when, and two miscellaneous notes about how interfaces can help both you and your code.

On the KillerPHP blog today, there's this new post that asks the question of when the choice should be made to use interfaces and why they should be used instead of classes in your code. It's an article/podcast, so for the full effect, grab the audio here.

The post itself are really just notes to support the content in the podcast, but they provide plenty of information by themselves. They talk about what interfaces are, include examples of both them and a class (showing how they differ) and an example of a class using and interface (dog implementing animal).

There are also a few other notes there at the bottom mentioning the purpose of interfaces, which one to choose when, and two miscellaneous notes about how interfaces can help both you and your code.

Jacob Santos talks in this new blog post about something that, if added to PHP, just might be more trouble than it's worth - inner classes.

Inner Classes are contained in parent classes and offer a sort of namespace mechanism for the public and open private class data transfer for private subclasses.

The functionality is already available in other languages, but the question is whether it is needed in PHP. The short answer is no. With PHP execution model, it would further slow down and bloat PHP compilation.

He demonstrates their purpose with some simple examples but also gives the reasons why it would be a bad thing to try to include them, including the better choice of namespaces over inner classes.

Jacob Santos talks in this new blog post about something that, if added to PHP, just might be more trouble than it's worth - inner classes.

Inner Classes are contained in parent classes and offer a sort of namespace mechanism for the public and open private class data transfer for private subclasses.

The functionality is already available in other languages, but the question is whether it is needed in PHP. The short answer is no. With PHP execution model, it would further slow down and bloat PHP compilation.

He demonstrates their purpose with some simple examples but also gives the reasons why it would be a bad thing to try to include them, including the better choice of namespaces over inner classes.