Live data from Hacker News

Laravel 9

laravel-news.com

121–130 of 262 posts

Re: Laravel 9

#121

Earlier quoted context omitted.

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

You left out Nova, which is also paid. I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel ad…

Rails very much was a commercial open source enterprise when it started out.

It's just that the enterprise was Basecamp and the other 37 Signals apps. They benefited enormously from the extra eyeballs on their framework, not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time.

They had no services to sell but they had a keen commercial imperative.

Re: Laravel 9

#122
post #109

Earlier quoted context omitted.

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

Free:

- Breeze: authentication starter kit

- Cashier: payment processing through Stripe or Paddle

- Dusk: automated browser testing

- Echo: real-time broadcasting

- Horizon: queue handler

- Jetstream: application scaffolding

- Mix: frontend asset compilation

- Octane: serverless Laravel

- Sail: Laravel Docker environment

- Sanctum: SPA authentication

- Scout: search engine

- Socialite: OAuth provider authentication

- Telescope: application monitoring

- Valet: macOS developer environment

Paid:

- Envoyer: zero-downtime deployment service

- Forge: Laravel hosting via AWS, DigitalOcean, and more

- Spark: application scaffolding kit

- Vapor: serverless Laravel hosting via AWS

Re: Laravel 9

#123
post #82

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…

14 files on the scale of a large app, is nothing?

Yeah, not a large app. I should have mentioned that it had like 12 endpoints total

Re: Laravel 9

#124
post #111

Earlier quoted context omitted.

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

I agree that writing secure PHP code is hard, but using a framework like Laravel, even if it has a single point of entry, makes it a lot more likely to introduce more security issues. When a framework is popular and open-source, people will spend a lot more resources trying to find and exploit vulnerabilities than in a custom private codebase: https://snyk.io/vuln/composer:laravel%2Fframework

I can see your point.

But at the same time, I have never seen a project built along the lines you discussed that has not collapsed under the pressure for expedience, and it's just as vulnerable to issues in libraries (which any project of any complexity will use).

Re: Laravel 9

#125
I thought Laravel was dead. Well looks like some people still like to use these slow and bloated frameworks. I cant say i miss the PHP ecosystem of bloat.

Re: Laravel 9

#126
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.

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.

Re: Laravel 9

#127

Earlier quoted context omitted.

Laravel definitely is everything, but light-weight. It's the slowest of the large names in PHP. see http://www.phpbenchmarks.com/en/comparator/framework or https://www.techempower.com/benchmarks/#section=data-r20&hw=...

You’re posting benchmarks for versions that are now more than 7 years old

TechEmpower appears[0] to be using Laravel 8.70, which was released about 3 months ago. Much less than 7 years ago.

The numbers there don't paint an encouraging picture either, but I'm happy to concede that performance isn't everything... it just doesn't matter for some applications. But, numbers like these are pretty appalling to me. (And yes, I feel the same way about Rails.)

[0]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Re: Laravel 9

#128

Earlier quoted context omitted.

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

You left out Nova, which is also paid. I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel ad…

You're right, thanks! Edited to add Nova (which I think is a fantastic product, and is worth far more than the $199 it costs).

Re: Laravel 9

#129

Earlier quoted context omitted.

You left out Nova, which is also paid. I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel ad…

Rails very much was a commercial open source enterprise when it started out. It's just that the enterprise was Basecamp and the other 37 Signals apps. They benefited enormously from the extra eyeballs on their framework, not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" t…

> not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time.

Tell me more. I remember when Rails was first released but missed that entire saga.

Re: Laravel 9

#130

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…

yes, that's basically what a framework is for. but you have to follow the framework's way of doing things. most of the time that works well. few times, you may be fighting the framework to achieve some special cases. you call libraries. framework calls you.

Yeah you're right this is kind of the archetypical "framework vs not" or "framework vs library" debate.

And I agree there's nuance to that conversation.

IMO, PHP codebases most err on the side of "reinventing the wheel" because PHP has since its inception just sort of worked, i.e. mirroring directory structure, spitting out HTML verbatim etc. So the framework luddites tend to be over-represented with PHP projects. Hence my opinion here.

Post reply on HN