10 ms·

PHP is probably the best language for server side webdev today. Still insanely easy to deploy, lots of features at the language level, and the frameworks that a

PHP is probably the best language for server side webdev today. Still insanely easy to deploy, lots of features at the language level, and the frameworks that are available are very sophisticated. Whether you like Laravel or not, it’s influence is spreading to other frameworks within PHP and other languages. Also, Laravel has some of the best docs in OSS, period. I think WordPress is pushing other projects forward as well. The tech stack over there doesn’t move nearly as fast, but the UX is still pretty good out of the box and with the enterprise clients I work with on a daily basis, they all still love WP. Back to PHP proper for a minute, the language is fast. There are efforts being made to run PHP on Serverless infrastructure or with continuous process environments. New features are added to the language on a regular basis as evidenced by this post and others. The defacto package manager, Composer, is also world class. It’s a good time to be a PHP dev! As a final point, I’ll throw out some of my worries. I’ve been writing PHP since 2010~ as a high schooler fooling around. The “Java-fication” of PHP is real. There is a push for more types and type related features. These aren’t bad in isolation, but as they move deeper into the core of the language, there is a risk of breaking legacy apps. Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. I’m not advocating keeping 100% compatibility forever, but recent versions have played more fast and loose with breaking changes. We’ve done a decent job of carrying the entire community onto new versions and that will be important for continued adoption. Take a look at the open RFCs for more details. I think there is value for pulling good ideas from other languages, but we don’t need every idea from every language. Here’s to another 20 years of PHP!

unfocussed_mike 5y ago
> The defacto package manager, Composer, is also world class. Composer suddenly got good, didn't it! Composer 1.x was one of my pain points I think. I can't think of many things that really bug me much anymore. Null coalescing operators and named parameters are the kinds of things that make me happy. I also adore Laravel (and particularly Lighthouse). But what I really like about PHP is the humility and maturity of the whole endeavour. It's really typified by Rasmus Lerdorf who openly critiques his own abilities and seeks out smart people.
- esistgut 5y ago
  Lighthouse is an hidden gem. I moved some projects from Node/Typescript to Laravel/Lighthouse after discovering it.
peter422 5y ago
What does a modern high performance php serving stack look like?
- PetahNZ 5y ago
  We use AWS elastic beanstalk mostly, so just auto scaling EC2 servers running nginx, RDS serverless, SQS worker queues etc. Front end is static hosted on S3/cloud front. Handles up to ~100k orders per day.
