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?

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?

None. I just finished up such a contract myself earlier this month. I was speaking of building new sites from scratch.

> I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time.

Put code in code files, under version control. Not in the database. Not in a blob field that gets eval()ed and is editable by users. This is sane web dev 101.

> I'd be interested to hear what good replacements there are for Wordpress+WooCommerce?

Drupal 7 + Drupal Commerce was very nice back in the day. I don't know the current state of Commerce under Drupal 9 but it's what I'd start looking at first if someone wanted me to build them a store from the ground up. Magento is still around, though I've heard that its code is incomprehensible. And if you're not afraid to take the thin framework or frameworkless route, the Omnipay library [1] combined with standard CRUD for the products should get you pretty far.

1: https://omnipay.thephpleague.com

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.

I understand you have invested time in other languages, we all have but lets focus on facts not fears of your choice of language seeming less popular.

Please read my comment again. I'm not saying Haskell is the best lang for webdev. I'm just saying that claiming "PHP is probably the best language for server side webdev today" is missing a lot of innovation that is very usable for webdev, and hint at bubble think.

The "best language for server side webdev today" is going to be a matter of taste either way. But when one's saying it is PHP, I immediately wonder what other languages the person has done webdev in: since PHP is not a very nice language IMHO.

> I understand you have invested time in other languages, we all have but lets focus on facts not fears of your choice of language seeming less popular.

So what are the facts that make PHP the best for webdev? I dont think it is often picked for greenfield project by highly skilled teams, when given the choice to pick any language they like. And that would be a fact I'd respect in this context.

When someone brings up haskell as a best choice for server side web development as a replacement for php it makes me think this person is either very new or trying virtual signal that they are smarter and more skilled because they use a more difficult powerful language. That's like saying building a laser from a kit to cut your bread is better than using a knife. Nevermind the cost, time, safety, availability of parts and employee market for each skill would clearly point to a knife as the best tool. Very few companies still in business build a laser when they need a knife.

For example, if you never programmed in any of statically-typed languages, you cannot say if they are better or worse. Similar things go for OOP-oriented stuff, or immutable-by-default languages or languages with well-designed stdlib, etc...

You may still think that PHP is the best language after trying a few other, wildly different ones, and that's fine. But unfortunately, in my experience, a lot of people who really advertise PHP (and some other languages like Pascal), haven't really tried the alternatives.

Who is saying that? I've read through this thread and I have not read anything to that effect.

> Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure?

OCaml is an excellent language depending on what you are intending to do. I can't imagine though that it would be a pleasant generic server side.

From a very quick search, it looks like to even connect to Postgres you'd have to manage yourself the connection pools ? https://medium.com/@bobbypriambodo/interfacing-ocaml-and-pos...

The same would apply to most languages on your list, except perhaps Clojure who has an excellent ecosystem thanks to the JVM. But then, is Clojure a good webdev language ? maybe ? I only toyed with it for a very short time, but I don't see it on par with PHP or ruby for instance.

comes to mind for OCaml.

https://github.com/paurkedal/ocaml-caqti

for db code.

Ocaml? Elm? Clojure? Haskell?. That's fun for side projects, not for real business.

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.

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.

Counter examples:

https://www.reddit.com/r/lolphp/ (this language is soooo weird there is a community documenting its weirdness)

https://www.destroyallsoftware.com/talks/wat (lovely talk about JS's weirdness)

I dont like the fundamental weirdness of these langs. I like predicatble langs. Unpredictable langs will never be "completely ok languages" to me.

PHP was quite fairly maligned for a long time. The issue was never "weirdness" but rather poor design. Starting with final 5.x they started turning it around and deprecating or fixing a lot of the worst bits.

JavaScript was a joke but modern js is tight, clean and generally very fast.

To me all weirdness IS poor design.

> JavaScript was a joke but modern js is tight, clean and generally very fast.

Fast it sure is, for an interpreted language.

