My question is: why would anyone want to start something new with PHP in 2021? Is there anything that it does better than any other language/ecosystem? I feel like the community is full of (but not exclusively composed of—there are some gems like Caleb Porzio who write good stuff) people who just care about hacking something together and, as long as it works, it's fine. They care nothing about elegance and have but a dim conception of larger CS/SE principles.
For example, why would you write something in PHP when you've got an excellent choice between Ruby/Rails or Elixir/Phoenix/LiveView, both of which are fantastic, and, especially in the case of the Elixir/Phoenix stack, really developer friendly, easy to set up and deploy, etc. and also have solid foundations?
I'm glad to see PHP getting better—it will certainly improve life for those maintaining old PHP projects that are agile enough to upgrade—but I really see no reason to not choose a better tool in this day and age.
(You may now call me a troll if you see fit. I stand by what I said though. :-)
In other words, they chose a tech stack which suited them as developers, and not which suited the end users of the software.
End users love PHP because you copy the files into a folder. That's why it's so popular. That fact that you are talking about architectural "elegance" shows how removed you are from understanding the needs of the end user.
As a person involved with a PHP + MySQL open source CMS, this is the pull quote for me.
The vast majority of web hosting I've experienced in the last 20 years offers PHP + MySQL out of the box, even on the crummy, ancient end of the spectrum.
Related to this, knowing that just about any flavour of hosting can run the CMS in real terms is enough to keep the development in check so a wider audience can use it. There's not much point in us adding extra features if the minimum ride height is beyond the reach of most users.
I'm not convinced that Discourse is the right example here, though. Arguably the actual steps for installing Discourse aren't significantly more complicated than WordPress's install, because they've gone out of their way to make it as easy as possible. (It does suffer from "you must use Docker for this," which would likely intimidate non-techies who could otherwise suffer through a WP install, though.) Also, I don't think Discourse can remotely be described as an abject failure, given that virtually every forum I've seen go up in the last five or six years runs on it, and I can think of more than a few sites that migrated to it from legacy PHP forums in that time.
Two thoughts and personal observations on that:
1. Nobody was ever fired for buying IBM. In my impression it's usually deployed as default for and esp. by very tech affine communities. It was the new, hot - and is now save - thing in town.
2. You see postings boasting how the Discourse forum is now powered by a new six core 8 GB RAM server improving performance ... for 200 concurrent active users and 80k posts. Yes, Discourse offers a lot of flashy features, but that's just borderline disgusting.
I guess companies that use Discourse and have huge traffic can pay a bit more, nothing wrong with that.
The point being that said numbers aren't big traffic, they should be handled by a Raspi.
But for the sake of argument: Discourse is a painless move upwards for big budget and/or big knowledge entities. Nothing wrong with that.
On the other hand Discourse isn't a replacement for low cost, decentralized, easy to deploy, engine-diverse, low knowledge communities which were served by a multitude of PHP solutions in the past.
There's an economic argument for a growing divide between "communities as a service" ala Facebook and high hurdle deployments ala Discourse, but one doesn't have to be happy about this development.
Much like Wordpress and phpMyAdmin, these projects are basically victims of their own success.
I don't see how. The repository seems to be quite active and has plenty of current pull requests.
I don't doubt that Discourse requires more resources than most PHP forum packages do, but it doesn't need that much more.
1. Downloading the application archive and uncompressing it
2. Creating a MySQL database according to the documentation
3. Either editing a small config file to give the application the database credentials, or even just going to the application's index page and filling in the details on a first run experience
And... that's it. Rails has no comparable experience, unless -- like Discourse -- you put in a lot of work to get it there.
Laravel -- and Symfony -- work basically like other "modern" frameworks do, for both good and bad. Laravel has "Mix," built on webpack, for instance. So if you're looking for that in PHP, it's there, but that's kind of a tradeoff in the context of small sites deployed/managed by a single person -- a use case that I think modern webdevs sometimes lose sight of. If we go back to the example of forums, those are very often that "one person wants to host a forum for their community" kinds of things. (And I'd like to see more of us get back to self-hosted blogs -- which is part of what led me down the road of "can you write something in a not-PHP language that's still easy for someone who doesn't know anything about web development to deploy and run." The answer still seems to be "reply hazy; ask again later.")
As other posters have mentioned, PHP code can be as simple as uploading files to a folder on a server using a GUI FTP app. (And for some non-technical users, even that might be too complicated).
By the way, Jeff Attwood (co-founder of Stack Overflow and one of the founders of Discourse), had this to say about PHP:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option." 
When did he say this? 2012.
It's now 2021 and has anything changed? Not really. Yes, we have Docker, Cloudtron, or Sandstorm etc but none of these are simple or easy to install or use. (A developer's definition of 'simple' and 'easy' bears no relation to the real definitions of these words).
Whatever you think of PHP, consider the following question: what language can match or beat PHP for ease of server-side deployment?
I mean I started laravel on shared hosting, why did I use laravel for most of my career? Because the job I was hired for was to build a custom CRM for a book business, I was learning Rails so I spent 2 weeks on a rails prototype...
Boss gave me access to their hostgator account - shared hosting and told me to install it there. I stared blankly at them, um... okay.
Rails version I built in didn't match and I couldn't figure out for the life of me how to make it work...
Laravel 4.2 was almost a complete 1:1 match (in terms of directory structure) to rails and the language was just a bit different so porting what I had to laravel was a cinch and I had it done in 3 days and up on hostgator. No problems.
Also if you're like me and you freelance/consult, there's a TON more business in existing software/legacy than there is in new builds. Wordpress, Shopify, Laravel, Drupal, Magento, Salesforce are probably the FAANG of freelance platforms to learn to earn income from.
PHP is also generally faster than Ruby, and with Swoole it's sooo much faster (even than elixir/phoenix), so really why not use laravel/php. There's also tons of great packages out there and tutorials. The community is freaking HUGE.
Rails you even have to roll your own auth system or use devise which is a PITA. Laravel it's more opinionated but it's built for you including 2fa, social/oauth, etc..
Which isn't to say I wouldn't use fancier langs, I'm jumping at the bit to build some backend apis in rust or go for the hell of it, but only when I'm the decision maker as CEO/CTO on a side-project. For bread and butter I'll stick w/ what I know I can get paid for which is PHP/Laravel/Wordpress/Vue/Livewire/etc.
What about that one guy who made https://remoteok.io/ using a single PHP file with no frameworks or libraries?
According to this live chart https://remoteok.io/open he made $88,000 last month from it alone with a 90%+ profit margin.
But more importantly it's a site that technically functions well and looks appealing. End users really don't care about which tech stack you used to build your site, they just want it to be fast, look nice and be easy to use which is achievable with pretty much any language or framework nowadays.
Many times when I've wanted to install something for my needs, like forum engine or something similar, I was looking only for an PHP option.
Because it really is a copy-paste process with typing credentials to your database into dedicated file. No need to know any language/framework-specific commands, and no need to be overwhelmed by missing dependencies.
And in huge addition to that, simple PHP hosting is extremely cheap - for years I've been paying for my personal server ~$20 PER YEAR, where servers that enables you to use Node/Ruby etc. costs around at least $10 per month. This is a huge game changer for me.
That's certainly how people deployed web apps built by other people a decade ago, but these days isn't it more common to use something like Docker?
Deploying a containerized app should be pretty much the same no matter what language it's written in. And Discourse does have a Docker container (https://github.com/discourse/discourse_docker), so I'm not sure the underlying language explains why it isn't popular.
Don't get me wrong, as a developer I hate the bloat, but as a UX/UI PoV you can install a lot of shit that's dockerized pretty easily...
sandstorm.io is a cool way to self-host open source projects for example
Most PHP apps out there are dump easy to use. That's not the case even for Python.
Docker probably is a better way of doing things, but it’s another layer.
There's limitations and bloat involved with containers that I don't like. I'd rather just configure nginx/letsencrypt and create some bash scripts to make deployments work...
I'll often pair this with jenkins or come ci or use deployer for deployments that don't tear down the old until the new is green, and keeps a few snapshots, but personally I don't like docker much, even my dev environment uses nginx and no docker.
Anyway regarding deploying, these days Go is available. It's probably the easiest one to deploy, just copy the binary to the server.
- you have already a dev team that are good PHP developers, it is stupid to switch to Python or Ruby , you lose their experience and any chance of reusing existing PHp code you have. The dev team probably knows JS so node might be an option.
- maybe you want to build something super simple, like some third party needs to send you a notification event and you want to record that event with other third party API. You can do this with one PHP file , one a super cheap hosting , with code that is simple and clear.
IMO all the dynamic backed languages are at the same level, so if you are experienced in PHP environment there is not enough compelling reason to erase this advantage to start from scratch with Python, Ruby or node.
This. PHP is basically Functions-as-a-Service over commoditized virtual hosting. Maybe we need a toolchain that can transpile down to PHP, starting from more common languages with better development workflow.
What languages have better development workflow? I'm myself biased towards repl-driven development with Clojure, but for example Rust's or Go's development workflow is a lot worse than PHP.
PHP: write file to disk, reload webpage/run curl
Rust/Go: write file to disk, compile file, run binary, reload webpage/run curl
The popularity of PHP is not hard to understand when it comes to ease of development.
unless you want to check your pure JSON api itself... but why arent you writing a test making sure of your behaviour there? its literally both less effort and assures you of the correct behaviour in the future as well.
I beg to differ.
- Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.
- You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.
- Different servers (apache, nginx, etc) give you yet another thing to configure.
From my very old past experience, PHP development gives you more headaches than Go.
Seems you just know more Go than PHP, which is fine of course. No language has "more runtime errors" than other languages, just developers of varying skill-levels in that particular platform
> - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.
And you don't get errors when assets you use in your Go program is missing? Only difference is that PHP compiles when you hit the webpage, instead of a separate step, so you'll get the error when trying to load the page, not when running "go build".
> - Different servers (apache, nginx, etc) give you yet another thing to configure.
Just like in Go, you don't have to use a separate server in order to develop. Just fire up the PHP development server that PHP ships with.
A type system reduces the risk of runtime errors, because it doesn't let you write code with undefined behaviour such as indexing a null. Depending on the implementation, it can even force you to handle all possible failures explicitly so that execution always completes. With languages such as rust or Haskell it's feasible to write complex code with almost complete confidence it won't hit any runtime errors, excluding resource exhaustion or machine failure of course.
On the other hand you could argue that logic errors depend on the skill of the programmer and not the language.
I'd add generics to that list, but Go doesn't have them either, so not really a point for discussion.
With type hints you can eliminate a lot of runtime errors these days.
When using Composer, specify the extensions and the PHP language level you need in "composer.json", and it will barf during deployment at the composer install stage.
The only thing Composer can't check is configuration parameters (e.g. max execution time, memory limit).
Not much anymore, at least Debian and Ubuntu integrate all three major web servers (apache, nginx, lighttpd) pretty much out of the box.
I would say node or if we need to use a static language would be Java. And the choice is not about the language but about the entire ecosystem(libraries, tools, developers, documentation)
Using type hints and a good IDE there are not many type related issue slipping in the code.
With PHP you have more moving parts, Apache/Nginx with their configuration and then the PHP script. With golang/rust/python/nodejs you have direct access to the webserver and more control, but the same simplicity.
From my limited node experience I had to setup Nginx too and then connect it with node, and setup some manager like "pm" to keep the things running.
When people say PHP is simple to setup they mean the customer buys some web hosting, and then puts the files there (at most you setup the db credentails and table names ). The customer will not need to hire a sys-admin that will have to use latest docker stuff or try to fix the issue that your customers runs RedHat but the developer wants to use X npm package but X needs some new npm and node version and now the sysadmin needs to make it somehow work.
I am not saying PHP is superior, if you are expert in Java, .Net, Python etc continue using that if it makes sense, in reverse if you (your team) are PHP experts then it is a waste to not exploit that experience. You might say that you should fire the good PHP developers that worked for you for years and take a chance on finding some CoolLang experts, from my experience is not easy to find good developers(in all dimensions not only good at reciting best practices), developers that you know that will not leave after 1 year because they want to work on new shit, developers that like to do their job for the end product , for the customer satisfaction and not just like to code because the language is cool, the framework is popular, the IDE colors are shiny and for the CV. If you have a good developer or team , use it.
Also PM is just a simple hypervisor, it doesn't have any logic, while Apache and Nginx do.
My point was that I already have a cheap webhosting, with a domain and email and I can now just login into cpanel and paste a script.
As a developer as other mentioned there are ways to run stuff from CLI, so IMO PHP is pretty equal with python or ruby , not sure there is a general clear winer so it always depends on the project and the team.
But if you are a new dev and you don't know any of the languages I would say start with Python, even if I prefer the C syntax. I got into PHP indirectly, I worked on desktop applications and I was asked to help with a web project so I learned it by doing (but I was already experienced so I did know what are some good practices), in the end desktop applications are no longer popular so I am still working on SPAs
if you want a quick script up and running
That's much more complicated with virtually every other language.
I mean, this has been going for decades, I didn't think it was up for debate. There's close to zero sysadmin skills required for dealing with PHP hostings, most of them have CPanel or something similar, most of them are very cheap, and there are plenty.
There's nothing similar for Python or any other language.
And 98726354 packages that get pulled when you `npm i express`
Is it a better language with better workflow? Maybe. But I do know there are people using it in just this way.
- Why would anyone want to start something new with Ruby?
- Why would anyone want to start something new with Elixir?
Answering the question seriously (assuming this is not trolling) here are some reasons to start something new with PHP in 2021:
1. Learning PHP 8 and a popular framework like Laravel will make easier to get a job on some small and medium companies. In the last job I had in a consulting firm, customers were asking for more Laravel developers to the point they accepted outsourcing because there was not enough talented Laravel developers in the US to cover the demand. There are thousands of bad PHP and Laravel developers, but there is not enough supply of good ones, so if you are talented and follow best practices, choosing PHP will make you shine between all those average developers.
2. I probably won't develop anything new with PHP 8 this year, but there are a lot of existing libraries and frameworks (Laravel and Symfony for example) that will benefit from implementing the new features of the language (reducing mess or making code more concise and readable). For the end user of those libraries and frameworks, very little will change since the interfaces don't change too much in order to allow backwards compatibility, so the existing ecosystem is a great reason to use PHP.
It has a very mature web dev ecosystem around Rails. It: is quick-to-learn, is OO to the bone, is FP where is fits with the OO, is easy to read, has little quirks.
Personally I'd go with something with stronger types, no "null" and proper sum types. But if you are cool with dynamic typing: Ruby is a great choice.
Ruby-like syntax (some advantages just mentioned) and BEAM runtime. Yields very scalable apps.
As as a comparison: who'd start an app in Perl these days? Or COBOL?
At some point a language may be considered "legacy".
Exactly same applies to PHP - without FP part but in exchange one is getting enormous, gargantuan ecosystem of libraries, developers, hosting, language oriented and designed to rapidly deliver result and easiest deployments out there.
Todays PHP is good, may be not trendy and hip right now, elitists may snark a bit but it's good language to deliver products.
You may call people categorizing PHP as legacy "elitist", but big shops that use a lot of PHP are heavily investing in other tech (yes I look at FB).
> it's good language to deliver products.
Never said it was not. But it is not, anno 2021, a good language to start a new project in. Not as bad as Perl and COBOL, but still legacy.
It seems you have identified a lot with that language, and I see this often. Usually this happens to people who have little experience with other languages. The defend it like it is their home.
My take on this topic comes from extremely pragmatic and focused on results angle: delivering product. Not sure what about 2 sentences I wrote allows you to make broad assumptions about my experience, I don't feel need or desire do describe it here but it's not only my own opinion 
I think that Reddit "lolcontent" could be not good metric to use when deciding what should be used for building software.
That you defend PHP like it is your home. We can deliver a product in Perl, but it's a bad choice these days. Unless... someone is reaaaaly well acquainted with Perl and little else.
Hence I suspect that's whats going on here. As I've seen this happen many times before, also outside of programming.
> allows you to make broad assumptions
I voiced my suspicion based on your defensiveness. That's all.
- The community is full of people who just care about hacking something together.
- Ruby/Elixir are fantastic, developer friendly, and have solid foundations.
The first happens with every popular scripting platform. Is JS community full of PhDs?
The second is highly subjective. Ruby is problematic, because it's supported by one framework which is showing its age, and the language itself has lagged behind in performance, which matters increasingly for web workloads. Elixir is a niche dialect of a niche language (Erlang). Don't get me wrong, Erlang is amazing. But you don't need Erlang to set-up a blog.
It seems the major reason going against PHP are:
- WordPress and the entire ecosystem around it sucks. Well, sure, but PHP has more frameworks with big mindshare like Symfony. It's not a "Ruby on Rails" situation.
- The meme about hating PHP is big. Everyone loves to hate PHP and Basic. Even when Visual Basic .NET evolved to be basically no different than C#, the meme of hating it lived on. Same with PHP.
The thing with memes is they're not rational. So fighting them with rational arguments is pointless. If peer approval matters to you, then code PHP in secret or don't code in it. If shipping projects matters more, PHP is a pretty good option for most websites.
During coffee time banter, sure, but in real performance related issues, what we face came down to query optimizing, cache management, algorithmic issues and data pre-processing.
We didn’t even hit the “let’s write this in C” moment nor debated about moving parts of the code to faster systems/libraries. I’m not saying it will never ever happen, just that ruby’s sheer speed doesn’t seem to have a practical impact other than slightly higher hosting cost perhaps.
What's left? The slightly unwieldy syntax (still C-like, so close enough), and the bad reputation driven by memes.
There is no specific flaw that is a roadblock, just a ton of things you know you shouldn’t do, cases you need to guard against, and base functions we effectively banned from our codebase. I still like PHP, and just moved for unrelated reasons, but I think that’s a specificity of the language (as a side effect, good PHP devs also easily become good JS devs in my experience)
PHP 7/8 have a lot more typings, it's still optional but you can require your code to use strict typings, and you can use a static analyzer like psalm to basically recommend best practices, add a few tests and your code is pretty damn solid and passes most "smell" tests and generally won't break often or as often as something in python, ruby, go.
Mix in swoole and you went from 200 reqs/sec to 6k which is about 2k more than elixir, so really just about every issue php ever had is basically replaced by just more "mature" architecture.
If you know advanced php, and the new features/best practices etc and use good tooling then php is an awesome language.
Nitpick: Elixir is not a dialect of Erlang. It doesn't even compile to Erlang, but directly to the BEAM bytecode.
Erlang and Elixir are very different languages. Think of it as Java and Groovy. Erlang is old, battle-tested, explicit and verbose to a fault (which stops being a fault when you try to maintain a decade+ old code) and is used mainly for writing large systems with very specific requirements. Elixir is younger, tries to be less verbose, adds magic completely absent from Erlang, and is intended to be used more like a traditional scripting language in addition to also covering the Erlang use case.
VB.NET is worst language on VB family, because it's totally degraded weird version of C#. I don't say VB6/VBS/VBA is cool, but it had some advantages compared to other languages.
Well, on Twitter the other day, I asked, only partly tongue-in-cheek:
> Even in 2021, any new server-side web app with even a vain hope of being installed by people who are tech savvy but not modern web nerds should probably still be written in PHP. True or false?
The "false" responses cited things like "it doesn’t matter what you write it in as long as it runs cleanly in a Docker container" and "Node is widespread enough I think it goes beyond 'modern web nerd' at this point," and they might be right -- but I'm not certain they are.
So, I guess I'd suggest that maybe the answer to your first question ("why start something new with PHP in 2021") doesn't actually depend on getting an unqualified "yes" answer to your second question ("is there anything it does better"). If I was starting a project that I wanted to have installed by the kinds of people who will not use the word "deploy" instead of "install," if you take my meaning, then I'd at least seriously entertain whether it should be in PHP.
Now, for the kinds of projects I think get talked about on HN (e.g., actual paid jobs), this is more of a fair question. I appreciate Laravel and Symfony, but PHP in 2021 has traded the feeling of being a cargo cult version of Perl for the feeling of being a cargo cult version of Java. If I do write a new project in PHP, it's probably not going to be with any existing framework, because even the lightest one feels like endless mazes of "get a Request object from a RequestFactory by instantiating a dependency injection container and passing it to a RequestFactoryFactory".
As a Symfony dev I agree. And the process to convert PHP into a Java-esqe Kotlin-esque language is continuing. Why not use a different language if you like it rather than change PHP?
> If I do write a new project in PHP, it's probably not going to be with any existing framework, because even the lightest one feels like endless mazes of "get a Request object from a RequestFactory by instantiating a dependency injection container and passing it to a RequestFactoryFactory".
I'll be interested to hear what you come up with. Two anecdotes:
1. I had to touch some PHP code I wrote many years ago based on the ColdFusion "Fusebox" architecture. It's missing some nice abstractions but unlike Symfony et al there was so little code I could understand what every line did within minutes. Parts of Symfony's internals are still magic to me (complicated by compiler passes).
2. I was asked to look at replacing a decade-old internal PHP app, the kind people look down on built using jQuery UI AJAX-powered datagrids and raw PHP. There were multiple problems like SQL injection but the app responded incredibly fast. I had to warn them that the replacement would feel slower unless they drastically increased the hosting, because a modern, engineered framework would've only finished booting up by the time this one was returning data.
My observation is also that PHP is growing too much in language size. Depending on one's viewpoint, this can be seen as either matching the feature and syntax bloat of other languages, or taming the language to make it "saner".
You can do everything from a one-file hacked together shell scripts (which I love to do because bash is just plain annoying sometimes, especially for stuff that has to work on OS X and Linux with their not-so-small differences in coreutils) to enterprise-style architected software in Symfony or Laravel.
The audacity of PHP 5.3 developers. How dared they!
The audacity of PHP 5.4 developers. How dared they!
The audacity of PHP 5.5 developers. How dared they!
The audacity of PHP 5.6 developers. How dared they!
The audacity of PHP 7.0 developers. How dared they!
The audacity of PHP 7.1 developers. How dared they!
The audacity of PHP 7.2 developers. How dared they!
The audacity of PHP 7.3 developers. How dared they!
The audacity of PHP 7.4 developers. How dared they!
The audacity of PHP 8.0 developers. How dared they!
The audacity of PHP 8.1 developers. How dared they!
(sorry, couldn't help. this particular argument is sooooo silly...)
I don't disagree in principal, but I'm struggling to think of much that isn't totally optional. For example, you can still completely ignore the type system.
There have been some BC breaks lately, but it's mostly around footguns that should never have been like that in the first place.
Comet to the rescue: https://github.com/gotzmann/comet
Same reason as any, familiarity. Not all people, even in software, enjoy learning new stuff.
PHP might be the only language they ever learned and it has paid their bills for over a decade. No point in learning anything new unless it's absolutely required.
As long as major pieces of software are written in PHP, those people will have a steady job.
I was a PHP developer for over 15 years and those three concepts do more to lower the barrier to entry than any other language I’ve come across, and are constantly underestimated in their power to enable developers to concentrate on the business logic of their program.
Trying to get a python/ruby framework working in the same env, without root access? Whoooo boy. 20 years in the business and I still refuse to do that crap. FastCGI and the like just never work properly the first time in shared hosting.
You need virtual environments to keep dependencies at bay, debugging is a pain if the web server and fcgi process don't communicate properly. Most likely you won't have access to error.log so good luck figuring out why everything returns HTTP 500.
While you're still figuring out how to get helloworld.py to respond, the dude with PHP is already done.
It encompasses every aspect: familiarity, usability, low learning curve, low time to market, enablement, and, eventually, greater margins.
That one is not great, unlike first two points. For one, larger bespoke programms need CI (and would benefit from CD). There is linting/type checking/testing to be done.
Secondly, "copy files deploy" is cheating. Somebody else did the job (hoster) and we are claiming that it is somehow benefit of PHP itself. Well? Did hoster do nothing? Really nothing at all? Nope.
On top of that. Performant set up for PHP nowadays do not look that much differently then say, setup for Python.
Two first points are very good. Shared nothing architecture preclude existence of subtle bugs. While multi-threading in mutable, imperative code is the definition of subtle bugs.
Those two keep PHP relevant and even on top of it's game (in certain domains).
This entire industry wouldn't exist if PHP wasn't so easy to deploy and if there weren't great open source projects such as Wordpress and Magento particularly targeted at that way of working.
It's not just "easy deployment", that's underselling PHP. It's "enabling an entire industry to exist" and also "letting small businesses pick a middle ground between hiring super expensive professional programmers or being limited to what Wix/Shopify have out of the box".
Wix and Shopify and Webflow and so on are getting better and more powerful, but I'm convinced it's going to take a long time before they replaced PHP in powering the majority of the web.
I agree with a sibling comment that Discourse could well have joined the ranks of WordPress and Magento by now, if only they'd chosen the right language.
While this is obviously location dependent, over the last year or so I've had dozens of calls from recruiters asking me to come work on PHP (mostly Symfony and Laravel) applications, and telling me they just can't find competent senior and lead devs.
I chose PHP for my recent startup -- despite being less experienced with PHP. The speed of development in Laravel is insane, because most of the framework is focused on making the common features of web apps more convenient. Coupled with static analysis tools and IDE helpers, all of the Laravel magic is actually understood by your IDE (PHPStorm). I've worked with Python and NodeJS for most of my career, and I've never seen this level of dev tooling. My newest project was in Laravel. I was able to ship the whole thing in half of the time it would've taken me in Django or some NodeJS framework, simply because the Laravel "magic" around databases, forms, CRUD, IDE helpers, ORM and scheduling and task queues is so fantastic.
With C++, absolutely. With Elixir/Phoenix? I never have to debug low-level issues. I also don’t have to waste time debugging stupid scope stuff and dumb data structure inconsistencies that PHP is full of.
> “magic” around databases, forms, CRUD, … scheduling and task queues…
“The bill comes due…” As long as you’ve got a small scope, sure, that might work. Maintenance on magic gets harder though. If the magic is what you need, you might want to take a closer look at the Phoenix system. Ecto’s DSL is just as easy as an ORM in the simple case, but is far more composable and robust in the complex cases. For simple jobs, you can just leverage the BEAM for task scheduling—I needed a little task run every 5 minutes; all it took was a dozen lines of simple code—no Redis needed! Just as “magic” feeling, but better architected and maintainable in the long-run.
>I would say that Laravel is an extremely high quality framework (on par with and even in some ways better than Rails) that nobody should be ashamed to use.
And add to that PHP both a language and its VM get way more improvement than Ruby.
Recently backed. Backed in the sense as investment into it. Ruby and Rails now finally have capital behind it for investment. Ruby JIT being worked on specifically designed for Rails from Shopify, running on Master with better QA etc. But they are comparatively recent.
Most of these improvement will take time. PHP on the other hadn't are already seeing those improvement today. And they were work that has been going on for past 4 - 5 years. So in that sense it is improving faster.
He asked why it's better, not the same as.
1. Even though I haven't used it in a while it is super simple to get in to.
2. They did not pay me to learn new stuff. They did not need a fancy web framework. They don't care about code elegance.
3. They already had a web site hosted on server with PHP.
4. Development environment is easy to setup locally (just download a portable PHP dev env and run). Everything is built in.
5. Passing it on to them, it's just a few text files to upload that they can easily modify as needed. Nothing to compile.
In short, it's just the simplest way to do it sometimes (KISS). And not all projects are big enough to justify more complex solutions.
might seem like trolling, but from what I've seen, Laravel encourages bad developer practices such as static code etc, while Symfony encourages good OOP practices. so Laravel in itself is attracting specific audience with different priorities than Symfony, so it may explain your main complaint about PHP code which cannot be treated as same. I mean Laravel is written in PHP but it does not mean that same code practices are used in other frameworks/projects.
I think it easily saves you 6 months of development time if you want to build a web app or a website beyond a static page. The ecosystem is very stable and reliable. So why not?
I encourage you to watch some of the introduction videos that they produce to show their ecosystem. That's how we were convinced to start investigating it. We spent a couple of weeks to make everyone productive with it. We had to catch up with all PHP7+ features and read Laravel docs. I think we will still build a lot with Java and Golang, but not for WEB. I don't see a better alternative for building web apps or front-end projects.
We don't however mention it in our portfolio or even on our job listing. It's apparently not cool for a publicly traded enterprise to say that we also use PHP.
I do PHP/Symfony and Elixir/Phoenix and really it's more nuanced than that.
Really if I don't need things that are suited for the BEAM/Elixir/Phoenix I'll probably be more productive with PHP/Symfony, especially for CRUD: the strict type system is better, the templating is better, the framework includes way more functionalities, the static analysis is better, PhpStorm with the Symfony plugin is amazing, even the docs are better.
But yeah, the app will probably be slower (but probably less than you think nowadays) and coding will be less fun ;)
What can you make in X language than I can't make in PHP? And vice versa?
Don't get me wrong, I fully support the "select the right tool for the job", there are obviously better languages and frameworks for different kind of tasks, but let's just consider the context in what PHP is usually used in.
I get that people dislike a syntax. I loathe Python, basically because indentation actually controls how and whether your software works and I can't use indentation for organizing the readability of my code.
But that doesn't mean that I would ever argue against the use of Python; again - what can you make in Python that I can't make in PHP? And the other way around still.
inb4 "But PHP doesn't do async" - [fibers](https://wiki.php.net/rfc/fibers) is a start on that journey. We've managed so far.
My Rails friends all recommend against using Rails for any new projects. I never bothered to get the laundry list, as that is enough to convince me not to learn a new language.
I wouldn't use Go or any language that requires compilation.
I don't know anyone who uses Elixir, which is enough to keep me away. I worked with Cold Fusion and with Erlang in the past. When I got stuck, finding someone to help me was not fun (with CF I even paid for consulting) and existing libraries were few and incomplete. (Although I enjoyed Erlang as a language).
For me, PHP is a go-to language for new projects, and it has become quick enough, stable enough, and complete enough to hit the check boxes I need.
You can make a simple website on PHP in ~30 lines of code (routing + boilerplate template) with nothing more than a text editor. It will have no dependencies beyond standard PHP modules, so you could then migrate this website to hundreds of cheap shared hosting providers just by copying files via FTP or SCP. It will run fast even on server with crap hardware. There is nothing remotely similar in any other language. All other solutions are less portable, require way more configuration and more infrastructure on the dev side.
~15 years ago I made a website for a certain community using PHP. I still maintain it. On my own time, on my own dime. It doesn't cost much, thanks to properties I described above. So it's still operational. Think about that next time you talk about "maintainability" and "stability".
I'd love to have the same ergonomics of deployment with other languages. You can make it work. Jetty + Apache Velocity, for example, can "feel" similar to PHP. But there are no hundreds of providers who will manage this for you with little to no configuration.
"people who just care about hacking something together and, as long as it works, it's fine."
If you need to hack something fast, deploy it using SCP on a cheap hosting then PHP is a very reasonable choice. The only thing which is needed is Apache PHP module enabled. No need to think about ports, starting some additional server, doing proxies, etc.
Registration form? In PHP you just need to open a file, add <? tag, 5 lines and you call database, another 5 to send email with SMTP server and you are done. No need for application generators, templates engines, DB abstraction layers. Fancy functional programing language not needed, basic knowledge of some C-like language suffice to hack something fast.
Obviously such application will have maintenance issues, etc. but very often this just does not matter.
Both PHP and the success of Web applications are inextricably tied to each other. It's easy to pick up and easy to run. Others commenters have already expanded on these advantages.
PHP has treated the Web as a first citizen before anything else for the longest time. It sits on the crossroads of I/O over HTTP(S) and it's really good at what it does. The massive amounts PHP frameworks are testament to that.
Even so, moving away from that vantage point, the story shifts quickly. The rise of the Web doesn't just imply managing / processing HTTP(S) I/O - building a simple web interface, a simple REST/JSON API,... - it also means managing the complexity of data management. Data migrations, transformations, juggling processing jobs, tying API's together,... are the bane of many a PHP developer.
Many a PHP framework provide API's to do background processing via PHP scripts you run on the command line. There are plenty of PHP libraries out there to make things easier as well.
Thing is, languages like Go or Elixir run circles around PHP when it comes to things like concurrency, multi-threading and robustness. Python's idiomatic approach to data munging makes it more suitable then PHP to deal with complex textual as well as binary datasets.
PHP absolutely has it place for several classes of business problems. But definitely not for everything. Having spend a decade in PHP consultancy, I've witnessed several client projects suffer heavy delays or fall through because an entire business domain got shoehorned in PHP, and - worse - in specific PHP frameworks that bring their own additional layers of complex abstraction.
The latter is not a fault exclusive to PHP or developers who solely specialize in writing PHP, or even a specific PHP framework. Rather, it's caused by complex biases and social dynamics that tend to lead towards a narrow-minded tool-centric approach of complex business challenges.
Just like a hammer, PHP is a tool with a limited set of use cases. Just like any language.
The argument is that PHP's strengths are its workflow, its state, and how you work with concurrency. i.e. PHP's execution model (per-request) allows for things like not having to worry about restarting the server when you're developing the files. The complete lack of shared state between requests means you don't get complex footguns.
Elegance and CS/SE principles don't usually have a business case.
Given a choice between PHP and Python for a web-service, there's no practical real-world difference between the two, except that it's slightly cheaper and faster to get your PHP service up.
The question is why would anyone NOT want to use php in 2021 for non desktop developments?
I also prefer pure php, with no frameworks. I think it's best to build your own tool that suits you.
We started one of our biggest projects on PHP 5.6 and Symfony 2.x years ago. The maintenance process and the upgrades were absolutely painless. If you're disciplined, you can probably do this with most of the languages, but we constantly were able to upgrade, so that we are running on PHP 8 now and the latest Symfony version. Of course we had to pull certain parts that started to be too big out of the app, some are now node, some are Symfony, some Java, but the core is running on the latest versions and the evolution of the language and the performance improvements that we had with the upgrades over 9 years are incredible.
Does that leave a PHP community comprised of only people who adhere to solid CS/SE principles? No, but that doesn't diminish the fact that PHP still has a lot going for it. It's easy to get started. You can adhere to solid CS/SE principles with little effort if you have the discipline to do so. It's trivially easy to deploy a PHP application. The documentation is still fantastic.
the ecosystem is very much complete. There is nothing that has not been done and tested in php.
Plenty of developers know php and if you have done C#/Java/C++ etc its super easy to learn.
Its easy to setup and well documented and the LAMP/LEMP stack is battle tested and people know it well.
There is great Editor/IDE support with plenty of options to choose from.
You can run it on any kind of developer-os and do you development there then just deploy it to a linux server. Altho docker solves this now with any lang its still nice if you dont want to use solutions like this. I have devs developing on windows, linux and mac with no issues getting the whole development stack running and then deploy the app on linux with no issue. This has been a challange in ruby on rails last time i tired it (back in 2010).
The laravel framework is great.
If I need static typing, I drop in TypeScript.
The performance is also crazy good for a "mere scripting language". If you need more perfomance than JS has to offer, there is only C, C++, and Rust left.
Back in the days I used PHP for those exact reasons. It was simple, fast enough, and supported everywhere. Sadly, that isn't the case anymore.
I guess it depends how you define "flexible". The language itself is clunkier, particularly anything involving closures (although that's getting better), but it does so, so much stuff out of the box (even if the APIs are often a bit footgun-y).
That means that you've missed the train of modern PHP and frameworks completely. It's not fair to compare old school PHP with modern lang like TypeScript
It has the lowest barrier to entry, both as a developer, and a user - as far as I can tell no other language has even tried to compete in this area :(
Because that is how people get things done.
Example. With Elixir/Phoenix/LiveView I will give you a simple task. Provision a phone number on Twilio. Please see this image:
What would you end up doing? I would bet wasting a ton of time or hacking something up with curl. With PHP/python/ruby I would be done in 10 minutes.
Probably the code would not be that much different, or at least not more complicated to write.
You would also not use curl anyway with Elixir, it has http clients like other languages you know, for example Httpoison.
Every time there is a PHP news update these kind of posts come out. They claim some vague experience in PHP and then go on to list all these other wonderful languages you could be using instead and that insinuate you must be a bit of a shit developer to be using PHP.
Unfortunately this troll has been well fed.
Because yeah, I'm using a programming language to CREATE something ... not to, you know ... use a programming language.
Moreover, it's also obvious from these kinds of posts that their authors have never thought about the business context at all, otherwise they would have realized that hiring PHP devs is hard enough ... but hiring [insert fancy new language] or even [python/ruby] is next to impossible without spending way, way too much money.
That is so far off my experience, and I don't mean "php=wordpress therefore you can find loads of devs". I mean that finding good people who can hit the ground running and not be a net drag on a project - in any tech - is, imo, very hard these days, and has been for probably the last 2-3 years at least. Basing mostly on regional network and chatter in user groups, but it definitely seems to have gotten worse recently.
"easier to hire good devs in X" doesn't seem like the best metric decide on (but maybe it is?)
So if you are devshop doing lot of CMS development and start doing webapps/apis then something like Laravel makes lot of sense.
So much documentation everywhere. So many helpful resources.
I've tried to learn Rails back in the days (ie 7 years ago) and was shocked by how poor the entire documentation is. I subscribed to Railscast but it hasn't been maintained for years.
The PHP ecosystem, however, is incredibly alive.
- You know how to use it (syntax, what it can do etc.)
- You've learned its ecosystem, package management, standards
- You can achieve results using PHP and complete projects while adhering to deadlines
Ruby doesn't offer anything substantial that would justify the switch. I'm all for developers honing their skills, but business does not exist to cater to developer's whims. Business exists to provide value to clients and put food on employee's table. Being nitpicky about the language and doing language swap is very expensive, especially when you swap language A with language B and gain literally nothing. For smaller businesses or one man shows, it's trivial to start a new project and use a different language.
I've seen fair share of superficial analysis and loud comments made by people who are not engineers, judging by their behavior. Like any language, PHP can be misused; and often is misused. It became a rite of passage to belittle PHP. Reading or hearing comments that attack certain technology without objective reasons merely means the person doing it is toxic and should be avoided in general. I dislike plenty of things in PHP / Python / Golang, but I would never dream of whining about it; instead, I try to reach out to maintainers and make suggestions to help make improvements.
Having written a few things, here's why you PHP is still appealing (this does not mean other languages cannot do this):
- it's sufficiently fast for CRUD-y applications. Bottleneck is usually I/O, but scaling horizontally is not an issue anymore, therefore performance doesn't have to be an issue.
- it's feature rich, type system received massive improvements and continues to improve
- it has more than 1 framework to choose from (Symfony, Laravel, CodeIgniter, Phalcon, Aphiria, Yii, Zend Framework and the list goes on)
- there's an async framework available, called swoole. It's an extension to PHP written in C++ and it brings async capabilities to the play. It's sufficiently quick and allows for building different types of applications: like web socket server or communication-oriented servers.
- new Foreign Functions Interface allows for experienced / polyglot developers to extend their apps in an easier manner opposed to writing extensions in C
With technologies like containerization, it became trivial to distribute PHP applications and avoid long setup times and reading the manuals on how to make something work. Not everyone use those technologies, but it's what's available and end result can be that you distribute a container image, which for all intents and purposes, means that you deal with a single "file" (thought I want to get across is that app distribution can be made extremely simple).
Question that poses itself is this: what reason is there to move away from PHP? Personal preference - I understand it, and this is what pushed me to try other languages and technologies out.
If you've got substantial performance, mature ecosystem, plenty of libraries, plenty of frameworks to choose from, great language features, async capabilities and ability to use the language for things other than CRUD-y applications - why use a different language that will ultimately merely let you do the same?
PHP used to be light years ahead in this since it is internet native language. With anything else you have a lot of moving parts that need to be aligned in a specific way to make it work, in PHP the default state is ready to go.
How do you deploy your new code to your LAMP server? You put it in a folder. No need for package managers, no need for any other kind of tooling. You even don't need any frameworks beyond your original product requirements.
If it's local server, you drag and drop the file you just typed in the code using your file manager. If it's a remote server you use your favourite FTP app.
If your idea turns out to be worth its salt you can pay an army of engineers to re-implement it in an elegant way.