The concept of frameworks in PHP predates its package manager and its PSR standards. Nowadays you can easily slap a collection of libraries together to create your own micro-framework that fulfills your precise needs. That is often a better decision than to go with a monster like Laravel or Symfony which by design aims to be good at all the things, instead of good at the things you need. Those frameworks themselves usually have individual components that can be used independently of the rest of the framework for exactly this purpose
hello, I am in a growth phase startup and have been here since the early days. I am speaking from experience about a specific type of company and codebase.
if you’re planning to scale a team and a company, do not do this. stick to Laravel. let your new hires read the docs and move on to shipping features.
if I were going to build a solo project, yes, I would consider bolting the libraries I want into a high comfort codebase that allowed me to move quickly.
there is a massive Laravel talent pool and straying from the standard approach just makes onboarding and maintenance more difficult. focus on your company’s problems and don’t be bespoke. if Laravel is even in consideration for you and your company and your problem space, there’s absolutely no problem that is worth reinventing the wheel on here
The biggest benifit to something like Laravel is that a new developer to your team can step in and know where everything should be and how it should generally work without asking. There is good documentation so you dont have to write that for your foundational code, just your business logic.
A bunch of bespoke packages strung together with no logic does not provide that. You can surely look up how one package works but its a lot harder to figure out how it all ties together.
I can see how it's seen as a benefit, but the flipside is that you're teaching your developers Laravel, not PHP. They assume whatever they do, they do in a good way because it's Laravel that does it which is great, but it abstracts actual knowledge. It's like if a developer uses SQL exclusively through an ORM and DBAL, how much can they be expected to know about the workings of SQL performance, indexes, etc.
I also find it very interesting that there's no stigma associated with "Laravel developers" that focus exclusively on that framework and its syntax and way of doing things and you have "WordPress developers" who do the exact same but are seen as incompetent.
I understand though that there are scenarios in which what you want is a guy that knows a framework really well, but if we're talking about skills of a developer, I'll pick the guy that knows vanilla PHP over a framework specialist 80% of the time
I find it hard to imagine how anyone who groks Laravel well enough to get a product shipped could be deficient in understanding PHP. Surely such cases are outliers?
I regularly interview PHP developers for hiring and I can quickly classify them into 1. Wordpress Developers, 2. PHP developers and lately 3. Laravel developers.
Specifically for no 3 is the kind of developer who considers the framework magical and has no idea how things are done without it because they've learned framework first and the PHP basics to survive. They can do well for basic CRUD tasks but for anything trickier they get stuck.
Being Laravel focused and knowing what is happening underneath the hood are not mutually exclusive. A mature developer knows when to stray from the framework when its absolutely needed, not when it just seems like a fun thing to do. 99% of the time the frameworks predetermined path is the right way as its the simplest to maintain.
If you’re pulling libraries instead of using a framework, you’re basically just writing your own framework. One that’s simpler but also it’s unique so you lose the ability to bring in a seasoned Laravel dev that can get going right away. You have introduced a learning curve for all new devs that didn’t need to be there.