On "clean and tight" I beg to differ. I find it an unholy mess: the language, the stdlib and the ecosystem.

Weirdness is subjective. If you look at lisp for the first time coming from other languages it will be weird.

PHP had glaring issues for years, but they started to clean up the language around 7.x.

JavaScript was effectively a toy but grew up in a hurry when Node pushed ecmascript forward and into a well paced release pattern.

JS isn't per se. You can use it for OOP, but it's only a subset of what you can do with it (I'd argue there is enough traps that it's better used with other paradigms than OOP). I also don't see ES6 as very related to C syntax anymore.

To your point, PHP and JS could be close in spirit, pushing forward the good parts while letting the bad parts rot on the side, and heavily relying on programmers' discipline to build clean code. Good PHP devs tend to be good JS devs as well.

I love Clojure, it’s so well designed. Haskell is hard to beat in terms of academic type correctness. But what if I’m trying to build a web app and my priorities were, ease of hiring and productivity, especially for junior devs, and a big ecosystem. Does Clojure win here against PHP? That’s a much harder argument to make. Would anyone say Rust is a better web development language than PHP?

All these tools have trade-offs. PHP is a fantastic choice for web development, the rough edges are becoming increasingly minimal with each successive version.

I'd rather hire someone that knows what they are doing and give them tools to maximize the scale of their strengths.

2 good devs working in elixir, rails or clojure will accomplish far more than 10 juniors working in javascript or go.

Strong typing helps me trust code is of certain quality.

Nah, I like to get shit done and make buckets of money.

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.

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.

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.

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.

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.

For most projects, that $4 server is great and what I would prefer. But where serverless can excel is an application that has very spikey usage.

If your $4 server gets hit with spikes of usage that would require a $500 server for an hour once or twice a month, you might be better off with serverless, rather than paying $500/month to have a server that big all the time.

You have your app, and database, and then your logging, tracing, and tracking stack and It all starts adding up pretty quickly.

Choosing serverless would be a bad game theory strategy choice.

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.

After some arguing with the company that is payed to manage their IT environment she got them to finally update the php version and now the server is running 8.1.

I was glad that at least wp was up to date. Current wp running on quite old php version and exactly nothing broke with the update.

I was positively surprised. Would have expected more problems from my experience with other projects in other languages.

We all know the tech is out of date at its core, but I don’t think it’s fair when people say they’re holding PHP back when there is an active effort to keep things compatible.

In general, the WordPress community is _slow_ and plugin authors and users definitely do not keep up at the same pace at the rest of the community using more modern frameworks. They tend to have written worse code in general, which are proportionately more impacted by deprecations and error promotions where the code wasn't using best practices.

The PHP internals maintainers hear complaints from people in the WordPress space saying "whoa you're making too many breaking changes too fast, I can't keep up", meanwhile having the developers of modern frameworks getting impatient, wanting all the new features to save them time in writing new code.

If PHP didn't have all these legacy projects still in use, deprecations/strictness changes could move at a faster pace.

I'm not saying there aren't good reasons for _some_ of the changes, including historical error prone baggage. I'm also not in any way try to disrespect the maintainers. But to say PHP is a stable language and ecosystem still does not reflect my experience with it.

You telling me you broke my code in advance doesn’t make it OK.

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

All performance issues we have ever encountered were always related to the database - never had an issue with PHP or Laravel.

However, we use Node.js for websockets. Though there are some improvements in PHP for event-driven development (like ReactPHP [1]), it was quite hard to find proper documentation and help to build a production-ready WebSocket server. So, we ended up using Node.js for that.

The new features added to PHP in the latest versions are great. Type hinting and return types are really helpful in writing better code. I hope there will be an addition to type hint advanced data structures (ex: Arrays of Objects) in a future version.

[1] https://reactphp.org/

https://hacklang.org

Internal framework PHP monolith, nginx, Aurora MySQL, redis, Memcache, internally developed message queue, handful of small Go microservices.

