An Internet of PHP | Hacker News Reader

An Internet of PHP

timotijhof.net

295 pointsedent318 comments

From W3Tech;

> PHP is used by 77% of all the websites whose server-side programming language we know.

I had a quick look at the methodology section, but it’s not clear to me how accurate this data is. Determining whether a site uses PHP can be relatively straightforward (especially with default extensions / if Wordpress is used / etc), but if a site (potentially using a different language) is behind a reverse proxy/uses an API/etc then it is less clear. Does anyone know whether PHP is over-represented in the results because it’s easy to identify?

No doubt PHP is still huge, but 77% seems almost too huge. There is also a very good chance that PHP is actually that big and I’m just in a different crowd.

Saying 77% of the web is run by PHP and concluding therefore that PHP is well-liked for websites is like telling most of banking is run in COBOL and therefore COBOL is well-liked for banking.

The conclusion has no coherence to the source.

I guess that most of the web runs on PHP (because it runs on Wordpress) if counted by page-view. But I'm not sure that's the proper measure.

In default configuration PHP identifies itself in response headers, but you can turn that off. People who know how to set up and administer web back ends generally do that from a security best practice checklist. So if anything PHP runs more sites than the number discovered crawling the web looking for identifying evidence.

Wordpress and similar CMSs, e-commerce platforms, and the Laravel framework give themselves away in other ways that take more work to hide. Likewise non-PHP back-ends have easy to see fingerprints in the headers and page source. There’s no reason to think PHP appears to dominate because crawlers can easily identify PHP but can’t identify other back-ends.

Banks and large companies with large COBOL code bases mainly maintain their legacy code, they don’t write a lot of new code in COBOL or RPG. And you won’t find COBOL powering web sites, which makes the argument irrelevant to the topic. The last time I worked on a big legacy back-end I was putting a web front end on it, using PHP and ColdFusion.

I agree. I always doubted these figures (I'm a PHP dev myself, so I wouldn't mind these figures being true). I think the methodology is shady. I wonder if they use what the server indicates. I think some servers like Apache with php mod send this information to the client in a header. But most servers don't. Therefore they maybe use this as "from all the servers giving a backend language information, PHP represents 77%" which wouldn't be surprising. The question is how many websites in your data don't give any information about the language used under the hood?

I think we should stop using these numbers. GitHub uses ruby on rails but we know it from the developer team, not from what the server tells us. How many websites communicate about their backend infrastructure?

I don't doubt Wordpress powers many websites out there. But I'm tired of these figures which don't mean anything to me. Especially that if you look for all job ads, PHP isn't so big (except in some PHP-centric countries like France).

You can't just make up numbers. If you give me statistics, give me the methodology you used and all the details. Otherwise I suggest we all start saying Haskell powers 87% of the web. After all, if you can invent what suits you, I can do the same.

Identifying the technologies behind a web site involves a lot more than looking at Apache's mod_php headers (which you can and should turn off for security reasons). The tools for figuring out what runs a site actually do a really good job by looking for multiple identifying features. Marketers and SEO people use tools like BuiltWith and Wappalyzer (and many others, most of them not free). You may not know about those tools or how well they work, but a quick browse of that space will disabuse you of the idea that these surveys just crawl looking at server headers.

Multiple independent surveys of web back-end technologies by different outlets, across many years, have reached the same conclusion: PHP powers approximately 3/4ths of public web sites/applications. I do a lot of PHP work and I see PHP used heavily in restricted/private web applications as well -- internal sites that won't show in these kinds of surveys. One school I work for has one public WordPress-powered site and several internal-only WordPress sites, and multiple internal PHP-powered sites not based on WordPress, including Moodle (learning management system) and their student management system.

The large ecosystem, relatively large population of experienced developers, and ease of deployment play into the decision process. Sometimes it comes down to hosting costs or other non-technical factors.

Deducing the number of jobs for PHP developers based on job ads will mislead you. Most jobs get filled internally, informally, or by recruiters before they get posted online (because that costs). If you don't see a lot of ads for PHP developers that might mean few jobs exists (which wouldn't match the experience of anyone who works with PHP). It may also mean the jobs got filled before the employer has to pay to advertise the job. A position for a 5+ yrs experience Elixir dev may sit open for months, but I can and have filled PHP dev openings in a few days, from a large list of applicants acquired by a free posting in a local PHP user's group forum, without having to post in public job forums or do LinkedIn email blasts.

We should also consider that web developers with more than a few years of experience have likely worked with multiple tech stacks, and those of us with 10+ years very likely cut our teeth on PHP. I started in the '90s with ASP and ColdFusion, with some Perl, and then saw employers move to PHP (and a few to Rails a few years later) mainly because ASP (which predates .NET) and ColdFusion required increasingly expensive licenses whereas PHP did not. Among experienced web developers you will find many/most of them have worked with PHP, and could work with it again, though they may prefer something else. Likewise I know COBOL and could fall back on that if more interesting work dried up for me, but I don't call myself a COBOL developer or look for jobs in that space.

Thank you for your comment. I was definitely wrong about the different methods used. This is why I love Hacker News. Always nice to learn something.

I still think the stats they provide are a bit weird since there is no "unknown" category. If they can't find the backend technology used for 5% of websites, it changes the whole result, and from what I have seen they don't provide this information.

But your really nice and detailed answer tells me I might be wrong once more.

I don’t see an “unknown” category. A large number of unknowns could skew the results if we had reason to believe those mostly represent non-PHP sites. Do we have any reason to think those unknown sites show a different distribution than the known sites? Do enough unknown sites exist to meaningfully affect the results?

Using your 5% example, supposing that 5% unknown includes no PHP sites, that only brings the PHP percentage down a little. It doesn’t change the main point that PHP dominates by a wide margin.

Well, it seems like a good part of the analyzer is about some "leaks" or specific behaviors from a language that could give us some tells about what technology is used. I checked Wappalyzer's code (at least the last commit before it went private: https://github.com/dochne/wappalyzer) and PHP gives more tells (https://github.com/dochne/wappalyzer/blob/main/src/technolog...) than Python for example (https://github.com/dochne/wappalyzer/blob/main/src/technolog...).

Some technologies seem to give more tells than others. Which means some technologies could be way more invisible than others. I am not sure we can suppose the known and unknown technologies have the same ratio.

I quickly checked some websites with BuiltWith and Wappalyzer and from my personal totally unscientific and small sample data, they seem to detect more easily PHP than other languages like Python.

Again, I don't know. But I took 5% to be optimistic. It could be 30% or 50%. And then the whole picture changes.

Edit: Funny thing, it even adds PHP to some sites I know (almost for sure) don't use PHP. Like GitHub using Ruby (true) and PHP with Drupal (???).

You could just click a couple of times to find the W3Techs methodology and data gathering process described, here:

https://w3techs.com/faq

No need to speculate about how it works.

tl;dr A lot more than looking at Apache headers or WordPress meta tags.

A lot of news outlets, e-learning and e-commerce websites are running on CMS/Frameworks made with PHP. Just to mention a few of them:

- WordPress - Joomla! - Magento - Moodle - Zend Framework/Cart - Laravel - Symfony - Open E-commerce

If you count all the websites using one of the above items, you will come up with a huge list of websites.

And way too many Academic sites are running on PHP.

The LAMP oder LNMP Combo (nginx instead of Apache httpd) is strong.

The vast majority of websites are probably small business websites which almost all run Wordpress.

That number doesn't surprise me.

People have already questioned the validity of this number. Do a search and you'll find people looking into this and conclude that the number is very unreliable. Whether you agree or not is up to you.

Also I want to point out that almost any time people quote number about PHP's popularity, this is the only number, which is strange -- for metrics like iOS market share you can always find multiple numbers from multiple sources which don't fully agree with each other but are within a certain range. Not for this PHP number. In other words, w3tech's number is not cross validated by any other source. I wouldn't use it to "prove" anything.

"People" questioning the numbers published by multiple outlets over at least a decade? Who? What data do they have to "conclude that the number is very unreliable?"

Whether PHP runs 77% or 69% of public web sites, how does that offend anyone or make them feel insecure? No one is trying to "prove" anything, there's no race to the one ultimate tech stack that requires winners and losers. You can accept the fact that PHP objectively runs a large majority of public web sites without interpreting that as a threat to your choices, your job, your image of yourself as a professional.

Having so much PHP out there may look like a problem, but programmers attaching their ego and identity to languages and tools and frameworks accounts for a lot more wasted time and crappy code than a popular language that has some obvious and well-known flaws.

Sorry to inform you that the original article definitely tries to use this number to prove that php is still relevant.

Idle musing, but this is likely correct. If someone who isn't tech-minded is throwing together a quick blog in WordPress or something chances are they aren't going the extra mile to change the headers or add a reverse proxy just to obfuscate that they're using a stock WordPress install.

That quote has a really big problem.

I run a couple of services that are accesible through an API built in Symfony (PHP), but the data is generated with software built with JS (event driven -> lambda, cloudflare workers), Python (depending on GDAL mostly) and also PHP.

It sounds like you're ultimately just saying that the 77% number doesn't feel right to you.

I agree that it's an interesting challenge to try to determine which language a large number of sites are using for the backend, or at least it would be a challenge in some small but maybe not insignificant percentage of cases. And no doubt whichever way they solved it involved compromises.

But that by itself doesn't give us enough information to draw conclusions about accuracy.

WordPress is one of the few CMSs that sends a header saying it's running WordPress and otherwise makes it very obvious. PHP is so high on the known list because every other back-end you can't tell what it is.

Not true. Identifying a tech stack involves more than looking at a couple of headers. Almost all of them leave enough fingerprints in the headers and page source to identify them. The tools for identifying what runs a web site have a lot more sophistication than you think, in the same way Facebook and Google don't need to see my driver's license to know a whole lot about me.

Agreed, these stats should always include the servers for which they could not determine the language - anything else is just lying with statistics.

This is great, and I'm glad for the PHP developers out there. But if I go job hunting, it's not PHP skills that offer the highest earning potential. At least not that I've encountered.

