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

91–100 of 262 posts

Re: Laravel 9

#91

Post by munk-a »

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…

If you want to talk about potentially irrational reasons to be put off Laravel: when picking a framework I ended up going with Zend over Laravel mostly due to the modularity of the former... but also because the wide prevalence of Laracasts made me concerned that written documentation would be difficult to use and the documentation space of the framework would slowly migrate to being half-out-of-date video and audio snippets that slowly became more and more misleading and inapplicable without being updated due to a lack of motivation.

Re: Laravel 9

#92

Post by blowski »

XCSme wrote: post #86
blowski wrote: post #79

Earlier quoted context omitted.

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.

So what happens if you want to hire a second dev to help you? Or you want to sell the codebase?

Re: Laravel 9

#93

Post by mechanical_bear »

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…

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

Re: Laravel 9

#94

Post by yurishimo »

munk-a wrote: post #80
tomschlick wrote: post #74

Earlier quoted context omitted.

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.

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.

Re: Laravel 9

#95

Post by munk-a »

masterof0 wrote: post #5
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.

Checkout Laracasts, Jeffrey Way is pretty good explaining things. I don't use Laravel (or PHP at all),but I do like his video tutorials a lot. I say this, because maybe is you the docs, or you cant find a way of doing something, etc...

When learning cool bird facts I really enjoy listening to people talk - but when trying to debug or learn a new framework I absolutely insist on written documentation. I need to be able to re-read paragraphs or segue to other topics briefly and then return which is incompatible with anything audio-visual. The existence of Laracasts was actually a strong disincentive for me to go with Laravel and I've been quite happy over in Zend/Laminas land.

Re: Laravel 9

#96

Post by XCSme »

bluedino wrote: post #87
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, mixi…

My point was more that PHP is more of a framework-less language, as most of the functionality needed for a basic web application is built-in (file-based routing, secure PDO database access, external libraries for specific functionalities like PHPMailer for sending emails).

I think that if you need something a lot more complex than this (realtime communication, processing data in separate threads, linking microservices), then PHP is not a good choice.

Re: Laravel 9

#97

Post by chipotle_coyote »

unfocussed_mike wrote: post #81
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.

I haven't interacted with it, either. "Engineered into it" would be too strong a phrasing, but it's hard not to get the impression Laravel's creator(s) really, really want you to use their other services. I mean, compare the menu bars of rubyonrails.org, djangoproject.com, and laravel.com: Rails's first links are "blogs" and "guides"; Django's first links are "overview" and "download"; Laravel's first links are "Forge" (their commercial provisioning service) and "Vapor" (their "serverless" deployment platform).

Re: Laravel 9

#98

Post by munk-a »

daveaiello wrote: post #20

Could somebody say, if you are planning to embark on a new Laravel project and you have no experience, how to begin? I bought a subscription to Laracasts, and there is a "What's New in Laravel 9" series. But "Laravel from Scratch" is still on 8.

Don't be afraid to investigate the other frameworks as well. Both symfony and laminas have a lot to offer and tend to be less all-encompassing. Laravel is the right choice to get something simple from 0 to 60 quickly, but if you need to do complex things or integrate legacy systems it can be a lot more punishing.

Re: Laravel 9

#99

Post by XCSme »

blowski wrote: post #92
XCSme wrote: post #86

Earlier quoted context omitted.

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.

So what happens if you want to hire a second dev to help you? Or you want to sell the codebase?

A new dev can start writing code immediately by looking at any existing file, as almost all of them do the same thing: include a shared header, get some input from the user, do one or more MySQL queries, return the result.

The backend is completely separated from the frontend (so the PHP application just exposes an API to work with), so any code written there does exactly what you expect with no side effects on the client-side.

Re: Laravel 9

#100

Post by yurishimo »

vanviegen wrote: post #63
raziel2p wrote: post #34

Earlier quoted context omitted.

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.

I'm not sure what you're trying to find. The main Laravel docs are fine for 90% of what you would want to do. If you're digging into the core of some internal class trying to decide if you can re-use something elsewhere, that seems edge-case-y.

The ORM, relationship model, templating, and routing are all thoroughly documented in the main docs. If you want to find out what obscure methods might be available for your custom package, you're probably competent enough to parse the auto-generated code docs or read the source directly (which is also very clear and well organized).

Post reply on HN