Live data from Hacker News

Laravel 9

laravel-news.com

161–170 of 262 posts

Re: Laravel 9

#161
I'm just now learning (week 2) Laravel after coming from using other custom frameworks for years. For the record I have my own framework with a fully featured ORM of it's own and 99% unit test coverage for said ORM which is a fork of one my friend started 15 years ago and I have contributed to for several years. We started it before Laravel existed and in many ways it's exactly like Laravel. [https://github.com/Divergence/framework]

But anyway.....

So far what I like:

- Migrations

- The ORM is pretty good

- Query writer is aight

- Blade

- Mixx

- built in CLI

So far what I don't like:

- All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh)

- File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory.

- [php artisan] - each project should have a file in bin folder with a PHP shebang [#!/bin/env php] with +x on the file and linked globally so instead of writing php artisan you would write $projectName instead. Link it globally even.

- .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments.

- Docs aren't great. Eloquent needs a PHP.net -like page where I can see every single member function but instead I google and get the getting started docs which gloss over the best features. I have to manually sit down and read the source code.

Re: Laravel 9

#162
post #91

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…

Are there any decent docs for Zend at all? I struggled with it for years. Simple "how do I ..." questions would just bring up nothing. Not from the docs, nor anywhere else on the web. Any solution I'd find wouldn't work in my case because other parts of my app were built in some incompatible way.

The Laravel docs on the other hand are the best I've ever seen and there's a huge amount of community driven guides that are mostly decent too.

Re: Laravel 9

#163
post #155

As a solo bootstrapped SaaS founder that literally relies on my app to pay my rent and food, I owe my sanity to Laravel. I've been doing web development for 10+ years. Nothing else understands the needs of a business owner AND solo programmer like Laravel does. I worked with Python (Flask/Django) for (4+ years) longer than I worked with Laravel (only 1 year), and yet I'm already 10x more productive in Laravel than I…

> As a solo bootstrapped SaaS founder that literally relies on my app to pay my rent and food, I owe my sanity to Laravel

I’m in the same boat as you, and I couldn’t agree more. Your comment absolutely nails it.

Laravel is a pleasure to work with. It takes care of 95% of everything I could ever need from a framework. And that last 5% is guaranteed to be covered by a high-quality community package. (Just look at Spatie, this is all just from one maintainer! https://spatie.be/open-source )

Some commenters in this thread seem to take issue with Laravel’s “artisan” approach… and yeah, sure. Maybe it’s a bit pretentious. But, whatever. They’ve earned it. Laravel, its ecosystem and community takes pride in being polished and professional — and rightly so.

Re: Laravel 9

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

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.

Re: Laravel 9

#165

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…

> Laravel has to jump through a lot of hoops behind the scenes to do what it does, leaving you with a framework that isn't particularly nimble and design patterns that often aren't particularly applicable to the rest of the PHP world.

And tell me, do you use React? Talk about jumping through hoops just to print HTMl.

Personally I'm very glad Laravel was written in PHP, because:

1) you can still use raw PHP in the templates if you wish.

2) PHP Traits allow a very interesting form of polymorphism and code-reuse which is especially suited to the kind of business logic you find in web apps.

3) PHP is very much a C-inspired language that was built ONLY for the web, so you get access to a lot of low-level constructs and a "baremetal" paradigm (passthroughs like system() for bash scripts with seamless handling of STDIN/STDOUT) plus a solid standard library for the web. The PHP standard lib supports everything you need to write HTTP servers: curl_setopt, parse_url, FFI for calling C functions for performance-sensitive code, date/time/number/currency formatting, global variables for cookies and sessions, etc. all out of the box.

For web apps, I'll take PHP over NodeJS/Ruby/Python any day of the week.

Re: Laravel 9

#166

I'm just now learning (week 2) Laravel after coming from using other custom frameworks for years. For the record I have my own framework with a fully featured ORM of it's own and 99% unit test coverage for said ORM which is a fork of one my friend started 15 years ago and I have contributed to for several years. We started it before Laravel existed and in many ways it's exactly like Laravel. [ https://github.com/Dive…

I doubt the routes are evaluated with regular expressions on every request, more likely it’s matched based on an explode of /

Re: Laravel 9

#167

I met Taylor a few years ago at a conference we were both speaking at. Coming from the iOS world, I had no idea who he was. "So, what do you work with?" "PHP mainly", he said. I replied "That sucks, sorry man." ¯\_(ツ)_/¯

To be fair, the guy is doing alright. His business is booming. He probably gets the PHP pity all the time and has learnt to deal with it.

Re: Laravel 9

#168
post #99

Earlier quoted context omitted.

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

> as almost all of them do the same thing It's the almost that will get you here.

The difference is mostly the user input, MySQL query and DB table and output. This is indeed prone to typos and "brain-farts" when selecting the wrong data.

Does Laravel provide any protection in making sure you don't SELECT from the wrong table?

Re: Laravel 9

#169
post #65
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…

But what if the app is a simple monolith that exposes some API routes and processes/reads/stores data in a database? Is something like this really harder to understand for a new developer than a Laravel project? .htaccess dbconfig.php /api /users create.php get.php getAll.php delete.php /products create.php get.php delete.php And where each file does something like (simplified) // /api/users/getAll.php include 'dbcon…

If your project is as simple as this then yes, a framework would be overkill for you.

The people that benefit from Laravel use a lot of its features and aren’t willing to waste time rewriting them for themselves.

In the businesses I have worked at, if we had spent the whole time building the stuff that Laravel already does for us then we’d have gone broke really quickly.

Post reply on HN