9

I don't understand Laravel...

I'm just a software undergrad in my final year. Coming from JS side of things (Express, NextJS), I find Laravel so complex, and maybe unnessecarily complex?

Like, when I wanna learn Laravel, I understand the MVC structure. However, going deeper into it, there are libraries/names like
1. Vagrant
2. Facade
3. Artisan
4. Guard
5. Gate
6. Policies
ALL OF THESE
WHICH I DON'T UNDERSTAND HOW IT TIES TO THE FUCKING MVC STRUCTURE

I'm seriously giving up... My courses forces us to learn this framework, and I feel more and more inadequate because I have so many things to learn, including things for my FYP, which involves the use of NextJS. And can I mention HOW EASY AND MINIMALISTIC JS FRAMEWORKS ARE?

LIKE, I JUST WANNA MAKE A STUPID FUCKING APP MAN, WHY MUST I KNOW SHIT LIKE ARTISAN MAKE, WHAT THE FUCK VAGRANT IS, HOW GATES ARE RELATED TO POLICIES, HOW POLICIES RELATE TO VIEWS, WHY THE FUCK DOES FACADE EXIST, and other fucking stupid questions I need to ask in order to utilize Laravel correctly?

Don't even get me started on JETSTREAM, FORTIFY, LARAVEL/UI, BREEZE. Like, WHY THE FUCK CAN'T YOU JUST HAVE ONE SINGLE PATTERN, AND THEN HAVE GOOD TUTORIALS RELATED TO THAT ONE SINGLE THING?

I don't know, am I just stupid? Looking at Laravel, I feel like my braincells die more and more looking at the words used, the unusual terms, and the pain that comes with trying to learn it, because I don't have time. I'm going to fucking fail this subject because I have too much other stuff in my life to learn about.

I'm fucking tired man...

Comments
  • 4
    Lots of PHP fanboys will argue over this
  • 1
    Fuck Laracasts. Laracasts tells you about whats new in Laravel 8, but as a new person going into Laravel, I can't fucking use it. I have to look at Laravel 6's tutorials, implying that I will have to downgrade my Laravel just to learn it. What the fuck man, can't I have an easier time learning Laravel?

    I just feel so helpless using this
  • 6
    I am a PHP fanboy.
    Fuck Laravel.
  • 4
    You don't even need to know most of this.
    Most of it are just conveniences, you can choose to use or not.

    You really only need to define routes.
    The route value can be a closure, callable or a class reference.

    - a class reference needs to be either invokable or implement the Responsable interface.

    You can also point a route directly at a blade view if you want.

    Models & migrations if you need data persistence.
  • 3
    @VerenOnline you should really aim to be as close as possible to the latest version of Laravel.

    Unless specifically required, why go with L6?
  • 6
    Senior PHP dev here, you don't need to learn or care about Laravel (or php frameworks) if you know how to put stuff together with composer and good php oop then you can pick and build your own architecture without an issue.

    Don't feel discouraged from not knowing or understanding large items from others code.
  • 3
    @c3r38r170 agreed, I would say that most proper php devs that are really hardcore about the language would normally dislike Laravel.
  • 4
    @AleCx04 why dislike something that makes it easy to get stuff done and keep it readable?
  • 2
    @lotd Major release every 6 months is ridiculous. For some people, keeping laravel projects updated with the latest release is a hard job.
  • 2
    I tried a few yrs ago to use laravel and yup thats exactly what i said. For me i went elixir and ocaml now my head doesnt hurt but i forgot to get glasses and keep getting hit by the unemployment bus.
  • 2
    I rather use phoenix elixir than using lavarel PHP ...
  • 4
    Laravel is and overengineered piece of crap. You thought you'll need PHP and MySQL, and maybe a package manager? Fuck you, here's some DevOps shit you never asked for, so you can keep wondering why is everything so complicated and why we call our users "Artisans".

    Yeah the whole Laravel ecosystem saves tons of time when you're dealing with large production-ready apps and need to have deployments, server management, tasks, and whatnot. But unless you're an established full-stack dev in some corporate environment, Laravel is an overengineered piece of software you can't use without first learning several technologies you don't need just so you have an idea how basic things in Laravel work.
  • 1
    These are pretty much convenience in case you want to modify stuff. Like Guard are for auth stuff and a kind of interface for doing auth. Implementing an authentication mechanism while using the guard interfaces and convention will allow you to not rewrite your old code. The same thing for the multiple Facades for stuff like Email, Hash,... Laravel is big on modularization. and you can probably replace pretty much anything.
  • 3
    So Laravel is basically the React of the PHP world?

    Overused, everyone kinda hates it, but it's still super popular?
  • 1
    @lotd I have never liked frameworks, never really, Rails was about the only one that ai enjoyed and had little to do with it. I got used to the .net and jvm ways of doing thins with proper ioc and pulling only configurations that I need through code, and whereas I know Laravel can use similar things it is still not to my liking. I don't like its default orm, I don't like its release cicle and more importantly: I don't need a framework to tell me what good, tested, properly engineered and documented code is, I know how to do that myself.
  • 2
    @c3r38r170 I'm a PHP slut.

    Fuck Laravel sideways.
  • 1
    @imaji hm haven't been hard for me.
    4 code bases so far .. :)
  • 2
    @AleCx04 I'm the opposite, really dislike the asp & .net way of doing things.
    Especially Identity framework..
    Entity is ok, code first is just not my thing 🤣

    I never said a framework dictates what's good & well tested.
    Just makes it easy to get going without too much work.

    Eloquent so far has fit my mental model the best.
  • 1
    Coming from dotnetcore and react I'm finding that laravel being opinionated is saving me a lot of time. Still not super keen on PHP itself, but I like having an established approach for laying out a large codebase.

    Also dotnetcore and react feel like they are changing faster so the constant rewrites seems (to me) worse in that stack.
  • 1
    @lotd Not trying to generalize ofc, but YMMV. It's been a hard time for my team in my previous job to maintain codebase for our app, it's a coal mining ERP btw, so it's really complicated for us every six months.
  • 1
    Your first mistake was even considering using PHP
  • 1
    @imaji they changed it to 12 months with laravel 8
  • 2
    @imaji I've made some booking apps & a video streaming app.
    Decently large code bases, especially the booking ones.
    Has retailers, vendors & online customer support
  • 1
    @lotd No no, I'm not trying to tell you that our app is bigger than yours. It's just our app complexity that makes us in pain for regularly updating while every mine location has its own copy of our app. Our client didn't want it to be an SaaS app, that's a direct bullet for our head keeping them updated and distributing them. 😂
  • 2
    @10Dev Yes, Laravel is the React of PHP.

    I use Laravel daily. Monolith, nearly 30 million lines of code, 3-4 million active users, over 100 developers.

    So it can scale.

    But we have a serious amount of style rules, to make things a bit more sane.

    The major issue with Laravel is that it gives a lot of freedom, and hands the developer tools which no developer should ever want to use. Ugly shortcuts.

    Sure, writing ->whereName($name) instead of ->where('name', $name) seems cute, but watch your IDE and static analysis tools trip over themselves and you'll start crying.

    We have also separated large amounts of code away from the framework.

    To be honest.... yeah fuck Laravel.

    But also, fuck MVC.

    There's no reason to pack all your models in one directory, all your middlewares in another, all your controllers together.

    DDD for the win. Use PHP8, write typehinted & statically analyzable code. Decouple domains as much as possible.
  • 4
    Oh BTW:

    1. Vagrant (/Homestead) = Get a real computer and use Docker, you OSX hipster.

    2. Facade = Swiss knife magic classes which act as proxies. Easy, but very annoying when your code matures. The Auth facade for example makes it easy to access the current user, request, session, etc from anywhere -- but that practice also makes things incredibly annoying to unit test.

    3. Artisan = Grunt/Gulp

    4. Guard = Authentication provider. You can have multiple, for example if you have a token-based API and also a cookie-based login.

    5. Gate = Authorization Facade. Defines whether the current request is allowed to access a resource.

    6. Policies = One step up from gate, it's a class which defines access control for a model.
  • 3
    One more thing:

    I would avoid Blade templating. It's 2021, APIs rule the world.

    Use Laravel Passport (optionally with Laravel Socialite for oAuth) together with league/fractal (Rest) or nuwave/lighthouse (GraphQL).

    Also, use Laravel 8 + PHP 8.

    Both are actually improving, and get a lot less messy with every version.

    spatie packages are famous for improving a large part of the Laravel ecosystem.
  • 2
    And if you want to use a nicer language & framework....

    https://rocket.rs/

    https://yew.rs/

    😁
  • 0
    @lotd Laravel 8 does not have a good tutorial on Laracasts
  • 2
    @VerenOnline

    Tutorials for frameworks are always kind of poopy compared to the official docs.
  • 1
    @bittersweet Agreed, but also my lack in ability to pay attention looking at text makes it hard for me to read documentation without getting distracted haha
  • 0
    Yeah, i agree.. for basic project laravel is ok to learn but for a complex project it gets a lot more messy.
  • 0
    @lotd I dig it and respect it, as a whole I just don't like frameworks, but understand the benefits they bring. Heck my php projects are big enough they might as we be frameworks themselves even if it is just a bunch of libs pieced together. Check out if you will, Advanced PHP by patrick Louys whenever you have the time (and money) the books is great in exposing how lib and framework consumption happens. I am probably missing out from using Laravel, but thus far just plain php with some libs have given me a lot of millage and I love it.

    For the web I tend to resort to php and go these days, Go is my second favorite language for building web applications, I have been severely enjoying myself using both in a libraries way of doing things
  • 1
    @imaji keeping track of distributed copies?
    Polling an API to check the version and suggesting the users to update? :)

    @bittersweet DDD FTW indeed.
    Mmh I use larastan(phpstan with laravel magic support), so far it's been fine.

    The magic where query methods is something I keep away from as well.
    Only use it occasionally, in tinker.

    For scopes I generally suggest extracting a eloquent builder with them, and return it with "newEloquentBuilder" in the model.

    For APIs, I usually opt for sticking with json spec together with spatie/laravel-query-builder

    I usually go with Sanctum, unless I actually need the extra stuff that OAuth brings.

    @AleCx04 Advanced PHP by Patrick Louys, gotcha. Thanks.

    I do prefer keeping things as simple and streamlined as possible.
    Having a bunch of custom libraries just gives me ~/3rd_party PTSD from code igniter 😅
  • 0
    Yeah I used Laravel for 3 years, learnt express recently and never want to go back to Laravel
Add Comment