How much revenue generation occurs on PHP? I'll cede the argument about the e-commerce platforms and CRMs, but I'm just not convinced that PHP is where a budding developer should be focusing their efforts. You enter the business/corporate world and there are tons of applications out there running the world, not just websites. Those applications are predominantly written in languages like .NET, Java, JS/ECMAScript, Python, Rust, and Go. Also, among the managed languages like .NET/Java/JS the knowledge is quite transferrable and sometimes almost identically named.

I'm not trying to bash PHP as a language, but every time I see this argument it's the same. Evangelizing PHP also seems to come with a requirement to mention Wordpress, Wikipedia, and Facebook. I'm sure there's money to be made in PHP, and I'm sure it's a great language for the internet. But learning .NET or Java is likely to have a much larger window of opportunity. Also, if you have a specific industry you want to work in you should be looking at the language predominately sought after in that industry.

I think this is why a lot of developers bash PHP, it's not that it's a non-valid choice. It's that it has limited applicability. I would never advise someone to learn PHP as their first language.

I was job hunting this year, I'm a long-time PHP developer (since '99).

It wasn't the language, it's everything around it. It's knowing frontend and how it works, it's knowing about cloud/operating systems, databases, 3rd party integration, IAM, SSO and the list goes on.

These skills are applicable everywhere, next to any language. Compensation I was offered revolved around the ability to be non-invasive towards younger teammates and to provide education with emphasis on critical thinking. During the years I've done this job, I learned other languages as well and I can safely claim that initial language one learns has huge impact but it's learning additional skills that makes up for a valuable employee.

In the end, knowing C# but not knowing PHP bears little insight into whether you're capable of listening about a requirement and coming up with a solution that satisfies the need, code it in such a way code can safely die one day and make in such a way that additional people in the team can jump in and manage it.

I also found a lot of job offers and opportunities. My previous engagement was insurtech/fintech, there's quite a bit of PHP used there (and it works well).

Wordpress, Magento, Facebook - these aren't the only places where PHP is/was used, the world we don't hear or read about is larger than the blogo-investo-googlesphere we're used to reading about.

So are you saying that you didn't see a salary difference between PHP roles and C# or Java roles? I've said before that I think modern PHP + tools can be very productive but smart/good developers will find that CV/Salary pressures steers them away from PHP.

> So are you saying that you didn't see a salary difference between PHP roles and C# or Java roles?

No. What I said was that language was not as relevant as the complete engineering ability that makes someone a valuable (financially viable) employee.

> but smart/good developers will find that CV/Salary pressures steers them away from PHP

I never met a person who entered world of IT with the criteria that you highlighted there. My recent experience shows that people enter IT/development based on salary alone, not based on research they conducted taking into account industry they'd work in, language features etc.

If this case you wrote of actually existed, world of software would be a place of much more high quality software and not of "it barely works" projects that resemble Frankenstein's monster.

That's very interesting.

My experience in London/UK market is that offered salaries are based on market rates based on keywords including tech stack. And I know a decent number of competent developers who deliberately moved away from PHP because of the lower offered salaries. It might just be the local ecosystem which imo doesn't really value engineering roles in general

I completely agree that it's not just the programming language, it's the ability to understand and apply concepts that will make a great developer. Furthermore, you're right on the money when it comes to applying those concepts to integrate them into a solution (re: "loud/operating systems, databases, 3rd party integration, IAM, SSO, [etc...]).

I was more focused on where I think one's energies early into their career should be directed if they want the best chance at advancement and integrating those solutions in the corporate space. Yes, those solutions are integrated in PHP for various projects, but not as often in the applications that are running your day-to-day corporate operations.

I've used and developed in PHP for many web projects. I've used and developed in .NET/MVC and Java/Tomcat for many web projects.

I've used and developed in .NET for many desktop/server/infrastructure projects. I've used and developed in PHP for a single infrastructure project, some custom development for pfSense integration (which was horrifying, running as root, hodgepodge scripts).

Objectively, the evidence I've seen, appears to indicate that a developer with skills in any other mainstream language has more opportunities for employment and a greater salary.

Right on the money. There’s a reason PHP shows so high on this list, and e-commerce is always mentioned. Analyses only have access to public sites, and PHP’s niche of blogs and e-commerce have lots of publicly crawl-able pages.

The majority of sites may well be in something else, and the majority of things that people will pay you to code may be behind a login page.

https://www.jetbrains.com/lp/devecosystem-2021/php/

Still seems to be most popular in France, doesn't appear to be dying off there... Interestingly it's gaining popularity. Curious why that would be.

Many people who learned to code with PHP in the 2000s are picking it up again as first choice for web projects since they improved it so much and websites can be updated and running with a simple `git pull` without restarting any services.

I saw a video not long ago that made me have hope for the future of PHP again -> https://www.youtube.com/watch?v=ZRV3pBuPxEQ

Symfony is from France.

> This is great, and I'm glad for the PHP developers out there. But if I go job hunting, it's not PHP skills that offer the highest earning potential. At least not that I've encountered.

PHP has indeed ranked close to the lowest in average salary in StackOverflow surveys for years. The amount of templated thrown-together solutions for the exact same site as yesterday with different branding vs. custom solutions probably is the root of this.

"PHP is dead" is dead. The amount of people praising PHP these days is quite high and increasing. Of course I may also be in a bubble (of php devs), but I have seen a constant increase from JS-people starting to look (and in some cases, convert to) php. Also, many new youtube videos highlighting the new stuff in the language, how modern it is, etc.

Honestly, anyone that blindly criticizes or dismisses php these days, is a big red-flag for me.

Well the problem is that "the internet" (google, stackoverflow) does not (by default) filter out any old/obsolete information.

People googling for solutions will get 30+ year old "advise" on how to do certain things / use certain libraries etc.

Especially StackOverflow should be incorporating a major version number for which the question is valid.

So yes, "PHP is still dead" as long as you get the same old advise.

StackOverflow has been trying to address that problem. I've recently seen them show a newer answer on top of the "accepted" answer even though it had fewer votes. This helps the answer evolve over time.

https://meta.stackoverflow.com/questions/405302/introducing-...

But that’s not the problem. The problem is that the questions are old.

It’s better to have the same question in a new era. The version info should be in the question. The question has either been answered or not, but it’s not relevant anymore for the original poster.

Only if it really is, you could add a new major version to it to indicate compatibility

I'm not sure I see the distinction. I've needed help doing "X", I googled "how to do X", and found ancient stackoverflow questions. The page has recent answers ranked the highest saying things like: "in recent years you should use the Y feature to do X". I haven't seen anyone get upset that the Y feature didn't exist when the question was posted.

Questions are often timeless. The answers change and SO shows them all with their timestamps ordered by its best guess at which will help you, the reader, not the original poster.

that's very true. But it is true for PHP as it is for any other language or tech that is at least a decade old. Interesting fact: chatgpt can recognize old stuff and give better recommendations

Still, somehow it’s more true for php.. maybe because other languages invest more in migrating to newer standards. Maybe because so many projects are self-hosted by non-programmers, in which case it makes sense to be conservative

Can you name one or two "newer standards" that "other languages" have invested more in migrating to, compared to PHP?

Did you mean standard, as in HTML5 or ES6? Or something more like a fashion or fad, like FP or OOP (which PHP has had for a long time)?

People ask the same old questions about PHP on StackOverflow et al. because a lot of people start with PHP and as beginners they will have the same questions every beginner had before them, and the same lack of ability figuring things out themselves or finding their questions already answered. That has nothing to do with PHP per se except that PHP offers a very easy on-ramp to getting started with web development, so a lot of newbs start there.

If you look at the W3Techs methodology, posted on their site for all to see but apparently few to bother with, you will see that self-hosted hobbyist and learning projects aren't going to make it into their results.

It’s like meeting someone in 2023 who hates Micro$oft WinBLOWZ. Have they been stuck in stasis for 20 years? What other values from the 9/11 era do they hang on to?

You mean like hating MS for putting ads in the OS?

MS didn't change, they still exploit as much as they can.

And they try to force people people into the cloud unable to secure their own software stack.

MS didn't get better just because Google got worse.

Don't forget that now Microsoft ♥ Linux

I'd much prefer the previous one that hates Linux but actually gives me a usable OS & tooling without ads or other user-hostility.

Windows 7 was great.

This reminds me of the sysadmin at a Greek university I once worked in back in 2009 or so. He had installed Linux at every one of the computer labs' computers. He'd changed the startup software to describe Windows as Windows UnProfessional. The default was Linux, and it would boot within 3 seconds unless you quickly changed it. Under Linux he'd included all the Gnome 2 window manager flash, including spinning cubes and windows that went up in flames when you closed them.... He convinced my friend to install Linux on her laptop. Good times.

I like the fun spirit of it. We do not have these people anymore.

A budding RMS!

Oh instead do people believe the obvious BS that Microsoft loves Linux and FOSS and has become an ethical company?

Yeah? Last time I installed Microsoft Windows -- I was genuinely giving it a chance -- it asked me during the install if I wanted to see ads.

Well, that's like asking me if I wanted a recreational root-canal, so I answered "no".

Boot into the OS, and the task-menu-bar-thing is spinning with X-box ads and all sorts of other crap.

I dispensed with that shit immediately, and gained a nice little extra disk-space for my /home dir.

It’s like meeting someone in 2023 who hates Micro$oft WinBLOWZ.

As someone who was on the whole pretty pro Microsoft for the past several years, 2022-2023 was when I started 'hating' Microsoft again. Both today me and year 2000 me would agree that 2020 me was completely wrong about giving Microsoft the benefit of the doubt.

Ironically since windows 11, after being pro windows since version 3.11 I have pretty much turned disdainful to Micro$hit WangBLOWz. What a time to be alive.

This might have been among the worst examples you could have used, considering current affairs.

Windows was getting better until MS started preventing users from deleting files, even if they are the owner of the computer. Yes, it is a foot gun, but it also makes fixing problems difficult and sometimes even impossible. Windows 11 seemed pretty nice until my son had a problem installing a game and one of those "untouchable files" was the wrong version, so every 10 minutes or so you'd get an error message. We fixed it by re-imaging it with Debian and Steam.

