In a new post to his site Paul Jones shares some of his thoughts about microframeworks, suggesting they're more "user interface" frameworks. Basically he suggests that microframeworks work best for the UI level handling and that possibly a second, more robust framework should be used for the application backend.

When we talk about “full stack” frameworks, we mean something that incorporates tools for every part of a server-side application. [...] Examples in PHP include Cake, CodeIgniter, Fuel, Kohana, Laravel, Opulence, Symfony, Yii, Zend Framework, and too many others to count.

When we talk about “micro” frameworks, we mean something that concentrates primarily on the request-handling and response-building parts of a server-side application, and leaves everything else out. [...] If the user interface is the request (as input), and the response (as output), that means micro-frameworks are not so much “micro” frameworks, as they are “user interface” frameworks.

He suggests that, if these statements are true, then microframeworks should be considered "user interface" frameworks. He makes suggestions of splitting things out into "containers" of functionality with the microframework taking care of user interactions while a second handles domain and infrastructure concerns.

Fabien Potencier is back with a new post on his site following up this article about application composition and Symfony 4. In his latest post he compares two approaches to applications: micro versus macro.

Monolith projects versus micro-applications; a never-ending debate. Both ways to develop applications are fine in my book. Symfony supports both. Even if the Symfony Standard Edition is probably more suitable for monolith projects as it depends on the symfony/symfony package.

[...] Silex took another approach where each individual components are required when needed. Does it make Silex simpler, more lightweight, or faster than Symfony? No. Nevertheless, Symfony 4 is going to be more similar to Silex in this regard.

He talks about changes upcoming in Symfony 4 including the move away from the "symfony/symfony" package system and in with a component/bundle driven system. He gets into a specific example around the "symfony-framework" bundle. He then comes back around to the idea of "composition" of applications, adding Symfony dependencies only when needed but still having them work together seamlessly. The post ends with a discussion that was had about going the "bundle-less application" route and, while Symfony 4 will recommend it, the bundle system will still function as expected.

In response to a few tips Alex Netkachov recently posted about micro-optimization, several other developers in the PHP community have written their own responses:

• Maggie Nelson - Optimization Woes
• Sebastian Bergmann - Do Not Micro-Optimize
• Padraic Brady - Can't see the forest for the trees? Quit micro-optimising and try again
• Stefan Priebsch - The five immutable rules of optimization

Alex's tips, which have the potential to be slightly helpful, can also give a false impression that they will make a large difference in an application and could make a developer write code differently (pre-optimization) to try to use them.