While we're largely hosted on AWS, some countries require us not to be, namely China, where are product lives on servers run by the government. We've kept are infrastructure non-AWS compatible.

For our US installation, monolith scales up to 50+ servers during the day and down to a minimum of 2 at night.

In total I think it’s something on the order of ~1000 application servers (nginx/PHP) that are specced to handle 28 concurrents, and 200 Percona instances of varying sizes. A big HAProxy cluster sits in front of the whole thing and cloud flare in front of that.

A whole bunch of memcached servers spread around too. By far the biggest bottleneck is the MySQL servers at the moment, so we rely heavily on memcached to keep requests away from the DBs.

- Laravel

- Redis

- PostgreSQL

- Nginx+ php_fpm

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.)

    example.com {
        root * /srv/public
        encode gzip
        php_fastcgi localhost:9000
        file_server
    }

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.

What I struggled with most in setting up things with caddy was the context for a config statement.

I could usually find the config parameters I needed, but I had no idea at what level of nesting it was and in what context it was used.

I would have found it incredibly useful to have a reference caddyfile for every parameter so I could see it used in context and then just strip that reference file down to what I need and go from there.

In the end, I just went back to nginx and dealt with Let's Encrypt myself since that was what I was most comfortable with and decided learning this new thing wasn't worth the benefit at that moment for the specific project. I'll probably revisit it later this year.

I do want to work on improving the "Tutorials" section to make it apply to more installation methods (i.e. running in Docker requires additional setup to use the admin API, running as a service means you may need to turn off the service before playing with the tutorial, etc)

"Caddy for X users" pages are complicated to get right IMO, and I'm not sure it's worth the effort - those are also general purpose servers, and can be used an infinite amount of different ways. Comparing them is difficult and I'd argue that it's not that useful. Take for example https://statamic.com/vs/wordpress to get a sense of what I mean.

> I think you possibly overestimate how many people have time to learn about the JSON syntax or API configuration

I definitely don't; I spend a lot of my time improving and polishing the Caddyfile adapter since it's definitely the easiest way to use Caddy. The tutorials do put too strong a focus on JSON in my opinion (Matt wrote them). But on the other hand I think it's pretty important to understand that the Caddyfile _is_ an adapter to JSON and not the native config language. It's key to knowing how to debug and inspect how Caddy actually runs.

> how many people want Caddy outside of a package manager installation

I'm not sure I understand this point though, what are you trying to say here? You can definitely just download the caddy binary and run it wherever, you don't need to use a package manager. I'm not sure what this is trying to point to.

I don't mean to start a fight between friends! :-)

> But on the other hand I think it's pretty important to understand that the Caddyfile _is_ an adapter to JSON and not the native config language. It's key to knowing how to debug and inspect how Caddy actually runs.

Agreed.

> I'm not sure I understand this point though, what are you trying to say here? You can definitely just download the caddy binary and run it wherever, you don't need to use a package manager. I'm not sure what this is trying to point to.

Sorry, I mangled that with a run-on sentence, didn't I! What I mean is, I think more users are likely to want the package manager, systemd-configuration deal. The automatic-HTTPS thing is such a strong sell that I think a lot of people will seek to replace nginx just for that.

I could totally be wrong here but this is where I think a sort of narrative document for Nginx users at least is perhaps worth it.

Some of this is always going to be a challenge because Caddy is a fascinating, category-straddling project; you've made a product that is somewhere between a magical automatic appliance, a Golang web dev framework and a traditional configurable server, that avoids the downsides of all of those things as far as is really possible.

Documenting that is definitely a unique challenge.

I'm prattling on now but thank you again for Caddy; it really is a great contribution.

Nah it's fine ^_^ we both know we have a difference of opinion there, and we balance eachother out on that.

> Sorry, I mangled that with a run-on sentence, didn't I!

Hah, maybe a bit! Thanks for clarifying, that helps. We'll definitely take those comments into consideration when we work on updates to the docs!

Thanks for the kind words <3