> What other values from the 9/11 era do they hang on to?

I'm still into taking care of my family, being honest with people, being nice to people, even if they are not nice to me, and I still like a good single malt whisky.

lolwut windows is worse now than it was 20 years ago.

I'm in my 30s and grew up with PHP since the 2000s.

There's still an insane amount of money to be made with WordPress plugins, WordPress support, and more. That industry isn't dead, it's thriving, it's insanely cheap to jump into and not get yourself into debt, and there's tons of people that need help.

While people here argue about the 10th "correct" way to do server-side rendering (hey, React says we gotta use RSC now!) or figure out how to get their Rust code to compile to WASM for their Codepen demo website to increase a number from 1 to 2, thousands of us churn away daily making money from this "dinosaur" PHP in the real world.

The bias on HN makes you think PHP is completely dead and it's funny to see the comments here.

Not just that. I recently checked out Laracon, the Laravel conference. You can find videos on YouTube. But I am yet to find another programming conference that was this high energy, fun and focused on great developer experience.

And because so many people make real money off of it, there is a focus on making practical things. Hackers who are looking at doing their own startup, might want to try out Laravel and it's ecosystem.

I'd be more than happy to jump back to PHP and do some WordPress dev for as little as $15/hr. I feel like the problem is finding the first project to get some experience and sell the next project.

where do you find work like this?

I like PHP, because it has a familiar C-like syntax and great tooling, like composer, and frameworks, like Symfony. The language has warts, but it's improving.

I think its strength is its architecture, namely shared-nothing state and concurrency at the web-request level. [1]

[1] https://slack.engineering/taking-php-seriously/

Maybe I'm missing something, but I disagree with the tooling comment. Composer is horrendously slow, taking on the order of multiple minutes just to do a update often times. This is just my experience, but I'd much rather take mix, cargo, or yarn any day.

xdebug, while it works, also feels antiquated. Trying to get it working in a new system or project can take quite a while. Again, compared to python or node's debugging experience or profiling experience, and it feels like something stuck out of the 90s.

Even just getting output from php is difficult for me. Maybe it's because of the webserver I'm using? But python, elixir, node, go, etc, all output logs to stdout while running a local service. Maybe that'd work with the built in webserver, but fpm or modphp, etc, it seems like you have to hunt down logs.

Not to mention that the dev servers almost always require a full apache or nginx setup just to function. Opposed to a node, elixir, python, or go server which all run directly from the directory you're in. (Including things like hot/auto reloading in node and elixir)

I'm not a full time php dev, but my time in php always feels like a grind, and just getting tooling working is not an easy thing. If I'm missing some state of the art alternatives, I'd love to hear them though.

composer 1 was slow, composer 2 (released 3 years ago) is fast

I'm on composer 2.5.8

HHVM is evidence of the weakness of PHP and is a bandaid hack, but the article spins this as justification for PHP.

What would you do if HHVM didn't even exist?

Admittedly PHP has had recent performance gains, but by no means would it ever be a first choice in any backend service architecture.

You either got hit by an avalanche of bad information or prefer to remain ignorant.

What would any of us do if some innovation never happened? How does Facebook committing heavily to PHP and then giving back in the form of performance enhancements somehow tar PHP as crap? What language or framework with any longevity didn't have something like that happen? Is Javascript crap if not for Typescript, or V8?

You may not make PHP your first choice but plenty of businesses and developers do. If you can point to some actual reasons no one should choose PHP, or widespread failures due solely to flaws in PHP, go ahead.

This is a pretty silly take. It's like saying that performance improvements in the Java runtime and advanced garbage collectors like G1GC and ZGC are evidence of the weakness of Java.

> Admittedly PHP has had recent performance gains, but by no means would it ever be a first choice in any backend service architecture.

Other than at Yahoo, Facebook, ...

Don't get me wrong; PHP has issues. But it's very mature; it's fast; it's easy to learn; it has a very diverse and rich ecosystem; it's easy to debug; and in general, it's very useful for building reasonably efficient and performant scalable web services.

> What would you do if HHVM didn't even exist?

If you're referring to the Slack article, it is a bit out of date.

PHP has since added stronger typing and better performance. I don't think using HHVM is very popular.

php runs securely in 5minutes in any web server 3-10$/month.

Every other tech, it's complicated servers or complicated billing, not to mention depencies and build tools.

thats why php

Well it's not exactly secure by default. I was deploying an app to a new server and some bot grabbed my .env file before I finished the Apache config. Ultimately it's my own stupidity, but you don't have to worry about that with most other languages

You shouldn't deploy .env files to production. You should set the actual environment variables on production. .env files are intended for convenience on non-prod systems.

Agreed, but server frameworks shouldn't easily enable a foot gun that allows bots to have disk access to your host. Instead, only explicitly defined routes or resource files should be available.

If I had to guess, this person committed their .env file in some repo and pushed that up, and that become available because the server was misconfigured.

For other servers (such as, say, Jetty), config files like that won't get exposed like that unless you're very obviously placing your config files in a public resource folder.

Yes but that’s a framework specific issue. And usually your documentroot would point to a directory below that which holds .env. Oh the memories of apache and php.

The mere concept of a "document root" is a problem though and a major footgun if you don't know what you're doing.

Every other language acts as its own web server which wouldn't even be capable of serving files even if you tried; the only thing it does is respond to web routes defined by the application.

This eliminates a whole chunk of security issues, from the one described above to malicious file uploads (PHP is probably the only language where a malicious file upload leads to RCE by default - other languages could happily accept and serve the malicious file back but wouldn't execute it).

> The mere concept of a "document root" is a problem though and a major footgun if you don't know what you're doing.

A non issue though after 2-3 days of working with this approach. All modern PHP frameworks have a so called front controller (an index.php file) that loads what it requires from ../ after, ideally, properly validating the request to avoid issues.

Your comment makes no sense. How is that framework or PHP specific? Its simply a misconfiguration the server.

Some frameworks in the old days of PHP relied on .htaccess files to restrict access to unwanted files. Properly implemented frameworks would load everything from a directory above the documentroot to avoid these issues.

So it wasn't the language, it was you? But it was the language?

Just like in C, where every buffer overflow bug is the programmer’s fault.

That has nothing to do with PHP. If you have .env files in your document root PHP didn't put them there or require them. Every web site back-end can expose .git directories or .env files if not configured correctly -- that has nothing to do with PHP except that way more people use PHP out of the box and don't know about these issues or how to fix them. That's analogous to way more teenagers crashing cars than more experienced drivers, but that has nothing to do with the particular cars.

This, or variations, can happen with every kind of backend.

The only way to avoid to have the server open only to you till everything is tied down right and the backend is ready to face the world.

To rely upon being quicker on the draw than the bots is quite courageous.

If you apply the same level of thoughtlessness to any other framework, I assure you bots will grab your config also.

True. I setup a woocommerce site for someone 3 years ago, still makes around $1000 a month (pretty good for a small biz in India) and I just helped them downgrade from a $10 digitalocean VPS to a $3 cpanel hosting.

Classic php ecommmerce customer: miserable cheapskate that thinks saving 80 dollars a year is great, had my fair share of these

Not sure why it is downvoted as this is true. That said it is more to do with shared hosts culture choosing PHP than PHP itself. (They tend to support Ruby and Node but not as well)

PHP is also pretty easy to support for shared hosting, as what they essentially need is just an Apache module (+ nginx probably), some clever filesystem permissions and they're done. For node, Python, etc, you actually need to keep the application servers running, which has to stay running even when they're completely idle. So I think PHP is a natural choice for shared hosting for those reasons too.

I worked 10+ years in a web hosting company. PHP was chosen not because it was easy, it's because most people just use a CMS or something in PHP.

Keep a shared host secure, PHP or something else was not an easy task, most people installed unsecure versions or misconfigure something.

Also it was a pain to support PHP versions after EOL (yes, money), and multiple versions .

This is exactly to the reason why PHP and before perl are successful in this space.

When you extrapolate that to modern tech, you could create a shared hoster with a configured reverse proxy and per customer docker images.

But that is so much expensive to build, operate and bill than an apache. And looks very close to AWS and friends.

> For node, Python, etc, you actually need to keep the application servers running

Not with CGI.

You're technically right, however I imagine performance would be really poor, especially for Node. PHP has transparent opcache support and it's generally fairly efficient when run as Apache module, so it's usually preferred. You can of run PHP as CGI as well, however it's much slower.

I wish cheap server hostings allowed loading php modules or at least had FFI module. Imagine thin php API-layer with rust-or-whatever-module under the hood. Easy deploying toys without need of VPS.

Doesn't cPanel supported several langauge including NodeJS runtime? I think most projects use composer or PHP packages.

Thanks to cPanel (written in Perl) this make life easier for developers to set up websites and skipped the ceremony but why is cPanel written in Perl instead of PHP?

But Go language has it own security implementations which are more secure and easier to deploy as a static binary. I did tried to write entire Go app using only built-in or some dev use Chi for routing. I didn't have to install Go runtime on VPS that you need for PHP.

Go built-in HTML template is quite secure, rare seen some fix to html/template make it easier to deploy new app, but our website has evolved with Astro web framework that require NodeJS since none of the server side language can solve client-side issues.

> Slack uses PHP for most of its server-side application logic […].

> the advantages of the PHP environment (reduced cost of bugs through fault isolation; safe concurrency; and high developer throughput) are more valuable than the problems […]

The "high developer throughput" is really what does it for me.

I remember vividly when I started at Amazon (where PHP is forbidden) and we were spending days building a single relatively basic CRUD endpoints in Java (with Hibernate, that sucks for non-trivial models), I was constantly thinking "this would have literally taken 1 minute and 5 lines of code with Laravel".

You want your whole team to become 10x developers? Switch to PHP.

Between the simply incomparable frameworks that do absolutely all the work for you and the fact that a simple instant page refresh shows your changes, productivity is multiplied.

I've always liked PHP. You wouldn't pick it for your job interview's coding test if you had a choice (Python all the way there), but it's so intertwined with the internet and what we've learned about programming over the years. First mover advantage kind of deal.

And I've never had to deal with ESM/CJS/AMD whatever module nonsense with PHP. No transpiling anything, just edit and refresh. And so many useful functions out of the box (array_column anyone?).

I think its bad rap comes from its ubiquity. Pretty much any existing website I've had to work on has been a putrid mess. That's just the way codebases go unless you're a SaaS with a CTO who's hell bent on preventing that.

And since most of these putrid messes have been based on PHP, due to it's age and ubiquity, people blame it, due to observation bias.

> You wouldn't pick it for your job interview's coding test if you had a choice (Python all the way there),

I do actually pick it for several reasons.

  1. I want to know if the environment I am going into is pragmatic about languages.  If you are going to refuse to continue working with me over something so minor as PHP then we aren't a culture fit.
  2. I want to showcase my best.  I know this language in and out.  It's the first language I learned and I have the greatest ease of building algorithms with it.  I've had interviews where I was asked to do something with PHP that PHP did not support and I found ways to make it work.
  3. In some ways I love the conversation that comes with positive interviews when using it.  Oftentimes the interviewer isn't very familiar and it sparks discussion on the languages benefits and drawbacks further showcasing my skillset.

Sure as we progress along in the interview process I will switch to whatever language the company uses primarily but if I get a choice I always choose PHP.

Your comment articulates my thoughts on PHP very succinctly. Especially the culture fit bit. PHP is so insanely pragmatic that if someone looks down on it due to false preconceived notions then they're not the kind of person I can probably work happily with anyway.

It's also the thing I'm best at!

And they are humble. They know their state, the flaws in their language and the long problematic history they have.

They cherish their languages but are not fanatics.

PHP has its fair share of snobbery as well. Non-framework devs look down on Symfony, who in turn look down on Laravel devs, and everybody looks down on WordPress devs.

Not to nitpick but choosing a programming language isn't a minor decision nor is switching programming style, e.g. OOB vs FP. Of course I agree with the intend and I too want to work in pragmatic and explorative programming environments trying out different programming languages and styles depending on the project.

>Not to nitpick but choosing a programming language isn't a minor decision

In the grand scheme of things, talking solely about software projects not life in general, it kind of is.

Most modern languages, are interchangeable, and projects of most kinds have been done with all of them succesfully.

As long as the programmers for the chosen language are available, and the libs you want are there, for startups doing some web backend for example, it doesn't really matter if it's Python, Ruby, JS/Node, PHP, C#, Go, Java, CL, Kotlin, Clojure, and so on.

I don't think "interchangeable" is the right word here. In some cases, perhaps, but different languages have different idioms and, since you have Clojure on there, different paradigms. If the individual coming into the new language is diligent about learning how to properly work in it, then all is well. If they decide to try and force what they already know into the new language, that is problem. I've experienced the latter far more often than the former. If you're working for a feature factory, though, I guess it doesn't matter.

Working with Clojure is a world apart compared with any of the others listed.

I disagree. There will be lots of considerations like ecosystems, long term support, ease to find developers, prior experience, etc…

If you worked long enough, language or code style are beginning to become almost completely irrelevant

That's a good point, I imagine doing that would screen out companies run by language snobs.

My go to for this is to say "I don't think Typescript is needed most of the time". The snobs look at you like you just farted in their face.

But having done some coding interviews where time and space complexity were a factor, I found it easier to succeed with Python.

> "I don't think Typescript is needed most of the time

This is a terrible example, typescript (especially in 2023) is basically free with most setups (including vanilla) and easy to ignore for velocity then optionally enforce typechecking later.

A much better hill to die on would be large frameworks/tooling like react/angular/webpack.

Exactly. If the interviewer responds like that, they've told me the company culture, and I know to stay away.

Bad rap comes from the inconsistency of the early APIs. The ability to interleave code and HTML was also tacky and never taken seriously but I think touted highly by some as a killer feature. The language is very unplanned, go look at an equality chart for PHP, it makes JavaScript blush as well.

"The ability to interleave code and HTML was also tacky and never taken seriously" - That was the whole point of it! The day I found PHP and could leave behind the cgi-bin and SSI it became my favourite thing - and has paid me well for the last 20+ years :)