- hu3 5y ago
  Not OP but I have seen web apps with 1 million MAU (Monthly Active Users) using: - Laravel - Redis - PostgreSQL - Nginx+ php_fpm
  - unfocussed_mike 5y ago
    I am deploying considerably smaller applications but I've had good results lately with Caddy and PHP-FPM [0]. I tend to use MySQL 8 but I've made use of both Redis and Memcached where appropriate. I don't even use any of the JIT stuff, but I will soon. [0] Once I figured out how to configure Caddy, that is. (Laravel vs Caddy documentation ease of use is night-and-day territory.)
    - francislavoie 5y ago
      FWIW, a Caddy config for a Laravel app is just the following (which you can find here in the docs https://caddyserver.com/docs/caddyfile/patterns#php https://caddyserver.com/docs/caddyfile/patterns#php): example.com { root * /srv/public encode gzip php_fastcgi localhost:9000 file_server } Do you have any specific comments regarding Caddy's docs? What exactly did you find difficult? I'm a Caddy maintainer, and I'm always looking to find ways we can improve.
      - unfocussed_mike 5y ago
        (Thank you for your reply! I'm using some of that pattern. It wasn't enough for my requirements, unfortunately. What I have now works fine; I use the handle directive a fair bit and that makes sense to me. This is not a problem now) The main problem with Caddy's documentation is that it is a maze of twisty tunnels! Lots of terse fragments of documentation that bounce you on to other terse fragments of documentation. It feels fractured and impermanent. I lose my place. Part of the problem is inherent to very flexible packages like this, and it is going to be difficult to solve. I think you possibly overestimate how many people have time to learn about the JSON syntax or API configuration, how many people want Caddy outside of a package manager installation, etc. It almost seems to me that you need entire documentation guides -- "Caddy for Nginx users", "Caddy for Apache users", "Caddy for people who need an API-driven server" -- that have much more narrative flow to them. (IMO, configuration file adapters are a hiding to nothing. Just explain to me why Caddy is better and help me make the switch) I love Caddy for what it is now doing for me -- please don't get me wrong, I think it's an impressive project -- but after 28 years of configuring web servers I really need migration documentation that I can read in detail without clicking from link to link and lots of emoji people. Small observation: the mid-blue text on a pale blue background for your code examples and monospaced text is difficult to read if your eyes are over 40 years old and it's been a long day.
tmpz22 5y ago
There is so much variety in web development that to crown any language as “the best” is at best unproductive. This attitude of “what is the best” promotes cargo culting and should stop.
- unfocussed_mike 5y ago
  > This attitude of “what is the best” promotes cargo culting and should stop. The terse certainty in your response is ironic, is it not? Considering the parent post frames that as opinion with the word "probably" and then makes a case for the opinion.
  - sieabahlpark 5y ago
  - pc86 5y ago
    The truth is whatever one's personal list of "must haves" and "should haves" are for a given language, there are probably at least 2 or 3 major languages that fit the bill in a given domain, and probably more if you're willing to use stuff like Haskell or Racket or Clojure (all fine languages but compare their popularity to JS or PHP to Python). For every person who is vehemently in favor of one language over all others, it's usually pretty easy to point out another language that will get you 99% of what that other language will. So it's not a very tenable position to think one language is the be all end all. But on the flip side, and in part because of the points above, "language cargo culting is stupid and should be avoided in almost every instance" can make a great deal of sense.
chockchocschoir 5y ago
> There are efforts being made to run PHP on Serverless infrastructure This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.
- francislavoie 5y ago
  For example: https://bref.sh/ https://bref.sh/
- throw_m239339 5y ago
  > This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have. Yes, but now you have to pay for every requests made to your app instead of just paying $4 a month for a shared Apache server and I also have to architecture my PHP app in a rigid way to fit whatever "serverless" execution model the SAAS runs with.
  - francislavoie 5y ago
    Which may be much cheaper than $4/month if you have very low traffic numbers.
    - throw_m239339 5y ago
      > Which may be much cheaper than $4/month if you have very low traffic numbers. A big IF. My $4/month stay $4/month without the added complexity of "serverless" deployment nor every stupid constraints this business model imposes. If serverless actually didn't make money, this business model wouldn't exist or wouldn't be pushed, mainly by Amazon employees here.
      - jjeaff 5y ago
dehrmann 5y ago
Something I pick on with PHP is because requests are so isolated, it doesn't have a good story for pooling SQL and HTTP connections. Its model really limits you when it comes to sharing resources between requests.
- francislavoie 5y ago
  It's possible to have persistent MySQL connections, but there's all kinds of caveats; MySQL connections are stateful, so bad things can happen, and the performance benefits are only very slight. https://www.php.net/manual/en/features.persistent-connections.php https://www.php.net/manual/en/features.persistent-connection...
- Nilithus 5y ago
  This is indeed a downside but there are workarounds -- The wikimedia foundation put out a good blog post talking about getting HTTP connection pooling for PHP https://techblog.wikimedia.org/2020/10/26/impact-of-using-http-connection-pooling-for-php-applications-at-scale/ https://techblog.wikimedia.org/2020/10/26/impact-of-using-ht... TLDR they used envoy proxy as a sidecar container. So to your point its a pain but still achievable
dgb23 5y ago
> Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.
- mjrpes 5y ago
  Are you tracking warnings/deprecations in logs? Usually PHP gives ample warning time (at least one major version) before producing errors.
  - ceejayoz 5y ago
    A good test suite does wonders, too.
    - dgb23 5y ago
      The tests are there to give us confidence about _our_ code. They can help in those situations, but they don't protect us from others pulling the rug from under us.
      - pc86 5y ago
        Unless you're upgrading production before lower environments, you'll still find out exactly what you need to fix, won't you? And unless you're waiting until the last possible moment to upgrade core infrastructure I don't see how anyone is getting any rug pulled out from anywhere.
        dgb23 5y ago
        Again, seeing what will be broken is the baseline expectation. My comment is not about that. It’s about breaking changes, having to resolve them, facing incompatible versions (language, libs, tooling). You telling me you broke my code in advance doesn’t make it OK.
hermanradtke 5y ago
I spent a decade writing PHP. I think the language is fine, but the lack of a real concurrency model (event loop or threads) pushed me to other languages for web dev.
- gremlinsinc 5y ago
  Swoole a php extension has solved this mostly, and has coroutines like golang.
- PetahNZ 5y ago
  Anything that can be run concurrently, we just push off onto worker queues.
cies 5y ago
> PHP is probably the best language for server side webdev today. What are your credentials with non-PHP, non-JS/TS languages? Have you written some Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those languages are different to some extend, they take fresh approaches, they contain new ideas and are scrape throat well designed. I find most cheering for PHP and JS have very little exposure to other camps of software development. > PHP is probably the best language for server side webdev today. I'm telling you (opinion ahead), it most likely is not. And most likely will never be. It simply has too many fundamental design errors that have long known solutions, are near impossible to fix in PHP/JS and are fixed-by-design in other languages that also have good tooling for web-dev. This is not just PHP/JS. But since we are looking at "the best lang for webdev" I limit myself the these and this use case.
- mmcnl 5y ago
  Why do you treat PHP and JS as similar languages? They're worlds apart, have different purposes and have almost nothing in common.
  - cies 5y ago
    > Why do you treat PHP and JS as similar languages? They're worlds apart, have different purposes and have almost nothing in common. Because (1) both very often used in webdev, (2) both have many "adherents" that totally love the language yet have little exposure to languages of different paradigms, (3) are (opinion alert) not very well designed. I'm aware of the differences between JS and PHP.
    - nkozyra 5y ago
      A fairly useful addendum to your list might be 4) both have grown up into completely ok languages. If you, like me and many others, shrugged them both of for years and came back to them pleasantly surprised, it might change the timbre when reading that. I'm not sure I agree that it's the best but it's got some things going for it: - incredibly fast to deploy and iterate - supported in some fashion on more hosting solutions than other languages or compiled binaries - one of the best performing interpreted languages Not all of these benefits apply to me so I don't use PHP but under the right circumstances I'd look at it again.
