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

81–90 of 262 posts

Re: Laravel 9

#81

Post by unfocussed_mike »

chipotle_coyote wrote: post #70

Personally, I liked Laravel when I was first investigating it years ago, but was always a touch put off by the pervasive "I am beautiful, adore me" undercurrent throughout its design, documentation, and even comments. I'll be the first to admit that's not a rational critique. Having said that, though, Laravel is relatively unusual among major frameworks in that it doesn't seem to have been developed in tandem with a…

FWIW I have never once interacted with Laravel's commercial model, or felt that I am being engineered into it. I just don't give it another thought.

Re: Laravel 9

#82

Post by PetahNZ »

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…

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

Re: Laravel 9

#83

Post by XCSme »

unfocussed_mike wrote: post #72
XCSme wrote: post #65

Earlier quoted context omitted.

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.

> absolutely encourages bad practice

Bad practice, as in security-wise, performance-wise, readability-wise, or something else?

If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices?

If the developer is inexperienced, can't they still implement something in a bad way in Laravel (e.g. save a user-submitted file on the disk without checking for permissions)?

Re: Laravel 9

#84

Post by unfocussed_mike »

cutler wrote: post #68
bdcravens wrote: post #40

Earlier quoted context omitted.

Any app without a framework ends up creating a framework of its own. Complexity isn't something to hand-wave away, but neither is the mess of include's and SQL injection risks that many "vanilla" apps become.

Not true of Node.js.

Node.js is only fine if you have the personal energy to keep up with all of JS tooling all the time. It strikes me as insanely unprofessional most of the time.

Laravel always seems to be the work of grownups; it's not cutting edge but it is solid and self-contained.

Re: Laravel 9

#85

Post by BareNakedCoder »

TimWolla wrote: post #53
ivanhoe wrote: post #41

Earlier quoted context omitted.

IMHO Laravel and Symfony are the best things that happened to PHP community since php5. PHP was an ugly mess of bad practices, fragmented into many outdated apps/frameworks and it was just exhausting to use. Symphony was a great improvement, but a bit too rigid and too enterprise-level for my taste. For me Laravel was honestly a breath of fresh air - finally I had something significantly more powerful than my custom…

Laravel definitely is everything, but light-weight. It's the slowest of the large names in PHP. see http://www.phpbenchmarks.com/en/comparator/framework or https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Agreed! Framework == good doesn't mean any/all frameworks == good. Many of PHP's frameworks seem to have ignored PHP's unique run-time characteristics and adopted Java idioms (with Java, you pay once at compile time; with PHP, you pay with every single request). Ubiquity, near/at the top of the PHP benchmarks, seems to accept PHP's unique run-time characteristics (so performs well) and yet still provides all the benefits of a framework (consistency, etc). Ubiquity should see much more love than Laravel/Symfony/etc but doesn't :(

Re: Laravel 9

#86

Post by XCSme »

blowski wrote: post #79
XCSme wrote: post #65

Earlier quoted context omitted.

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.

I agree, one big reason to use frameworks is that they at least make it harder to make insecure things, but as you said, if the developer is inexperienced they can still introduce vulnerabilities in any codebase.

I would say, in this regard, that Laravel is better than plain PHP when working with inexperienced devs that are likely to make mistakes or write bad code.

Re: Laravel 9

#87

Post by bluedino »

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…

Self-made frameworks are great as long as:

  They work. If they are full of bugs they are a pain

  They are complete. If they are missing parts because they weren't needed yet, they are a pain

  They are documented. Documented well is a bonus

  There isn't a self-made framework for every project at the company

  The person who made the framework is still around

  The person who made the framework didn't also make v2 and v3, mixing them in the same project

Re: Laravel 9

#88

Post by skinkestek »

cutler wrote: post #68
bdcravens wrote: post #40

Earlier quoted context omitted.

Any app without a framework ends up creating a framework of its own. Complexity isn't something to hand-wave away, but neither is the mess of include's and SQL injection risks that many "vanilla" apps become.

Not true of Node.js.

True, and just like with the Gradle build system on JVM, every project is its own unique snowflake.

That's what you meant, right ;-)

Or is it just everything I inherit?

Re: Laravel 9

#89

Post by tomcam »

unfocussed_mike wrote: post #72
XCSme wrote: post #65

Earlier quoted context omitted.

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.

Non-PHP, non-Laravel person here just trying to learn. That looks pretty good to me. What bad practices does it encourage?

Re: Laravel 9

#90

Post by ehnto »

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…

If I am working alone, I sometimes do similar stuff. But if I am working with others, I don't really want to deliberate over every new architectural decision if a project grows. I want to be able to say, "Hey, can you make a new storelocator page" and then they can get it done using the docs. They know where models, controllers, views live, they know how to make migrations for the new tables, they can even google "store locator laravel" and probably get 90% of the way there in a day or less. Once they are done, I already know how this new feature should work before I even read their code.
Post reply on HN