PHP is the new JavaScript?
mux.com
mux.com
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.
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.
For example, in Laravel you have the dependencies sprinkled all around the app and with Eloquent you kind of need to use active-record.
I am not a big fan of Laravel but I think it is a great tool to build websites, not sure about data heavy backends.
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.
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.
For example:
if (js()) {
/* javascript */
}
else {
/* PHP */
}
I don't know what to say, just that I wish I hadn't read this code
...that looks incredibly cursed.
The content of the article is describing the concept of a full stack framework, as if Laravel is the novel solution to it.
How in god's name is this tripe upvoted on HN?
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.
[1] https://forge.laravel.com/ [2] https://envoyer.io/ [3] https://usefathom.com/ [4] https://vapor.laravel.com/ [5] To prove I'm not a shill, this is from literally last night: https://github.com/simonminton/consensus-article
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.
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.
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.
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.
But I was literally asking --and curious to the answer to-- what "you" (would) pick.
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.
Well composite keys are a bad idea, so maybe it had a reason for that.
There are perfectly valid uses for composite keys. In a table that indicates a relationship between multiple other objects, for example.
But having 30s requests in general should be a red flag into other systems, laravel surely won't take that much to bootstrap.
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.
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.
And your code become hugely dependent on them.
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.
Strings are concatenated with the . operator, not +.
Or in older PHP versions it would output a number (because it would cast the strings to 0).
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.
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.
(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)
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
Typescript compiles to a dynamic language anyway.
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.
"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 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.
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.
Ruby also has the cleanest syntax of the three. Php and python are downright ugly in comparison.
For more than 1 decade Silicon Valley bros considered PHP a bad,irrelevant, legacy programming language.
Now, with a PHP framework receiving millions in funding, PHP is cool again.