Cyberdog 5y ago
> I think WordPress is pushing other projects forward as well. If anything, it's holding PHP back. I don't often work with WordPress projects, but when I have to, it makes me want to cry with how backwards they are. WordPress doesn't even have a real routing system! Furthermore, its ecosystem just seems to encourage really, really bad things, like user-editable templates, PHP code "snippets" stored in the database, images which should be in themes stored as post attachments instead, and just general lack of respect for the idea of separating code and content. Almost every "plug-in" or template is crippled and begging for license fees and/or throwing spammy "notifications" all over the admin interface. I know this sort of stuff are more culture issues than code ones, but they're still problems, and ones you only really see happening in WordPress sites. I get angry when a client comes to me with a bundle of WordPress mess and asks me to fix or improve something. It's shameful and disrespectful to take a client's money and give them a WordPress site in return. Do these people actually not realize there's far better things out there?
- exodust 5y ago
  > It's shameful and disrespectful to take a client's money and give them a WordPress site in return If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that? I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time. It's better to have 10 code snippets to achieve 10 fixes, than 10 plugins to address those same fixes. There must be a lot of developers out there paying their rent and feeding the cat from Wordpress plugin subscription earnings. While this does encourage the spammy ecosystem, it also encourages competition between plugin authors to maintain and develop quality plugins that do the job. > Do these people actually not realize there's far better things out there? I'd be interested to hear what good replacements there are for Wordpress+WooCommerce? I find WooCommerce slows down Wordpress, regardless of caching plugins and other tricks. It's annoying, and I'm genuinely interested in alternatives with as much flexibility and support?
  - technobabbler 5y ago
    Shopify?
nanochad 5y ago

unfocussed_mike 5y ago

> The defacto package manager, Composer, is also world class. Composer suddenly got good, didn't it! Composer 1.x was one of my pain points I think. I can't think of many things that really bug me much anymore. Null coalescing operators and named parameters are the kinds of things that make me happy. I also adore Laravel (and particularly Lighthouse). But what I really like about PHP is the humility and maturity of the whole endeavour. It's really typified by Rasmus Lerdorf who openly critiques his own abilities and seeks out smart people.

esistgut 5y ago
Lighthouse is an hidden gem. I moved some projects from Node/Typescript to Laravel/Lighthouse after discovering it.

peter422 5y ago

What does a modern high performance php serving stack look like?

PetahNZ 5y ago
We use AWS elastic beanstalk mostly, so just auto scaling EC2 servers running nginx, RDS serverless, SQS worker queues etc. Front end is static hosted on S3/cloud front. Handles up to ~100k orders per day.
hu3 5y ago
Not OP but I have seen web apps with 1 million MAU (Monthly Active Users) using: - Laravel - Redis - PostgreSQL - Nginx+ php_fpm
- unfocussed_mike 5y ago
  I am deploying considerably smaller applications but I've had good results lately with Caddy and PHP-FPM [0]. I tend to use MySQL 8 but I've made use of both Redis and Memcached where appropriate. I don't even use any of the JIT stuff, but I will soon. [0] Once I figured out how to configure Caddy, that is. (Laravel vs Caddy documentation ease of use is night-and-day territory.)
  - francislavoie 5y ago
    FWIW, a Caddy config for a Laravel app is just the following (which you can find here in the docs https://caddyserver.com/docs/caddyfile/patterns#php https://caddyserver.com/docs/caddyfile/patterns#php): example.com { root * /srv/public encode gzip php_fastcgi localhost:9000 file_server } Do you have any specific comments regarding Caddy's docs? What exactly did you find difficult? I'm a Caddy maintainer, and I'm always looking to find ways we can improve.
    - unfocussed_mike 5y ago
      (Thank you for your reply! I'm using some of that pattern. It wasn't enough for my requirements, unfortunately. What I have now works fine; I use the handle directive a fair bit and that makes sense to me. This is not a problem now) The main problem with Caddy's documentation is that it is a maze of twisty tunnels! Lots of terse fragments of documentation that bounce you on to other terse fragments of documentation. It feels fractured and impermanent. I lose my place. Part of the problem is inherent to very flexible packages like this, and it is going to be difficult to solve. I think you possibly overestimate how many people have time to learn about the JSON syntax or API configuration, how many people want Caddy outside of a package manager installation, etc. It almost seems to me that you need entire documentation guides -- "Caddy for Nginx users", "Caddy for Apache users", "Caddy for people who need an API-driven server" -- that have much more narrative flow to them. (IMO, configuration file adapters are a hiding to nothing. Just explain to me why Caddy is better and help me make the switch) I love Caddy for what it is now doing for me -- please don't get me wrong, I think it's an impressive project -- but after 28 years of configuring web servers I really need migration documentation that I can read in detail without clicking from link to link and lots of emoji people. Small observation: the mid-blue text on a pale blue background for your code examples and monospaced text is difficult to read if your eyes are over 40 years old and it's been a long day.

tmpz22 5y ago

There is so much variety in web development that to crown any language as “the best” is at best unproductive. This attitude of “what is the best” promotes cargo culting and should stop.

unfocussed_mike 5y ago
> This attitude of “what is the best” promotes cargo culting and should stop. The terse certainty in your response is ironic, is it not? Considering the parent post frames that as opinion with the word "probably" and then makes a case for the opinion.
- sieabahlpark 5y ago
- pc86 5y ago
  The truth is whatever one's personal list of "must haves" and "should haves" are for a given language, there are probably at least 2 or 3 major languages that fit the bill in a given domain, and probably more if you're willing to use stuff like Haskell or Racket or Clojure (all fine languages but compare their popularity to JS or PHP to Python). For every person who is vehemently in favor of one language over all others, it's usually pretty easy to point out another language that will get you 99% of what that other language will. So it's not a very tenable position to think one language is the be all end all. But on the flip side, and in part because of the points above, "language cargo culting is stupid and should be avoided in almost every instance" can make a great deal of sense.

chockchocschoir 5y ago

> There are efforts being made to run PHP on Serverless infrastructure This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.

francislavoie 5y ago
For example: https://bref.sh/ https://bref.sh/
throw_m239339 5y ago
> This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have. Yes, but now you have to pay for every requests made to your app instead of just paying $4 a month for a shared Apache server and I also have to architecture my PHP app in a rigid way to fit whatever "serverless" execution model the SAAS runs with.
- francislavoie 5y ago
  Which may be much cheaper than $4/month if you have very low traffic numbers.
  - throw_m239339 5y ago
    > Which may be much cheaper than $4/month if you have very low traffic numbers. A big IF. My $4/month stay $4/month without the added complexity of "serverless" deployment nor every stupid constraints this business model imposes. If serverless actually didn't make money, this business model wouldn't exist or wouldn't be pushed, mainly by Amazon employees here.
    - jjeaff 5y ago

dehrmann 5y ago

Something I pick on with PHP is because requests are so isolated, it doesn't have a good story for pooling SQL and HTTP connections. Its model really limits you when it comes to sharing resources between requests.

francislavoie 5y ago
It's possible to have persistent MySQL connections, but there's all kinds of caveats; MySQL connections are stateful, so bad things can happen, and the performance benefits are only very slight. https://www.php.net/manual/en/features.persistent-connections.php https://www.php.net/manual/en/features.persistent-connection...
Nilithus 5y ago
This is indeed a downside but there are workarounds -- The wikimedia foundation put out a good blog post talking about getting HTTP connection pooling for PHP https://techblog.wikimedia.org/2020/10/26/impact-of-using-http-connection-pooling-for-php-applications-at-scale/ https://techblog.wikimedia.org/2020/10/26/impact-of-using-ht... TLDR they used envoy proxy as a sidecar container. So to your point its a pain but still achievable

dgb23 5y ago

> Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.

mjrpes 5y ago
Are you tracking warnings/deprecations in logs? Usually PHP gives ample warning time (at least one major version) before producing errors.
- ceejayoz 5y ago
  A good test suite does wonders, too.
  - dgb23 5y ago
    The tests are there to give us confidence about _our_ code. They can help in those situations, but they don't protect us from others pulling the rug from under us.
    - pc86 5y ago
      Unless you're upgrading production before lower environments, you'll still find out exactly what you need to fix, won't you? And unless you're waiting until the last possible moment to upgrade core infrastructure I don't see how anyone is getting any rug pulled out from anywhere.
      - dgb23 5y ago
        Again, seeing what will be broken is the baseline expectation. My comment is not about that. It’s about breaking changes, having to resolve them, facing incompatible versions (language, libs, tooling). You telling me you broke my code in advance doesn’t make it OK.

hermanradtke 5y ago

I spent a decade writing PHP. I think the language is fine, but the lack of a real concurrency model (event loop or threads) pushed me to other languages for web dev.

gremlinsinc 5y ago
Swoole a php extension has solved this mostly, and has coroutines like golang.
PetahNZ 5y ago
Anything that can be run concurrently, we just push off onto worker queues.

cies 5y ago

> PHP is probably the best language for server side webdev today. What are your credentials with non-PHP, non-JS/TS languages? Have you written some Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those languages are different to some extend, they take fresh approaches, they contain new ideas and are scrape throat well designed. I find most cheering for PHP and JS have very little exposure to other camps of software development. > PHP is probably the best language for server side webdev today. I'm telling you (opinion ahead), it most likely is not. And most likely will never be. It simply has too many fundamental design errors that have long known solutions, are near impossible to fix in PHP/JS and are fixed-by-design in other languages that also have good tooling for web-dev. This is not just PHP/JS. But since we are looking at "the best lang for webdev" I limit myself the these and this use case.

mmcnl 5y ago
Why do you treat PHP and JS as similar languages? They're worlds apart, have different purposes and have almost nothing in common.
- cies 5y ago
  > Why do you treat PHP and JS as similar languages? They're worlds apart, have different purposes and have almost nothing in common. Because (1) both very often used in webdev, (2) both have many "adherents" that totally love the language yet have little exposure to languages of different paradigms, (3) are (opinion alert) not very well designed. I'm aware of the differences between JS and PHP.
  - nkozyra 5y ago
    A fairly useful addendum to your list might be 4) both have grown up into completely ok languages. If you, like me and many others, shrugged them both of for years and came back to them pleasantly surprised, it might change the timbre when reading that. I'm not sure I agree that it's the best but it's got some things going for it: - incredibly fast to deploy and iterate - supported in some fashion on more hosting solutions than other languages or compiled binaries - one of the best performing interpreted languages Not all of these benefits apply to me so I don't use PHP but under the right circumstances I'd look at it again.

