Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Laravel 9

laravel-news.com

Post reply on HN
Print view View original

71–80 of 262 posts

Re: Laravel 9

#71

Post by XCSme »

ehnto wrote: post #52
XCSme wrote: post #19

I like using plain PHP + PDO MySQL. I structure it so almost all files contain a single function/MySQL query, with very little dependencies. I already know how to implement core functionalities when needed (e.g. CSRF, user permissions). Why should I consider Laravel if plain PHP seems to work excellent in my case (been able to maintain the same codebase for over 9 years without issues, can quickly create a new app if…

Frameworks are useful for working in teams, and on long term projects. This is because they provide a set of idioms, patterns and decisions that everyone can learn and know, without having to invent them all yourself. It doesn't have to be the perfect way, it just has to be a way, so that you can focus on your domain specfic problems. Likewise, when a new developer arrives, they know exactly where to find everything…

> on long term projects

Aren't frameworks harder to use in a long-term project if the codebase is not constantly updated to match the new framework standards?

For example, a code-base written in React (pre-hooks) is probably pretty hard to understand for a developer that has only learned React recently and uses hooks for everything.

Re: Laravel 9

#72

Post by unfocussed_mike »

XCSme wrote: post #65
ehnto wrote: post #52

Earlier quoted context omitted.

Frameworks are useful for working in teams, and on long term projects. This is because they provide a set of idioms, patterns and decisions that everyone can learn and know, without having to invent them all yourself. It doesn't have to be the perfect way, it just has to be a way, so that you can focus on your domain specfic problems. Likewise, when a new developer arrives, they know exactly where to find everything…

But what if the app is a simple monolith that exposes some API routes and processes/reads/stores data in a database? Is something like this really harder to understand for a new developer than a Laravel project? .htaccess dbconfig.php /api /users create.php get.php getAll.php delete.php /products create.php get.php delete.php And where each file does something like (simplified) // /api/users/getAll.php include 'dbcon…

There is no doubt that getting in and out of a Laravel project is a bit more difficult than the example you suggest. But the example you suggest absolutely encourages bad practice.

Re: Laravel 9

#73

Post by jordanmorgan10 »

I met Taylor a few years ago at a conference we were both speaking at. Coming from the iOS world, I had no idea who he was.

"So, what do you work with?"

"PHP mainly", he said.

I replied "That sucks, sorry man."

¯\_(ツ)_/¯

Re: Laravel 9

#74

Post by tomschlick »

pluc wrote: post #60
jackconsidine wrote: post #30

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 whe…

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 u…

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.

Re: Laravel 9

#75

Post by colecut »

XCSme wrote: post #49
castis wrote: post #22

Earlier quoted context omitted.

> Why should I consider Laravel If you work on all those projects alone, and you're happy doing this, you probably wouldn't. You aren't the target market for a framework like this. Laravel (and any good framework, really) is for people who want a consistent dev experience _with good documentation_.

Yes, I do work alone on those projects, but I do use frameworks on the frontend-side as I find them to help in the long term, not hinder the projects as PHP frameworks do (a lot of boilerplate). It makes sense that if Laravel is strongly-opinionated to result in a consistent dev experience, but is a consistently bloated dev experience better than an inconsistent lean one?

Bloat can be mostly ignored, inconsistencies can not.

Re: Laravel 9

#76

Post by n42 »

pluc wrote: post #60
jackconsidine wrote: post #30

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 whe…

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 u…

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

Re: Laravel 9

#77

Post by unfocussed_mike »

castis wrote: post #22
XCSme wrote: post #19

I like using plain PHP + PDO MySQL. I structure it so almost all files contain a single function/MySQL query, with very little dependencies. I already know how to implement core functionalities when needed (e.g. CSRF, user permissions). Why should I consider Laravel if plain PHP seems to work excellent in my case (been able to maintain the same codebase for over 9 years without issues, can quickly create a new app if…

> Why should I consider Laravel If you work on all those projects alone, and you're happy doing this, you probably wouldn't. You aren't the target market for a framework like this. Laravel (and any good framework, really) is for people who want a consistent dev experience _with good documentation_.

> You aren't the target market for a framework like this.

I don't know about this. But then I am of an age where I consider myself to be a team of programmers separated by time.

There are the younger, less easily tired versions of myself who thought this was a great idea for a career and lived on takeaway curries, there's me, and there are the four or five older versions of myself who will hate me for trying to be clever and not trying to be consistent.

Laravel helps me take on projects that allow me to hand off pieces of work among my team ;-)

Re: Laravel 9

#78

Post by munk-a »

jackconsidine wrote: post #30

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 whe…

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.

Re: Laravel 9

#79

Post by blowski »

XCSme wrote: post #65
ehnto wrote: post #52

Earlier quoted context omitted.

Frameworks are useful for working in teams, and on long term projects. This is because they provide a set of idioms, patterns and decisions that everyone can learn and know, without having to invent them all yourself. It doesn't have to be the perfect way, it just has to be a way, so that you can focus on your domain specfic problems. Likewise, when a new developer arrives, they know exactly where to find everything…

But what if the app is a simple monolith that exposes some API routes and processes/reads/stores data in a database? Is something like this really harder to understand for a new developer than a Laravel project? .htaccess dbconfig.php /api /users create.php get.php getAll.php delete.php /products create.php get.php delete.php And where each file does something like (simplified) // /api/users/getAll.php include 'dbcon…

Nearly every time I see PHP projects like this, I find massive security vulnerabilities combined with extremely brittle functionality.

Sure, this describes many Laravel and Symfony projects as well, and not every vanilla PHP project is bad. But there is definitely a pattern.

Re: Laravel 9

#80

Post by munk-a »

tomschlick wrote: post #74
pluc wrote: post #60

Earlier quoted context omitted.

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 u…

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 b…

I think this is a benefit from using a framework in general and there are some good alternatives in the PHP space.
Post reply on HN