I got the opportunity to work with the Laravel framework on a new piece of software we are writing at work.
My favorite part so far is that I’ve managed to stay away from things I don’t yet need, like ORM/migrations and controllers-as-classes, while at the same time things like routing or caching were available for me when I needed them. If you’re interested at peeking at how I am using it, let me know.
I think my ideal framework at this moment would have all the pieces turned off, but available for me to turn on when I decide I want to use them.
Dan Bernardic 
I guess it depends on how coupled the packages are but you can just remove (or comment out) any or the service providers in app/config/app.php to disable anything you don’t want to use.
Thank you for the comment and reading, Chris.
I don’t think you’re technically correct about app/config/app.php, and I don’t think it is actually easy with Laravel. I tried cleaning it out when I started working on this software, so while I by no stretch of the imagination know for sure that it is hard, I have definitely failed once 😉
I’ll give you an example of what I imagine – If I don’t intend to write unit tests, which is not unheard of, there should be no unit testing code/directories anywhere. If I don’t intend to write “commands”, there should be nothing about that in my codebase. If I don’t care for pretty error messages, Whoops! should simply not be installed.
One implication of such an approach would be that in production none of those things are loaded, which perhaps helps with performance. In the end, I decided to expect that loading all those unused things does not impact performance of my software, and to just let it all get loaded. I am curious whether that’s true.
There is a certain amount of performance overhead. Lots of setup goes into booting a Laravel app. All those service providers you see in that list each have two methods full of bootstrap code, which get called every time the app loads regardless of whether they’re needed or not for your particular application. If you understand the system a bit more, you can determine which providers you can disable without breaking the system.
Alternatively, as with similar frameworks such as Symfony, you can use the individual building blocks of the Laravel framework if you don’t want to use the whole thing. For example, if you just want caching, you can just install the illuminate/cache package via Composer. However, you’ll then have to put more programming time into setting it up for use in your application, because obviously Laravel won’t be there to do it for you.
Ultimately, depending on circumstances, it may be more important that a project be easily maintainable and scalable than be fully micro-optimised. If performance becomes an issue, you may find it more useful to have a system that can easily distribute the load between multiple servers, than a system which is fully optimised but getting it to load balance is a programmatic nightmare. Using a framework like Laravel also helps if you have an application which is likely to evolve over time e.g. if you do need the ORM one day, it’s already there and ready to use rather than having to go through the pain of setting up illuminate/database yourself.
Thank you for the great comment. I just wonder whether it would be possible to architect a system where enabling a component, like ORM, could be as simple as uncommenting/adding a line to a config file, so that both goals are met.
What are your thoughts on the framework as a whole?
Hey Brenley, thanks for the question. I have only used for a fairly small app, and used only certain parts of it, and as I wrote there, it has mostly stayed out of my way in all the right places, while providing me functionality I was looking for. So I cant complain really.
Have you used it?