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

61–70 of 262 posts

Re: Laravel 9

#61

Post by cmg »

dgb23 wrote: post #12
geenat wrote: post #10

Laravel and Drupal 7+ frankly ruined PHP for me. PHP as a platform is KISS and elegant, and I still admire some of its features such as built in templating, filesystem based routing, etc. But whenever I look back at Laravel, I remember how dangerous overly complex fluff with a nice logo is to a platform.

You can use Laravel just for the basic wiring, integrated tooling, SQL query builder, auth, sessions, and HTTP routing. It really gets out of the way if you need to avoid features you don't like. All of the stuff I listed above are a PITA in plain PHP.

I went kind of in another direction a few years ago - CodeIgniter's routing/sessions/etc base was plenty for most of my projects, but I wanted a real ORM. So I integrated Eloquent from Laravel and ignored the built-in CI database layer. A bunch of these sites are still running smoothly on modern PHP.

Re: Laravel 9

#62

Post by unfocussed_mike »

TimWolla wrote: post #13
Darmody wrote: post #2

I've been programming in PHP for around 5 years. I've used vanilla PHP, full featured MVC frameworks, micro frameworks and I've been working with Laravel for around 2 weeks. Worst experience ever. The more I dig into it the more I hate it.

This is my experience with Laravel as well. Laravel looks great on the surface for a simple CRUD application, but once you need to do something non-trivial with it, you need to start fighting the framework. Also I dislike the large amount of magic happening within the framework. I want to understand what the code is doing, so that I can properly debug it in an emergency. As a specific example I needed to override hal…

Passport is the only bit that makes me nervous, because of one over-broad exception that it raises that I don't really like. I accept that the action from that exception is the same in each case but I'd rather it broke it up into more than one.

The rest of Laravel I have no complaints over; compared to Rails it is a model of pragmatism.

Re: Laravel 9

#63

Post by vanviegen »

raziel2p wrote: post #34
rob74 wrote: post #29

Earlier quoted context omitted.

Not the OP, but one thing that stands out for me is the (lack of) quality of the documentation. It reads more like a book (that tries to explain how to do things) than a reference (an exhaustive list of all classes, methods, parameters etc.). Ok, it's nice to have the former, but the latter would be far more important!

If you think so, it's available here: https://laravel.com/api/master/

That does seem very, uhh, minimalistic, if that's supposed to be the reference documentation. Just one very short sentence per method. Most arguments are unexplained. No examples that I could find.

Re: Laravel 9

#64

Post by unfocussed_mike »

riipandi wrote: post #28
jackconsidine wrote: post #11

Exactly 45 minutes ago I went on Laravel docs and saw the "you're on an old version of Laravel" message on the Laravel 8.x docs. Wow, I thought, Laravel quietly dropped a major release and I didn't even see press for it.

Don't forget to watch Laracon Online, tomorrow on Youtube.

Ooh thanks for this.

Re: Laravel 9

#65

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…

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 'dbconfig.php';
    checkPermissions(ROLE_ADMIN);
    $res = $db->exec("SELECT * from users");
    echo json_encode($res);

Re: Laravel 9

#66

Post by doublerabbit »

mschuster91 wrote: post #54
doublerabbit wrote: post #46

Earlier quoted context omitted.

Same applies for frameworks. Your hoping that the framework and ecosystem is clean as to get everyone to update the framework isn't an easy task espcially when a vulnerability arises from within. It's moot. Take Wordpress for example.

> However your then hoping that there are not any vulnerabilities within the framework. The likelihood of me introducing an injection, authentication/authorization bypass or RCE vulnerability in homegrown stuff is orders of magnitude larger than in an application where at least the sensitive core parts are handled by something that's battle tested in millions of deployments and regularly audited.

If the framework is promoted to be enhanced by a ecosystem of plugins, widgets, your still introducing the same exploitable ground as of developing your own. If not more dangerous because your operating already on core infrastructure and with a wider audience. How often does the developer get bored and start to neglect the plugin?

I do agree that a single home-hobbyist programmer should not be coding a bank and that sql injections and the rest are all lethal to the internet. However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.

It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.

Re: Laravel 9

#67

Post by unfocussed_mike »

riipandi wrote: post #27
defenestration wrote: post #21

We have been using Laravel for over 8 years. Nothing but praise. It's a framework we could rely on. No painful upgrades and clear documentation. For us it's a pleasure to work with. I also recommend Laracasts from Jeffrey Way.

Yeah. Maybe what we love from Laravel isn't only great docs and painless upgrade process, but also the great ecosystem.

It's the fact that it has a culture of grown-ups. Where by "grown-ups" I mean there is an avoidance of cute hacks for the sake of things, there is an approach where nobody assumes anyone is the same kind of expert, and takes care to contextualise.

There is a stronger emphasis on being able to _write_, to explain, etc.

I love really cute hacks and neat minilanguages and metaprogramming and all that when I am doing things for fun. But when I am working, I want documentation, not five-line git READMEs that presume I am up-to-date.

Re: Laravel 9

#68

Post by cutler »

bdcravens wrote: post #40
geenat wrote: post #10

Laravel and Drupal 7+ frankly ruined PHP for me. PHP as a platform is KISS and elegant, and I still admire some of its features such as built in templating, filesystem based routing, etc. But whenever I look back at Laravel, I remember how dangerous overly complex fluff with a nice logo is to a platform.

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.

Re: Laravel 9

#69

Post by pak9rabid »

geenat wrote: post #10

Laravel and Drupal 7+ frankly ruined PHP for me. PHP as a platform is KISS and elegant, and I still admire some of its features such as built in templating, filesystem based routing, etc. But whenever I look back at Laravel, I remember how dangerous overly complex fluff with a nice logo is to a platform.

Having worked in both environments (framework vs no framework), for anything other than very trivial apps, you want the framework to force everyone into a common way of doing things. Otherwise the project turns into a a massive clusterfuck of everyone doing their own thing, often with many instances of "reinventing the wheel" going on.

Re: Laravel 9

#70

Post by chipotle_coyote »

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 real-world project like Rails and Django were (e.g., BaseCamp and the Lawrence World Journal's internal CMS), but rather developed just to be "a better framework." Each successive release of Laravel seems to push even harder at tying you up with other Laravel add-ons, some of which are paid services. Rails and Django are open-source projects, but Laravel is an open-source product. Again, not necessarily bad, but there's an increasing feeling that the Laravel commercialization model is "give us sufficient money and you'll barely have to write any code."

My other nitpick with Laravel is that learning to develop with it is often learning to develop specifically for Laravel rather than learning to develop for PHP. This is a charge leveled against Rails and Django, too, but Python and (perhaps especially) Ruby are just better languages for developing DSLs in. Laravel has to jump through a lot of hoops behind the scenes to do what it does, leaving you with a framework that isn't particularly nimble and design patterns that often aren't particularly applicable to the rest of the PHP world.

If you're willing to hop fully on board with the Laravel train, none of this may be an issue for you. But at this point I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all. Use Composer to pull in specific packages that you really need, and ask "if I can get the functionality I need from this package with an afternoon's work, is the package bringing anything to the table that I still want" before adding them. (Sometimes the answer is "yes," but not always, and I tend to be wary of packages that primarily just wrap other packages.)

Post reply on HN