zlacker

I think you're putting too much faith in frameworks there. My employer's large PHP application is written in a framework that was once popular but then was abandoned years ago. Since that framework defines every aspect of the application, down to the directory layout, migrating away from it towards a more recent framework is largely impossible at this point. While it's true that the framework is "easy to understand", it's also true that it encases the application like a concrete coffin.

Libraries are infinitely preferable to frameworks if you want your application's life cycle to be independent of $POPULAR_FRAMEWORK's.

Even with Laravel, which is the current thing in the PHP world, I've worked in multiple teams where their application is written in a very old version of Laravel and there's no desire to attempt an upgrade to the most recent version.

>>motogp+(OP)
Outside of 'frameworks', I've tied projects to specific libraries that also were abandoned, and it's no better. Having every single query/dataaccess go through an abandoned library is not all that much different from an abandoned framework, imo.

For better or worse, there's some degree of 'upkeep' that has to be done with any code, if only to take advantage of some newer tooling (even ignoring security and performance concerns).

> and there's no desire to attempt an upgrade to the most recent version

That seems to be a problem there. I would not want to be using, say, Laravel 4 in 2022. Nor early Symfony, or any other framework (or library) that is years out of date.

What's been interesting to watch in Symfony and Laravel is to see an ecosystem grow around them which amplifies the value of using that framework (laravel shift springs to mind, based on your example above).

The danger seems to be in being complacent, regardless of tool choice. I've had to go back to Java/Spring code I wrote 10 years ago, and it's... challenging to make some things run again.

>>motogp+(OP)
What you should always do is to write your own code outside of the framework and pass in values or plain class objects from the framework to your code to avoid that the framework taints the entire project. One of the most common polluter is the ORM becuase it often passed to every layer of the application. And it is never too late to start.

>>mgkims+k3
> Outside of 'frameworks', I've tied projects to specific libraries that also were abandoned, and it's no better. Having every single query/dataaccess go through an abandoned library is not all that much different from an abandoned framework, imo.

Isn't it better to tie projects to specific libraries rather than frameworks because it should be easier to swap/replace a library than the whole framework ?

(Or is that OOP kool-aid I still taste ?)

>>johnch+751
using an ORM "library" was just as problematic, because data access is something that gets fairly deep in to a project. Had we tied the project to, say, symphony, there would have been a better upgrade path (but that brought its own set of challenges). We adopted a few libraries instead of "a full framework" but when the libraries are abandoned... you still have a lot of work to refactor.

>>mgkims+Ce1
I believe we are talking about the same thing but I lack the experience of projects big/complicated enough to really grasp the difficulties.