phpFashion

Frameworks are a Relic

The way applications are developed in PHP has dramatically transformed over the last 5 years. Initially, we moved away from pure PHP and learned to use frameworks. Later, Composer arrived, enabling library installations from the command line. Now, we are witnessing the end of frameworks as we know them.

Monolithic frameworks are gradually disintegrating into separate (decoupled) components. This transition offers several advantages. While previously using just one part of a framework was difficult or impossible, today you can simply install its component. The development cycle of individual components can vary. They have their own repositories, issue trackers, and can have their own development teams.

You can update components to new versions continuously, without waiting for the next version of the entire framework. Alternatively, you may decide not to update a certain component, perhaps due to a BC break.

The meaning of the word “framework” is shifting; talking about versions is almost obsolete. Instead of using framework XYZ in version 2.3.1, you use a set of components in various versions that work together.

Splitting a framework into components is quite complex. For Nette, it took 2 years and was completed last year. The adoption of Composer and the consistent use of dependency injection were absolutely essential. Nette now consists of over 20 separate repositories, and the original one retains only a single class.

All major frameworks, such as Symfony, Zend, Laravel, or CakePHP, are divided into components, though one step remains to be completed: splitting into separate repositories (instead of a workaround like Git subtree split). Zend promises to do this in version 2.5; we'll see what happens with Symfony.

Composing Nette

Through this long introduction, I wanted to lead you to the idea that viewing Nette as a framework in any specific version is outdated. It's smarter to approach it as a set of components.

That is, instead of declaring a dependency on nette/nette, you should declare dependencies on specific components. This is now being done by Sandbox. For the foundation of a future application, you can also use the Nette Web Project, which is a minimalist version of the Sandbox. Download it using

composer create-project nette/web-project

and remove from composer.json the components you do not need. This will speed up Composer operations.

Bug fixes will also reach you faster. Once an error is fixed, you can immediately tag a new version for the relevant component, whereas the release cycle for the entire framework is much slower.

If you are creating add-ons for Nette, do not hesitate and immediately replace the dependency on nette/nette with a list of actually required components.

Of course, new versions of the framework will continue to be released as before, require nette/nette will still work, and for version 2.3, distributions in ZIP archives will also be released. But their significance will gradually diminish.

Nette is the 3rd Most Popular Framework!

In the Best PHP Framework for 2015 survey conducted by SitePoint magazine, Nette secured an impressive 3rd place. Thank you very much to everyone who voted; I truly did not expect such a fantastic result. [perex]

What I find gratifying is that users seem to be satisfied with Nette, otherwise, they probably wouldn't have sent their votes. And, of course, the fact that Nette has thus made itself known in a world where it is less known due to language barriers.

Another interesting aspect of the results is realizing how many PHP frameworks are actually used, that there are other popular “local frameworks,” and that there are still many who do not use any framework at all.

“I Have the Worst Client, They Keep Changing the Requirements”

Do you know the complaints developers have about their clients not having a clear vision and constantly changing the project requirements? That's them crying over their own inability. Whenever I hear this, I wish the poor client had a better provider.

The client doesn't have a clear brief because they are not experts in web design. I wonder how many web designers understand their client's business well enough that they could create a precise brief if the roles were reversed.

If the client continuously changes the requirements, it means they are interested and engaged in the project, constantly thinking about it. There's a higher chance that something truly useful will emerge. And most importantly: they will keep asking for more and more work.

If the developer realizes this, they will understand that it is they who must adapt their working style. Perhaps simplify the addition of a ZIP code column on the website, even though it wasn't in the original brief.