Putting HTML inside of scripted code blocks was legendary back in the day and every web-oriented language did it. I guess people have already forgotten about ASP and ColdFusion. Being able to for each an array into table rows? Game changing.

I have been coding in coldfusion (openbluedragon) on 2012. Still lurks in my dreams. I refactored to components (objects) some functionalities as a POC, it did not fit well with the main programmer.

> The ability to interleave code and HTML was also tacky and never taken seriously but I think touted highly by some as a killer feature.

And yet people seem to keep inventing variations of this as "templating" languages.

That presumably take care of the escaping rules and grammar of the output language, unlike the giant string concatenator that is PHP.

Yeah, a big problem with the traditional PHP-in-HTML approach to generating web sites is that it's one of the areas where PHP hasn't dramatically improved since the early days. Later templating engines learned from the problems people encountered with PHP and were built to be aware of the output format, and PHP never did that. A lot of work was put into writing templating engines in PHP that in retrospect really should have instead been a language mode for PHP itself.

We would have seen dramatically fewer bugs and injection attacks over the years if PHP had made <input value="<?=$value?>"> a perfectly safe and normal thing to write back in 2005.

There are actually shockingly few context-sensitive templating languages for php and those that exist don't seem that popular (Latte is the main one I'm aware of). Most of them are more of the giant string concatenation type, maybe with escape by default semantics (e.g. Smarty, Mustache).

> The language is very unplanned, go look at an equality chart for PHP, it makes JavaScript blush as well.

This has been fixed in PHP 8. https://wiki.php.net/rfc/string_to_number_comparison

> make non-strict comparisons more useful and less error prone, by using a number comparison only if the string is actually numeric. Otherwise the number is converted into a string, and a string comparison is performed.

That… makes it even worse.

why?

> The ability to interleave code and HTML was also tacky and never taken seriously

And yet people would take a bullet for React and the JSX templates.

Funny how "server side rendering" became a hot new thing too.

I was so confused when I heard that, "like... a HTML file?".

Keep going at this rate and we'll be using frames again.

> "like... a HTML file?"

Serving a static HTML file is not server-side rendering.

It's much dumber than that. The people advocating for SSR want the server to respond with HTML generated based on whatever is in the request.

> using frames again.

That’s pretty much what htmx is…

I too find this hilarious. Not because I want to defend PHP, but moreso that I personally sort of despise react and it's whole ecosystem. I've never liked writing code less than when dealing with a spaghetti monster react app.

Well React was born in Facebook which was famously PHP codebase. It makes sense.

JSX and PHP are actually seriously different. When you break out of PHP, you're just outputting text to standard output. When you're using JSX syntax, you're constructing Javascript objects that can be manipulated using standard javascript techniques. Anyone who believes they're comparable seriously doesn't understand the task that is before them.

Oh please, I professionally use both daily (enjoy them both), but even I can see JSX is just PHP with extra steps.

My reading of this thread is that people are comparing JSX as a templating language to PHP as a templating language, splicing PHP <? ... ?> into HTML like how we have { ... } in JSX. At the end of the day React lets you write a function that returns HTML just like a PHP file.

The bad original library, the original lack of features that help against bad coding practices and the fact that it is so accessible to beginner programmers that you’ll find a lot of beginner code.

The ability to mix html and code means it’s extremely easy to get started which is the big strength.

I'd love to see a modern PHP without the language quirks and with a decent standard library.

https://hacklang.org/

PHP is akin to, I don't know, the Subway (fast food restaurant chain) of programming languages?

You don't hear too much about it. You almost never notice it unless you're actually looking for it, unlike McDonald's with its ostentatious golden arches.

It's popularity is waning. But it's still everywhere. [0] There are a hundred other sandwich chains that have tried to do it better but none have managed the ubiquity of Subway.

People like to look down on it and espouse the alternatives, but when it comes down to it fast food can only ever be so good.

I guess that means that JavaScript is McDonald's?

[0] https://en.wikipedia.org/wiki/List_of_the_largest_fast_food_...

> It's popularity is waning.

I don't think that applies though. If anything, laravel is pushing PHP into another "golden age" not seen since code igniter 2, with again a framework that does things not quite how they should be under the hood, but definitely how people need them to be to be fast and efficient, except this time backed up by a proper package management system, a much better and stronger language and an ecosystem based on reusable modules.

Does it have the favor of the modern hype or new language seeker or anything like that ? No, absolutely not, but when has PHP ever had that ?

There will be no golden age for anything using node.

With this analogy python would be the Ikea. You can go for the fast food (site scripting) or you can get really invested and build out your ML modules with it at scale ( remodeling a decking out your kitchen)

That's a fun list.

Of over 100 I have only heard of 1/3: 35 in total.

I have only ever been into and eaten anything from half of those.

So fully 2/3 of the list I've never even heard of. Interesting.

> I guess that means that JavaScript is McDonald's?

My first reaction to this was that it's actually very accurate insofar that I genuinely wonder how one can like either of these and why they're so popular. At least JavaScript has the obvious excuse that it's the only thing that runs in a browser, so it's still more logical than the popularity of McDonald's.

I haven't used it for a long while, but I did a LOT of PHP5, several years. In my opinion PHP4 was horrific (from a language/standard library perspective, most languages you can get what you want done regardless of that), a lot of it carried over into PHP5 despite being a lot better (e.g. see phpsadness). Then the fiasco that was 6/7/whatever made it really hard to have confidence in the future of PHP.

No idea how recent PHP is. It's hard to escape those opinions that formed fairly widely in the industry is, though.

I've gotten a lot of value by being able to go to a library in my vendor folder, and add some var_dumps in there to figure out where my code is going wrong. The way the dependencies works is magnificent.

Xdebug?

Things I really like about PHP:

Once the file is on the filesystem, it's deployed.