Cyberdog 5y ago

> I think WordPress is pushing other projects forward as well. If anything, it's holding PHP back. I don't often work with WordPress projects, but when I have to, it makes me want to cry with how backwards they are. WordPress doesn't even have a real routing system! Furthermore, its ecosystem just seems to encourage really, really bad things, like user-editable templates, PHP code "snippets" stored in the database, images which should be in themes stored as post attachments instead, and just general lack of respect for the idea of separating code and content. Almost every "plug-in" or template is crippled and begging for license fees and/or throwing spammy "notifications" all over the admin interface. I know this sort of stuff are more culture issues than code ones, but they're still problems, and ones you only really see happening in WordPress sites. I get angry when a client comes to me with a bundle of WordPress mess and asks me to fix or improve something. It's shameful and disrespectful to take a client's money and give them a WordPress site in return. Do these people actually not realize there's far better things out there?

exodust 5y ago
> It's shameful and disrespectful to take a client's money and give them a WordPress site in return If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that? I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time. It's better to have 10 code snippets to achieve 10 fixes, than 10 plugins to address those same fixes. There must be a lot of developers out there paying their rent and feeding the cat from Wordpress plugin subscription earnings. While this does encourage the spammy ecosystem, it also encourages competition between plugin authors to maintain and develop quality plugins that do the job. > Do these people actually not realize there's far better things out there? I'd be interested to hear what good replacements there are for Wordpress+WooCommerce? I find WooCommerce slows down Wordpress, regardless of caching plugins and other tricks. It's annoying, and I'm genuinely interested in alternatives with as much flexibility and support?
- technobabbler 5y ago
  Shopify?

nanochad 5y ago