Live data from Hacker News

An Internet of PHP

timotijhof.net

291–300 of 333 posts

Re: An Internet of PHP

#291
post #290

Earlier quoted context omitted.

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.

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

Re: An Internet of PHP

#292

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/u…

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.

Re: An Internet of PHP

#293
post #288

Earlier quoted context omitted.

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!

Re: An Internet of PHP

#294

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/u…

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.

Re: An Internet of PHP

#295
post #288

Earlier quoted context omitted.

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 swoole. Much faster and easier to maintain. No separate FPM container too!

Re: An Internet of PHP

#296
post #288

Earlier quoted context omitted.

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.

Why would you enable xdebug in production?

Re: An Internet of PHP

#297

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

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.

Re: An Internet of PHP

#298

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/u…

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 7…

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.

Re: An Internet of PHP

#299

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/u…

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.

Re: An Internet of PHP

#300
post #212

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/u…

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…

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

Post reply on HN