Each invocation to run PHP is stateless and it parallelises effectively. (There's no communication, synchronization between PHP instances.)

It is definitely refreshing to simply upload a file via FTP and it updates your server. But it's this interpreted nature that makes PHP one of the slower languages in terms of throughout. I know, don't prematurely optimize, but there's a reason other languages don't do it this way

You almost convinced me to try it again but then i remember about:

* php.ini * php extensions * hardish deploy needing a specially configured web server * huge number of terribly named builtins * functions returning int|bool|null|whoknows * $, -> * cant trivially dockerize * laravel wants me to install even more crap other than Apache phpfpm php composer artisan sail larathis larathat so he can buy the second lambo by copying rails and django * xdebug

And i just go on my merry way. Php devs forgot the mountain of quirk and bullshit they internalized. That’s the same reason I’m starting to hate python

Can you add some color the bit about it not being trivially dockerized? Might be doing this soonish for work, would love extra info.

For a Production setup we had to configure an nginx container plus the FPM container, let em talk, Configure some more Commands to enable/disable xdebug (that requires a restart of the containers since it needs a php estension) and i think that’s all. Other langs we use are literally “run the app” then kube will handle the rest.

I skip all of that and use a docker image with octane. Much faster and easier to maintain. No separate FPM container too!

I skip all of that and use a docker image with swoole. Much faster and easier to maintain. No separate FPM container too!

Why would you enable xdebug in production?

I wouldnt but the container setup was the same to prod

Got it, thanks!

Yw, not really hard but since we’re not a php shop it required a lot of research, trial and error, complexity as in “need to know something not related to Application or domain” and ops are unhappy at having to support this one of a kind setup. There might be a better way tho

One thing I absolutely love about PHP is the mod_intl which is almost always enabled everywhere. It provides ICU Transliterator and BreakIterator which is godsand to handle user-create content that's in Asian, Complex Script, etc.

Last I check a few year ago Java is the only other platform with as good ICU integration, and nodejs has BreakIterator but not Transliterator. Other platform require complex setup to install ICU as a third party library.

I’m quoted a bunch in this, which I appreciate, but there’s one mistake here — Slack no longer uses PHP, having migrated its codebase to Hack.

Also listing language usage by what’s returned in server headers undercounts languages used on some of the biggest, most popular internet properties.

Sites like Amazon, TikTok and YouTube/Google consume a lot of our total attention, but they tend not to report their backend server languages in response headers.

If you shift from raw numbers to where people actually spend their time, I doubt PHP would be at the top.

Hack is a “dialect” of PHP created by Meta to be more performant and have types, among other features. So its not like they shifted their codebase to an entirely new language.

It certainly markets itself as a completely different language, though you'd probably expect that.

On one hand I'm almost positive that someone who's made the transition from PHP to Hack would point out that it's way more cumbersome to switch than you're making it out to be but on the other I have no personal experience with it and I would assume that set is small enough where we might have issues finding one to inform us here.

As an ex-PHP developer (almost 10 years now), I do not miss it. As a language, it is a scripting language with an okay interpreter. But as an eco-system, it is a hot mess. It has both the worst software developers (and I was one of them) as well as the worst clients (and the cheapest, regardless of geography).

It is not a surprise that PHP is running the web. That's because WordPress made sites/e-commerce accessible to the average Joe. Despite the massive security issues with these setups, it has enabled a large number of people to run businesses.

But if you are a software developer, I'd strongly advice you not to do PHP.

This just reminds me of what originally got me into PHP as a teenager. Creating a site for our gaming community in PHP-Nuke was all too easy. Extending it with plugins, and eventually writing my own plugins to show live data from our game server.

Now I look back on PHP3/PHP4 with disgust. Globals, function names, massive pieces of code right in the middle of HTML, shell_exec.

> Globals, function names, massive pieces of code right in the middle of HTML, shell_exec.

And they're not inherently bad.

PHP made the internet fun. Anyone could get going with a PHP enabled host with by creating an HTML document starting with <?php> and have a working something that the world could see by end of the day.

Today's web development feels like such a drag. In that you need to choose the scaffolding, create the scaffolding, wait for the concrete to dry, drill holes for the infrastructure and then construct the infrastructure.

When you then go to connect the infrastructure you find that one of the girders has buckled which requires a patch-up or refactor. Someone's misprinted the blue-prints and the cable ferret has gotten lost down one of the connectivity holes. You then discover that a new scaffolding company has come to town so your construction is now obviously out of date.

PHP enabled you to have something cool in days. Nowadays you spend days just trying to setup react. my two cents.

This matches my experience. In the old days (mid-2000's) I did a ton of PHP freelance work. This was done mostly with home grown "frameworks", built around HTML form to MySQL database mapping and CRUD operations. This was before REST APIs were really a thing, everything was page driven ("SSR" in today's terms, I guess.) For anything dynamic, we'd use JQuery, make an ajax call, return partial HTML, and inject it into the page. It was actually incredibly productive. I later moved on to Laravel and ditched the home grown stuff for newer projects.

I don't do PHP work much these days (permanent "working from home" made me not want to do any extra work from home after hours), but it felt incredibly productive compared to the more modern tech I've seen in my day jobs. There's a lot of crap to wade through nowadays. A typical small project might have a React front end, Python back end, REST API's, documentation, cloud deployments, on-and-on. Web development isn't fun anymore.

What's the closet think to a modern PHP nuke?

PHP was the Visual Basic 6 for web. People without proper training and theoretical knowledge just went and did stuff.

I think this is a sound analogy. I certainly recognize myself in the person without proper training and theoretical knowledge that just went and did stuff. Of course I changed and so did my tooling.

If it wasn't for how easy it was to get started and learn PHP back in 1998 when I started, I'm pretty sure I'd have gone to culinary school and became a chef instead of an software engineer.

I owe everything I have to Rasmus and his beautiful "shitty" language.

Empowered a generation to get stuff done.

I saw a webpage in the early 2000s that when I clicked something, it remembered the data on the next pages. Think simple counter. I checked out the site and it claimed to be using something called PHP which even free hosts of the time provided. How is this not enabling right?

I had a similar "simple counter" moment at a later date and the tech was AJAX. I am yet to have a similar moment after that. Perhaps WASM based interfaces? But it's not the same. Maybe I am not the same.

And leaving a steaming pile of unmaintainable shite being them.

Can we see your non-steaming pile of totally maintainable non-shit for comparison?

and made millions of dollars

It relocated wealth, but it did not create it.

There are lots of industries that are lucrative, but there's clearly no linear correlation to quality or societal benefit.

> did you make the pie bigger or did you take a bigger slice?

I think PHP did make the pie bigger, but there won't be shortage of companies who used PHP to only take a bigger slice.

billions

Considering Facebook is PHP (oh shut up Hack is PHP too) we could even say trillions.

Modern PHP may as well be a new language. But then node came along. It's almost like PHP users couldn't stand a clean ecosystem.

NodeJS is the new PHP aka it's the first language someone who want to "web stuff" pick up. A decade ago most blog post about PHP had major security issues because the people who wrote those posts were just learning the ropes and copying each other in the same way most tutorial about react these days don't care about cleaning themselve up, unit testing and all that stuff that make the difference between a cowboy and a software made with quality in mind.

The state of JS is maddening, whoever spit on PHP but love JS will need to explain why an hello world from create react app has 800 dependencies in the node_modules, why do we keep using babel when most browser is already supporting es6 fine and why do we have some many way to import modules. PHP had its issues which got fix over time but we can't say the same with JS.

I wonder how many more years it will take HN to stop pointing out client development idiosyncrasies when comparing Javascript to a language like PHP that has no client development story at all when supposedly trying to compare server-side DX.

Clean???¿??????

Dude, Node is as broken as PHP. And it starts from having no standard library leading to hell like leftpad and general software supply chain holes that PHP never had in the same quantity.

It isn't clean. Node was just shinier and had more applications to leveraging it for a shiny frontend.

I think that’s what he’s saying: That they jumped from php to another hot mess. At least that’s how I read it.

I don't think the language is the problem. As bad as it is, it is certainly more well thought that the original JavaScript. But PHP is used mostly by "businesses" with no budget and this is essentially the absolute rock-bottom of the "software" industry.

I think the language is the problem in some key areas. I started using PHP at the tail end of 2.x and remember trying to get a couple of endemic sources of bugs fixed in 3.x: register globals, requiring constant diligence NOT to ignore errors, and inconsistencies around things like parameter ordering for array functions or magic type conversion. Every time, it got pushback from someone saying it’d break too much code – at a time when there were billions of lines less PHP in the world, and when those were causing high profile security issues and app failures. I ditched PHP in the 2000s after getting tired of that, but picked up a legacy project a couple of years ago. Register globals is finally gone but everything else which I remember causing having to carefully train developers to avoid in the 90s is still a rake in the grass today.

I like PHP, one issue which I face with PHP though is, that it is difficult to create a self-contained docker image.

With node.js or java spring boot i can build an application with an http endpoint and create a single docker image with all included easily.

With php I need 2 distinct containers, e.g., nginx, php-fpm and the code mounted on a volume to the the containers. So it seems to be more difficult for setup and continous integration etc.

I would like to have one image with php, a webserver and the code. Is there something like that for PHP?

I don't really know what directed you to the nginx+fpm+volumes in the first place.

  FROM php:7.2-apache
  COPY src/ /var/www/html/

and this is it.

You want fpm for non hobby projects

Don't follow any advice to use Apache as a reverse proxy, or bundle php with a classic web server.

There are real application servers using an event loop by now, most notably Roadrunner (https://roadrunner.dev), FrankenPHP (https://frankenphp.dev), Laravel Octane (https://laravel.com/docs/10.x/octane#introduction), Swoole Bridge for Symfony (https://github.com/insidestyles/swoole-bridge-bundle).

In general, you can do a lot with OpenSwoole or Roadrunner. They are vastly superior (in a container scenario) to any other suggestion in this thread!

You can also use nginx’s unit docker container, which hosts php’s interpreter in the nginx process.

https://unit.nginx.org/installation/#installation-docker

I use RoadRunner for that purpose. It even has some amazing features you can enable as keeping the application loaded in memory between requests.

https://roadrunner.dev/

Had good success using Nginx Unit (distinct from normal nginx) for this. There's a unit-php docker image that can be used.

Yes, the apache[0] image will do what you want

[0] https://github.com/docker-library/php/blob/1c4b255f3e5ab610c...

You can't have nginx and php in the same container?

Does not docker recommend a single process story? Nginx is typically a reverse proxy in front of an application server.

That's just a generic recommendation though, really nothing stops you from having php and nginx in the same container.

PHP has had a built-in web server since version 5.

People use Apache or nginx because they want to, but because they need to.

The built in web server is awful on its own. Forget production usage, it’s hard to even use for a quick bit of E2E testing.

Unfortunately it has some really opinionated routing rules with certain file extensions, preventing you from having a dynamic URL with something like a .json or a .xml extension. Instead it will always try to look up a static file of that and serve it instead.

I can’t find the bug tracker issue for it but it was closed out with a message along the lines of “don’t use the built in web server for anything besides a toy”.

Luckily there are plenty of PHP Cli based web servers now that some other commenters have mentioned.

You can take full control over the routing using router script, then none of the default rules will apply. To be honest, I really dislike how many applications are wired around some Apache configuration or at least assume some specific hostname or path to be used for no reason. If it works with the built-in webserver, then it will work just as well with pretty much any SAPI.

The built-in web server can only process one request at a time.

I think using the php built-in webserver is not an option for a production setting.

Correct. From the documentation:

Warning: This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

the embedded server is great for dev, but useless for production. for example any url that contains a dot "." is considered to be a static file. so for example this path does not do what it's spposed to do /login.php?token=fghjjbjkkooll.rfcgg

Yes- apache with mod_php. It's the most common deployment by far.

What I went with was having both a web server (Apache/Nginx) and PHP-FPM in the same container image, held together by Supervisor: http://supervisord.org/

In my case, the Dockerfile looks a bit like the following:

  # Whatever base web server image you want, Debian/Ubuntu based here
  FROM .../nginx
  # Bloated packages for installing dependencies and also Supervisor
  RUN apt-get update \
      && apt-get -yq --no-upgrade install \
          software-properties-common \
          supervisor \
      && apt-get clean \
      && rm -rf /var/lib/apt/lists /var/cache/apt/*
  # Add repository for PHP 8
  RUN export LC_ALL="C.UTF-8" && add-apt-repository ppa:ondrej/php
  # Then we install PHP and the Nginx integration package (we use PHP-FPM)
  RUN apt-get update \
      && apt-get -yq --no-upgrade install \
          php8.2 php8.2-common php8.2-cli php8.2-dev php8.2-opcache ... php8.2-fpm \
      && apt-get clean \
      && rm -rf /var/lib/apt/lists /var/cache/apt/*
  # We will also need Composer for managing dependencies
  RUN curl -sS https://getcomposer.org/installer -o /tmp/composer-setup.php \
      && php /tmp/composer-setup.php --install-dir=/usr/local/bin --filename=Composer
  # Create directories, clear regular web server index directories
  RUN mkdir -p /run/php \
      && rm -rf /var/www/html && mkdir -p /var/www/html
  # Copy over config (whatever you have)
  COPY ./php_nginx/etc/nginx/nginx.conf /etc/nginx/nginx.conf
  COPY ./php_nginx/var/www/html /var/www/html
  COPY ./php_nginx/etc/supervisord.conf /etc/supervisord.conf
  # Copy PHP config (whatever you have)
  COPY ./php_nginx/etc/php/8.2/fpm/php.ini /etc/php/8.2/fpm/php.ini
  COPY ./php_nginx/etc/php/8.2/fpm/php-fpm.conf /etc/php/8.2/fpm/php-fpm.conf
  COPY ./php_nginx/etc/php/8.2/fpm/pool.d/www.conf /etc/php/8.2/fpm/pool.d/www.conf
  # Default run script
  COPY ./php_nginx/docker-entrypoint.sh /docker-entrypoint.sh
  RUN chmod +x /docker-entrypoint.sh
  CMD "/docker-entrypoint.sh"

Here's the entrypoint:

  #!/bin/sh
  echo "Software versions..."
  nginx -V && supervisord --version

  echo "Running Supervisor..."
  supervisord --configuration=/etc/supervisord.conf

Here's a snippet of nginx.conf, how to get *.php to be executed (put inside of a server block):

  location ~ \.php$ {
      include snippets/fastcgi-php.conf;
      fastcgi_pass 127.0.0.1:9000;
  }

And here's the Supervisor configuration:

  [supervisord]
  nodaemon=true
  
  [program:php-fpm]
    command=/usr/sbin/php-fpm8.2 -c /etc/php/8.2/fpm/php-fpm.conf --nodaemonize
    stdout_logfile=/dev/stdout
    stdout_logfile_maxbytes=0
    stderr_logfile=/dev/stderr
    stderr_logfile_maxbytes=0
  
  [program:nginx]
    command=/usr/sbin/nginx
    stdout_logfile=/dev/stdout
    stdout_logfile_maxbytes=0
    stderr_logfile=/dev/stderr
    stderr_logfile_maxbytes=0

Of course, it isn't necessarily the most idiomatic way to work with containers, but if you have health checks then it should still be fine. With a base image a little like this, you should then be able to build your own images with the code included, or use a bind mount. You can probably get images that work a bit like this pre-made, this is just how I do things, in case you're curious about what that might look like from scratch. Apache also has mod_php which would be even simpler, though generally will perform worse than PHP-FPM.

Curiously, this is also one of the few detriments of PHP in my eyes - when compared to something like Java that just spits out one .jar that can be run on anything with a compatible JDK version (at least with how things are done in the recent years vs standalone Apache Tomcat).

Well, at least in the past you could have run apache with mod_php. And the php files should also integrateable into the image.

Ironically enough, if people actually tried PHP, many would be amazed, especially at the quality frameworks. Productivity is very high in something like Laravel, and compared to JavaScript frameworks PHP frameworks are much more feature complete and well though out.

I'm a big fan of trying out different stacks, and I think a lot of people would love Laravel if they tried it. Give it a shot using PHPStorm and Laravel IDEA (free trials for both), and see what you think. Can't hurt.

As a PHP developer of 10+ years, large frameworks like Laravel and Symfony still bewilder me. I really have no idea why 99% of people would ever want to use them.

They add a layer of complexity over the top of PHP such that instead of learning how to write PHP, you need to learn how to write the framework.

Let's take an example right from Laravel's homepage:

     Authenticating users is as simple as adding an authentication middleware to your Laravel route definition:
     
     Route::get('/profile', ProfileController::class)  
         ->middleware('auth');
     
     Once the user is authenticated, you can access the authenticated user via the Auth facade:
     
     use Illuminate\Support\Facades\Auth;
     
     // Get the currently authenticated user...  
     $user = Auth::user();

As a developer, looking at that code tells me nothing. WTF is the "auth" middleware? Where is it configured? What's it doing?

Then we come to `Illuminate\Support\Facades\Auth` - another meaningless string with a seemingly arbitrary name. WTF is "Illuminate" and why is it in my code? Why do I need it to authenticate users?

So I have to go and learn all of this crap before I even begin to understand what the code is doing. And for every other thing I want to do with the framework I need to look up how to do it "the Laravel way".

The reason why many use frameworks like Laravel, Symfony, RoR or Django is often because they have non trivial needs. If I need to do something very simple like a small blog I might just throw something together on my own.

I personally have a large prject with a ton of code that was written in the last 16 years from when I was very inexperienced to now. After a while you realize that patterns are important, and you start building more and more features to make development and maintenance simpler and faster.

Here is a list of things I created over some years for that project: - Authentication system that supported different types of login. - Pretty routes. - Simple dependency injection container. - Emailing. - A templating system. - A scheduling system. - A worker pool. - Reusable forms. - Simple DB migrations in code. - Caching system. - A file storage system. - Data seeding. - Testing. - Websockets. - Asset bundling and versioning. - Localization. - Payment integrations. - +++

Sure, I could do it the JS way and find different packages instead of doing it myself, but I don't want to rely on a bunch of projects as that quickly can become maintenance hell.

After a while you realize that you're basically reinventing the wheel. Is Laravel and Somfony complex? Yes. Does it sometimes seem like magic? Yes. Is it hard to use, modify or figure out how it works? No.

You might not know why 99 % would want to use them, but I'd agrue that most probably should when the project achives some complexity. That way you can reap the benefits of the work and experience of thousands of contributors behind these projects.

I am one of those "I want to know what happens in the background" people too, and it's not that hard to figure out how Laravel works if you want to know. But most developers are not interested in how the framework they are using really works. The questions you have about what the auth middleware is, how it works, and what the Illuminate namespace is for(Laravel) is easy to figure out by checking the docs.

Laravel is definetly an opinionated framework, but personally I think most of the options are good ones.

> They add a layer of complexity over the top of PHP such that instead of learning how to write PHP, you need to learn how to write the framework.

To be fair, you could say this about many frameworks in many languages; Ruby on Rails is the first obvious example of this.

Well, I used to do PHP back in the day, and I know the language has changed and evolved a lot, but I've looked at Laravel thinking it would be something cool and interesting and productive, and it seems bewildering and bloated. Doing one simple thing seems to take a mountain of incomprehensible overhead.

Not to say it's bad, but even with some experience, I couldn't grok it.

> Doing one simple thing seems to take a mountain of incomprehensible overhead.

If you just need to do one simple thing, don’t use a framework :)

If you need to lots of simple (or complex) things, in an organised manner across a single project, Laravel is great!

(Having said that if you have an example of what you were referring to, I’d be curious)

> Laravel IDEA

Is that a fork of IntelliJ or did they just usurp the “IDEA” branding from JetBrains?

A framework-centric IDE seems silly. Like mini cupcakes.

Unsurprisingly it's a Laravel plugin for IDEA.

https://plugins.jetbrains.com/plugin/13441-laravel-idea

It’s the name of a PhpStorm plugin, which adds extended support for Laravel. PhpStorm is built by JetBrains on IDEA.

Laravel annoyed me deeply when they spammed the installation page with garbage like "Meet Laravel" and "Why Laravel?" I stopped digging into Laravel right at this point. Unfortunately, this awkward documentation style is typical for most PHP frameworks, have also seen it in the TYPO3 and WordPress docs.

Out of curiosity, in your projects where you use PHP with frameworks such as Laravel, do you do server-side rendering, or SPA applications? I prefer the former but I wonder what's the trend now for the people into Symphony, Laravel, etc.

PHP is a great web success story at so many levels. From massive sites like Wikipedia that have changed the world to the long tail of blogs and "Web 2" type decentralization.

Anecdotally I see also rude health: Wordpress already has an activitypub plugin whereas symphony based kbin is a very interesting proposition for a federated alternative to reddit that already sees traction. And Nextcloud is delivering data sovereignty and showing the way for personalized "clouds" here and now.

What is missing from PHP is really an easily communicable "story". Both at the technical level of the language and its tooling and at the community level and its vision.

This is not unique to PHP. Older ecosystems like C++ and Java, on which much of the world still runs, have a similar problem. But the singular web focus of PHP means it has more of chance to develop an attractive personna.

Its not easy but its very useful to have a very clear identity. Right now the tech world goes through an ML/AI fever (and associated nightmares) and a clear vision and purpose would, for example make it obvious how the PHP ecosystem fits into new developments and the broader client/server design.

Thank god. Imagine if the whole internet was as fragile as the latest opinionated twitter rockstar programmer with VC's money

Of the brainwashed elixir zealots trying to convince everyone to use phoenix for a 3 users internal dashboard

Fearless concurrency with actor model

> Slack uses PHP for most of its server-side application logic […].

Slack migrated to Hacklang in 2016 [1].

[1] https://slack.engineering/hakana-taking-hack-seriously/ "We started migrating to a different language called Hack in 2016."

Isn't Hack basically compiled PHP so that it is faster for FB's use case? I understand it's not technically PHP, but I imagine it is effectively still PHP, or is it more like what C++ is to C?

I understand PHP is fast adding any actual language features that Hack has over it?

At one point it was, but since then it’s become it’s own language with a completely new (JIT-based) implementation

At the end of the day if your software works and users like it, does the programming language even matter?

It does, language comes with culture, I'm polyglot and the amount of horrors I've seen in php3/4 days was on par with legacy cobol.

It was too sweet on effectful code around random maps (what's not to like, you can do whatever and spend hours trying to find the right combination of stdlib array_ functions until something happens).

Of course things change after the nonphp6. But if someone only knows and love php I'll check twice before working with him. I'm actually dealing with someone like that right now.

Yeah, the "culture" had its technical issues. But in real culture PHP people are typically good mooded, friendly and humble fellows.

So culture is a plus thing. Because the technical mishaps are there in any community with size (looking at you JavaScript)

It does matter. I can't offer an opinion on the modern state of PHP since I'm not familiar with its recent developments. However, it's true that certain programming languages and frameworks can facilitate writing maintainable, secure code, while others might naturally foster problematic, insecure code. It isn't to say that you can't write good code with them, but it can be unreasonably difficult.

Take, for instance, the PHP environment around the time the "a fractal of bad design" (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) article was published — which also coincides with the last time I worked professionally with PHP. During that period, PHP was plagued with inconsistencies, a tendency to hide errors, and insecure default settings, all of which encouraged writing bad, unmaintainable, and insecure code. Those aspects truly matter.

It's very unlikely these days for a medium sized and above software project to be written 100% in a single language.

I agree that it should not matter but there are people out there who really have strong feelings about PHP. I understand those strong feelings because PHP was very popular since it was on every shared host and it was super easy to quickly whip up scripts that render dynamic pages back in the day. That ease had consequences that PHP is trying to dig out from under to this day. I personally reach for PHP first for all my personal web projects. It's where I am most comfortable.

I write C++, Rust, Python, C#, and JS in various capacities both personally and professionally and I always go to the first language I learned whenever I want to prototype, PHP.

That said, I agree with the sentiment you are expressing. If the app works, and people enjoy using it, the underlying language only matters to other devs who might work on it and that is it.

Still do this day I don't know of any serverside language that you can just drop files into to update.

Next.js is a bit like this. In at least it does the 1-1 file to route mapping. Not drop in on the server but is so on the dev machine.

Maybe not for the user, at least not directly, but developer experience is something to optimise for.

PHP is also the one language whose choice can make an impact on users' experience, since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this?

There are multiple options by now. For one, PHP got a JIT compiler a while ago. That, in combination with the existing opcode cache, actually causes PHP to outperform its interpreted competitors in most cases.

Additionally, there are several application server strategies, sometimes with a process manager that keeps preloaded request workers at hand, sometimes hosting an event loop, and sometimes a request worker that gets partially reset after handling requests. This yields performance comfortably comparable to optimized Node.js apps.

In general, PHP has a highly optimized runtime, and we didn’t even really touch caching yet. Trust me when I say performance is not one of the problems PHP poses :)

And not to forget traditional web server caching. Since they mimick html files on the server, doing your app right, you can use the very mature caching options in the web server / proxies.

The most common defense I hear here is that the inefficiency just never mattered.. and if it did it was because the product was a blockbuster success and you could hire to rewrite the slow parts or adopt hack or whatever.

It does not when your project has not 100s of users hitting at the same time. And honestly, which application survives that at first sight and does not need to solve the problem one level higher (like building for load balancing, writer/read databases, etc ).

If you need it, Swoole and Roadrunner exist

> since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this?

I mean, you kind of answered your own question - they use caches like apcu or memcached. Apcu is just shared memory so its basically ends up being very similar to languages that don't do shared nothing.

If you do it 40 hours a week - absolutely.

One thing I really dislike about PHP is the global scope and imports. Introduction of namespaces is an improvement but it does not change the fact that everything is in global scope. The best practice for imports is to not include them outside of execution context, but it also makes it very hard to reason about what is actually being used by the file + you try to think about not loading files unnecessarily so it's not uncommon to add the import statement in the same file multiple times before using something and there are no type hints that say whether the include was imported or not. Which is more or less a consquence of the environment not having a proper runtime and everything being re-initialized with every request (in a runtime context, all files that would ever by used would be included, because they would be used eventually). I genuinely wonder how it came to be that a language developed specifically to serve web requests is not a loop, you would think that a runtime would be especially useful for handling requests and Facebook learned it the hard way, heck CLI input -> output programs are probably the only type of program where it would not be a limitation.

It looks like a report on quantity of instances (sites, frameworks, packaged setups) but doesn't go into other metrics like traffic load, users, PnL or other money-metrics. Say the top 100 websites were all to use PHP, that would be a very different story than none of the top 100 websites using PHP, but neither is reported. We have some "we are in the top 500" and "we have billions of page views", but not much else.

That said, how good or bad a language is might not be quantified or qualified to a point where all audiences are happy. How it's used vs how it's structured, where it's used vs. how much money it's making can all mean different things to different people. If you look at it from an academic (CS) perspective it might not matter how much money it makes if it lacks some scientific nuances. But the same works the other way around as well; it doesn't matter how cool COBOL, FORTRAN or lisp is if you can't run your massive eCommerce web app with it (there is a joke in here somewhere).

I love and use php but this article feels more like propaganda.

There's a lot and hate of criticism of PHP out there, so some praise and sane opinions are nice to balance it out.

Hate almost always comes from people who haven't used PHP in a very long time or touched it briefly at some point. Fanboyism serves no purpose. Experienced developers understand that programming languages are just tools each with their own trade-offs.

A good programmer doesn't really care about the langage itself, but rather whether the language is the right tool for the job.

For example, Erlang is painful to adapt to, but in some cases (example: if you build a Messenger app) it will be the best.

It doesn't mean that Erlang is a bad language at all, it is designed for a main purpose in mind.

It's normal to see junior developers and low-quality packages in PHP, JavaScript, Java or Python, it's because these languages are well-documented and rather accessible.

There is no point in making a language needlessly complex.

It's not any different to my point. You can use a hammer to hammer in a screw it doesn't make it fit for the job but it will work up to a certain extend. Similarly you can make a messenger app in PHP but you are better off using Erlang or maybe Node.

> Experienced developers understand that programming languages are just tools each with their own trade-offs.

Which is literally what the article said.

This doesn't make sense as a criticism. What do you think a blog post or an essay is?

To declare that blog posts, essays and propaganda are functionally the same thing is wickedly cynical, don't you think?

No i don't. Perhaps we have a different definition of the word propaganda?

Related: I recently discovered the "fanlisting scene". In the early 2000s, some people started a trend of creating fan sites (a.k.a. shrines) for characters in TV shows, anime, games, etc. These sites ran on simple PHP codebases, such as Enthusiast, PHPFanBase, and BellaBuffs. Someone interviewed one of the developers here: https://hey.georgie.nu/hg-jem/ (For some reason fanlistings tended to use .nu domains, because it was cool I guess).

Most of these fanlistings (and also the massive number of forums running on vbulletin and phpbb in the early 2000s) were created not by software developers, but people who had a passion. It was a road that a lot of people, especially girls, took to get into software development. I think that gender parity in software development might have hit a record high during that time.

PHP was not great in the early days, same goes for Javascript, but they made web we use today, I'm not going to use today's standard on yesterday's realities. Both have moved on and are much better off now.

Comparing to PHP, modern frontend is the true mess still though, there was never a simple to use SPA frontend in existence, they're all complicated, over-engineered and changing too fast to me, and now they are even adding what PHP was good at(SSR), frontend is the problem and getting even worse to me. The backend, be it PHP-laravel, Ruby-rails or python-django, even node-express are an already solved problem, the frontend framework folks adding SSR into frontend frameworks are simply insane to me.

NOTE I'm not against SSR, what I dislike is that they add SSR directly into an already over-complicated SPA framework, which will kill itself under its own weight soon.

I learned how to code when I was a kid with a mixture of C++ my dad showed me on our Dell running Windows 95 and PHP that I taught myself in the years after. All through my teenage years into my early 20s, anything I wanted to make I made in PHP. I still have some PHP projects online, but recently when I want to make anything, I set up an API in Python and build the front with a JS framework.

Is part of this just getting in on the latest trend? Definitely. I like scrolling through trending on Github, ya know?

But I was also just tired of writing PHP. Python is cleaner, so if I can do the more complex backend stuff in that, coding is more fun. I would say PHP and JS are about equally “unclean” but if it’s just frontend all those brackets and parentheses don’t become an issue as much.

Just one experience.

None of the cleanliness of Python will ever justify the dependency management madness it brings over simply using composer in PHP. It’s not in the same league, not even playing the same game. Give me composer and I’ll get you reproducible installations in CI and prod in three minutes. With Python? The gurus are still discussing the best package manager after the first two days.

I've never used composer, so can't really comment. I'll check it out sometime! Thanks for the tip.

javascript is way worse in cleanliness. PHP has the advantage of having been able to break backwards compat and fix some of its worst messes, even down to some questionable soft equalities. Also PHP nicely sidesteps the string addition/concatenation problem by having a dedicated operator for concatenation.

Even better, you don't even need to worry about those backward compatibility breaks if you wrote relatively clean, warning-free code in the first place. Only the very worst parts of PHP's legacy have been thrown out, and only after multiple years of deprecation notices. They've also been following semver quite strictly since 5.3, so you know exactly when to expect breaking changes.

Compared to the Python 2 to 3 mess and the constant churn that today's frontend frameworks seem to suffer from, I would say that PHP is more serious about maintaining backward compatibility than nearly every other language commonly used in web dev.

Fair enough!

I'm sorry but if your only reason why PHP and JS are less "clean" than Python is because they have brackets and parenthesis, you're sharing your inexperience, not your experience.

I meant "all those brackets and parentheses" as a synecdoche. I definitely don't mean my opinion to be a comment on any of the actual technical benefits of JS/PHP/Python. Just explaining the reason I've most recently preferred the act of writing one over the other.

Unfortunately, the current maintainers of PHP have not learned from the success of it. And are driving PHP into the direction of having the rigid structure that Java has.

It is so successful because people who build new things are different from people who are paid to maintain old things. That is why WordPress, Wikipedia and countless other successful internet projects have been created using PHP and not using Java.

People who build new things like simplicity and elegance and tools that empower them. While people who are paid to maintain old things like a rigid structre which gives you the feeling of "nothing can go wrong".

Also, people who build and run things do not like breaking changes of their stack. While people who are paid to maintain old things don't care about breaking changes in their stack. Because they are paid to then work around those changes.

In the last version (8), PHP has introduced a ton of breaking changes which makes the language more rigid. And therefore less useful to build new things and more cumbersome to maintain:

It broke the order of parameters in join statements.

It broke calling static functions without the need to declare them as static.

It broke adding properties dynamicly to objects.

It broke easy string handling for many functions where null was rendered as an empty string. This is especially annoying as you often get null values from the database. It makes sens to have a value for "Don't know the color of the car" in the DB. And it makes sense to render it as "Color: " in the user interface. The easy string conversion always was one of the strengths of PHP. Why is it sabotaged now?

Some of these changes have been objected to by the original developer of PHP and long standing contributors like the author of xdebeug, PHP's most popular debugger. Yet they have been implemented.

The big danger is that this trend continues and existing PHP projects will be choked to death by more and more breaking changes. Changes which have to be worked around by making the code of the projects more and more bloated.

PHP dev since 5.0 here. I think the severity of these breaking changes is overstated.

I’ve been able to keep several large business-critical projects up-to-date for years, even up to PHP 8.3, with little to no breaking changes encountered.

PHP 8 didn’t really break adding properties to objects dynamically, it just deprecated one bad-practice way of doing so. I remember worrying about this before upgrading, across my entire project with 40+ Composer direct dependencies, there were zero instances of this deprecated approach being used.

With other breaking changes there’s plenty of notice given (years, even). You can control where and how deprecation notices are logged, there really shouldn’t be any surprises at upgrade time.

“Old PHP” made it easy to write buggy or unpredictable code. Modern PHP feels more like writing TypeScript vs JS, there’s real safety and a much better developer experience now. PHP is having a resurgence for good reason, yes, it’s (marginally) harder to keep up with, but with proper tooling (PhpStorm, phpstan, etc.) the DX is leaps and bounds ahead of where it used to be.

I thoroughly enjoy writing modern PHP. I don’t have to worry about the language doing unpredictable dynamic type casting unless I want it to explicitly. The flexibility of old PHP is still there, but it’s much harder to shoot yourself in the foot accidentally.

I think you missed my main point: That people are different.

I have not doubted that there are people who like the more rigid structure which the current maintainers push for. I actually mentioned that.

But the success of PHP comes from the people who like PHP the way it was. Empowering them to write their own web projects with the least amount of code and bloat.

> But the success of PHP comes from the people who like PHP the way it was

I'm sure that was the case for many years, but I believe the successful resurgence of modern PHP is coming from the people who want to see PHP actively improving. Not those who like PHP the way it was!

PHP got a nasty reputation thanks to things like the "Fractal of Bad Design" site. Modern PHP has resolved (effectively) all of those early critiques.

The ongoing success of PHP comes from it continually improving :)

This move toward a more rigid and static typing pushed me to move to Java (which also pays more). After 15 years of PHP and over 5 in Java, I wouldn't go back now.

For a one-off script, I might still use a bit of PHP, if I didn't have javascript.

Wow, and here I was complaining that they are fixing the language too slowly…

Tacit acceptance of backwards-incompatibility is a pandemic in our industry, it was only a matter of time before PHP was infected.

I feel like a lot of this is mostly a commentary on WordPress.

Which it should be, since WordPress is such a huge part of the PHP ecosystem. Laravel is a distant second.

To talk about PHP without mentioning WordPress, whether in a good light or not, would be like discussing Ruby without mentioning Rails.

No doubt but it calls into question some of the reasoning in the article about PHP itself being so great. Like, people write a lot of VBA because of Office but I would not conclude that that’s because VBA is such an excellent environment to work in and more because Office is a great product and VBA is how you interact with it.

The article addresses that so no

Where? The article left the impression with me that without Wordpress the numbers would be less impressive.

I love PHP and MySQL. I'm self taught and I've been writing it since 2007. It has helped me solve real problems at every job I've had since which has helped me advance my career in tremendous ways.

I know PHP is not perfect and I've definitely contributed some hot messes of code in the past as I figured things out. Sorry...

PHP has let me code anything I've wanted so far, so it's a really powerful tool for me.

I'm the guy who built an automated home cinema using PHP and MySQL: I hit a button on a website and it tells a Raspberry Pi to start the desired show.

It selects a Dolby ad, some sort of vintage ad like dancing hot dogs, a couple of trailers, and the feature. It brings the lights up for the credits.

All PHP: https://www.youtube.com/watch?v=Q7YEVGWJjvI

For those of you who are proponents of other web ecosystems, I’m curious what benefits you enjoy? What framework or language do you use and what makes it great?

I use PHP everyday but we definitely have a lot to learn from others.

Starting from 1997, over the years I completely replaced PHP with Python. Apart from the language itself, which I like a lot for many reasons, some benefits that come to my mind:

    - Better libraries and frameworks overall
    - Better programmers overall, so more competent colleagues
    - Relevant in many fields outside web development
    - Allows to learn and use various paradigms, like async/multithread/multiproc...

I do keep track of PHP improvements. In fact, I keep a small personal toy framework as a way to test its new features. Some of these were very much welcomed, like safe mode + runtime typing. But some of these were just catch-ups and none of these are compelling enough so that I would want to start a new project in PHP.

Other ecosystem I'm interested in is Go, for other reasons.

I expect Python to be more stable over the coming decades than PHP.

PHP had a lot of breaking changes in the last version. Changes which got pushed through despite being quite controversial. I fear that this trend will continue.

Python had breaking changes in version 3, but at least those made the language better. PHP's recent changes were unnecessary and counterproductive.

As the "Pitch Meeting" producer guy would say: PHP is tight!

I think 77% sounds about right. But I can’t decide if it’s 80 or 95 percent of those 77% that don’t need php in the first place.

77% of top 10M sites - sounds like reeling in the long tail for effect, has to be way lower for the top 1K sites.

php is great to get things done quickly. great framework is cakephp, no one has mentioned it here yet

From php.net home page: « PHP 8.2 is a major update of the PHP language.It contains many new features, including readonly classes, null, false, and true as stand-alone types,… » That says all for me. Doesn’t matter if it powers half the web. It’s an awful programming language.

Can you explain why you think it’s an awful language? It definitely used to be lacking in features, but the improvements in the recent versions have been great.

Developer experience is awful. Variable names starting with $, heavy object orientism that seems like an after thought, tooling ecosystem is subpar, standard library is a joke, etc It’s a pile of crap and that’s my opinion

What’s wrong with the standard library? Seems pretty extensive. Supports all kinds of DB drivers out of the box, JSON, XML, drawing tools…

I agree that the language itself has many warts and the standard library is what it is, but I found the modern PHP developer experience and tooling is surprisingly good. At least when working within the Laravel ecosystem.

The internet is full of spam sites made with Wordpress. This means nothing for PHP as a language.

Spammers are also coders. We all do not like them, but they are. Their pages and system are part of the system.

If you are spammer and read this: search a different job and drop all tables before you leave!

The internet is not just wordpress sites...

But it overwhelmingly is.

43 % does not sound like it qualifies for the use of overwhelmingly

For me PHP was the logical evolutional step between HTML and JavaScript. Those three components combined with CSS are all you need to create something great on the Internet.

As soon as WASM is able to draw to the canvas, we can stop using the DOM for anything and everything and pick up where we left off with GUI development in the 1990s.

Dealing with text would still be a huge problem. Drawing text on canvas and making it selectable is still a hard problem, you have to think about all the intricacies of text (character widths, spacing, RTL, etc)

Very good point. This would require some standard library approach for much of this, which may or may not be feasible.

Since PHP 5.3 why would you want to use PHP instead of Java when you're effectively writing Poor Man's Java but without the benefits of the JVM?

Laravel really change the game for PHP!

I would argue Symfony did a lot as well. Their upgrade and release schedule is very good.

Reply on news.ycombinator.com