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

101–110 of 262 posts

Re: Laravel 9

#101

Post by tnorthcutt »

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…

Just for some context, here's how the items under "Ecosystem" on laravel.com break down on free vs. paid:

Free:

- Breeze

- Cashier

- Dusk

- Echo

- Horizon

- Jetstream

- Mix

- Octane

- Sail

- Sanctum

- Scout

- Socialite

- Telescope

- Valet

Paid:

- Envoyer

- Forge

- Nova

- Spark

- Vapor

Re: Laravel 9

#102

Post by ehnto »

XCSme wrote: post #71
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…

> on long term projects Aren't frameworks harder to use in a long-term project if the codebase is not constantly updated to match the new framework standards? For example, a code-base written in React (pre-hooks) is probably pretty hard to understand for a developer that has only learned React recently and uses hooks for everything.

There is often ongoing maintenance for sure, but if that is a concern a framework probably doesn't fit your project for other reasons already.

Frameworks are heavier, but in the same way a company gets heavier as it gets more professional and more complex.

I think your use case doesn't require a framework, so don't think my angle is to convince you that you do. Just that there is definitely a time and place for them.

Re: Laravel 9

#103

Post by munk-a »

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…

I wouldn't consider Laravel for this use case - I might consider either Laminas or Symfony though since those two frameworks allow you to pick and choose which features you actually want to roll into your project. If you'd like to simplify your routing files but otherwise leave everything else the same - Laminas and Symfony can do that trivially. If you find yourself forced into an ORM due to needing to support multiple SQL dialects, Laminas and Symfony can also do that trivially.

Laravel is a sort of all-in option that tends to perform worst when integrated into a legacy project - it isn't completely overbearing (it won't creep into absolutely every file you're using) but it will end up requiring changes to a lot more files than is reasonable.

Re: Laravel 9

#104

Post by tnorthcutt »

munk-a wrote: post #91
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…

FWIW that hasn't been my experience at all. The documentation is great and well maintained. The repo is public and you can see all changes here: https://github.com/laravel/docs

Re: Laravel 9

#105

Post by unfocussed_mike »

XCSme wrote: post #83
unfocussed_mike wrote: post #72

Earlier quoted context omitted.

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 implemen…

> 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?

That depends. How tired is the developer? How under pressure? How over deadline? ;-)

I do get your point and I understand where you're coming from.

But this model of PHP (where every URL entry point is its own script) is the thing that most encourages expedient development rather than good development, because you can just hack on that one thing without affecting anything else.

It also (traditionally) encourages somewhat riskier hosting configurations, because any PHP file the web server can route may need to be executable, and because a failure of web server configuration can expose PHP files as readable. Whereas with a single point of entry (index.php router), you can locate your codebase outside the document root, refuse to directly execute anything but your endpoint script, etc.

These are partly old-fashioned concerns, admittedly, but it's surprising how often the approach you're outlining is still the source of malicious PHP exploits where a script file gets buried in a hacked release, or where some server vulnerability can be inveigled into executing PHP code by some image file upload mechanism that didn't do adequate checking.

Re: Laravel 9

#106

Post by XCSme »

tomcam wrote: post #89
unfocussed_mike wrote: post #72

Earlier quoted context omitted.

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?

I wrote that example, which is simplified, but here are some security things to keep in mind when dealing with PHP/MySQL:

    - Always use PDO prepared statements to avoid SQL injections  
    - Should probably implement a CSRF token check  
    - You shouldn't output values directly from the user/database and that can lead to XSS  
 attacks (either sanitize the stored data, or when outputting it make sure the page is always interpreted as plain text)   
    - You might forget to check for permissions in a specific route (code enforce this via some linting/IDE rules, by using some automated tests or by checking in an included shared script that permissions were indeed verified)

Re: Laravel 9

#107

Post by chipotle_coyote »

munk-a wrote: post #91
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…

That's not super irrational. :) Laravel does seem to be keeping up with their written documentation, although it's also occasionally an example of their "See how great Laravel is? See? See?" style.

Re: Laravel 9

#108

Post by pluc »

tomschlick wrote: post #74
pluc wrote: post #60

Earlier quoted context omitted.

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…

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 can see how it's seen as a benefit, but the flipside is that you're teaching your developers Laravel, not PHP. They assume whatever they do, they do in a good way because it's Laravel that does it which is great, but it abstracts actual knowledge. It's like if a developer uses SQL exclusively through an ORM and DBAL, how much can they be expected to know about the workings of SQL performance, indexes, etc.

I also find it very interesting that there's no stigma associated with "Laravel developers" that focus exclusively on that framework and its syntax and way of doing things and you have "WordPress developers" who do the exact same but are seen as incompetent.

I understand though that there are scenarios in which what you want is a guy that knows a framework really well, but if we're talking about skills of a developer, I'll pick the guy that knows vanilla PHP over a framework specialist 80% of the time

Re: Laravel 9

#109

Post by aprdm »

tnorthcutt wrote: post #101
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…

Just for some context, here's how the items under "Ecosystem" on laravel.com break down on free vs. paid: Free: - Breeze - Cashier - Dusk - Echo - Horizon - Jetstream - Mix - Octane - Sail - Sanctum - Scout - Socialite - Telescope - Valet Paid: - Envoyer - Forge - Nova - Spark - Vapor

This gives absolutely no context as I have no idea what these funny names are :)

Re: Laravel 9

#110

Post by unfocussed_mike »

chipotle_coyote wrote: post #97
unfocussed_mike wrote: post #81

Earlier quoted context omitted.

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 "Forg…

I take your point and I understand that you could get that impression looking at the website; they have stuff to sell.

There's also more of a market for some of that stuff, and the reason is the huge proliferation of different PHP execution environments. PHP runs in more places and there are more opportunities to help correct for the limitations of those environments (with log monitoring tools and the like).

(Also -- contrarywise as they say -- PHP does _not_ run first-class in some serverless environments; you need a custom execution environment for PHP in Lambda. So there's an opportunity there.)

But as a developer experience it is really not commercialised at all. I do not look at or think of any of those things, and I've not encountered any significant upselling. I'd forgotten all about Forge until you mentioned it! (And will now revisit it)

Post reply on HN