Maravel-Framework
The last drop that made me create it was version 11 of Laravel and its new bootstrap sousage (in romanian sousage means metaphorically also chaining things one after another).
Besides that, deprecation of Lumen was the second main reason.
Other reasons were:
- yearly major releases with no LTS
- useless overhead
- lack of PSR12 coding standard
- maravel-rest-wizard lib suite depended on Laravel while Laravel team did not show any interest in it or in its freemium version
- many corner cases not covered
- many things not improved
- the fact that beginers are more important for Laravel than older users (this is how I understood the v 11 change)
- lack of developer controll over the core
- too much happy flow for my taste
- the fact that new code was/is committed without type safety when possible (not always new methods/properties can impose typed params/returns because those could come from other untyped params/returns in older methods)
- the fact that else word is used too much instead of early return
- I dislike using daemons (octane, worker in daemon mode) that cut features from PHP (static, singleton etc.) because safety is compromised
- and others
You may ask why use it then?
Because nothing is perfect and anything can be improved!
Eloquent was the soil that allowed MaravelQL and maravel-rest-wizard lib suite to evolve. Even if the active record is an anti-pattern, without it, I can hardly imagine the existence of these tools that automate data management at this level and speed.
Symfony’s speed and complexity did not convince me.
I like a job done with the least number of execution steps (=> speed) and in a bulletproof manner (=> safety).
Top comments (0)