Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 doesn't match my experience at all, and given Laravel's popularity... this comment would be a lot more valuable with a why.

I will say I opt out of the starter packs and Laravel Sail (their Docker-for-dummies basic setup) in favor of a more bespoke setup, but my Laravel experience has been great otherwise.


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.


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).


Does Laravel have anything akin to the Rails Guides? (ie, higher level based on what you want to do, rather than API-level documentation)



Rails has a number of "cast" sites as well. There are times however that you just need well organized text documentation.


It's actually not unreasonable to expect something that exists between the main documentation and the automated API documentation. Sounds like a great idea for someone to build and contribute back to the community!


I've been programming in PHP since ~2000, I've created giant systems with vanilla PHP, Kohana, Code Igniter, WordPress, and for the last ~8 years, Laravel. It's been a dream to work with.

I, like others, am curious about what your actual complaints are more than "I hate it".

As others have said, its opinionated, but its opinions tend to be strong ones with good data. It is also extremely customizable, with a smaller learning curve than most other frameworks and a richer community and documentation that the vast majority of frameworks.

If I were to hazard a guess, you're running into your opinion being counter theirs?


I've been programming PHP since around 2003 and although I don't find Laravel to be perfect, I find it to be a very solid framework to build general web solutions with. I have successfully launched everything from complex OAUTH solutions handling insane amounts of traffic, to dumb startup ideas, to just simple CRUD apps I use in my own personal life.

I find it to be fully featured, incredibly well documented, and easy to use/learn. I find it to be my favorite "RAD" tool for generic API development. Also, the community is pretty solid too - specifically the IRC channel. I'll go far enough to say that Laravel has positively motivated my development as a software engineer - it's opinionated but I find it to be opinionated in a good way. Example: Laravel is heavy on testing/tooling which I think is outstanding.

I am really curious as to what specifically you're finding problematic?


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 half of the classes of Laravel Passport within the DI container to fix issues upstream wouldn't acknowledge at the time / doesn't acknowledge. Some of them are fixed by now (e.g. they finally support non auto increment Client IDs OOTB), some of them are not when I last checked.

I wouldn't choose Laravel again.


Exactly this for the exact same reasons, only more specific to the Eloquent ORM instead. God forbid you need to do nested-nested-nested relationships or something relatively complex. Laravel works VERY well for the simple cases, but all the weak typing, reflection and runtime searches that it uses just makes every runtime framework problem a pain in the ass to debug. I'll stick to Spring Boot or ASP.NET Core any day.


It sounds like Doctrine https://www.doctrine-project.org/ is what you need if you want an ORM to handle relatively complex stuff. It's the default in Symfony projects and I don't know if there's a Laravel integration.

ASP.NET Core is nice mind; if you have the choice... :)


ASP.Net Core runs perfectly well on Linux so cheap VMs are an option now.


I don't know if many share the same sentiment, but mine is to keep ORM use to the simplest of query. Anymore complex than that is better to be developed with raw queries, which also usually supported by the ORM.


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.


Do you have any actual complaints?


Honestly surprised by this. It's an opinionated framework, but it's consistent and the ecosystem is rich with options. I've been very happy working inside the laravel ecosystem for the last couple of years.


A problem with any "opinionated" framework is that people may disagree with the opinions. :)


What would you suggest as idiomatic server code which is not Laravel, in PHP?

I had the "pleasure" to work a bit with a PHP legacy server written in Laravel, and I thought that the framework was alright - the problem was in the PHP code written with it (specifically its typing). I think laravel is opinionated and can help to have a consistent codebase... curious to know why you had such a bad experience, and where you were happier :D


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.


So you decided not to use framework because there is website with video courses about it? Interesting reasoning. Isnt there website with videos about the other framework?


There were a few reasons that was just one of them. My concern was that the website with video courses might supplant text based tutorials. Additionally, we've all got different learning styles - I've got ADHD so video courses are extremely ineffective for me.


I think I know where you are coming from. The first time I touched laravel was somewhere 2016-2017. I loved the way you got started and using valet got your app up and running a few minutes. Recently I wanted to do a quick project and noticed it is getting bloated. You have multiple paths you can follow instead of being straight forward. It adds to the learning curve. It is ironic because some of this new things were supposed to make it easier to create an MVP, but what happens is that it makes it harder to learn how the framework operates and integrates with all the new features.


Downvoting because you're not adding any info besides 'laravel bad.' I am interested in your experiences, but "I hate it" isn't useful by itself.


This is a wildly unhelpful comment without additional explanation. My guess is you're doing it wrong.


I'm curious what you don't like about it. I work with a team of people who love it.


Facades is the one that comes up every time I ask this question.


Which is a little silly, as you can avoid them entirely if you don't like them, and use the dependency injection or helpers instead.


Given the success of the framework, you just might need sone more time before it clicks


Please tell us why?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: