Hacker News Reader

Comment by jackconsidine | Hacker News Reader

For those here wondering why you'd use Laravel over vanilla PHP + MySQL + PDO, a few of my clients had this opinion so I've had experience. The Laravel "fluff" saves you from rewriting tons of code, helps you write test cases, and makes logic easy to follow.

One of my clients was very anti "needless vendor packages" (definitely some truth to this sentiment), but we ended up with 14 extra php files reinventing the wheel. I'd opt for the former any day.

View on HN

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

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 think this is a benefit from using a framework in general and there are some good alternatives in the PHP space.

One of the nice things about Laravel, is that in a lot of ways it extends the functionality of Symfony and uses many of it's packages under the hood.

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

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.

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.

Seems easy enough to teach if those developers have picked up whatever is in front of them in the past.

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

There is a micro symfony build just for this purpose, as barebones as possible, pull in only what you need.

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.

yes, that's basically what a framework is for. but you have to follow the framework's way of doing things. most of the time that works well. few times, you may be fighting the framework to achieve some special cases.

you call libraries. framework calls you.

Yeah you're right this is kind of the archetypical "framework vs not" or "framework vs library" debate.

And I agree there's nuance to that conversation.

IMO, PHP codebases most err on the side of "reinventing the wheel" because PHP has since its inception just sort of worked, i.e. mirroring directory structure, spitting out HTML verbatim etc. So the framework luddites tend to be over-represented with PHP projects. Hence my opinion here.

I would say that if you're considering frameworkless I might suggest Laminas (the Zend successor) as an alternative since it allows you to pull in tools in a more piecemeal style. Integrating roll-your-own components into Laravel can be difficult due to have tightly knit and off the beaten path their internal style can be.

I think there are a few quite good choices of frameworks right now in PHP and I hope the space remains healthy and varied since the different options do cater well to different use cases.

14 files on the scale of a large app, is nothing?

Yeah, not a large app. I should have mentioned that it had like 12 endpoints total

Reply on news.ycombinator.com