141–150 of 262 posts
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…
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…
Earlier quoted context omitted.
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.
Basically, well after they'd released the framework they had to change the Rails scaffolding (and I think their own apps) because parts of the scaffolding (CRUD deletes) would use GET to do the action that should only be done as POST. They discovered it about the time link-prefetching was invented ;-)
Basically, browsers were pre-fetching all the clever scaffolded delete URLs and destroying records, seemingly at random.
I was really impressed with Rails at the time but stayed well away from the scaffolded code in production, and I was gobsmacked by the idea that people talking about a clever, opinionated framework that did the right thing and produced magical, clean, elegant code to rescue you from terrible alternatives did not understand that GET requests should be idempotent.
Edit: here is one bit about it:
https://dhh.dk/arc/000455.html
The unearned high-mindedness of this still makes me chuckle.
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…
> other Laravel add-ons, some of which are paid services
These other services are what you're looking for - that's how Taylor and the team dog-foods Laravel.
While I don't object at all to the claim that small PHP projects can easily be done w/out a major framework, it's worth noting that both many components of these frameworks (including Laravel) can be incorporated into a smaller project ad hoc.
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." ¯\_(ツ)_/¯
Earlier quoted context omitted.
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.
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…
Sounds reasonable. (how) do you do testing (unit test and integration tests)?
I did have integration testing for a while for the core functionality, but in the end that was not helping much either, and after releasing a new version of the app I deleted the tests and (after 2 years) still haven't written new ones, without any bad consequences so far.
I deploy a new version to a beta branch, test it myself for a few hours/days (as I do use the app myself daily), then publish it live. Customers gradually upgrade to the new version and if anyone encounters an issue they let me know, and I fix it ASAP, but it almost never happens.
Also, the app is pretty complex, so writing tests for every use-case and environment is impossible.
I am not a big fan of writing tests when working in a small team (That being said, if I ever have the time and am bored enough, I will write some integration tests, but mostly for the installation part of the application, not for the usage part.
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 already know how to implement core functionalities when needed (e.g. CSRF, user permissions)
Even if you know "how", this is still wasted time on your part. These are solved problems.
Particularly when it comes to security features like CSRF, relying on yourself to implement it sounds like a major footgun opportunity. When you use a framework that has this built in, you have to try really hard to bypass these security features. You barely even have to think about how to implement it.
Earlier quoted context omitted.
So what happens if you want to hire a second dev to help you? Or you want to sell the codebase?
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…
It's the almost that will get you here.
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.