If you are thinking about building a web application, take a look at Laravel. I not a huge PHP user, but Laravel is always on the top of my list for building web applications. It's the greatest web framework to ever exists, even better than Rails IMHO.
The ecosystem around Laravel is really incredible and unlike any other framework. They have libraries for every stage of a web application from taking payments all the way down to server management and hosting.
They even have awesome libraries like Inertia which are built for Laravel but can be used with other frameworks.
It's the only reason I still stay fresh on my PHP.
+1 for laravel as well. I joined a php project for a fresh rebuild in laravel and had mostly .net experience. Laravel was great.
The documentation is an almost perfect blend of examples and nitty gritty detail. The documentation is almost engaging if you’re coming from other frameworks.
I found myself thinking “wow that’s almost no code, what about this feature or that” and the next section would be the exact topic I was wondering about. Had a blast and could learn more php details as I went
Laravel is great if you just want to get something simple done as fast as possible with the simplest, most elegant (at a glance) code possible and don't care at all about understanding how it works, what's going on under the hood, performance, doing anything the devs didn't expect, etc.
Everything in Laravel is as obscured, "magical" and opinionated as possible for the sake of making the code "beautiful" (again, at a glance) to the detriment of basically everything else. I really have no idea how any experienced programmer can look at it and think it's usable for anything beyond the most simple project.
The mere fact that models are PHP classes but none of their properties that exist in the database are actually declared as properties in the class because the ORM just "magically" puts them there at runtime should be enough to drive away any sane person. And let's not forget the amazing "Facades" a.k.a. glorified global variables filled with magic methods that you're expected to make extensive use of.
Can you give me a few real life examples where you got bit by the "magic" conventions or ran into any serious issue from not explicitly setting properties on your models?
Facades are not global glorified variables with magic methods. Usually they're just a way to instantiate and access a class with less code. People complain that facades limit testability. In fact, they're easily mocked. Etc.
The docs do a very good job of explaining how things work and how you can override any "magic" you may not like. If something is doing something you didn't expect, you probably didn't read the docs. In fact, a delight of working with Laravel is it's so intuitive that you can often guess how to achieve something and be right.
> And let's not forget the amazing "Facades" a.k.a. glorified global variables filled with magic methods that you're expected to make extensive use of.
Each of the facades comes with a corresponding dependency injection if you prefer. You can write an entire Laravel app without ever touching a facade.
So I suppose you also write your own compiler, your own operating system, and built its computer from bare transistors as well? Because all of that looks like magic to me too.
At some point you have to accept the foundation you have as something that works, it's battle proven, and it's built by experienced and reliable developers and you build on top of the shoulders of giants. Reinventing everything from scratch so that you understand it makes you the only one that understands it.
There was a famous phrase by Arthur C. Clarke that I think applies here along the lines of "Any sufficient advanced technology is indistinguishable from magic".
Laravel is a decent web framework, that comes with batteries included and _often_ has sensible ways to override and avoid things if you don't want them.
For example, you don't need to use the ORM at all and can just use their query builder (which is pretty good). It's there if you want it, but the framework works happily without it and doesn't get in your way in that regard.
I inherited a Laravel codebase from a previous contractor and it was reasonably ergonomic to navigate and extend, because I was able to lean on the framework documentation to understand how it all worked. But there were several points where it was _not_ reasonable, because of Laravel/PHP magic and those were pretty painful to figure out and debug.
The reason I wouldn't choose it myself anymore is the magic, the little surprises and hard to debug idiosyncrasies that it provides in order to look pretty. Also generally Laravel, PHP and related ecosystems are moving too fast and are difficult to keep up to date without breaking and/or misunderstanding things. It's not quite JS/npm level of churn, but unnecessary regardless. A more minor point is the baseline performance tends to be on the lower end of what I need.
There are ecosystems out there that value stability and clarity more and provide better tools to test and debug the code if necessary, and I've come to appreciate those things much more with experience than other factors such as reducing the initial development time.
What other ecosystems and frameworks are you talking about? I've tried many things across many ecosystems in the last 20+ years and so far, despite any drawbacks it could have Laravel is the best one by a long shot. So I'm curious what those other better solutions you mention are and what are its trade offs.
> [Laravel]'s the greatest web framework to ever exists
Back when I worked with PHP, we used Symfony and several coworkers very much looked down on Laravel. Symfony was modular and you could easily switch whichever component for your own by just implementing the interface and overriding the dependency injection thing. Word was that Laravel hardcoded many things and was less customisable.
What is your take on this? In what way is Laravel superior to Symfony?
This is the big reason I use Symfony for most of my projects.
I do lots of refactoring and modernizing of legacy or non-scalable codebases as a freelancer; with Symfony you can replace it module by module and slowly implement the Symfony framework structure.
Through some configs, it can do dependency injection, event listener stuff, etc, but the framework is mostly glue around components.
With Laravel, you need to go "all-in", and you had to do things the Laravel way. If I strayed from that path, it would make things really difficult.
I still work on projects with either of the frameworks, but if I had a choice, it would almost always be Symfony.
Laravel is great for prototyping and fast building. If you want to make a big application with Laravel, it's better to use Symfony-like approach with interfaces and DI (you can do it by using Laravel).
What I personally do not like in Laravel is their ORM, too much magic calls involved.
I think that people believe they'll switch out components more than they really end up doing, but in Laravel, you can override things within Service Providers, and then use the built-in dependency injection to get the thing you want.
I don't know about that. I have been looking at Rails 7 and there's a lot things in Rails now I like better than Laravel.
Symfony did most of the heavy lifting with getting PHP relevant again, Laravel was just better at marketing. Laravel is good, don't get me wrong but everyone seems to think Laravel is the only good thing in PHP and a lot of Laravel is built with Symfony libraries.
I'm rebuilding an old online community / forum in the TALL stack. It's awesome. I do have to do a lot of raw sql query building to keep it performant though.
- Laravel has many "admin libraries" (Voyager, Orchid, Filament, Twill, Backpack, ...), some of them open core, each with their own idiosyncrasies. Symfony has EasyAdmin.
- Laravel uses Inertia for Vue.js or React integration while Symfony has an integrated solution with Symfony UX
- Symfony has become more modular with Symfony Flex
- Symfony has put a lot of effort into improving "developer experience" in the Symfony DX initiative
- Symfony has brillant docs in many languages including a new open book by Fabien Potencier and other Symfony collaborators
Looking at the Laravel site, I’m concerned about Laravel’s reliance on an ORM. Not only because ORMs are widely derided, but because I have a legacy MySQL DB and PHP 5 project I want to resurrect. I’m down to rewrite the server, but how do I restore a database full of user data with Laravel?
I work on a project like this and you'll run into some papercuts, but it's not hard.
You can take a model for anything in your legacy code, and just set properties on the model to teach Laravel how to deal with things that don't follow conventions.
For example, you can override the table name. Suppose you had a legacy table called "postdata". In Laravel, this table would be called posts, and a model would be Post.
So you'd just tell Post to query postdata rather than posts.
Likewise, you can tell it which fields to cast as dates, booleans, etc. You can tell it which fields represent timestamps for updating, creating, deleting and so forth.
You can setup relations that don't follow naming conventions the same way.
The only issue I've run into is doing things like setting up relationships across databases. You can do it, it's just not super straightforward.
I think you'll find it's a breath of fresh air to have a modern wrapper around your legacy code, and that your legacy stuff will then fit in quite nicely with your new work.
Laravel is “linked” together via a combination of Composer dependency manager and Dependency Injection. You can easily customize your setup to remove the dependency on Eloquent ORM and use something else.
What I'm doing is recreate everything the Laravel way and worry about importing the data (millions of pictures, videos and comments) later. I figured that once I'm proficient at Laravel that writing some import jobs would be relatively easy.
Were building some internal tools for customer service on Laravel's Orchid package and its the first truly RAD I've had in php that doesn't hold me back. Building interfaces is a pain and I lost touch with Javascript a decade ago, but it handles all of that for you.
Next.js is great but can't compare to Laravel, they are not for the same use case. Laravel comes with an ORM, a job queue, a mail framework... And it can also scaffold a complete auth system for you
How so? Nextjs only offers ssr and routing. Nothing else. Not even close to the full stack functionality you find in a default laravel or rails project.
Next.js is great as long as what you're building is not much more than a landing page, or you're proxying to a real backend system (by another team, etc).
Trying to build a "full stack" application with just Next.js is suiciding everyone that comes to the project after you leave.
I spent a week learning Laravel and modern PHP for a project that never materialized. I am so grateful the project never materialized, because for all the past 2 decades of improvement PHP remains a language I never want to work with. There may be some details in "A Fractal of Bad Design" that no longer apply, but the phrase itself still very much applies - PHP (and Laravel) remain a fractal of bad design.
PHP was my first language back when I was a teenager in highschool - it all started because I wanted to get some data from users and store it (I just knew basic HTML and CSS back then), when a friend mentioned he used a PHP snippet to send an email from a website. That sounded like magic to me so I bought a book on PHP and my mind was blown by the possibilities.
Several websites and years later I had a pretty good understanding of backend/frontend concerns, web security, SQL and databases... although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT!
After University I then started working as a software developer doing full stack work (mostly Java & Python backends) and Angular, then React for frontend.
In many ways I prefer TypeScript + React in the frontend with a Java/Nodejs + TS GraphQl backend, but I remember the speed with which you could get a website up and running, self contained, with no CI/build/deploy issues and it was the best thing ever to learn really
I'm almost curious to see what it'd be like to build a website super professionally now with PHP, but I'm pretty sure it'd feel very similar to typed python or Java
Hey, I'm the author of the post. A while ago I made a video where I built a small but serious hobby project in PHP with Laravel. It was a five hour recording, but I condensed it into a commentated 20-minutes timelapse: https://www.youtube.com/watch?v=mmtVkDh9RGw
Which leads me to start to think if there is a way to make timelapse videos that filter out some of the too quick movements, like windows and dialogs opening ... to make you mostly see how the code grows. App idea perhaps? :)
I think the amount of front end building we do for the web nowadays is absurd. We transpile everything - JS, CSS HTML, and then we bundle them in odd ways to circumvent all kinds of issues. The way we make webpages is so disconnected from the technologies that browsers offer us.
Makes you wonder when people are going to realize that we're way past serving static pages and don't need the next big front end tool, we just need a better way to run actual applications in the browser.
> The way we make webpages is so disconnected from the technologies that browsers offer us.
Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React apps almost always leverage the capabilities of of course HTML/CSS/JS, history, AJAX/HTTP, cookies, and so on. As the JS distributions evolve, the build systems do too in terms of output.
Maybe I misunderstand something, but in general the idea that just writing vanillaJS or some analogue would be sufficient to deliver the quality of apps enabled by frameworks (and talented devs) seems a bit naive to me.
Haha we had the exact same experience. My mind was blown by PHP as a teen and I even made decent money in high school making websites - all without ever setting up a local environment.
I didn’t keep doing dev work and had a different career but changed back to development a few years ago (also mostly TS). I’ve also been curious for a while about what it’d feel like to start a new project in Lavarel instead of Next.js or Sveltekit like usual.
> although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT!
That was serverless before serverless was even a thing.
However it came with its fair share of problems. One being that to be usable on a wide range of hosting providers, applications had to be written for the least common denominator.
I started my career with PHP. Created my own apps, created client websites etc. Full of footguns, but I didn't know any better. Once I learned more languages, I never used PHP again. I actually started to feel like I'd been fooled into using PHP.
Now the small PHP community keeps trying to justify their language choice with articles like these and comments like the ones on this submission. They claim it's a no brainer to use Laravel for new apps, because it has a big ecosystem and good ergonomics, and pretend that this description somehow does not apply to hundreds of other frameworks. They claim that the article A Fractal of Bad Design (which was really cathartic to me when it came out) is out of date, but when I look, all the old footguns are still there, all the problems with the standard library are still there and stdout still writes directly to the browser. The foundations are rotten.
Go ahead and use it, I don't care, but stop trying to convince me to use it.
And now the downvotes begin. PHP devs hate dissent it seems.
I don't wish to be the bearer of bad news, but nobody is trying to convince you to use it: nobody cares what you're using for software development... and you're working with out of date information if you think that A Fractal of Bad Design is relevant any more. PHP has evolved a great deal over the last decade, as have the people using it and as has the ecosystem.
Personally, as my username might hint, I've been using PHP for a long time, and, as I've commented on HN before, I would not choose PHP if I was building an engineering organisation from the ground up, and I do not use PHP professionally at the moment, but I absolutely choose to use PHP for my own projects and can enthusiastically say it's a great language in 2023.
If you're not willing to try out modern PHP, that's fine, but ranting and raving about PHP based on your experience more than a decade ago is not relevant any more, given this is a post about the improvements made in the last decade. Many people with experience beyond PHP think PHP is a great language today.
> They claim that the article A Fractal of Bad Design (which was really cathartic to me when it came out) is out of date, but when I look, all the old footguns are still there, all the problems with the standard library are still there and stdout still writes directly to the browser.
So dramatic. No one cares what you use, and I suspect you could just not read articles about PHP and voila your problems would go away. Choose your own destiny!
You have to ask yourself why such a large proportion of work gets done in two objectively bad languages, PHP and Javascript. They dominate the space. I think it tells us that it's not actually that important to have a 100% perfect language, when it comes to building stuff.
tbf, TypeScript has taken over a huge part of the JS ecosystem, and while doing so has fixed lots of common "meme" gripes with the language. It has also introduced new issues, but alas, the web is typesafe.
Learning PHP though is exactly as the article describes. I had to do it in college and even using a modern version of PHP, the language felt as if it had been written by 3 first semester students under pressure to meet a deadline.
> You have to ask yourself why such a large proportion of work gets done in two objectively bad languages
I did ask myself that, and I came to the same conclusion as the author of "Fractals of bad design": The majority of work gets done by amateurs and amateurs, per definition, don't know any better.
> And now the downvotes begin. PHP devs hate dissent it seems.
I mean, write stupid comments win stupid prizes?
> Now the small PHP community keeps trying to justify their language choice with articles like these
How would you expect people to react when you frame it like that. I assume you're one of those people that think you have good opinions, but wonder why others don't want to hang around and hear them.
I don't get how people can say that. WP is almost ~50% of all websites. PHP is ~80% of the websites. There is a whopping 30% in between.
And moving WP to a 'modern' language (whatever that modern means) is not something possible. ~60,000 plugins, similar number of themes, 30% of all ecommerce websites, billions of dollars of businesses with dependencies ride on it.
> Right now, WordPress only has beta support for PHP 8.0. Now, to be clear: PHP 8.0 was released in 2020, and is now end of life, three years later — and WordPress doesn't yet support it…
There are dozens of alternatives better than WordPress, if upgrading it meant a complete tooling change I think many would take the opportunity to replatform to something else. The only thing WP really has over them is it's expansive plugin library, and buy in from clients.
But it's not really up to devs. I don't think many devs believe it's the best system, but it is desired by clients very often.
You probably dont make content sites. The reason PHP is still relevant today is because no other language has CMSes as good as those from PHP. And i dont mean WP or Drupal.
Craft, Kirby, Twill, October, Grav, Statamic, Bolt, Processwire…
All of those projects have big active ecosystems around them and are used for serious projects. Most other languages dont have a single CMS. There is no CMS in Go or Elixir. Javascript have some but they are super immature and mostly hype. Python has some super ugly ones based around Django.
Now people may look down on these PHP cmses but many web projects like ecommerce grow as extensions of CMS. And most of these CMSes are suited to this because they are nice web framework with customizable admin area. So it often doesnt make sense not use PHP.
Out of curiosity, what language are you using for backend now?
Not a fan of PHP like most of professional PHP devs, I guess but the utility of Laravel for example is unbeatable IMO.
It’s funny because when I think of “fractal of bad design”, Javascript is the first thing that comes to mind. I love Javascript but it makes me ask “why?” a lot.
PHP is kind of the same league, a lot of hate comes because some senior employee told a bunch of juniors after years of working in Wordpress that PHP is a garbage language and you should not touch it. "It's cool to hate PHP!"
PHP can make absolute garbage, and it can make a elegant product. Just like Javascript can. And same with Python and Ruby and what ever else everyone recommends.
It may be a lot harder to make garbage in Rust, but it's possible. PHP has a problem where it gets out of your way, gives you the entire toolbox to build a house. But the problem is which one of the 17 types of hammers do I use to hammer in one of the 104 different types of nails. Where as Ruby, gives you 3 hammers and 4 different nails, and 7 magic nails that appear after you're done hammering.
Many of the statements in that article were misleading or outdated already in 2012, though. E.g. the part about PHP being tied to Apache… At that time I had been using php-fpm behind nginx for years.
I didn’t go back to all the points, but I get the feeling the configuration and security parts are mostly fixed, while the functions related issues and type looseness stayed mostly the same.
What really struck me was the statement: "In total, $580,000 was raised in 2022
The Foundation pays 6 developers to work on PHP" which made me realise how easy it is to take for granted the development and maintenance of these open-source languages and ecosystem as a whole.
Say what you will about PHP, but we all rest on the shoulders of the incalculable effort that goes into the software we use everyday without thinking twice, and is something I'm very grateful for.
Similarly, cURL has been maintained by Daniel Stenberg for nearly 30 years. Billions of installs, every major tech company probably uses it... labor of love.
Absolutely, writing modern PHP with Laravel as a framework makes the whole language feel totally different compared to just even a few years ago. I do also really like the statelessness of how PHP is ran.
At the day job we are using it to serve tens of millions of API's a day, without having any issues concerning stability and/or scalability.
The video from that site (also https://youtu.be/x9bSUo6TGgY at youtube) is really quite well done. I wish more language comparisons were done in this way, with two speedy minutes in an editor accompanied by taut voiceover. Very impresssive!
I used to work way back in the day on PHP too, but even though I'm sure this will be downvoted, it's really sad people still take it seriously as a language in 2023. There's nothing remotely elegant about it. It's not expressive or programmatically succinct in the way Ruby is. It's not beautifully well thought-out the way Python is. It's not fast and modern in the way Rust is. It's not elegant or composable or client-side renderable in the way React.*script is. It just brings nothing to the table. It's an ugly hodgepodge borne out of an over-engineered homepage from 28 years ago. Various business interests have kept it afloat, and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
This is your issue - PHP < 5.3 is very different to PHP 7+. Not just at the language level - but the community, frameworks and best practices too. No more random scattering of SQL statements in HTML files!
Modern PHP (with a framework like Laravel or Symfony) is probably one of the most productive ways to build web applications.
> It's not beautifully well thought-out the way Python is.
This is definitely an interesting take... Python hasn't even solved package management yet. And the 2.7 => 3 migration is probably the most famous example of making a mess of an ecosystem with backwards incompatible changes. In contrast PHP has Composer and 5.3 code is pretty much compatible with 8.0 (although ideally all code from the 5.3 era should be burned at the stake).
> and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
You've basically just said that PHP devs are too inexperienced to be able to scale a codebase past 10k LOC? Pretty much every serious web dev using Symfony/Laravel would disagree with you.
Sure, there's been a lot of progress since the PHP 5 days, but the core of the language has been left mostly untouched by design, and we haven't seen the kind of drastic moves like JS moving to ES6 syntax.
It's a matter of taste, so there's no absolutr truth. I hate PHP's function and property access syntax differenciation and wildly prefer ruby's approach or instance. And there's so much more nice things coming in languages that have been designed from the ground up to be nice to use.
I understand PHP's pragmatism, but can't find it pleasant to use TBH.
PS: we got arrow functions, but they stay limited to anonymous functions for instance...
> No more random scattering of SQL statements in HTML files!
And yet you will still find this, because the long-tail of bad PHP is near infinite.
> although ideally all code from the 5.3 era should be burned at the stake
I guarantee you that a decent amount of real PHP coding right now is maintaining legacy stuff, not the new fangled 8.
It is, of course, the same in the Java world - most of the day job is not using Java 17. It's just that Java 6 code forced onto Java 8 isn't as bad as PHP 4 code hacked into PHP 5 code still struggling along in PHP 9. (Especially because as a scripting language, it will more likely fail at runtime, not build-time).
Sorry to be dismissive, but elegance, expressiveness or succinctness are not mandatory for "making things". Gatekeeping a programming language on esthetics is quite shallow in my opinion.
Ease of use and deployment, breadth, availability, low cost of maintaining, are sometimes more important, and PHP offers plenty of value in these respects.
I don't want to work with it, but I will never presume to look down on people that do. PHP has been a cornerstone for a whole generation of programmers and I think the current web-development ecosystem would not be where it is without it.
It doesn't matter what happens, anytime something good PHP is mentioned the thread always turns into a fight. Why can't we just stop gate keeping programming languages and let people enjoy them. PHP gets tore apart all year long, and 1 nice article comes out and everyone jumps on it like it's preaching Delphi or VBA.
PHP has continued to done wonders for me, I continue to write huge apps in it, I continue to love it. I've used every other language you wrote, and continue to this day to write in PHP. Not because I'm not able to grasp how good another language is. But because it works. If I need something I go to packagist and search, it's always there. If I need to deploy something, there is tons of ways, and even basic ones. I don't need no fancy deployment setup, but I can have a fancy deployment setup if I want.
But people are more then welcome to hate it, and every time a positive post comes out about PHP I will continue to post my statement and then carry on building stuff. As there is ALWAYS a negative comment.
Everyone's at a different step in their journey. But I do agree if you're building stuff then exactly, who cares? End of the day it's definitely about what's built, not how.
I’ve made a few “serious” projects with PHP and has been great, I never feel like I’m fighting against it to do what I need to do, the code can be very concise, its very fast and has a lot of batteries builtin.
Python is not beautifully well thought out, the syntax is awful and the version conflicts make it a mess.
You’re comparing to React which is not a language or in the same domain is confusing and makes me doubt your credibility.
React isn't a language, it's an elegant pattern layered on top of (Java|Type)script which are languages. Not sure what versioning conflicts there are with Python but there are a lot of community solutions in the form of pyenv, virtualenv, etc. Python is well thought-out, imho, but I think it can take a certain type of person time to realize it. I used to hate it but the way I ultimately came around to understanding it was someone explained to me it's essentially extremely close to pseudo-code, which I think is ultimately why it can seem very natural and why so many universities and the larger STEM/ML community have all adopted it.
Someone who worked with Python / Django and JAVA / Spring for years professionally, I see PHP / Laravel as absolute superior way to build web apps, especially if you are in a team and people might come and go.
> and people who don't know any better keep championing it
Experienced developers understand that there are different tools for different jobs. They also understand that languages are not successful for 30 years without providing some legitimate value.
I think that PHP isn't that bad for some use cases. What I really disliked about PHP as a developer was how much control the host has over tweaking the runtime; this can be"problematic" in some shared hosting setups.
However, I'm also a bit of a hypocrite here because I worked for a hosting company, and also loved that feature.
So, I think in the context of something like a container (or vps/dedicated) it can work well.
I think PHP gets a lot of hate because it used to be a nightmare. I know friends who still use it, and they claim it's a day and night experience from the olden days. It probably wouldn't be my first choice for a project, but I probably wouldn't groan either, if I had to reach for it now
I agree with all of those points, except that it does have one thing going for it - it is easy for end-users to deploy PHP apps: FTP your files onto any random cheapo shared web-host, done.
I’m amazed that it’s been so long and no other language comes close to that :(
Re-deploy, sure. Deploy? PHP packages still need installing, modules need enabling/configuring, PHP version needs to be chosen, etc. Unless it's a tiny project, the days of "just put the files on FTP" are almost gone.
Meanwhile for small, low traffic projects, serverless services are pretty close to the "just copy to deploy" model. And fly.io is all trivial for quite a few frameworks.
Compared to moat languages, if you have no visitors, php takes up 0 system resources from your system to just sit there and wait.
So you could have hundreds of small sites on the same machine for an extremely low resource cost. That is something it brings to the table and its very beneficial for hosting solutions where there are a lot of small webaites sharing on the same resource.
I might be misinterpreting "taken seriously" with utility, but to me it is very valuable that a PHP script can just be dropped on almost any web server and it can start doing stuff, and that alone is reason enough not to not dismiss it.
I used to agree with this and think of it as a main benefit, but setting up a server to use Nodejs is easy and a lot of servers come prepped with node, npm, etc, so it's just as easy ad starting up a PHP project, if not easier because package.json can easily install dependencies.
Kinda, you have to make sure all the extensions you need are installed, then fix php.ini so it's not doing anything wrong, and then it usually works if you haven't missed anything, until something becomes deprecated.
It's more productive as Ruby and Python and much faster than either? Is that not reason enough for some to choose it? I'd argue that of the PHP, Python, and Ruby it is Ruby that should die. It's the same use case as Python, but harder to read and just as slow.
PHP had design flaws (many of which have been addressed since the 5.x days), but what language doesn’t?
A significant cause of it’s bad rap is touched on briefly in this article, Wordpress.
Even back in 5.3 days, you could write elegant and scaleable code, it just took work to do. At a former employer using PHP 5.3 on 2005 era hardware, we could do 500+ req/sec per machine with an average response time under 100ms and a P99 response time of under 250ms, with a zero downtime SLA and hundreds of millions of requests per day. Yeah, it wasn’t easy, but it worked.
As a dear friend used to say, PHP is a ball of nails. You throw it and it sticks. Just exercise care when picking it up and all is well.
> we should show this comment to facebook that uses hack (php originated lang) in millions of files to run their little website and infrastructure.
Appeal to authority isn't a valid strategy.
Facebook used PHP because they wanted to build something really quickly and afterwards it became too costly to switch, as it always does, so they built an entire engineering department to work around PHP issues.
Your average PHP dev team can't do that.
Plus, what are you comparing it to? Reasonable people don't compare it to Vlang, they compare it to Python, Ruby, Java, C#/.NET, Javascript/Typescript, Golang, and PHP ranks at best averagely against those regarding language, standard library and ecosystem consistency.
The language is valuable and a good choice because it’s easy to read and your codebase Be(when used with a framework) are very maintainable. We have Java Perl and python and php has been the easiest to get people working on existing code.
I loved the straightforwardness of just having a nice simple HTML page with some <?PHP ?> sprinkled in. Now everything has to be done through a million layers of indirection. Which is fine when it's necessary, but I still like to write my own pages as simple unstructured PHP.
Readit News
The ecosystem around Laravel is really incredible and unlike any other framework. They have libraries for every stage of a web application from taking payments all the way down to server management and hosting.
They even have awesome libraries like Inertia which are built for Laravel but can be used with other frameworks.
It's the only reason I still stay fresh on my PHP.
The documentation is an almost perfect blend of examples and nitty gritty detail. The documentation is almost engaging if you’re coming from other frameworks.
I found myself thinking “wow that’s almost no code, what about this feature or that” and the next section would be the exact topic I was wondering about. Had a blast and could learn more php details as I went
Everything in Laravel is as obscured, "magical" and opinionated as possible for the sake of making the code "beautiful" (again, at a glance) to the detriment of basically everything else. I really have no idea how any experienced programmer can look at it and think it's usable for anything beyond the most simple project.
The mere fact that models are PHP classes but none of their properties that exist in the database are actually declared as properties in the class because the ORM just "magically" puts them there at runtime should be enough to drive away any sane person. And let's not forget the amazing "Facades" a.k.a. glorified global variables filled with magic methods that you're expected to make extensive use of.
Facades are not global glorified variables with magic methods. Usually they're just a way to instantiate and access a class with less code. People complain that facades limit testability. In fact, they're easily mocked. Etc.
The docs do a very good job of explaining how things work and how you can override any "magic" you may not like. If something is doing something you didn't expect, you probably didn't read the docs. In fact, a delight of working with Laravel is it's so intuitive that you can often guess how to achieve something and be right.
Have you worked with Laravel in practice?
Each of the facades comes with a corresponding dependency injection if you prefer. You can write an entire Laravel app without ever touching a facade.
At some point you have to accept the foundation you have as something that works, it's battle proven, and it's built by experienced and reliable developers and you build on top of the shoulders of giants. Reinventing everything from scratch so that you understand it makes you the only one that understands it.
There was a famous phrase by Arthur C. Clarke that I think applies here along the lines of "Any sufficient advanced technology is indistinguishable from magic".
For example, you don't need to use the ORM at all and can just use their query builder (which is pretty good). It's there if you want it, but the framework works happily without it and doesn't get in your way in that regard.
I inherited a Laravel codebase from a previous contractor and it was reasonably ergonomic to navigate and extend, because I was able to lean on the framework documentation to understand how it all worked. But there were several points where it was _not_ reasonable, because of Laravel/PHP magic and those were pretty painful to figure out and debug.
The reason I wouldn't choose it myself anymore is the magic, the little surprises and hard to debug idiosyncrasies that it provides in order to look pretty. Also generally Laravel, PHP and related ecosystems are moving too fast and are difficult to keep up to date without breaking and/or misunderstanding things. It's not quite JS/npm level of churn, but unnecessary regardless. A more minor point is the baseline performance tends to be on the lower end of what I need.
There are ecosystems out there that value stability and clarity more and provide better tools to test and debug the code if necessary, and I've come to appreciate those things much more with experience than other factors such as reducing the initial development time.
Back when I worked with PHP, we used Symfony and several coworkers very much looked down on Laravel. Symfony was modular and you could easily switch whichever component for your own by just implementing the interface and overriding the dependency injection thing. Word was that Laravel hardcoded many things and was less customisable.
What is your take on this? In what way is Laravel superior to Symfony?
I do lots of refactoring and modernizing of legacy or non-scalable codebases as a freelancer; with Symfony you can replace it module by module and slowly implement the Symfony framework structure.
Through some configs, it can do dependency injection, event listener stuff, etc, but the framework is mostly glue around components.
With Laravel, you need to go "all-in", and you had to do things the Laravel way. If I strayed from that path, it would make things really difficult.
I still work on projects with either of the frameworks, but if I had a choice, it would almost always be Symfony.
I don't know about that. I have been looking at Rails 7 and there's a lot things in Rails now I like better than Laravel.
Symfony did most of the heavy lifting with getting PHP relevant again, Laravel was just better at marketing. Laravel is good, don't get me wrong but everyone seems to think Laravel is the only good thing in PHP and a lot of Laravel is built with Symfony libraries.
- Laravel uses Inertia for Vue.js or React integration while Symfony has an integrated solution with Symfony UX
- Symfony has become more modular with Symfony Flex
- Symfony has put a lot of effort into improving "developer experience" in the Symfony DX initiative
- Symfony has brillant docs in many languages including a new open book by Fabien Potencier and other Symfony collaborators
Take a look at Symfony before Laravel. It will be very similar to Java developers who are familiar with Spring.
You can take a model for anything in your legacy code, and just set properties on the model to teach Laravel how to deal with things that don't follow conventions.
For example, you can override the table name. Suppose you had a legacy table called "postdata". In Laravel, this table would be called posts, and a model would be Post.
So you'd just tell Post to query postdata rather than posts.
Likewise, you can tell it which fields to cast as dates, booleans, etc. You can tell it which fields represent timestamps for updating, creating, deleting and so forth.
You can setup relations that don't follow naming conventions the same way.
The only issue I've run into is doing things like setting up relationships across databases. You can do it, it's just not super straightforward.
I think you'll find it's a breath of fresh air to have a modern wrapper around your legacy code, and that your legacy stuff will then fit in quite nicely with your new work.
Highly recommend
Trying to build a "full stack" application with just Next.js is suiciding everyone that comes to the project after you leave.
Several websites and years later I had a pretty good understanding of backend/frontend concerns, web security, SQL and databases... although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT!
After University I then started working as a software developer doing full stack work (mostly Java & Python backends) and Angular, then React for frontend.
In many ways I prefer TypeScript + React in the frontend with a Java/Nodejs + TS GraphQl backend, but I remember the speed with which you could get a website up and running, self contained, with no CI/build/deploy issues and it was the best thing ever to learn really
I'm almost curious to see what it'd be like to build a website super professionally now with PHP, but I'm pretty sure it'd feel very similar to typed python or Java
If you don't have the time to watch it, you can also check out the open source code of that project: https://github.com/brendt/aggregate.stitcher.io
I still work on it, and I'd say i's a pretty accurate representation of a standard Laravel application.
I miss those days.
I think the amount of front end building we do for the web nowadays is absurd. We transpile everything - JS, CSS HTML, and then we bundle them in odd ways to circumvent all kinds of issues. The way we make webpages is so disconnected from the technologies that browsers offer us.
Makes you wonder when people are going to realize that we're way past serving static pages and don't need the next big front end tool, we just need a better way to run actual applications in the browser.
That's not going to happen. It's been tried, and it's almost always proprietary.
So it isn't really adopted.
WASM might be "it", but in that case, you're still compiling/building stuff :-)
Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React apps almost always leverage the capabilities of of course HTML/CSS/JS, history, AJAX/HTTP, cookies, and so on. As the JS distributions evolve, the build systems do too in terms of output.
Maybe I misunderstand something, but in general the idea that just writing vanillaJS or some analogue would be sufficient to deliver the quality of apps enabled by frameworks (and talented devs) seems a bit naive to me.
I didn’t keep doing dev work and had a different career but changed back to development a few years ago (also mostly TS). I’ve also been curious for a while about what it’d feel like to start a new project in Lavarel instead of Next.js or Sveltekit like usual.
That was serverless before serverless was even a thing.
However it came with its fair share of problems. One being that to be usable on a wide range of hosting providers, applications had to be written for the least common denominator.
Now the small PHP community keeps trying to justify their language choice with articles like these and comments like the ones on this submission. They claim it's a no brainer to use Laravel for new apps, because it has a big ecosystem and good ergonomics, and pretend that this description somehow does not apply to hundreds of other frameworks. They claim that the article A Fractal of Bad Design (which was really cathartic to me when it came out) is out of date, but when I look, all the old footguns are still there, all the problems with the standard library are still there and stdout still writes directly to the browser. The foundations are rotten.
Go ahead and use it, I don't care, but stop trying to convince me to use it.
And now the downvotes begin. PHP devs hate dissent it seems.
Personally, as my username might hint, I've been using PHP for a long time, and, as I've commented on HN before, I would not choose PHP if I was building an engineering organisation from the ground up, and I do not use PHP professionally at the moment, but I absolutely choose to use PHP for my own projects and can enthusiastically say it's a great language in 2023.
If you're not willing to try out modern PHP, that's fine, but ranting and raving about PHP based on your experience more than a decade ago is not relevant any more, given this is a post about the improvements made in the last decade. Many people with experience beyond PHP think PHP is a great language today.
> They claim that the article A Fractal of Bad Design (which was really cathartic to me when it came out) is out of date, but when I look, all the old footguns are still there, all the problems with the standard library are still there and stdout still writes directly to the browser.
You have to ask yourself why such a large proportion of work gets done in two objectively bad languages, PHP and Javascript. They dominate the space. I think it tells us that it's not actually that important to have a 100% perfect language, when it comes to building stuff.
Learning PHP though is exactly as the article describes. I had to do it in college and even using a modern version of PHP, the language felt as if it had been written by 3 first semester students under pressure to meet a deadline.
> You have to ask yourself why such a large proportion of work gets done in two objectively bad languages
I did ask myself that, and I came to the same conclusion as the author of "Fractals of bad design": The majority of work gets done by amateurs and amateurs, per definition, don't know any better.
I mean, write stupid comments win stupid prizes?
> Now the small PHP community keeps trying to justify their language choice with articles like these
How would you expect people to react when you frame it like that. I assume you're one of those people that think you have good opinions, but wonder why others don't want to hang around and hear them.
If WordPress moved to a modern language tomorrow, PHP would cease to exist afterwards.
But there's also Typo3, Spryker, Magento, Drupal, Shopware, Sylius.
I won't touch Wordpress. I worked with it about 15 years ago for a few years, but didn't touch it afterwards.
And moving WP to a 'modern' language (whatever that modern means) is not something possible. ~60,000 plugins, similar number of themes, 30% of all ecommerce websites, billions of dollars of businesses with dependencies ride on it.
> Right now, WordPress only has beta support for PHP 8.0. Now, to be clear: PHP 8.0 was released in 2020, and is now end of life, three years later — and WordPress doesn't yet support it…
There are dozens of alternatives better than WordPress, if upgrading it meant a complete tooling change I think many would take the opportunity to replatform to something else. The only thing WP really has over them is it's expansive plugin library, and buy in from clients.
But it's not really up to devs. I don't think many devs believe it's the best system, but it is desired by clients very often.
Craft, Kirby, Twill, October, Grav, Statamic, Bolt, Processwire… All of those projects have big active ecosystems around them and are used for serious projects. Most other languages dont have a single CMS. There is no CMS in Go or Elixir. Javascript have some but they are super immature and mostly hype. Python has some super ugly ones based around Django.
Now people may look down on these PHP cmses but many web projects like ecommerce grow as extensions of CMS. And most of these CMSes are suited to this because they are nice web framework with customizable admin area. So it often doesnt make sense not use PHP.
Language wars are silly.
It's remarkable how the language evolved, and how many of the issues mentioned have been fixed and improved over the last ten years.
1. https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
PHP can make absolute garbage, and it can make a elegant product. Just like Javascript can. And same with Python and Ruby and what ever else everyone recommends.
It may be a lot harder to make garbage in Rust, but it's possible. PHP has a problem where it gets out of your way, gives you the entire toolbox to build a house. But the problem is which one of the 17 types of hammers do I use to hammer in one of the 104 different types of nails. Where as Ruby, gives you 3 hammers and 4 different nails, and 7 magic nails that appear after you're done hammering.
Am I missing other important parts ?
Say what you will about PHP, but we all rest on the shoulders of the incalculable effort that goes into the software we use everyday without thinking twice, and is something I'm very grateful for.
Then I had to pick up a Laravel project and - for me - Laravel alone has resuscitated PHP's reputation.
I honestly don't know if this is supposed to be a good or bad thing.
Thanks!
This is your issue - PHP < 5.3 is very different to PHP 7+. Not just at the language level - but the community, frameworks and best practices too. No more random scattering of SQL statements in HTML files!
Modern PHP (with a framework like Laravel or Symfony) is probably one of the most productive ways to build web applications.
> It's not beautifully well thought-out the way Python is.
This is definitely an interesting take... Python hasn't even solved package management yet. And the 2.7 => 3 migration is probably the most famous example of making a mess of an ecosystem with backwards incompatible changes. In contrast PHP has Composer and 5.3 code is pretty much compatible with 8.0 (although ideally all code from the 5.3 era should be burned at the stake).
> and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
You've basically just said that PHP devs are too inexperienced to be able to scale a codebase past 10k LOC? Pretty much every serious web dev using Symfony/Laravel would disagree with you.
Sure, there's been a lot of progress since the PHP 5 days, but the core of the language has been left mostly untouched by design, and we haven't seen the kind of drastic moves like JS moving to ES6 syntax.
It's a matter of taste, so there's no absolutr truth. I hate PHP's function and property access syntax differenciation and wildly prefer ruby's approach or instance. And there's so much more nice things coming in languages that have been designed from the ground up to be nice to use.
I understand PHP's pragmatism, but can't find it pleasant to use TBH.
PS: we got arrow functions, but they stay limited to anonymous functions for instance...
Deleted Comment
And yet you will still find this, because the long-tail of bad PHP is near infinite.
> although ideally all code from the 5.3 era should be burned at the stake
I guarantee you that a decent amount of real PHP coding right now is maintaining legacy stuff, not the new fangled 8.
It is, of course, the same in the Java world - most of the day job is not using Java 17. It's just that Java 6 code forced onto Java 8 isn't as bad as PHP 4 code hacked into PHP 5 code still struggling along in PHP 9. (Especially because as a scripting language, it will more likely fail at runtime, not build-time).
Ease of use and deployment, breadth, availability, low cost of maintaining, are sometimes more important, and PHP offers plenty of value in these respects.
I don't want to work with it, but I will never presume to look down on people that do. PHP has been a cornerstone for a whole generation of programmers and I think the current web-development ecosystem would not be where it is without it.
PHP has continued to done wonders for me, I continue to write huge apps in it, I continue to love it. I've used every other language you wrote, and continue to this day to write in PHP. Not because I'm not able to grasp how good another language is. But because it works. If I need something I go to packagist and search, it's always there. If I need to deploy something, there is tons of ways, and even basic ones. I don't need no fancy deployment setup, but I can have a fancy deployment setup if I want.
But people are more then welcome to hate it, and every time a positive post comes out about PHP I will continue to post my statement and then carry on building stuff. As there is ALWAYS a negative comment.
Python is not beautifully well thought out, the syntax is awful and the version conflicts make it a mess.
You’re comparing to React which is not a language or in the same domain is confusing and makes me doubt your credibility.
They both render HTML and do it in a very different way.
Experienced developers understand that there are different tools for different jobs. They also understand that languages are not successful for 30 years without providing some legitimate value.
However, I'm also a bit of a hypocrite here because I worked for a hosting company, and also loved that feature.
So, I think in the context of something like a container (or vps/dedicated) it can work well.
I think PHP gets a lot of hate because it used to be a nightmare. I know friends who still use it, and they claim it's a day and night experience from the olden days. It probably wouldn't be my first choice for a project, but I probably wouldn't groan either, if I had to reach for it now
I’m amazed that it’s been so long and no other language comes close to that :(
Meanwhile for small, low traffic projects, serverless services are pretty close to the "just copy to deploy" model. And fly.io is all trivial for quite a few frameworks.
So you could have hundreds of small sites on the same machine for an extremely low resource cost. That is something it brings to the table and its very beneficial for hosting solutions where there are a lot of small webaites sharing on the same resource.
Slagging PHP and then saying this just means you are trolling which is not exactly welcomed on HN.
php isn't bad. just got a bad rep. many langs got quirks. some more than others. but php has more web production success story and usage than most.
A significant cause of it’s bad rap is touched on briefly in this article, Wordpress.
Even back in 5.3 days, you could write elegant and scaleable code, it just took work to do. At a former employer using PHP 5.3 on 2005 era hardware, we could do 500+ req/sec per machine with an average response time under 100ms and a P99 response time of under 250ms, with a zero downtime SLA and hundreds of millions of requests per day. Yeah, it wasn’t easy, but it worked.
As a dear friend used to say, PHP is a ball of nails. You throw it and it sticks. Just exercise care when picking it up and all is well.
Appeal to authority isn't a valid strategy.
Facebook used PHP because they wanted to build something really quickly and afterwards it became too costly to switch, as it always does, so they built an entire engineering department to work around PHP issues.
Your average PHP dev team can't do that.
Plus, what are you comparing it to? Reasonable people don't compare it to Vlang, they compare it to Python, Ruby, Java, C#/.NET, Javascript/Typescript, Golang, and PHP ranks at best averagely against those regarding language, standard library and ecosystem consistency.
The documentation is also excellent.