Since I no longer work on big projects, I actually prefer Codeigniter. It's just simpler and yes, it doesn't do nearly as much as Laravel and I'm OK with that.
Ha, this reminds me of a time I was proposing our team use Symfony rather than Laravel for a new project. It was such a battle.
Eventually I wrote up a document (I must have spent 20 hours on that thing) showing the pros and cons according to our needs and what each options offered. The gist of it was that Laravel was a nice wrapper over Symfony components at the time (though it did offer more as well, too - it just wasn't the more we needed), and since we were kind of like power users (data heavy backend with tens of thousands of users, rapidly growing), we should go direct to the source and use the Symfony components without any abstraction.
I mean, we shouldn't have been using PHP at all at the time, but what can you do.
Literally no one arguing for Laravel knew it was based around the Symfony components. Once the CTO saw that and heard me out, we didn't actually end up reviewing the Laravel option at all. I was so relieved.
Those were weird times. I'm not sure how much Laravel has changed since then. At the time it was kind of like an easy way to build simple stuff fast, but it didn't strike me as a great tool for our use case. We needed to make the most performant php-based booking system possible, and some basic benchmarking showed that Laravel introduced some incredible performance penalties that didn't make any sense for us.
Sometimes I miss that product. It had massive potential. I still stumble across it while booking stuff. The UI has barely changed. I suspect they haven't made many changes or made much progress since I left 7 years ago. I really wanted to build it into something better.
Long story short: Laravel wasn't the right choice for that kind of application, no one who wanted to use Laravel had any idea about its architecture but argued with me about it for weeks, haha. Write detailed documents to support your case, it works wonders.
Laravel hasn't changed much. I mean, it did, PHP also changed a lot in the last years but the whole idea behind the framework is the same. Full of features, easy to set up, many tools built around Laravel to deploy your app, to build your own SaaS, etc but it's highly opinionated, you have to do it their way.
Symfony on the other hand takes more work but it's more flexible. One of internal apps is made with Symfony and after working on it for a couple years, if I had to set up the whole thing again I wouldn't know how.
Back in the day we used Symfony at work. I have a vague feeling that some of my coworkers looked down on Laravel. Less dependency injection, more weird magic.
> I have a vague feeling that some of my coworkers looked down on Laravel. Less dependency injection, more weird magic.
Well, you can rest easy knowing it probably wasn't just a vague feeling, because I'm pretty sure every moderately experienced programmer who has tried both and went with Symfony feels that way.
Laravel was clearly written from the ground up with one goal above all else: to make it was easy as possible for beginners to write babby's first website as fast as humanly possible. Every other essential aspect of such a framework (maintainability, modularity, code clarity, ease of debugging complex issues, etc) was thrown to the wayside in favor of that one main goal, which is why there's so much "magic" everywhere. You're expected to just blindly trust the magic and never look behind the curtain. Unfortunately, beginner programmers that have no intention of ever evolving past their beginner phase are a huge audience nowadays, so you end up with many people who have never had to write or maintain a complex codebase hailing Laravel as the next coming of Christ.
This is all heavily reflected in this article: the author picks one of the most extremely simple use cases to implement, a 99% static page with a single dynamic variable that doesn't even seem to use a database. And despite the code being extremely simple, he still has to ask AI to write 90% of it for him because he isn't interested in learning how anything works, he isn't interested in expanding it or maintaining it in the future, he just wants to pump out the minimum viable product as fast as possible.
Laravel follows dubious practices: god objects (like a parent class which has hundreds of functions), static functions etc. The kind of practices our product is actively moving away from (originally based on Symfony 1 which had all the architectural issues Laravel has now), because it didn't scale beyond CRUD (makes it easy to write hard to support spaghetti code etc.). So it feels like a step backward... Especially when you learn they base it on top of Symfony which is already great and nicely designed.
Count me as one of those disgusted by weird magic people. Unfortunately for us, the majority seem to love it. The more coding resembles throwing spaghetti at the wall and seeing what sticks, the happier they are. "What do you mean this could have been 10 lines and no frameworks; that can't possibly be complex enough [for some ETL thingy]."
The comments on this thread are interesting. I use Laravel extensively. For big applications, serving lots of users. It works when the application is relatively complex, and the ecosystem is second to none. Need to just throw it up on a server? There's Forge[1]. A better CI/CD process? Envoyer[2]. Want serverless? Not for me, but Fathom[3] use it to deal with >100Ms of hits a day; there's Vapor[4]. All three of those are Laravel developed and maintained solutions.
If I'm throwing something small together then sure, I'll maybe use Flask or something lightweight[5]. But Laravel is very good for nearly every use-case where you intend to actually build something.
Then there's the bigger question: if you're building to meet a business use case, or well, to make money, then why wouldn't you use the most complete scaffold possible? I'd say Laravel is that. If it's too much of a pain to do something in PHP I can just stick in a call to a python file or really whatever language I want. But for the basics? A db? Auth? and lots of other stuff that I never want to personally build again? Yeah, give me Laravel everyday.
Related: Laravel, the PHP framework mentioned by the article, just received a $57 million investment from Accel, the same folks that invested in Sentry and Vercel.
There's been enormous improvements to PHP's performance and to the language itself over the past couple decades. It's something worthy of praise.
That being said, it's not the "new Javascript". Javascript isn't dominant because of Node.js or anything like that, but because it runs in every major web browser. Whether you like it or not, Javascript is essentially part of the web itself.
PHP definitely is not the new JavaScript, but for people who want a server side solution for content delivery that's separated from the client, I'm sure it's much better than the mess it was 10+ years ago. That's still just a transition from meme level tech to valid option though.
I mean, in some ways JS truly is the new PHP. That is when you output some jsx template string, which conditionally has pseudo HTML elements (more components, but with HTML syntax) inside it, mixed with normal HTML tags, which in turn contain snippets of JS, which can have side effects ...
All of course preferred by the daily JS coder, instead of separating it out as one used to do with traditional template engines. PHP is the one that probably started this intermingling of everything, treating HTML as a mere string, instead of structured data, one of the biggest sins, leading to countless vulnerabilities over decades of web development. JS now carries on that torch of treating HTML wrong, only that the frameworks have apparently built in parsers or processing steps for their jsx, so that they find the web components and can separate them out from the surrounding HTML string, to evaluate them and output the HTML of those components into the surrounding HTML string.
JS also got the hallmarks of attracting a lot of beginners, just like PHP used to do, due to all the hype around JS frameworks. It is very tempting. You can quickly see the browser do something. With some backend language it will take much more, to see anything graphical. Seeing things move or change how something is displayed is a strong feedback and motivator for the beginner.
Yeh I got up to the repeated bits of having an LLM do the work and gave up because it's indistinguishable from all those articles shilling AI as productivity tools.
With server-side only you need only one place to keep state. Then you have a stateless webserver that needs to persist all to a db. Those constraints make software easier.
React is just the view part in the browser. You still needs state management in the browser, which is NOT stateless like most web server apps. On top of that all browser apps still need a backend: so you manage state twice.
Laravel + Vue is a popular and straight forward framework pairing. With all the shade in these comments, there's almost no suggestion for alternatives.
Ktor + jOOQ + Elm + OpenAPIv3 generators for generating a type-safe Elm client and Kotlin DTOs for the serverside.
IHP (Haskell) w/ HTMX.
Elm + Lamdera; for small games (super low boilerplate).
Hasura (Postgres + authorization exposed as GraphQL w/ generated schema) + Elm + GraphQL generator for generating a type-safe Elm client.
Rust + Yew w/ Actix or Axum on the backend.
Rust + Dioxus.
The thing I propose is: use something that makes it hard (near impossible) to express runtime errors. Life's to short for fixing bugs, and in many cases business is too fast to write 95% test cov. You need safety baked into your langs/tools.
You could use something like Yesod or even IHP (and that's batteries included). There is Servant, Spock, Scotty for lighter weight than those. There's also the newer hastl (haven't tried it). Yet if you are using htmx, you probably want to keep things simple. On the one hand, there is simplicity from having a framework already together for you. On the other hand you can get that simplicity from only having the dependencies that you actually want for your needs.
You need something to handle:
- server connection (everything is built on top of wai and warp). There's servant and scotty for lightweight layers on top of wai (which uses simple HTTP requests and responses)
- database persistence (for postgres - Persistent/Esqueleto, postgres-simple, hasql, Opaleye, etc.; for sqlite there is sqlite-simple)
- html templates (optional, but it does make writing html more convenient. blaze, lucid2)
- auth (server-session, client-session, or roll your own. Of course, stuff like Yesod gives you all of this out of the box)
- sessions (most people roll their own Session module. The reason is that it tends to be dependent on your database and other decisions you have made for routing, connections, etc.)
- routing (libs like Servant and Yesod come with routing out of the box. Of course, you could just route with strings, but why are you using Haskell if you don't want type-safe routes? There's also stuff like web-inv-routes that give you type-safe, composable routes.)
Ultimately, I think the best way to go down the bespoke path is to know what functionalities a web server/web app needs to have as far as categories like the above and then to build it up one piece at a time (maybe with side exploratory proof of concept mini-projects). If you don't have time for that, I'd just use one of the frameworks so you can ship.
> What happened? Well. Laravel happened (and has been happening).
Funny, because Laravel was one of the things driving me away from PHP, in the same way that Rails drove me away from Ruby. PHP was becoming a salvageable language with some of the 7.0 changes, but if you don't dump 1000 pounds of gunk on top to make the easy things hard and there hard things dang near impossible, then you're not a "web artisan", I guess.
Laravel needs its own 'fractal of bad design' article. My experience was being told to use it for a work project by a koolaid-driven manager, and finding that it made our CRUD apps about 1000 times harder to write[1] and 100 times slower to execute. It seriously took Laravel 100 times longer (0.3s to 30s) just to bootstrap itself than it took our Phrebar app to handle a request including a bunch of database accesses and permission checks.
[1] Or maybe infinitely, even with code generation, because the ORM didn't support composite keys. In that way we were forced to bypass the whole thing regardless of my feelings about it.
Granted, this was on some virtual machine on a computer from 2007. But I did pare it down and down until all that was left was Laravel itself, doing "nothing".
I don't find it all that surprising. Overly-complex startup times are the convention for web frameworks that want to be taken seriously [by koolaid-driven managers]. These days I'm forced to work with Spring Boot, and it also takes for-eh-ver to get to the point where it can run my code. According to the logs, it's a lot of walking the classpath to find every different class and figure out how to assemble them into an application. Because heaven forbid someone call a constructor to make the object they want.
ORMs only make easy things slightly easier. Complex queries are not expressable in ORMs, so you need SQL queries (usually as strings, in external files or generated with a tool like jOOQ/LINQ).
I think just doing all with SQL is easier to understand and maintain.
I see no benefit of ORM considering the small benefits vs cost of learning.
Agree 85%. 10% relates to cases where you want dynamically- generated queries, which is why Phrebar has facilities to help with this.
No off-the-shelf ORM that I've ever used has done anything but get in the way.
Another 5% disagreement over whether they even make easy things easy. They often require some contortion of your application code in order to work at all, like annotations or inheritance on value objects that lead to them being coupled to a specific data source.
Hearing these negative laravel opinions is super interesting. As someone who absolutely dreads working with php, I’ve always been curious about laravel cause people seem to love it so much.
As someone who has worked in a lot of languages and a lot of frameworks, I never understood the hype around Laravel. It's very opinionated as to how you structure your application but it gives you very little for forcing all that structure. I thought it would be and should be more batteries included. And the active-record style ORM is also not my cup of tea.
Nothing to fear about it. It's just a scripting language. It has some bad history but not so much because of the language but how it was used. The same messes could have been (and were) created with VBscript (ASP) and Perl back in the day.
All I can figure is that a lot of people, especially those willing to put up with PHP's warts in the first place, look at a giant crusty knot and can only be impressed with its size and seek to emulate its design. If, upon seeing the huge crusty knot, you puke in your mouth a little and say "are you sure you needed a knot at all" they briefly look at you funny before carrying on to make bigger and bigger knot composition frameworks to blather about on their blogs where they have a picture of their head in a little circle, because that was trendy among the so-called artisans for a time.
If an ORM can't be used to access a valid database, then that ORM sucks. (ORMs often suck for additional reasons, but that one's pretty hard to ignore if you have an existing database that you need to interact with.)
There are perfectly valid uses for composite keys. In a table that indicates a relationship between multiple other objects, for example.
Forget the framework, forget the AI assistant. What are PHP developers like these days?
Awhile back, we wrote an MVP, a proof of concept, using Wordpress. I dug around some of the plugins and themes we used, and my god, it's still garbage. Things being shipped with huge swaths of code just commented out, spaces & tabs intermixed for indentation, TODOs littering the codebase. Things that were just flat out broken.
I used to be a PHP developer, and the habits that I learned probably stunted my professional career by a good decade. And from what I've seen - granted, in a very limited exposure - tells me that most PHP developers still write garbage code. Weirdly, I've even seen examples at work where developers write perfectly cromulent Elixir and Javascript/Typescript, but somehow revert back to the fecal firehose when it comes to writing PHP code.
I don't care how good Symfony or Laravel is. I care about what happens when my employer hires someone who can't write good code, and in my experience, the odds of that increase hugely when we talk about PHP.
Wordpress should be avoided like the plague if you care about code quality at all. It actively encourages bad code and this will never change.
PHP programmers being conditioned to write low quality code due to their experience with things like Wordpress or other legacy bespoke codebases that aren't built on top of good programming practices is a real problem, and using a modern framework alone won't solve that problem, but I think Symfony in particular deserves credit for generally trying to steer people in the right direction. If you're just starting out writing complex applications in PHP, by using Symfony with PHPStorm (and possibly other code quality tools like PHPStan and php-cs-fixer, though PHPStorm already has decent static analysis and formatting built-in), watching the SymfonyCasts tutorials and being open to learning new ideas, you will likely end up writing at least moderately decent code because almost all of your programming environment will be pushing you in that direction.
Of course, if you just hired a straight up incompetent developer, they will likely end up writing unmaintainable spaghetti no matter how much they're pushed in the right direction, and there's definitely a high risk of that when hiring PHP developers, but I feel like there's an equally high risk for any popular high level language nowadays. Especially Javascript, there seem to be tons of self-proclaimed "front-end developers" out there who literally only know how to copy-paste React code and don't actually know much Javascript or CSS at all.
> if you just hired a straight up incompetent developer, they will likely end up writing unmaintainable spaghetti no matter how much they're pushed in the right direction
I'm currently dealing with a laravel app. Said app has an 18,000 line "AdminController", and a 7k lines "WebController"
These contain all the logic. No, I'm not exaggerating. Model files are empty, save for 4 lines of model declarations. It's a whole CMS written in a SINGLE FILE. of course, such a dumpster fire can't exost without copious amounts of copy-paste, of which there indeed hundreds.
I'm talking multi-levels of nested if conditions, each with many branches, and said branches are very well over 10-20 lines of code that only differ by a single word.
And I won't even get to the disgusting mess that is the view templates... Let's just say they follow the same principles as above, except the original developer was unfortunately constrained by having to create a separate view file for each controller method.
To play on how every engineer is different, OP is excited about PHP because of a framework, while I'm having more fun than I've ever had explicitly _not_ using a framework!
(I am using the PSR standard interfaces[1], which means I can sub in any number of different libraries for different pieces of infrastructure. Including Laravel's. :D)
What ever happened to Hack (https://hacklang.org) the language Meta built as a superset of PHP?
Why not take an approach more similar to TypeScript?
I sometimes do wonder if many of the server side rendering approaches (or alternative Node runtimes) would be better off trying to emulate some aspects of PHP
I agree. I do rails stuff, and recently I've been doing some laravel stuff. Ruby+Rails is just so much better than anything PHP could offer. Rails feels much more ergonomic than laravel, and the syntax is much cleaner.
It feels like Rails developers are just absent from all these online discussions because they're too busy living happy, fulfilling lives.
Every time I have to work with another technology, I end up wishing it could be done like Rails.
Rails's drawback is that with enough before/after filters it feels like logic is hard to grasp, but it still turns out to be better than any alternative I could of. The laravel middleware approach is much more cumbersome and less powerful.
Always thought React (specifically JSX) made JavaScript "the new PHP" in that there is markup all mixed in with syntax that is so similar to old school PHP.
"New school PHP" frameworks like Laravel are nearly exactly like Ruby-on-Rails: The same MVC style, database and ORM built-in, Laravel is so similar to Rails in many ways.
I would say:
"Laravel is the new Rails"
and
"New PHP is the old Python/Ruby"
The original dev use case for Wordpress where you can easily put up a basic CRUD app with user logins and roles/permissions was largely displaced by Django, which is just a little bit more mature of a project for such tasks than Wordpress could ever be. WP never wanted devs anyway, they wanted bloggers - so a lot of people stopped writing PHP simply because WP lost popularity as a web framework.
PHP lost a ton of up-and-coming developers to Python (esp. in academia) and JavaScript (esp. to Node), in the same way Flash/AS3 lost developers to iOS/Android. Unlike Flash, PHP never really died - just kept hanging around.
It's not a bad language, brings back fond memories at least. But there's nothing about its performance or usability that stands out, and there's no core platform need for it the way there was with Wordpress. JavaScript has the browser DOM and Node, Python has AI/ML libraries and best practices that aren't available in other languages, and in terms of another PHP use case - all the dynamic languages can quickly start an http server on localhost now. There's just no use case for PHP.
I would say an actively harmful TypeScript. Just a couple of days ago, I had bug in production because apparently the union of two types is not the intersection but the sum. It exploded because one type had a method that the other didn't. That's an absolutely horrible footgun
JS has done the impossible: It made me kinda appreciate PHP.
I still despise PHP for its many design (it wasn't actually designed, it just happened) failures, but I've yet to see an application running on a single server with PHP, Apache and MariaDB run slower than "modern" JS slop that needs half a cluster to run the dozens of random object DBs and caches JS devs insist on using prematurely where the application takes 20 seconds to load a simple page because the fully decoupled frontend needs to load and execute 500MB of JavaScript and that JavaScript then loads the data in 50 sequential XHRs because the API dev found a "loadAll" endpoint to be premature optimization.
...I envy TypeScript, though. I wish PHPDoc was more powerful... I just want ADTs.
> ...I envy TypeScript, though. I wish PHPDoc was more powerful... I just want ADTs.
You can get a lot of the way there with static analyzers like Psalm (psalm.dev). Annotate your functions/classes with detailed types in PHPDoc, and it'll verify that your code behaves consistently with those types.
Haha, thanks so much for this level-headed reply. PHP is really great to speed up your backend while not resorting to low-level c or rust. And many people will be able to read the code.
I had some modern "AI"-frontend that slowed my browser down to a crawl because i wanted to click a button. Vanilla Typescript and a bundler is enough overhead for me, most dynamic comes from fetched xml - i don't need a framework for that.
Typescript makes a lot of fun because it forces you to use clean interfaces and think about your design decisions - you cannot "write down" code like in PHP and i think that's great, but for a backend i will still resort to a database / shell env with php and some transformations and call it a day. It starts in 50ms and my TS-bundle is 500KB. That's ok i guess. The functionality is on par with modern pages hurling megabytes of code in my browser and taking ages and lots of promises to respond.
No wonder they all need kubernetes ....
I tried to befriend frontend-frameworks like React but the moment i saw i had to use hacks just to handle empty arrays i stopped reading and resort to write my own stuff for the frontend use case.
everytime I see PHP and python, it reminds that the best of the three main languages in the "slow / overly dynamic" lane (Ruby) got the short end of the stick for some reason, it's terrible
Ruby is real fairt tails magic, and using it makes me so happy. Ruby makes me feel like Cinderella in her dress, except there is no midnight time limit. And the carriage os Rails.
Ruby also has the cleanest syntax of the three. Php and python are downright ugly in comparison.
Just VC money buying good press. PHP still shit. Not valley bros, just engineers that have worked many hours with several wildly different languages simply know what works well.
The rest of the article seems to be more about AI code editing and MUX video players then PHP.
So I am not really sure what I am supposed to take from this post.