Nobody cares about convincing YOU; you made up your mind a long time ago and could care less about all the nice things in PHP 8, the performance improvements and the massive ecosystem and huge parts of the web still driven by PHP.
I consult with startups a lot and routinely program in a variety of programming languages -- C++, Java, Swift, Kotlin, JS/NodeJS, Python, Ruby, PHP and a bunch of bash,awk,sed and perl. Most of these languages have been evolving to support most modern programming styles and have package ecosystems that are well managed and relatively easy to use.
The point is not to prove that one language is better. For the most part, for web development, there isn't much difference in productivity for a programmer competent in the language between (JS/NodeJS, PHP, Python and Ruby) Java is a little more heavyweight for pure web development but if you have a bunch of backend services that need to be reliable you will find the type system to be of help.)
What is more important for productivity is a deep familiarity with the frameworks, and tools -- the IDEs CI systems etc. that you need to build and deploy your solution.
The other important thing is the ease with which you can hire programmers for that language in your market. Here in India finding PHP programmers is easier than say finding Kotlin programmers but harder than finding Java programmers. But that is not the case in other markets like the US. There is also the issue of perception of candidates. If like you, a large majority of candidates think the language is legacy, you'll end up having to pay more to hire them (because they will be harder to find -- most of the extra cost will be search costs not salary costs.)
To the extent that the PHP community can convince folks that it is not a legacy language (and it really isn't) that is good for not just the language but the overall tech community. And this article furthers that goal well.
It think there is a reasonable argument that in PHP and JS there are an equal amount of issues. Inconsistent API, inconsistent language, bad data types, same speed .. just to name a few.
Not that I would not also prefer node over PHP ... But that is mainly because of C/C#/Java familiarity and frontend code reuse/familiarity than anything else.
Here’s something to think about: You and some buddies start a startup whose product is a complicated piece of medical software that uses Tensorflow’s inference but most of it is written in Go. Cool stuff, you’d never do that in PHP.
You’re getting ready to launch, and you’re going to need a marketing site and a site with documentation and help articles for users. Do you write that site in Go?
Hell no. You hire someone cheaper whose skillset isn’t systems programming or ML, and they spit out a templated site in a weekend that looks sleek and makes a good impression, and when you need more content you tell them and they turn it around in an hour, and you spend your time on the Go stuff.
And that market, the market for Good Enough sites that front Really Good products and are fast to work with: that’s a great market for a lot of people who want to sling some code, get things done, clock out at 5 and spend time with their kids in a nice house in the suburbs. That’s why for people who want that kind of life, I recommend learning some PHP (or rather, learning the super-common frameworks that use PHP).
Depends a bit on how fancy your Hugo-site is. Unless you’re just feeding markdown into a pre-made template, you’ll at least use the Go template syntax, since that’s what Hugo’s templates are written in.
And if you want to integrate Hugo with anything, Go is the way.
Depends a lot on your set-up. Many pair Hugo with a headless CMS for exactly this reason.
Even with a standard Hugo set-up, most content is in Markdown files, so one could also just train someone from marketing on how to edit those. Not exactly rocket science.
Hum... Probably. (I personally have a thing or two against Go, but yes, probably.)
Is the site some empty generic marketing that you'll put up to fill a feature list or is it meant to be useful? On the first case, sure, go offshore to somebody cheaper.
But on the second case, the time you can waste due to language, framework, software architecture and every other technical aspect is almost irrelevant near the time you will spend creating content. And you can't offshore the content if you want it to be great.
You hear that guys? Our boy here is working on very interesting medical data with too-over-your-head machine learning models. Did you get all that? He/she doesn’t clock out at 5pm like the rest of you, “cheaper” people.
Most likely your app doesn’t do shit and you are wasting your time patting yourself on the back and making underhanded comments. Once people realize how useless the apps you guys make are, you’ll be even cheaper than the guy you paid to make your “sales” website.
There’s a reason everyone shat on your ‘typical’ website developer for years, then they finally shut the fuck up, gave up on their dreams and joined a bootcamp to learn how to make basic ass websites.
The definition of a basic ass website keeps evolving. In no time, everything we all do will still be looked upon as making a basic ass website.
There's Hugo (mentioned elsewhere ITT) and I hear it's pretty good. If I were making my own personal site that I was going to spend a lot of time on and I was more into Go than I am (I like Go but prefer Node.js) I'd totally use it.
But if you need a site spun up for something and it's not the main focus of your business, shooting for the middle of the market makes a lot of sense. Wordpress is super easy to set up and create pages on, and there are tons of people with expertise in it. It's the kind of thing even non-programmers can administer, which makes it accessible to people who have skills in other stuff like marketing or social media management.
Hugo is a static site generator, it's like jekyll or pelican.
I was more thinking if you want to build an interactive site, what is the go to Go web framework?
Along the same lines with the Wordpress example, I'd choose Ghost for that as I come from the JS end of the spectrum also. I wonder what the Go based options are here? If I ran a Go shop I'd probably lean towards that (unless, of course, they're all horrible :)
100% agree. I can go to any number of hosting providers and have a working WordPress site or even a simple PHP Server up in minutes, the longest part of which is entering my credit card number. Then there's an almost infinite number of agencies that can use an almost infinite number of plugins to make it look nice, perform well and do lots of stuff. If the site isn't more than a marketing front-cum-webshop, honestly, I see no reason to use anything other than PHP.
There must be a reason why most languages don't have single good self-hosted CMS and PHP has like 8 really good ones with thriving markets behind them.
I mean most of the marketing websites are build with such PHP tools.
I think the news of PHP's death came a bit too early. Most people I know claimed it was dead during the time Node was getting popular and people started pushing for things like websockets to make updating pages faster. PHP couldn't do that so people said it would die, and honestly if you were in a startup or a FAANG at the time it looked like it would. Everyone was moving from a REST web 2.0 model to a "live, concurrent users" model.
But the trend didn't continue. People did it for a whilw, but then moved on to other models which still worked for PHP because few apps really need live data and concurrency like that.
The problem for PHP is that the reputation for being "a dying language" stuck.
That reputation is only viewed that way by a tiny number of nerds, typically with static language backgrounds that don't ship much code or product.
I added more value to a tech agency and their clients with PHP than several of the senior Java guys did combined. And they were talented. Just set in their ways and lacked a focus of getting things done and adding value.
They'd waste time overbuilding shit that nobody used because it was interesting to them, not that it would create value for the client or end-users.
Also, I took over several large Node projects built by hipsters and they are the messiest code bases I've ever seen. And I've inherited a lot of trash PHP ones over the years.
Regarding the concurrency thing with PHP - ReactPHP is very nice, PHP 7 and on performance gains were massive, and real-time (search, chat, etc) can be better handled by Algolia/Pusher/etc anyway.
The Node hype train had a great run. And I still like Node. But PHP is the language of getting shit done.
If you could predict the future, it'd be easy. And you can pretty much learn any language.
The question is who's hiring/where will you work, and what will you work on? In my area, there aren't many PHP shops. So it could be Wordpress or Facebook/Meta. PHP might be long-lived, but if you have to relocate to find a PHP job, does that help? Same with e.g. COBOL, Sharepoint, etc. And to be fair, what's rising has that problem outside tech centres.
Something popular like Python is generally a "better" investment, covers more bases.
I can’t tell if you’re arguing for PHP or against COBOL. I kid, but a lot of the other languages/ecosystems people will consider investing in are at least as old and evolving right alongside PHP. Many of them with very similar evolutions.
Ya that's basically what I was getting at. Not about COBOL, but about others that are similarly long lasting in the market, dynamically typed, and general purpose.
But what is, if not Visual Basic? Do you shoot for what has had longevity, or what's rising?
But what is, if not Motorola 68000 Assembly? Do you shoot for what has had longevity, or what's rising?
Pointing out that there is not absolute certainty about what is the top choice for a better idea does not make php, or visual basic, or 68000 worth spending your time on in 2021.
Ya, but PHP is actually still being used in a lot of agencies and in certain types of work. Far more than elixer and rust, probably just below ruby.
Also I wasn't pointing out what you say, you're reading into it a bit. I haven't used PHP in a long ass time. But it seems like not a bad choice for certain markets, at least as much as Python and Ruby imo
yes, with the sole exception of facebook. If you really believe people are going out and learning php just to get jobs at faceboook I've got a bridge to sell you.
What is this out of the park career path I'd have had choosing ruby? Can you share some more details?
Almost the best advice I can give to a developer is stop being fixated on language, and start being fixated on how to solve business problems, on communicating coherently (and like a human being), and being able to quickly grok complexity. The language you program in is almost the least important part of the offer (as long as you're competent in it)
That's a fair point, I implied individual websites instead of % of traffic on the internet. I interpreted this thread mostly to be about number of jobs, in which case I think the number of websites is more important than the percentage of traffic, but I should have been explicit about it.
How so? Ruby just released a new version with a JIT and new concurrency model. Rails is releasing a new major version later this year with a bunch of great improvements. Shopify, Stripe and others are putting a ton of improvements into the Ruby interpreter. Many large tech companies still use it. Many startups still use it. If nothing else, it's still a popular scripting language.
It's not as 'trendy' as it once was, but it's better than ever and still widely used.
> How so? Ruby just released a new version with a JIT and new concurrency model. Rails is releasing a new major version later this year with a bunch of great improvements. Shopify, Stripe and others are putting a ton of improvements into the Ruby interpreter.
Is speed the only measure of a programming language?
Honestly, I have no idea how it compares to PHP. If I wanted truly fast I'd use a compiled language. The point is more that Ruby is still being used and improved upon all the time; far from 'dead'.
> The point is more that Ruby is still being used and improved upon all the time; far from 'dead'.
Exactly the same with PHP. The handful of Rails devs I know bemoan the fact that fewer shops are growing their Rails/Ruby use. I did a stint at a shop that was mainly PHP, but they migrated most stuff to a combination of node and python, because "they couldn't find php developers". While it was sort of true, they couldn't find affordable php devs to work with the legacy mess (which was only 5-6 years old), and it was cheaper to have less experienced (but more) node/python folks come in and rebuild distinct bits of the older PHP stuff (at least, that was my understanding as an outsider - this happened after I left).
Some orgs are moving away from PHP - others are moving towards it. Same with Ruby, although I don't see as much movement toward Ruby as I do with PHP. But I do also see orgs moving away from each.
We'll need to look at it a year or two from now and compare oranges to oranges; the new Ruby JIT (YJIT) is optimized for real world web apps, not for some artificial fibonacci benchmark. Shopify is using benchmarks on actual Rails apps like their store front to see the improvement (https://speed.yjit.org/).
If I had to bet I think yes Shopify is serious enough about this to make Ruby faster than PHP - who is working on PHP internals now - Zend? In the end it's mostly a question of how much resources you throw at a problem.
I bet that there is a bigger demand for PHP devs then all the Rust,Go and Elixir combined.
So if you need a job you would probably have better chances knowing PHP then knowing Rust. But if in your area is raining with Rust jobs then go ahead and learn only Rust.
Python, JavaScript, Java, C# have all had great longevity, and much more popular, and can do anything that you can do w/ PHP and a whole lot more. Encouraging new programmers to learn PHP is cruel.
Java and C# are not website-first languages and have never been popular on webhosts. They're still very widely used, maybe even growing; certainly I'd bet that both have a better growth rate than PHP at the moment.
If you have to learn a new language for some reason and you don't know what to pick, go for something that has things you've never done before. Perhaps consult TIOBE for extra data points if you value current popularity.
Some popular choices in this bubble seem to be:
- clojure
- common lisp for some reason
- php is mentioned often here, also not sure why
- rust
- swift if you're into ios/apple, kotlin if you're into android
It depends on what you want to do. The problem is that PHP is hyper-optimised for serving up HTTP. That was great in the 2000s when the web was eating the world and the other options were Java, Python, and Perl, but is less useful in the current climate where there's so many more platforms and web development requires javascript.
By learning PHP, you are effectively locking yourself into the narrow niche of backend web development (ask me how I know!), whereas other languages have much broader target platform appeal.
As an example, the obvious competitor to PHP of Javascript already beats PHP by also providing backend web services, but also has support from AWS lambda, GCP Cloud functions, and even the somewhat esoteric embedded javascript for micro-controllers options.
> Do you shoot for what has had longevity, or what's rising?
Coming back to your original question - I think it's both. Depending on what you wanted to do, I'd pick Javascript (see above), then depending on what else you wanted to do, one of Golang, Python, C#, or Kotlin.
Best since everyone is thinking along the same lines Javascript/Python/Go developers are quickly becoming a commodity; e.g there are millions or tens of millions of developers who learn them as their 1st language (many of them are now hirable remotely).
Just worth noting I think...
Most languages lock you into one type of niche or another.
I'm quite happy with the Web niche, it's one of the longest lived, the stablest, the most open, and has some of the longest backwards-compatibility records around.
I can write a website today which will work in 25 years worth of client software! I think that's remarkable.
PHP pays my bills. I don't use it for web backends, it runs automations for a number of operations that glue APIs together, as well as exporting some custom document types and sorting out workflows/data.
Simplistically speaking, all I have to do is stick the path hashbang at the top of a php file, follow with the business logic and run it as a shell script. Clears any urgent ad-hoc request within a day.
Why are y'all arguing about this when you already learned like 20% of php by reading the OP. Learning enough of a high level scripting language like php to be able to be useful and productive in it is not some huge time sink, it's a few dozen hours of reading docs and tinkering
Those "few dozen hours" reading PHP docs and tinkering could also be used to learn Python, Ruby, or Javascript, each of which are almost certainly better choices with broader applicability and more modern ergonomics.
Python gets you web backend + ML, Javascript gets you web backend + web frontend. Ruby gets you a multi-paradigm language with nice ergonomics and cats. PHP gets you job offers customizing Drupal and Wordpress websites.
If you already know a "scripting language most popularly used for websites", then you could choose to pick up Rust, Nim, Go, Swift, or Kotlin instead. It's much better to have a new kind of tool in your belt than a second hammer.
The world is full of so many choices. PHP has a lot of incredibly compelling alternatives. Unless your job demands PHP, you're probably better off looking elsewhere.
I mean if you tinker around with programming languages a lot, odds are pretty good that you have also spent a few dozen hours on Python, and another few dozen on Ruby, and it's probably pretty hard to avoid spending dozens of hours mucking about with JS even if you don't like learning new languages just by virtue of it being necessary for writing web stuff or scraping stuff off existing webpages.
So yeah. Don't make PHP your first language. Probably not your second either. But if you've played with Python, and learned to write the simplest and clearest thing that can possibly work, if you've worked in C, and decided that's as close to the bare metal as you ever want to get, if you've learned enough Java to know when to use the SeriousBusinessFactoryProxyInterface, if Haskell has made you realize that programming is really just math... then sure, learn you some PHP, write a toy web project and discover that the simple things really can be simple.
I still don't know of any stacks where it's easier to write a simple, low maintenance side project that will stay up for years without issue, where multiple projects can share a $5 / month VPS, than the LAMP stack.
> PHP has a lot of incredibly compelling alternatives
There's no alternative to dropping a file on a LAMP server that goes with almost 0 maintenance for price that goes to almost 0 with 0 downtime whenever you make a change.
PHP is my tool of choice whenever I need to create an simple endpoint but don't want to deal with the hassle of running and monitor a full blown application. At best, the alternative to that is AWS Lambda but that's a wall garden in itself
> then you could choose to pick up ..... better to have a new kind of tool in your belt than a second hammer.
> PHP gets you job offers customizing Drupal and Wordpress websites
I get that there's a lot of legacy PHP sites, that you could end up finding yourself working on.
But there are still plenty of new Drupal and Wordpress sites being built.
You could also say that building a site with these tools as akin to "customising", as a lot of what you're doing is configuration rather than coding (but I would say sometimes JS + NPM is pretty similar).
There are still opportunities to push yourself with coding, with some fairly complex Drupal sites being built.
The core language itself and stdlibs, sure, it'd take just several dozen hours to pick it up. That goes for any high-level, C-family programming language around today, really. Can you do that and be nearly as productive in PHP (or any other language) as you are in your current daily use language? No: you need to invest in learning common design patterns, the library ecosystem, and tooling in order to be productive at a high professional level, and that is a task that takes longer and arguably never even really ends. Putting down real roots in a programming language is a large investment.
PHP has a lot of quirks that have to be learned so that they can be avoided. It's a bit of a time sink in that way, and the sort of time sink that doesn't accumulate new skills that could be applied elsewhere.
I started with BASIC, then shell scripting, then an internally developed language similar to COBOL. Being self taught I didn't really "get" data types, so the big names at the time like C and Java made no sense. PHP was a crutch that allowed me to learn and experiment with functions that were pretty forgiving. The eventual type related bugs I'd introduce into my code where it would work but not correctly eventually helped the concept click in my brain. I still don't get Java.
PHP was my gateway to _everything_, most importantly employment.
I don't use it any more, but in 2002 when shared hosting and deploying by uploading files via FTP was the thing it was a lot easier to get started with than Perl or Java (which I desperately tried to get into back then).
Oh yeah. PHP was the first language where I thought "hey, this thing that already works, I could rewrite it in exactly the same form in another language". I rewrote a Perl payment gateway thing that I had written almost alone earlier into PHP, made it OO and everything. No point whatsoever but what an exercise :P This was ~1997.
So it was almost the first language I used to make actual money.
> Is php the best language to spend your limited time learning in 2021? Almost definitely absolutely not as well.
Depends if you want a job or not.
At least in many European countries, there are plenty of them doing PHP.
In fact, when doing our Java and .NET consulting sales for Web projects, PHP is the adversary, not Python, Ruby, Go, Rust, or whatever is on the frontpage, like everyone likes to discuss over here.
PHP is an ok language for web frameworks. But for most other things, it is a poor fit.
There’s a reason why people are generally not doing scientific computing, machine learning, hardware integration, systems programming, etc. in PHP (yes, there are likely some obscure projects doing all of those, but in general, it’s not done because of limitations in the PHP runtime).
If you already know PHP, you can probably have a long and healthy career in that space. But if you’re new to programming, you’ll probably be better off learning Python or Rust, or maybe one of the platform-oriented languages like C#, Kotlin or Swift. JavaScript is also a very popular choice, because it’s currently the only thing you can easily use in the browser, but that might change with the rise of WASM.
people aren't doing web stuff in python?? django, flask, etc. are still very popular. maybe not as much as a few years ago, but people tend to stick to tech they know well, and python's web libraries are pretty battle tested at this point.
Lots and lots of people do web stuff in Python. There are a whole bunch of Python web frameworks like Django, Pylons, Flask, etc.
And there are big sites written in Python, too. Reddit, YouTube, some Google apps, Spotify, Netflix.
Rust is still a bit young, but also has several web frameworks like Rocket. No big case studies that I know of, but Rust still has many more fields of applications than PHP does.
Whichever way you spin it, building web stuff is a perfectly normal thing to do with Python. Thousands of companies do so, even big famous brands like the aforementioned.
In theory, true. In practise, they are most popularly used for the Microsoft and Android ecosystems, respectively. I’ve reworded it to platform-oriented.
Well, I’m not trying to invent scientific classifications here, but the common reason to choose one of said languages is to use them with the Microsoft/Apple/Android ecosystems, respectively.
I could be mistaken, but I can’t remember last time I heard of a C# project that wasn’t either targetting Windows as a platform (whether server or desktop) or running against some other Microsoft-thing like Xamarin.
In the early days of Mono, there were some attempts at using C# outside Microsoft circles, like building Gnome-apps with GTK#, but most of those projects have faded away.
I have around 500 c# .net lambdas. And several linux servers with .net on it. Also do almost all of my work On linux. Tho I’m starting to switch back to windows 11 with wsl2…
I have used PHP for years. Like it. Have accomplished some nice things with it. Think it's evolved nicely in recent years. Feel it's a great tool for particular problems. Will continue to use it. Will always be open to alternatives.
Will never understand why some people find that so offensive and will tell you that you mustn't use it or imply that you are ignorant or stupid for using it.
Pretty rare to find someone who writes a lot of PHP without also writing a lot of JavaScript. If there are JavaScript engineers who’ve never touched PHP then they probably don’t have much feelings about it at all
I haven't used PHP for years. I did some Python-based web stuff for a while. Python is a daily driver, but I still reach for PHP when I want to make something that responds to HTTP requests.
I haven’t used PHP in over a decade. I can never forgot how much PHP got wrong in terms of how application development on the internet would happen. The ergonomics of using it were just… bad compared to other frameworks that came on the market. I remember when rails came out and it was so mind blowing compared to PHP. The language was certainly useful for a time, and I’m sure the language has progressed since, but switching to PHP still feels like it would be a huge step backwards.
Since $x is an array, it will get rejected at runtime by `function f(int $a)`. So this `array` type is limited but useful.
You can also add annotations like `/* @var []int */`. External tools (psalm, phpstan) use annotations in their static analysis of the code and will raise an error if $x elements are not integers.
Of course, it's far from Haskell, but my experience with types in PHP is smoother than in Python. Though it was 2 years ago in Python, and the environnement has probably matured.
In my opinion, a worse problem with PHP is that classes properties are dynamic. `class A {}; $a=new A; $a->x=1;` is perfectly valid and will add a property to the object that does not exist in the class. There's no simple way to forbid this, even at runtime (hacking the magic `__set()` creates other pain points).
Comparing Rails to PHP is unfair given that one is a framework and one is a programming language. Compare PHP and Ruby or Rails and Laravel to keep things apples to apples and oranges to oranges.
A lot of people 10+ years ago were building websites by interpreting PHP and using the output as HTML. The language (at the time) seemed to encourage this. I agree that PHP is not a framework, but it seemed to have some opinion on how HTML was to be generated, which most languages don’t have. Also rails is 7 years older than Laravel, so my point still stands that PHP was behind the curve.
If your standard is rails then literally everything in every language before rails was "behind the curve". Currently PHP has frameworks that have caught rails, but Ruby's perf is still garbage.
Django was released shortly after Rails. Ruby and Python developers _needed_ to build something like Rails and Django because those languages didn’t promote the same type of script-as-html pattern that PHP did. Had more thought gone in to serving websites, PHP might enjoy more popularity today. PHP had the first mover advantage after all, but frameworks built in other languages were purely better in almost all categories.
I'd be interested to know what you think PHP got wrong with respect to web development? The majority of the web is running on PHP to this day, so at least in terms of popularity it seems people don't feel this way generally. Furthermore, if one were philosophically-minded, it could be argued that PHP's "shared nothing/one thread per page" execution model is the very quintessence of HTTP.
Except Erlang (and nowadays Elixir as well) has that for 30+ years already and it's done much better -- one green thread per request, and you can have 200,000+ of them at the same time on some fairly modest hosts, without any of them stealing run time from the others (as much as the hardware allows, of course).
PHP's "prescient" model demanded one OS process per request which is frankly absurd and I don't get how anyone views PHP in serious light because of this single fact alone.
Now think about how many companies/products need the power of Erlang vs PHP where PHP has more tooling, better ecosystem and far more available talent to choose from. Just because Erlang can perform better doesn't mean it is the right tool for the job. Performance is one aspect and PHP is good enough for lot of use cases while it has tons of other advantages that Erlang doesn't.
Not performance per se. It's a much more robust model of work that in addition is sipping hardware resources more efficiently (so DoS attacks from one user to all others are hard).
"How many companies need X" is not a discussion, it's an exchange of opinions and won't ever go anywhere, so I refuse to start it.
I was merely responding to the claim that PHP had "prescient" ideas. It didn't.
Surveys generally indicate that of sites where it is possible to determine the language, somewhere between 70% and 80% of them are running PHP. Of course, that figure will include a lot of WordPress sites.
What percentage of websites is it possible to determine the language? My guess is not many. Your metric self-selects for recognizing PHP sites because of Wordpress.
What alternative language do you propose? Not that asking for a source is unreasonable, but you seem to doubt that PHP has majority market share. Do you suppose that Node is more popular? Rails? Go? Flask?
I don't think any JS code can be worse than old PHP code. I've had to deal with legacy software written with PHP4. I was to port it to PHP7 since it was not compatible with PHP5.4+. The code used "register globals", meaning that variables were created on the fly from the parameters in the URL, the POST form data, and the cookies.
Requesting `index.php?something=X` implied `$something = "X";` in the global scope at the beginning of "index.php". And since the global scope was not limited to a file, tracing a variable through files and side effects was a nightmare. Even understanding the code intent was often hard!
Before PHP7, there were many elements of the language that were meant to simplify its usage, but had awful consequences in many cases. Even more because it bent the PHP community toward a quick and dirty process. "Magic quotes", the automatic escaping was one of those abominations. For any request input (e.g. POST form data), it added backslashes before single quotes. It was meant to protect data automatically in case it was inserted into a SQL request... It granted no security gain in this context, and was a mess for any other use.
Don't forget how <??> is built-in and was heavily abused to create insecure, incomprehensible spaghetti messes.
You'd have to try really hard to make callback labyrinths in JS match the mess that came out of the above combined with runtime-as-template-engine. This was basically idiomatic at the time.
Fun fact: to this day you still cannot have request parameters with “.” in them, because a dot is not valid in a variable name—even though register_globals was removed several major versions ago.
The value of a form input with the name “foo.bar” will instead be available under $_POST[“foo_bar”].
You notice the pattern. Mimic it. Struglle with it. Persevere.Endure. Will you reach perfection? Maybe not. No problem. Satisfaction is few layers below.
No doubt there are people reading this message who speak Japanese who will correct me, but ... 30 years ago I studied Japanese a little bit. One interesting feature of the language was that once a subject was introduced, there was no need to restate the subject if it hadn't changed, resulting in paragraphs like the one which intrigued you.
"I have used PHP for years."
The first sentence establishes the subject is "I".
"Like it." etc
Because this sentence doesn't have an explicit subject, it is implicitly the same one, "I".
As I recall, "wa" and "ga" were the Japanese particles which established new subjects. Say you wanted to talk about Bob's new car, you'd say something akin to "About Bob's new car, is expensive. Arrived last week. Has poor gas economy."
This is called pronoun dropping [1] and happens in quite a few languages, including Japanese as noted.
I had a friend in college who would always point it out (in English, where it's not very common). I still notice it often years later and I'm pretty sure it's thanks to her making me aware of it.
Interesting. The Chinese examples on the wiki page sounded completely natural to me and are in accordance with how I speak/interpret the language, but I never realized I was dropping pronouns due to their inference.
I was just trying to get a number of key points across calmly and succinctly without wasting time diving into a long-winded academic debate about whether or not I am "allowed" to use a programming language that I have used with success for the last decade!
Not sure that I have any tips for you. Other than that it is often helpful to remove unnecessary words when communicating. This is something I have become sensitive to over the years. I used to write a lot more voluminously but I find it is harder to convey messages to people when they are confronted with a wall of text.
I don’t find it offensive at all. I do, however, feel like the problems I worked on in many years of PHP were some of the least interesting projects of my career. It wasn’t the language’s fault necessarily but the types of things that language is most commonly used for? Also it was just a different time so PHP is possibly not the issue.
Here's a choose your own adventure for people new to the field. Pick something you want to build, then see which languages are the best suited. If you want to build several things, see which languages are the most recurring and versatile:
- Web frontend: Javascript/TypeScript
- Web backend: Javascript/TypeScript, Python
- Performant backend (where you manage threads and queues): Go, Java, Rust
- Machine learning: Python
- Command line scripting: Python
- Command line tools (binaries, eg 'ripgrep'): Rust, Go
- Mobile: Kotlin, Swift
- Systems/bare metal: Rust (discourage C/C++)
- Desktop games: C#, C++, GLSL, Rust (in ten years)
Mix and match.
The safest three to learn that give you the most flexibility are probably Javascript/TypeScript, Python, and Rust. You can build almost anything with those three.
You might also want to know a few languages were you're sure to get a job, and right now, it seems that Ruby on Rails and PHP are some really safe bets, compared to Python.
Sure, Rust is _fun_ but there's little demand for it right now in the market.
Rust is great, but if one is looking for a job in systems programming, C and C++ is what gets one hired, regardless of their flaws.
Recent example, while Android has adopted Rust for replacing their bluetooth stack, the newly introduced Android Games Development SDK focus on C and C++.
Or Microsoft, despite all their security speech, Azure Sphere OS and RTOS only support C on the official SDK, and the new WinUI components are all based on C++.
And naturally anyone wanting to contribute to the Rust compilers, most likely will need to brush up their C++ skills if they intend to mess with GCC or LLVM internals.
That I can fully agree on, after all it was learning systems programming via BASIC and Turbo Pascal, that made me adopt best practices in C and C++ from the get go.
So from that point of view, learning about lifetimes, modular code, and that bounds checking isn't evil are already good education stepping stones.
I've done shell scripts in PHP. Mobile development in Ruby, JS and haxe. Web development with Go. Nothing is stopping you, and if you know the language it is usually not to weird either.
I really would not discourage C, at all. Even encourage it, especially for embedded. It really makes you grok the lower levels in a way few other languages do, and it's still widely used.
I'll take anything on that list with static typing, and discard the rest. I've certainly enjoyed many of those languages but I wouldn't build anything with dynamically typed language unless I were forced to.
Does PHP still look like that in 'real life'? I was reintroduced to PHP last year via a Laravel based project and it looked nothing like that. It was all Objects and Models and Controllers spread out across a half dozen folders and scaffolding code generated via CLI commands. All actual HTML was generated with Blade templates.
I really like Python. It's what I reach for when I need something working quickly. I have a whole folder of one-off python scripts I wrote over years that I occasionally still use.
For very large projects, however, I advise against it. The dynamic type system bites you a lot in my experience. I prefer static typing.
None of the reasons listed exclusively argue for PHP; unconvincing. To start the article with the type system of PHP as a reason to learn it in $CY is insanity.
I’m going to try to offer a positive take from a non-PHP-fan perspective: yes it’s obvious both from vaguely checking in on the language’s progress and from the article’s presentation that PHP has made considerable strides. It’s impressive how much, over that time, it’s become less insular and much more readily adopted similar improvements to similar languages. The object over time, for example, more and more closely resembles TypeScript, and that’s a good thing.
I haven’t worked in PHP for I don’t know how many years, and I probably still have an unfair negative reaction to it. It has a strange cultural idiosyncrasy I find more limiting than anything about the language itself. But I’m happy to see it evolve and I’m happy to see it evolve alongside other technologies I work with more readily.
I don't really understand the reasons for using PHP outside of that people are already familiar with it and like working with it or want to find jobs in that area.
If someone is new to software development and in an area of the world where it's not mostly PHP shops, so bigger cities, I don't really understand the benefit.
PHP is often used to do certain things or it may be faster for you to whip something up in Laravel but if you had someone who was a complete blank slate and could chose any language and any framework in a town that doesn't have PHP jobs...why? What's the reason then?
I really think these articles come off really strange like they're trying to convince me as a "fact" but are really just nostalgia, like someone who goes off about how "cars were built so much better back in the day, there's still uses for older cars!" Maybe there is a grain of truth there and some real reasons behind it (repairability) but for 95% of use cases it's just that there's no contest, for a new driver, in an average situation there's no benefit towards going to an older car, and the guy going on about "older cars are the best", while they may have some weird reason that does actually apply to them (and as far as this analogy goes, I think Fortran is a better example than PHP in this case than PHP as for some maths applications it apparently still has an edge but that could have changed) honestly it's just nostalgia/trying to indoctrinate people...
Do you plan on creating a start-up that you intend to scale to a babillion customers? That you intend to hire teams of developers for? Probably not a good idea.
Are you a new programmer trying to figure out which language to learn first? Absolutely not. Python, Java, JavaScript, C# are much more flexible if nothing else. Anybody who tries to convince new programmers to learn PHP is doing them a great disservice.
On the one hand I have a few examples of huge, successful projects written in PHP and I know they are still around 20 years later and haven't been rewritten in another language. I use projects in PHP on a daily basis (Nextcloud, Rainloop, Wordpress) that work well and have been maintained for years. On the other hand I have a few comments calling out PHP without convincing arguments. Something is wrong.
I practice Python and Javascript daily, I've written PHP code 10 years ago, still use some of my code. I occasionally update PHP code on a website I manage. I've seen good things in the new versions.
Should I begin a new project today, I would not rule out PHP that fast. I like Python and Typescript, but PHP projects are often a breeze to install (unzip, done) and survive system upgrades and reboots easily as long as php-fpm runs. Projects in other languages need more babysitting. I know, I also use web software in other languages, including one I author.
PHP is dead simple to write too.
I would probably go for nodejs for something that requires Websockets or SSEs (or a compiled language). Otherwise, I'd seriously consider PHP because it does not require setting up something like uwsgi or celery, write reverse proxy rules, write init service files or running Docker. Put the files in www and it's done. Also no code for managing routes, the file system organization does this for me. No memory leaks, everything is thrown at the end of each request. The architecture is robust.
* It's waning in popularity, new programmers aren't being taught and there isn't a lot of incentive for them to seek it out
* Other languages are also good at making websites but many are more popular and more flexible - machine learning, video games, front-end web development, enterprise services (and sure PHP can be "enterprise" but many new cloud/apache projects are java first)
So yeah, I'm not saying PHP is dead...just that it's not a good investment for new developers and it's questionable for new projects.
> Do you plan on creating a start-up that you intend to scale to a babillion customers?
Not interested in PHP in the slightest, but how is this myth still going around?
Wikipedia, Pornhub, Facebook (initially at least) were all built on PHP. There are hundreds of other examples.
Laravel nowadays has an outstanding reputation and I doubt it's performance is lagging so far behind Django for example.
More generally, after all these years I still need to see a story of a startup that failed because they chose the wrong stack. There are some blog posts with spurious claims in this sense, but really, when has a startup with good product-market fit and a finely designed product ever failed because they chose PHP instead of something else?
Those startups you mention are 15+ years old, would they still choose PHP today?
Maybe you haven't heard of startups failing because of choosing the wrong stack, but I'll wager you don't hear about most startups failing because...why would you? Also, have you heard of startups re-platforming? Either because the current stack is falling apart or the company is acquired by a bigger fish and they need to integrate with other services so parts end up getting rewritten to Java/C#.
The fact is PHP is good for making websites, and that's all you'd really want to do with it. There are other languages that are good at making websites and they are more popular and have other benefits.
If you are building things with PHP and it's working for you, then awesome. But seriously, why encourage it?
How is PHP 8.1 an “older car”? Have you looked at the language and runtime recently? I hear stuff like this from people whose latest PHP knowledge is based on that ancient fractal of bad design article.
Yes, I have. I recently programmed PHP after 10+ year break from it and while some things were fixed many of my old issues with it remained. I would not recommend PHP to anyone unless they have an existing code base in it.
I think there's value in a large, established ecosystem.
Languages tend to go through a few years of flavour-of-the-week fads (think of the Vue/React/Angular competition, and all the also-rans that we can't remember now). If you get in too early, there's a fair chance you'll bet on the wrong ecosystem, and end up with unsupported dependencies or difficult to maintain code. In the worst case, you scrap the whole thing in six months and write it for a new framework to keep it alive.
PHP went through that phase back when "we've got to support IE6 users" was a legitimate talking point. You can be reasonably confident Wordpress or Laravel are here to stay.
PHP is also fundamentally a hugely battle-tested platform. It's been ran on 486s in the broom closet, and entire rack clusters in data centres. If you have some performance or usability problem, there's a good chance someone else has had it already and worked out a solution. With some new language, your odds of "never seen that before" errors are much higher.
A very pragmatic reason exists: deployment is dead simple for users with very little technical skill. Deploying PHP software is as easy as subscribing to a shared web host (expensive or not, but most will make your life easy), connecting using FTP/SFTP, and extracting a ZIP file into the main directory. Some hosts even skip the last couple of steps and let you apply a template with a well-known PHP CMS to get you started. Hey presto, you have a functioning web shop, business website, charity home page, or whatever other thing you want. There's a (PHP) app for that.
In comparison, other programming languages are hard to figure out. Python, Ruby, Java etc all need some kind of a package manager to install dependencies (PHP apps are self-contained) and need to have the correct runtime version installed (PHP just needs to be in the general neighborhood of what's required, since most broadly used packages seem to be written in a backwards compatible fashion). This is scary and unfamiliar, and highly technical. If you're deploying on a VPS (because rarely anyone has managed Python/Ruby/Java hosting services), you've now also become the sysadmin with full responsibility for the box, including patching and downtime. Compared with shared PHP hosting, it's bonkers.
You must have not worked with small non-profits with zero technical expertise and zero budget for hiring a consultant/permanent paid staff. Heroku is overcomplicated, and Docker/static sites (or the command line/running a server of any kind) might as well be alien technology. Some orgs know just that little.
I don't see how PHP fits into your example either.
Who is writing the code in the first place? They're uploading existing code to a shared host through FTP but then who wrote the code? Is it a prepackaged Wordpress? But then Wordpess hosts already exist.
If the developer is giving them a zip to upload, why can't the developer handle the deployment as well?
You moved the goalposts so far that the example doesn't make any sense anymore.
> Hey presto, you have a functioning web shop, business website, charity home page, or whatever other thing you want.
If we're talking about simple templates to open a store or a simple landing page there are so many no-code options like Wix/Shopify/SquareSpace/Square that I don't think PHP offers any significant advantage.
It's not that hard to get deplatformed, but yes, I can see your point. From an operational ease of use perspective they are strictly better than PHP, at the expense of trusting the providers to do the right thing.
I'm a PHP fan, but I think the following needs clarification
> package manager to install dependencies (PHP apps are self-contained)
PHP has Composer, which is one of the best things to happen to the ecosystem. Chances are, the piece of software you install will manage its dependencies in this way, and I'd be reluctant to install it if it didn't, as you wouldn't be able to update the software easily.
When you start on a minimal server installation setting up LAMP to the point that wordpress doesn't complain is just as much work as setting up RVM/Node and Passenger to run whatever language you want.
This is not accurate. While some shared hosts offer node or rails you will be limited by memory and it might not even run your app. The reason PHP is so good for shared hosting is that it runs per request and when you have rarely visited PHP application it requires basically no resources. You can have 100s of small websites sharing resources that get few visitors a day on single server and it will be fine. Try doing that with node or rails which are application servers that need to run all the time.
Heroku is fine but imagine you are agency managing 50 small sites. Heroku is like 7usd month minimum? You can pay 350usd month for Heroku or put it all on 20usd VPS and result will be same.
That's why all self-hosted CMSes worth something are in PHP world and there are very few in python/rails/node.
Also its not like PHP devs have been living under a rock for 20 years and don't want nice things. Git deployment is offered even by many shared hostings, people use SFTP+rsync, or things like https://deployer.org/. And there is very active market of server management tools like https://forge.laravel.com/https://ploi.io/https://moss.sh/ that combined with attributes of PHP will give you your own little super easy heroku.
And scaling... well most people don't need scale, you scale CMSes by caching anyway. And you can run pretty big scale just on one machine. And if you want automatic extreme scaling it's not like you can't do that with PHP https://vapor.laravel.com/
However the way rails apps works with phusion passenger is exactly what you are explaining. I can run hundreds of apps next to each other on a tiny VM. Once a app is loaded I don't have to rebuild the state on each request, if it is not needed anymore (or rather another app needs the resources more) it gets unloaded again.
Setting up passenger, nginx and git for pushing is also a job of 10 minutes max.
I get there is a market for PHP, I too recommend wordpress when I don't want to code something for someone. I just don't see it's 'simplicity' as argument.
> I don't really understand the reasons for using PHP outside of that people are already familiar with it and like working with it or want to find jobs in that area.
I look at it this way sometimes: there are the interpreted languages, the VM-based languages and then systems languages.
PHP is a good option in the "interpreted" languages category, if your problem domain is web-based, as it includes a lot of built in functionality for web-based problems. It's also open-source, reasonably performant, has an improved type system, has a C-like syntax and enjoys features inherent to a scripting language e.g. fast startup time, so would be a good option for lambdas.
Finally, one of the features that has been unreasonably good about PHP is the shared-nothing request model, which makes running a website on PHP a stable experience, in an imperfect world of weird state issues and libraries that might sometimes have a bug that leaks memory.
There are also other options in the "interpreted" category which I would fully expect people to also look into, however that's not to say PHP isn't a good contender for this space, given learning time is a limited resource.
However I would expect people to know a VM-based language and a systems-based language (or at least a bit of one) in addition.
Not a completely fair comparison. Then at least also tell readers that the 'old cars' you talk about are not in the museum or on the junkyard, but make up half of all the active cars on the road. That's not nostalgia.
> If someone is new to software development and in an area of the world where it's not mostly PHP shops, so bigger cities
In Europe there is a lot of PHP. Even in the bigger cities. And as someone who knows a lot of different programming languages, modern PHP with Laravel is pretty hard to compete with on a productivity basis.
- Is the "your app gets initialized and torn down for every request" true for frameworks like Laravel and Symfony?
- Does this model uses OS threads? Does it uses green threads?
And then a few remarks about the language:
- I feel like the Go model is a way better model for server software than async. Since PHP is mostly used for server software, I feel like they shouldn't go with async. Python is currently going through the transition and it's painful and long.
- It feels a bit weird to see how full of objects PHP is. Modern languages (Go, Swift, Rust, TypeScript) tend to use less objects, and more plain imperative code or slightly functional code in my experience.
> Is the "your app gets initialized and torn down for every request" true for frameworks like Laravel and Symfony?
Yes, though heavy optimization in opcode caching and JIT keeps it fast and the primary process manager today (php-fpm) generally keeps a pool of PHP processes persistent. Each request is initialized from scratch but there's no disk nor interpreter hit after the first.
There are, of course, frameworks that simply handle HTTP requests directly (amphp, swoole) that operate as persistent application servers, so state is maintained.
> Does this model uses OS threads? Does it uses green threads?
No. PHP webserver backends are generally a long-lived forking model.
> I feel like the Go model is a way better model for server software than async
Swoole [1] offers a coroutine and channel model. It's incredibly fast and the techempower benchmarks [2] attest to the raw speed.
> It feels a bit weird to see how full of objects PHP is
Agreed. It's often way over the top with Java-esque OOP complexity. It does depend on the libraries in question but the popular ones are very heavy (Symfony). You can of course write very simple imperative code just fine too.
I don't agree with Symfony being inherently "very heavy". As set of framework components, you can any part you find useful, and wire to together yourself, if necessary. e.g.
I would have to question how relevant a piece of core plumbing is to a regular user of the framework, as a regular user of the framework would likely never come across this class.
Also if you're working in the domain as a Symfony core developer, the idea of a ContainerConfigurator is not so insane, if you're developing a dependency injection container.
That"your app gets initialized and torn down for every request" is _the_ best feature of PHP. This may sound strange first, but it's true. With web applications written in any other language you have a stateful server running all the time with the following "problems":
* If you have a memory leak your complete server will get killed some time later when running out of memory
* If you have a bug which crashes your web server every running request is killed
* You get all the hard-to-find concurrency bugs when multiple requests concurrently can access some objects.
With PHP's model of (1) initializing and destroying all the state on every request and (2) every request running in it's completely isolated virtual space you don't have any of these problems.
And if you really want to have a long-running server with shared space you can have that too, take a look at Laravel Octane.
Folks bashing PHP like it's crap but praising any crappy thing if it's built with an esoteric lisp-based language. I mean, if you're starting out, chances are you're better off with js/py or even go but in the end you're paid for the types of problems you solve, not by the language you use... It just turns out that some problems are easier in this or that language, or even people who are good at solving this or that problem just happen to use an specific language (like the bioinformatics people using R when they could have used py).
The thing people forget about most is the LAMP stack. Although before node.js, PHP was simply a viable cost saving language to use. Now that WordPress moved to node however, it doesn't seem worthwhile to learn unless there are special uses you can get out of it.
But I agree with you about the whole "esoteric lisp-based language" comment. It seems like every other day I see something like that here and all I wanna say is "why?" I mean nobody cares about lisp except for the stallman-esque nerds. The best programming language is the cheapest one to create, support, and replace others with. Not cause some random programmer that thinks they know what they're talking about because they don't like it.
R is another language that it is bashed constantly, but it is generally much productive in its field (EDA and stats on structured data) than the alternatives like Python.
This. While I'm not sure I'd build a website or something with R, for pretty much anything data related R is a first choice. Even for big data on clusters or something. It's absolutely amazing at what it does. Super easy Fortran and C++ interop. Bonus that it's well enough known in academia and fields like statistics or economics.
I have. Guess I haven't tried to build something bigger with it. Seemed to me to be mostly something to share visualisations, not for building say, a whole CRUD site Rails or Django-style.
You're right - in my experience it's great for, say, creating an online calculator/simulator for something specific but it too fast becomes difficult when you started trying to add features like SSO, persistence etc.
Absolutely agreed! You can feel that R was made for its specific use case. Exploration, visualization, experimentation and modeling just __click__ for me in R in a way Python can never inspire.
In the Python ML world only the matrix libraries - numpy and similar APIs like torch.tensor and jax feel natural and click in my brain. The rest - data frame, visualization, scientific libraries; I'm not very sure how to explain it, but it always feels like some context switch is needed between using Python the language, and calling out to these libraries.
Promoting php is truly a head in the sand attitude. Yes there is valuable old software, but come on. Move on if you don’t have to touch it. Stop being oblivious and rejecting advances in programming language design. That probably goes to a lot of other languages too.
Hmmm... Most points in this article are shouting "yeah we have those too!!" but it didn't give any convincing arguments why I (or anybody who doesn't already know PHP) would like to learn and use PHP over other decent modern languages and ecosystems, which happen to have those points as well.
for me the biggest advantage is the size of the market. I know Python and PHP quite decent but I've never found any quick job (or long time job) for my Python skills. For PHP I have to convey some of jobs to others, I am getting so much of them (I even run some job advertisement site only for the purpose to redirect people pinging me with offers, really).
IDK what is a good salary in US/Canada, I live in European Union. My salary as WordPress developer is more than 4,5k USD/month and I see job offers with 8k USD as well (still for WP developers, this is my specialization and I know this field the most; I expect for better recognized PHP fields like modern frameworks like Laravel it could be more)
And yes, 4,5k USD/month is massively good salary for Europe.
On the other hand, I see many job offers with salaries being just a joke (idk if they find any good developers for such money)
Absolutely agree, 4.5K USD (3,970€) is certainly not a "massively good salary for Europe" although that heavily depends on the country. Here in Germany its about entry level for a CS major
Yeah, Europe has significant variance in a) reporting of salaries (some report pre-tax, others post-tax) and median income levels. Generally though, programmers are paid pretty well by the standard of the country they live in.
Where in the EU are good (web) devs willing to work for less than 8k USD, considering the current work market situation? I am in urgent need of those. :^)
I don't think salaries across Europe are comparable. There are huge discrepancies between locations.
For example, in Berlin it seems to me that average salaries are around 70k EUR/year (6.6k USD/month) and really good salaries are well above 90k EUR/year (8.5k USD/month).
You can see more data in https://www.levels.fyi, which it is skewed to the high side, but gives you an idea about what good offers are nowadays.
PHP salaries in the UK are decent. Perhaps a little lower on average than other ecosystems (the high-end has a tendency to use other languages), but I've definitely seen some well paid jobs. As a junior it may well make sense to start with PHP as there are just lots of jobs available, then you can move onto something else. There are other good options too of course.
Same here in Switzerland. And other than working on actual modern PHP these jobs are usually maintaining old software with weird custom scripting languages like typoscript xsml ...
I'd consider a PHP job, but only if they quarantee they don't have any of those legacy maintaining things lying around.
> I'd consider a PHP job, but only if they quarantee they don't have any of those legacy maintaining things lying around.
I see your point, but there is lots of legacy code (in any language) laying around and making shit tons of money for their owners - hence the need to maintain these systems.
I love maintaining old rails projects. No worries with that, MVC is making it easy to work with any project done by someone who knows the language. The language allows and encourages updating as well. It can be fun even.
PHP had no common way to do anything for a long time and you still see it from people writing PHP today.
My point was more that if there's money being made with some chunk of code, a sensible product owner would allow a modern refactor or even a rewrite in the same language to not endanger the long term success of said app.
The best part of PHP is the development model. You copy some files to a server, and load the page. That's it. It is really hard to beat how easy it is to iterate, even if the language is truly terrible.
I don't see how that makes the development cycle any better. I can just edit a file, press save, and it compiles and tests run automatically. If I'm doing something in interpreted languages, the code updates in memory.
Furthermore if I'm working with JS/TS, hot reloading even makes it so I don't even need to refresh the page. I can even inject code into arbitrary places with the debugger (as if I'm editing the source)!
So, all these other ecosystems are on par with the PHP...
I'm glad PHP adopting ideas from other communities, and that the community is becoming more cohesive, though.
Aside: I used to write PHP before (back in the 3 to 5 days), and worked for a big web hosting provider that had a big shared hosting customer base; PHP was by far the most popular technology in that space.So, I'm not trying to bash on PHP.
Javascript has come a long way, but I think there's still a different.
With PHP, you install the toolchain, save a file and the page becomes available.
With JS/TS, you install the toolchain, and then enter a complicated process of yarn/npm incantations in the command line to get the project working right. The manual may say "yarn add typescript" but in practice there's always more setup and configuration to be done before it works well.
For "real" projects, there's not that much of a difference between yarn and composer. For getting started, though, the process is a lot more involved.
Another problem is that running Javascript on the backend is almost completely different from normal frontend development. If you want to store state, you end up using the same (or even worse, a similar) programming language with completely different contexts and available libraries and methods. You can't document.createElement in the backend to tell the user that an operation succeeded or failed, even though that's what you'd do if you were working on a frontend file.
With PHP, you can't do frontend, so whenever you write frontend code, you can't get confused. In my opinion, this makes learning PHP backend dev a lot easier. It's only natural that you choose to continue working in the language you've started you development career in. You can see that by the fact that there are still people who swear by VB.NET, despite everything.
The JS ecosystem does have the advantage of coming with a debugger, but PHP users can get the same by hooking their PHP install into the PHPStorm debugger. I think it doesn't matter much which language you use at that point, it's just a tooling preference.
All in all, I think both languages have their uses. If PHP really was as bad as people say it is, it would've died out already.
I have seen people deploy php this way but I'm not aware of anyone who'd do it today.
Locally however it is save, alt-tab, ctrl-r and immediately you see the result. Absolutely no waiting.
These days I rather use Quarkus for this but until Quarkus arrived this was a huge advantage that PHP had over every other language and framework I was aware of.
Also the documentation was fantastic compared to most of the stuff I have had to suffer through on Java, .Net and even React and Angular.
Every thing you may reasonably wonder about was described in a clear, straight forward way and included examples.
Same. Our Node applications can take up to 10 minutes to build and deploy from a pipeline, but our PHP applications are deployed in <2 seconds by executing `git pull` on a VM.
That ship has sailed a long time ago (or you're just playing around and most languages will have a REPL nowadays)
Modern PHP wears a business suit and wants to buddy the "big boys" (Java/C#) of the world. You'll have deployment pipelines, strong push towards classic OOP, strict type checking etc.
I personally think ruby for instance is leaner in its dev process in most real world projects.
Sure, but would you have that in production for the company you work for?
One can also use old school CGI to serve their site, it’s super lightweight and you just upload the file at the right place, for almost any language. But that has been deprecated for the last 2 decades now.
I see a number artisans managing their business on pen and paper, and handwrite receipts.
It works for them, but I wont tell random people starting a business now to go with pen and paper, 99% of the time that would be a bad advice when there are much much better alternatives now.
Many people learn PHP as a first or at least as an early language. They don't want to know about deployment pipelines, CI/CD, or how to configure JDBC, they want to make a website store a list of names. You can't easily generate HTML from Java without some kind of templating language and framework around it, or a billion string concatenations if you're working without external libraries. ASP.NET has an advantage similar to PHP, but getting ASP.NET up and running has always been a chore in my opinion; there are a lot of moving parts that you need to configure right to get the browser to show you the end result.
I believe that PHP is the easiest way to just Get Things Done when you're starting out with a programming language. To deploy a website, you sign up for a free account somewhere, often with a free subdomain like mywebsite.cheapwebhosting.com, put the files on there and hit refresh. Seeing a result immediately is very motivating for beginners, and PHP doesn't require knowing anything complex like DOM manipulation to generate web pages the way Javascript does. If there were as many free web hosts that allowed the same ease of use for C# or some other language with inline templating, I'm sure it'd take off just as easily.
The language isn't as bad as people claim either, I think it's on par with languages like Python and Javascript. PHP has its quirks, like using a dollar sign for variables, it's really not that much worse than its competitors. Shorthands like $_POST/GET/SESSION are such a relief to work with compared to the "professional" languages with their frameworks upon frameworks and complex, layered objects representing state. It's a great tool for setting up a simple website, maybe even a very basic web shop, where the "big boys" are complete overkill. A website like HN doesn't need more than a few PHP files to function until it hits a certain scale, and even then scaling up PHP websites is relatively easy.
I think the real reason people hate PHP is because it's a language used by a lot of beginners and intermediate programmers who overestimate their ability and deliver subpar projects that someone else now needs to maintain or rewrite. I wouldn't want to inherit some kind of custom blogging engine written by an intern three years ago in any programming language, and because of its ease of development many PHP programs are just designed badly.
My issue with your approach is your first time programer still needs to:
- install/update PHP or go with the outdated version that shipped with their system.
- have a hosting service that will accept random PHP files
- know what their hosting's PHP version/configuration is to match it locally. For instance their hosting will keep the most secure config possible, thus no out of the box fetching of URLs.
- endlessly fight to find syntax errors as they are too new to have a linter. Depending on the PHP version they settled on they won't have error logs in one place but two.
- fight the endless stream of out of date tips and tricks left by 2 decades of PHP programers of various pedigree.
All of these have different variations for different languages, they all have their barriers and dead bodies in the closet. My take is that PHP isn't specially beginner friendly at this point, at least not as friendly as it was when it began.
Making a public website from scratch will be complex anyway, so they might as well go with a saner setup that uses a templating language and not write code right into the HTML. It won't be much harder and they'll have a fighting chance to find up to date tutorial to host their project easily (hosting a rails project on Heroku for instance could be miles easier in that respect)
PHP already has caught up to others with 5.6, these days PHP 8 doesn't lack anything found in other major languages.
What is still confusing is the standard library, but only for people who never worked with C/C++ before - as most of the native PHP standard library actually originates as a verbatim copy of the C/C++ libraries.
> use PHP over other decent modern languages and ecosystems
There's not a lot that is comparable to the PHP ecosystem when it comes to bespoke web-based e-commerce, or anything to do with bespoke customer or content management.
If you're trying to integrate with some weird 3rd party API, chances are there's going to be something written in PHP, or you can easily pay someone to do it for you.
Not only this, but there are agencies providing long-term support for parts of this ecosystem.
Other languages with strong ecosystems in this area would be Java, or Ruby, I think. I like Java for the same reason, and would probably like Rails. Anything that has "batteries included" is good to me.
My favorite thing about PHP is the execution model. Every single request is brand new and runs the whole program start to finish.
IMO that's extremely powerful in its simplicity and while you can get it in other languages, it feels like like a "core competency" for PHP (just like how async code is easier in javascript than in python, because JS kind of had it from day 1)
Forgive me for going a little off topic here but is it really true that JS was async-friendly from day 1? When I started using JS seriously 8 years ago, async code was horrible (callback hell, etc.) The web standards guys retrofitted native async way after the matter.
Doesn‘t this more or less mean "the only execution environment is event based, has a run loop outside of your control and calls your code whenever it wants" and "there is no busy sleep". So it was callback based from day one. Is that the same as async? I think it is?
I see this as the opposite and find it adds quite a load of complexity and prevent to do some form of optimization in an app that has its own server.
It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.
You do not need an _external_ server for a lot of languages. If you use node for example you can use the express package to run a custom server, or embedded tomcat for java
I suppose, but I've never encountered a production site that was using Gunicorn or similar as a true server. Usually that's coupled with something like Nginx or HAProxy.
So yeah, you technically don't need one for Ruby or Node.js, but I sure would.
Good point, but just to nitpick: I think that ipfs-js let's your external server be a process in someone else's browser, which is about as unserverlike as servers get.
Lots of languages and frameworks make it easy to be self-hosted with there own server. In Python, .net, Go, Rust this is quite common.
This means that your app can be a self-contained app + server and the server part can have some business logic as well.
With Go, .net, Rust apps (and potentially others) that's quite nice to be able to produce a single binary app that you can just run anywhere without installing any framework or setting up any external server and it's ready to listen to incoming queries.
That can even be a good enough setup for home things that are not exposed to the web and where setting up reverse proxies could be overkill.
PHP does have it's own built-in server as well, although it is not really meant for production use.
Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.
I've never actually tried writing CGI scripts with a non-PHP language (I've not really seen the point since it's usually more ergonomic to just use a language native-server interface like Python's WSGI).
Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).
>Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level?
I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.
> Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level?
I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.
Async code is a good way to achieve some level for performance in I/O bound workloads, but it's a pain for the programmer. Because of that I wouldn't say that it's necessarily a good thing that JS is async-first.
In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.
>In my opinion, high level languages should not expose async primitives to the programmer
Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.
Isn't that exactly the same as most web frameworks except without a few lines of code saying something like "when this URL is accessed, run this function to handle it"?
2. PHP is far less terrible than I remember (having used it in very early days)
I manage a WP (woocommerce) site for a small business. It's not my day job, it needs to be simple. Most of the "day job" is handled by content management users. I have written a fair amount of plugins though to enable custom functionality and the process is perfectly fine.
I looked at Ruby, I looked at Python, I looked at node. There's nothing as simple and, frankly, as mature aside from commercial platforms like Shopify that charge an arm and leg.
Yeah, I hear that a lot, and to me it always seems like a person curling their lip in disapproval from the nearby Ivory Tower.
I honestly always wonder: as opposed to what? Let's take my simple requirement, a small business ecommerce store that's not going to look like trash and where non technical users can make pages, edit descriptions, etc.
I can do: WordPress, Magento, or I can pay a SaS provider. Essentially both do it yourself approaches are PHP and Magento has really sabotaged itself with the complicated migration. SaS means higher costs and if I want custom functionality (and yes, the business needs it), it ranges from impossible to possible but a headache.
So here is a business that is now online for a minimal cost for two years, allowing great flexibility for me, while allowing completely non technical users to get crap done.
I've used php extensively in the past decade. You could kinda of say your argument about any modern web language. If I'm already comfortable in php, .net, node, ruby, or heck even java, for making a web app, do I really "need" to learn another? Not really. Every one has a different way of doing things, sure, not every different thing is better, but it is different. I think just people like to learn about multiple, but sure, you can always be stubborn and stick with your single hammer.
The two things I can think of quickly, that I like about php, over another, is the ease of code->browser. You have to manage 0 build configurations or pipelines to get what you want working. Just download the files and open a browser. The second, is 100% transparency with third party libraries. Because of the lack of ability to compile, when I download a third party library, I'm getting their actual true source, and can much easier, navigate and understand the library right through the ide, without having to read a bunch of docs online and that it's true to source. Being able to control click into third party libraries is quite liberating.
1. The develop-try cycle is fast: In PHP if you change some code it will be immediately visible - no server reload needed. That's because the "application" is reloaded at every web request. There is no application server.
2. The PHP ecosystem is quite mature, and packages are of good quality in general
3. Dependency management works well. You will rarely end up in a state where your dependencies are incompatible between each other (something that happen often with npm for instance)
For me the main turndown of using PHP is when I need to host the PHP website, php-fpm and Apache+mod_php seem to be the only two options. (FastCGI doesn't even have a proper specification).
I would be a little bit careful while using swoole. They added some code that loaded code from a third party server [1] (a core developer who seems to be located in china). Even though it seems like they removed it doesn't bring a good feeling. It seems like there were also some disagreements with a contributor who maintained the website of swoole and he forked it [2]: https://github.com/openswoole/swoole-src
Excellent article. Learned much for this even though I have used PHP for about 20 years. PHP has vastly improved since version 7 - both in terms of language features as well as in terms of performance.
However, error handling continues to be an issue. It isn't uncommon for PHP to fail silently. That would be one complaint I have against PHP.
PHP is perfectly fine, and all of the "better languages" are only better in an academic sense. But you can't really use PHP. It's too uncool. If you use PHP in 2021, you had better have a really good understanding with your manager, because your manager may read that PHP is "bad" or "a fractal of bad design" and start to question your competence.
I think PHP gets all the clapping when in fact the statistic that the majority of the Internet uses it to power its services is misleading. Let's face it, Wordpress is a great project, it could have been written in Perl and it would still have had the perks of being Wordpress. When people use it, they don't know what happens behind, I think WP is the perfect example of what a good extensible product is and how it can build an insane ecosystem around it. The plugin architecture is there since 2004, it was and still is very ergonomic. Though Wordpress was not unique in that time, phpBB, vBulletin should be mentioned.
The closest this post gets to supporting its thesis is this section:
> You might have heard people say that PHP was "doing serverless before serverless was a thing", and this is kind of true.
I believe that PHP is...not bad I guess? I'm sure it can make good things. But after reading this I have no idea why I would pick up PHP over any of the other capable tools out there.
Because too many people learn only Javascript in their pRofeSSioNal WeB dEv BoOtCamPs so the only thing they know is JS. Why learn a solid backend-focused language if you can throw JS at it?
Because Elixir has transparent parallelism and trivially scales to 2000 reqs/second on a $5 VPS even though it's a dynamic language, oh and because it has LiveView which eliminates the need for most of the JS in a project (if latency isn't critical), so now a backender can take care of 100% of a web project.
I worked with PHP 9-10 years ago. Still not impressed to this day. Why should I use it? Terrible type coercion that can and will catch you with your pants down is my chief complaint -- that alone is enough for me to never touch it again. I want predictable tools, not something I actively have to fight against so I can get my job done. How is this even considered productive?
So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
But companies might want to use PHP, because it has a rich ecosystem, which handles corner cases.
Chances are, if you want to send out bulk email, or connect to a payment provider, there's going to be a library in PHP that allows you to do that, often with long term support from an agency.
A corner-case I recently had was needing to decode an email. There's a function for that: quoted_printable_decode. This is a common situation for PHP. If you have some sort of issue around the web, there's likely to be a PHP solution.
And if you're a small business that needs a bit of bespoke software written, then you can easily hire someone, and know a decade later, you'll be able to hire someone if the requirements change.
Much of this can also be said of the Java ecosystem.
Just recently, I was using a small business that managed their bespoke business process built on a PHP CMS. They don't need 2000 reqs/second.
It's not that I never tried anything else. I got through 8 languages and made what I feel is an informed choice.
> Much of this can also be said of the Java ecosystem.
And yet, so many programmers and companies moved on from both Java and PHP to other tech and are managing very well. The company I work for has mere 6 backenders and we serve millions of visitors regularly without ever hitting >70% CPU on 3-4 servers.
Citing the entrenched state of affairs is not an argument either. It's an appeal to statistics (a good chunk of which are flawed as well).
I'm not going to try and convince anyone to stop using PHP or Java. Truth is, most programmers want stable predictable careers and there's nothing inherently wrong with that. I simply am not in that group.
> So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
I gave some reasons, citing problem domains for which there are stable, supported solutions in PHP. e.g. payment gateways, email handling, and citing the availability of programmers who can support medium bespoke or tailored systems. This isn't an "appeal to statistics" it's a strength about the ecosystem.
Similar to Python having many solutions and libraries built around data science.
> I'm not going to try and convince anyone to stop using PHP or Java.
None of what you enumerate is game-breaking, at least in a chunk of the programming area. You seem to be referring to an area where people pay pennies + have almost zero programming experience so they want to launch a project with clicks.
Sure. In that area PHP still more or less dominates. But I thought we were discussing the actual programming?
> I thought you were asking a question.
That's exactly why I said what you quoted me on: to reassert that I am looking for a good answer on "what does PHP do better" and I am not in fact seeking to change hearts per se.
> You seem to be referring to an area where people pay pennies + have almost zero programming experience so they want to launch a project with clicks.
Over my career, I've worked with companies using PHP in sales. One of those had over a million customer subscriptions, the other was a multi-national looking at PHP for a greenfield e-commerce project. I noticed working in Europe some high-growth agencies that use PHP.
> So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
> But I thought we were discussing the actual programming?
Your original question just said "use PHP". PHP is a general purpose web scripting language. It's similar to Python or Ruby. It is generally more performant and later versions have a gradual type system. It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production, as it avoid bugs that can arise around stale state, multi-threading and it keeps running if other libraries have bugs that leak memory.
Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.
Arguably, the thing that would make you use it over Python, or Ruby, is the ecosystem, especially around content management and e-commerce, as the language itself is roughly comparable to others. Also I think there are more agencies that support PHP, rather than Python or Ruby.
> It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production.
I think we have a vastly differing definition of "in production". I'll agree PHP was good enough for plenty of things, and likely still is. But good enough in general to run things in production as it's understood today? You'll find that many people will disagree with you here, not just me.
> Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.
That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now. Happily Erlang/Elixir are having lightweight and transparent parallelism and concurrency for a long time now. Languages like Go and Rust also progressed very well in this area so I am looking to work more with them in the future as well.
---
I think you and I are not aligned on what is "successful" or "good enough". You seem to insist that statistical success speaks something of the merits of a technology, and this is where I and many others disagree: people just adapt to what's given to them. That doesn't say almost anything about if the thing is good or not. People simply get what they can. Back then PHP was available so they took that. The rest is post-hoc rationalization. Stretching the simple and isolated historical fact "people used PHP because there was nothing else viable at the time" to mean that "PHP is good and successful" is where I'll disagree with you.
But yep, we severely digressed from the original discussion. I am OK with that though.
> I think we have a vastly differing definition of "in production".
Running software that customers use, directly or indirectly.
I've supported servers running PHP and Java software in production. The shared-nothing per-request nature of PHP meant I didn't have to deal with a bug in a misbehaving library causing memory leaks and taking down the application server.
> That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now.
PHP's problem domain has been web-based e-commerce and content management systems. In this area, PHP powers most of the web. You'd want to use PHP in this field, over other languages. Every improvement around PHP has been to advance this goal, such as the recent addition of gradual typing. There's no question of "catching up" in this area. That it is broadening out into different areas, great.
> You seem to insist that statistical success speaks something of the merits of a technology.
If the technology doesn't have a marketing department, or large companies forcing people to use it, then arguably, this does, as otherwise people would just use something else.
There have also been many other qualitative improvements to PHP over the years. I also mentioned its shared-nothing architecture, which is a qualitative, not statistical aspect behind PHP's success, as it has proven to provide stability in production. People use PHP because in certain problem domains, it is qualitatively, and statistically (assuming you mean, it benefits historically from a wide number of successful, maintained libraries) the best tool for the job.
Elaborate? Every language can be used, I stand by that statement. Sure they have very differing levels of easiness to start with but all are usable regardless.
I mean, because I know them already and I would have to learn PHP? But I'll give examples of what I wanted to see for languages I've done amounts of work in:
*Python* A disgusting level of flexibility (probably too much). You never really get trapped into anything, you can even (but should not) overwrite functions during runtime. You can make and break all the rules. Supports a number of modalities (often badly). Really killer console-based debugging tools (I love pudb for instance).
*Elixir* Insanely durable data/process model that makes it incredibly difficult to damage a working path through a non-working one. Never have your entire web app crash again. Pattern-matching and message-passing based language makes expansion easy and low risk. Macros are best used carefully but when appropriate are a breath of fresh air.
All the languages are turning complete. By definition you can solve any problem with any of them.
Hey if you don't like PHP please don't use it. I 'd hate to bring the culture of tiny packages, fake compilers, transpilers and weekly trends to PHP. Personally I use php because it works well and fast and still supports my 10 year old websites, not because it's cool.
Using ASP and want to calculate an MD5? Oh, you need to pay an add-on for that. Want to send an email? Ditto.
Then there was PHP, with all included (and cheaper hosting, because Linux). I started working on a web shop and after a month ASP was legacy and PHP the new cool thing, together with MySQL instead of using... Access as "database" in ASP.
I was new to the world of software development in 2000 (in high school) but immediately loved PHP / MySQL. Made it easier for me to stand up websites for my two bands and integrate more dynamic and database-oriented features into those sites. And hand-wrote JS for things that at the time seemed cool (silly in retrospect hover effects).
It was the SQL part of the book that helped me build the SQL skillset that is an integral part of my day job.
A compiler translates code from a source language into a target language, normally targeting either physical hardware or some virtual machine. That is not what happens when "compiling" - or more accurately, "transpiling" [1] - JS-related software where what often feels like the JS-related dialect of the day (coffee-, mocha-, type-, tea-, frappucino-, latte-, pilzener-script) is converted into the resident JS dialect, discombobulated through some language feature thingamajig, transmogrified by some other package-combining gizmo (not the same gizmo as you used last week, that is now ancient technology, the new one is sooo much slower^Wbetter and has a snazzy content-less website to prove it), mixed and matched with a bunch of related packages many of which are marked with dire warning about bugs and staleness by the helpful package manager thing (which you had to update before even trying to proceed since the current version was no longer supported even though you're running version 12 and the box stated you needed at least version 9), uglified (as if it wasn't ugly enough already) and zipped up.
Doesn't all that make you long for the days of ./configure --prefix=/somewhere/sane && sudo install -d -o yourusername /somewhere/sane && make install? Just add empscripten to the tool chain and you can do web things with it, sort of...
That sounds fairly childish. Aside from the very obvious fact that you'll miss out on a lot of cool stuff, if you don't agree with the value judgements of your peers, the problem most likely resides with your choice of peers.
Red flag just means that you take a close and critical look - not that you automatically dismiss. And those "peers" are the people on the internet - f.x. blog authors.
good, I'd say. I'm not waiting half an hour in a queue in front of a hipster ice cream parlor. when I go into nature I have a good chance of actually finding some peace b/c I do not go where Instagrammers take their selfies. I'm not torturing my soul on TikTok. I use choose technologies conservatively instead of by hype cycle. List goes on.
I would love not to use it, but I'm compelled to. It is not only my choice, but the choice of others who are not interested in new languages (assuming that Python is new language...) and prefer to use PHP because they don't know anything else.
So yes, let me express my antipathy toward the PHP language and its ecosystem.
I work not "well". It has hundred of issues that are not, and will never be addressed. Like the inconsistent choice of function names, the antic (if not prehistoric) way of extension managing, the clumsiness of xdebugger, the bugs in the PDO library, etc.
I spend 80% of the time trying to figure out "a hack", and spend too much time on php.net & stackoverflow hunting for the right answer.
Yeah, the area between "backwards compatibility at all costs" and "progress" is full of potholes. I think PHP was to mach on the "backwards compat." site of that gradient, I think that some bc breaks are onavoidable when improving the language itself and its standard library.
Sure, it would be nice to have something like rusts "editions" (and I am sure other languages share that concept to some degree) where we could have the runtime support all code that was valid before, but that comes with its own complexity.
As someone who still owns their rent coding PHP, I really enjoy the development of the language from php 7 onwards. It certainly feels better in any way compared to the 5.x or even 4.x days.
As long as we do not get another python 2 vs 3 disaster, I am happy.
Php change from 4.x to 5.x broke my web sites and I still don't trust php after that. I guess they might do it again from 7.x to 8.x, we'll see.
If having the same code working for a long time is the most important for you then you should probably use java or .net. Maybe c++ also but that is not as popular for building web apps.
PHP are deprecating language "features" from 7.x to 7.y.
It's very hard for me to treat a language seriously when I could write code that simply won't be valid PHP in 2 years time, or worse, behaving differently.
Given the severity of some past PHP vulnerabilities, being on an old version can certainly be a problem.
> I guess they might do it again from 7.x to 8.x, we'll see.
I found the transition from 4 to 7 oddly easy, but that might just be the conventions i was using. I don't know about 8, don't plan to use it until i have to
I made my homepage in PHP, nothing important, but I spent some time doing it and I liked the result.
Then I didn't have enough time to maintain it, and I stopped paying attention to it for a while.
Later I checked my homepage again, the webhosting company updated the PHP version, nothing works anymore. It is not simple to fix, so I gave up.
I am not going to spend the same amount of effort on making my homepage in PHP again. Trust is easier lost than gained.
I would still be willing to code something in PHP for someone else, because hey, if it stops working in a year or two, it's their problem, not mine. But I would warn them that something like this is possible, and in my opinion likely to happen.
467 comments
[ 2.1 ms ] story [ 341 ms ] threadYou might as well try to convince me I should start my next business with cutting edge software written in Fortran or COBOL.
The point is not to prove that one language is better. For the most part, for web development, there isn't much difference in productivity for a programmer competent in the language between (JS/NodeJS, PHP, Python and Ruby) Java is a little more heavyweight for pure web development but if you have a bunch of backend services that need to be reliable you will find the type system to be of help.)
What is more important for productivity is a deep familiarity with the frameworks, and tools -- the IDEs CI systems etc. that you need to build and deploy your solution.
The other important thing is the ease with which you can hire programmers for that language in your market. Here in India finding PHP programmers is easier than say finding Kotlin programmers but harder than finding Java programmers. But that is not the case in other markets like the US. There is also the issue of perception of candidates. If like you, a large majority of candidates think the language is legacy, you'll end up having to pay more to hire them (because they will be harder to find -- most of the extra cost will be search costs not salary costs.)
To the extent that the PHP community can convince folks that it is not a legacy language (and it really isn't) that is good for not just the language but the overall tech community. And this article furthers that goal well.
it's quite a nice language, and for many many cases is certainly fast enough these days.
Not that I would not also prefer node over PHP ... But that is mainly because of C/C#/Java familiarity and frontend code reuse/familiarity than anything else.
You’re getting ready to launch, and you’re going to need a marketing site and a site with documentation and help articles for users. Do you write that site in Go?
Hell no. You hire someone cheaper whose skillset isn’t systems programming or ML, and they spit out a templated site in a weekend that looks sleek and makes a good impression, and when you need more content you tell them and they turn it around in an hour, and you spend your time on the Go stuff.
And that market, the market for Good Enough sites that front Really Good products and are fast to work with: that’s a great market for a lot of people who want to sling some code, get things done, clock out at 5 and spend time with their kids in a nice house in the suburbs. That’s why for people who want that kind of life, I recommend learning some PHP (or rather, learning the super-common frameworks that use PHP).
Yes! https://gohugo.io/ would be a great choice for that kind of thing.
And if you want to integrate Hugo with anything, Go is the way.
Even with a standard Hugo set-up, most content is in Markdown files, so one could also just train someone from marketing on how to edit those. Not exactly rocket science.
Hum... Probably. (I personally have a thing or two against Go, but yes, probably.)
Is the site some empty generic marketing that you'll put up to fill a feature list or is it meant to be useful? On the first case, sure, go offshore to somebody cheaper.
But on the second case, the time you can waste due to language, framework, software architecture and every other technical aspect is almost irrelevant near the time you will spend creating content. And you can't offshore the content if you want it to be great.
Most likely your app doesn’t do shit and you are wasting your time patting yourself on the back and making underhanded comments. Once people realize how useless the apps you guys make are, you’ll be even cheaper than the guy you paid to make your “sales” website.
There’s a reason everyone shat on your ‘typical’ website developer for years, then they finally shut the fuck up, gave up on their dreams and joined a bootcamp to learn how to make basic ass websites.
The definition of a basic ass website keeps evolving. In no time, everything we all do will still be looked upon as making a basic ass website.
But if you need a site spun up for something and it's not the main focus of your business, shooting for the middle of the market makes a lot of sense. Wordpress is super easy to set up and create pages on, and there are tons of people with expertise in it. It's the kind of thing even non-programmers can administer, which makes it accessible to people who have skills in other stuff like marketing or social media management.
I was more thinking if you want to build an interactive site, what is the go to Go web framework?
Along the same lines with the Wordpress example, I'd choose Ghost for that as I come from the JS end of the spectrum also. I wonder what the Go based options are here? If I ran a Go shop I'd probably lean towards that (unless, of course, they're all horrible :)
Honestly if all I needed was a marketing site and a place to host my documentation, I would 'write' it in something like Squarespace.
I mean most of the marketing websites are build with such PHP tools.
But the trend didn't continue. People did it for a whilw, but then moved on to other models which still worked for PHP because few apps really need live data and concurrency like that.
The problem for PHP is that the reputation for being "a dying language" stuck.
I added more value to a tech agency and their clients with PHP than several of the senior Java guys did combined. And they were talented. Just set in their ways and lacked a focus of getting things done and adding value.
They'd waste time overbuilding shit that nobody used because it was interesting to them, not that it would create value for the client or end-users.
Also, I took over several large Node projects built by hipsters and they are the messiest code bases I've ever seen. And I've inherited a lot of trash PHP ones over the years.
Regarding the concurrency thing with PHP - ReactPHP is very nice, PHP 7 and on performance gains were massive, and real-time (search, chat, etc) can be better handled by Algolia/Pusher/etc anyway.
The Node hype train had a great run. And I still like Node. But PHP is the language of getting shit done.
Is php totally worthless in 2021. Absolutely not.
Is php the best language to spend your limited time learning in 2021? Almost definitely absolutely not as well.
The question is who's hiring/where will you work, and what will you work on? In my area, there aren't many PHP shops. So it could be Wordpress or Facebook/Meta. PHP might be long-lived, but if you have to relocate to find a PHP job, does that help? Same with e.g. COBOL, Sharepoint, etc. And to be fair, what's rising has that problem outside tech centres.
Something popular like Python is generally a "better" investment, covers more bases.
But what is, if not Motorola 68000 Assembly? Do you shoot for what has had longevity, or what's rising?
Pointing out that there is not absolute certainty about what is the top choice for a better idea does not make php, or visual basic, or 68000 worth spending your time on in 2021.
Pick whatever you want. Just don't pick a language that is known to be on it's last legs.
Also I wasn't pointing out what you say, you're reading into it a bit. I haven't used PHP in a long ass time. But it seems like not a bad choice for certain markets, at least as much as Python and Ruby imo
Where? At Facebook? Or somewhere else?
What is this out of the park career path I'd have had choosing ruby? Can you share some more details?
Almost the best advice I can give to a developer is stop being fixated on language, and start being fixated on how to solve business problems, on communicating coherently (and like a human being), and being able to quickly grok complexity. The language you program in is almost the least important part of the offer (as long as you're competent in it)
I’ve heard that exact sentiment over and over since the RoR community aggressively started with their anti-php agenda in about 2006.
It's not as 'trendy' as it once was, but it's better than ever and still widely used.
Do all of these make it faster than PHP?
Honestly, I have no idea how it compares to PHP. If I wanted truly fast I'd use a compiled language. The point is more that Ruby is still being used and improved upon all the time; far from 'dead'.
Exactly the same with PHP. The handful of Rails devs I know bemoan the fact that fewer shops are growing their Rails/Ruby use. I did a stint at a shop that was mainly PHP, but they migrated most stuff to a combination of node and python, because "they couldn't find php developers". While it was sort of true, they couldn't find affordable php devs to work with the legacy mess (which was only 5-6 years old), and it was cheaper to have less experienced (but more) node/python folks come in and rebuild distinct bits of the older PHP stuff (at least, that was my understanding as an outsider - this happened after I left).
Some orgs are moving away from PHP - others are moving towards it. Same with Ruby, although I don't see as much movement toward Ruby as I do with PHP. But I do also see orgs moving away from each.
We'll need to look at it a year or two from now and compare oranges to oranges; the new Ruby JIT (YJIT) is optimized for real world web apps, not for some artificial fibonacci benchmark. Shopify is using benchmarks on actual Rails apps like their store front to see the improvement (https://speed.yjit.org/). If I had to bet I think yes Shopify is serious enough about this to make Ruby faster than PHP - who is working on PHP internals now - Zend? In the end it's mostly a question of how much resources you throw at a problem.
So if you need a job you would probably have better chances knowing PHP then knowing Rust. But if in your area is raining with Rust jobs then go ahead and learn only Rust.
It is cruel, and something Universities have been doing forever.
That's not true for Java or C#.
Some popular choices in this bubble seem to be:
- clojure
- common lisp for some reason
- php is mentioned often here, also not sure why
- rust
- swift if you're into ios/apple, kotlin if you're into android
- typescript
By learning PHP, you are effectively locking yourself into the narrow niche of backend web development (ask me how I know!), whereas other languages have much broader target platform appeal.
As an example, the obvious competitor to PHP of Javascript already beats PHP by also providing backend web services, but also has support from AWS lambda, GCP Cloud functions, and even the somewhat esoteric embedded javascript for micro-controllers options.
> Do you shoot for what has had longevity, or what's rising?
Coming back to your original question - I think it's both. Depending on what you wanted to do, I'd pick Javascript (see above), then depending on what else you wanted to do, one of Golang, Python, C#, or Kotlin.
I'm quite happy with the Web niche, it's one of the longest lived, the stablest, the most open, and has some of the longest backwards-compatibility records around.
I can write a website today which will work in 25 years worth of client software! I think that's remarkable.
Simplistically speaking, all I have to do is stick the path hashbang at the top of a php file, follow with the business logic and run it as a shell script. Clears any urgent ad-hoc request within a day.
Those "few dozen hours" reading PHP docs and tinkering could also be used to learn Python, Ruby, or Javascript, each of which are almost certainly better choices with broader applicability and more modern ergonomics.
Python gets you web backend + ML, Javascript gets you web backend + web frontend. Ruby gets you a multi-paradigm language with nice ergonomics and cats. PHP gets you job offers customizing Drupal and Wordpress websites.
If you already know a "scripting language most popularly used for websites", then you could choose to pick up Rust, Nim, Go, Swift, or Kotlin instead. It's much better to have a new kind of tool in your belt than a second hammer.
The world is full of so many choices. PHP has a lot of incredibly compelling alternatives. Unless your job demands PHP, you're probably better off looking elsewhere.
But PHP is a quite nice language with a lot less ceremony than many other languages. Especially nowadays as the article says.
Go make a Wordpress site!
So yeah. Don't make PHP your first language. Probably not your second either. But if you've played with Python, and learned to write the simplest and clearest thing that can possibly work, if you've worked in C, and decided that's as close to the bare metal as you ever want to get, if you've learned enough Java to know when to use the SeriousBusinessFactoryProxyInterface, if Haskell has made you realize that programming is really just math... then sure, learn you some PHP, write a toy web project and discover that the simple things really can be simple.
I still don't know of any stacks where it's easier to write a simple, low maintenance side project that will stay up for years without issue, where multiple projects can share a $5 / month VPS, than the LAMP stack.
There's no alternative to dropping a file on a LAMP server that goes with almost 0 maintenance for price that goes to almost 0 with 0 downtime whenever you make a change.
PHP is my tool of choice whenever I need to create an simple endpoint but don't want to deal with the hassle of running and monitor a full blown application. At best, the alternative to that is AWS Lambda but that's a wall garden in itself
> then you could choose to pick up ..... better to have a new kind of tool in your belt than a second hammer.
Different tools for different job
I get that there's a lot of legacy PHP sites, that you could end up finding yourself working on. But there are still plenty of new Drupal and Wordpress sites being built.
You could also say that building a site with these tools as akin to "customising", as a lot of what you're doing is configuration rather than coding (but I would say sometimes JS + NPM is pretty similar). There are still opportunities to push yourself with coding, with some fairly complex Drupal sites being built.
1. You're using it for actual work
2. Learning it will teach you something fundamental
I feel like the only way 2. might happen with PHP is if it's the first language you're learning.
I don't use it any more, but in 2002 when shared hosting and deploying by uploading files via FTP was the thing it was a lot easier to get started with than Perl or Java (which I desperately tried to get into back then).
So it was almost the first language I used to make actual money.
Depends if you want a job or not.
At least in many European countries, there are plenty of them doing PHP.
In fact, when doing our Java and .NET consulting sales for Web projects, PHP is the adversary, not Python, Ruby, Go, Rust, or whatever is on the frontpage, like everyone likes to discuss over here.
There’s a reason why people are generally not doing scientific computing, machine learning, hardware integration, systems programming, etc. in PHP (yes, there are likely some obscure projects doing all of those, but in general, it’s not done because of limitations in the PHP runtime).
If you already know PHP, you can probably have a long and healthy career in that space. But if you’re new to programming, you’ll probably be better off learning Python or Rust, or maybe one of the platform-oriented languages like C#, Kotlin or Swift. JavaScript is also a very popular choice, because it’s currently the only thing you can easily use in the browser, but that might change with the rise of WASM.
And there are big sites written in Python, too. Reddit, YouTube, some Google apps, Spotify, Netflix.
Rust is still a bit young, but also has several web frameworks like Rocket. No big case studies that I know of, but Rust still has many more fields of applications than PHP does.
In the early days of Mono, there were some attempts at using C# outside Microsoft circles, like building Gnome-apps with GTK#, but most of those projects have faded away.
Will never understand why some people find that so offensive and will tell you that you mustn't use it or imply that you are ignorant or stupid for using it.
Lots of new good things in php7/php8. The typecasting is way better than before, but it still allows you to be more "dynamic" if you want to.
You can also add annotations like `/* @var []int */`. External tools (psalm, phpstan) use annotations in their static analysis of the code and will raise an error if $x elements are not integers.
Of course, it's far from Haskell, but my experience with types in PHP is smoother than in Python. Though it was 2 years ago in Python, and the environnement has probably matured.
In my opinion, a worse problem with PHP is that classes properties are dynamic. `class A {}; $a=new A; $a->x=1;` is perfectly valid and will add a property to the object that does not exist in the class. There's no simple way to forbid this, even at runtime (hacking the magic `__set()` creates other pain points).
There's a current RFC that is aiming to deprecate this 'feature'.
https://wiki.php.net/rfc/deprecate_dynamic_properties
PHP's "prescient" model demanded one OS process per request which is frankly absurd and I don't get how anyone views PHP in serious light because of this single fact alone.
"How many companies need X" is not a discussion, it's an exchange of opinions and won't ever go anywhere, so I refuse to start it.
I was merely responding to the claim that PHP had "prescient" ideas. It didn't.
I think JS can be worse. There are things that are possible with dynamic languages that are literally impossible with static ones.
So think of PHP less as a "bad language" and more of a code smell.
Requesting `index.php?something=X` implied `$something = "X";` in the global scope at the beginning of "index.php". And since the global scope was not limited to a file, tracing a variable through files and side effects was a nightmare. Even understanding the code intent was often hard!
Before PHP7, there were many elements of the language that were meant to simplify its usage, but had awful consequences in many cases. Even more because it bent the PHP community toward a quick and dirty process. "Magic quotes", the automatic escaping was one of those abominations. For any request input (e.g. POST form data), it added backslashes before single quotes. It was meant to protect data automatically in case it was inserted into a SQL request... It granted no security gain in this context, and was a mess for any other use.
I'm currently working for a company where all our microservices were written in Node.js by juniors.
JS can absolutely be worse than PHP
You'd have to try really hard to make callback labyrinths in JS match the mess that came out of the above combined with runtime-as-template-engine. This was basically idiomatic at the time.
1. https://www.audero.it/blog/2016/12/05/monkey-patching-javasc...
The value of a form input with the name “foo.bar” will instead be available under $_POST[“foo_bar”].
Surely that depends on when the PHP in question was originally written.
You didn’t use “I” at all, but it seems likely there are some other rules going on here.
You notice the pattern. Mimic it. Struglle with it. Persevere.Endure. Will you reach perfection? Maybe not. No problem. Satisfaction is few layers below.
"I have used PHP for years." The first sentence establishes the subject is "I".
"Like it." etc Because this sentence doesn't have an explicit subject, it is implicitly the same one, "I".
As I recall, "wa" and "ga" were the Japanese particles which established new subjects. Say you wanted to talk about Bob's new car, you'd say something akin to "About Bob's new car, is expensive. Arrived last week. Has poor gas economy."
I had a friend in college who would always point it out (in English, where it's not very common). I still notice it often years later and I'm pretty sure it's thanks to her making me aware of it.
[1] https://en.wikipedia.org/wiki/Pro-drop_language
Thanks for the insight!
Not sure that I have any tips for you. Other than that it is often helpful to remove unnecessary words when communicating. This is something I have become sensitive to over the years. I used to write a lot more voluminously but I find it is harder to convey messages to people when they are confronted with a wall of text.
- Web frontend: Javascript/TypeScript
- Web backend: Javascript/TypeScript, Python
- Performant backend (where you manage threads and queues): Go, Java, Rust
- Machine learning: Python
- Command line scripting: Python
- Command line tools (binaries, eg 'ripgrep'): Rust, Go
- Mobile: Kotlin, Swift
- Systems/bare metal: Rust (discourage C/C++)
- Desktop games: C#, C++, GLSL, Rust (in ten years)
Mix and match.
The safest three to learn that give you the most flexibility are probably Javascript/TypeScript, Python, and Rust. You can build almost anything with those three.
Sure, Rust is _fun_ but there's little demand for it right now in the market.
Recent example, while Android has adopted Rust for replacing their bluetooth stack, the newly introduced Android Games Development SDK focus on C and C++.
Or Microsoft, despite all their security speech, Azure Sphere OS and RTOS only support C on the official SDK, and the new WinUI components are all based on C++.
And naturally anyone wanting to contribute to the Rust compilers, most likely will need to brush up their C++ skills if they intend to mess with GCC or LLVM internals.
That's true, but as a beginner I feel like starting with Rust is a lot more accessible, and could help someone switch into C++ later.
So from that point of view, learning about lifetimes, modular code, and that bounds checking isn't evil are already good education stepping stones.
I've done shell scripts in PHP. Mobile development in Ruby, JS and haxe. Web development with Go. Nothing is stopping you, and if you know the language it is usually not to weird either.
C++, though, agreed.
The PHP language can be used as a templating language itself:
Only thing which hurts there: not everywhere deployed like PHP is :)
And technically you need a 2 files boilerplate. But that will vanish within the next year when I understand the .NET team right.
For very large projects, however, I advise against it. The dynamic type system bites you a lot in my experience. I prefer static typing.
I haven’t worked in PHP for I don’t know how many years, and I probably still have an unfair negative reaction to it. It has a strange cultural idiosyncrasy I find more limiting than anything about the language itself. But I’m happy to see it evolve and I’m happy to see it evolve alongside other technologies I work with more readily.
If someone is new to software development and in an area of the world where it's not mostly PHP shops, so bigger cities, I don't really understand the benefit.
PHP is often used to do certain things or it may be faster for you to whip something up in Laravel but if you had someone who was a complete blank slate and could chose any language and any framework in a town that doesn't have PHP jobs...why? What's the reason then?
I really think these articles come off really strange like they're trying to convince me as a "fact" but are really just nostalgia, like someone who goes off about how "cars were built so much better back in the day, there's still uses for older cars!" Maybe there is a grain of truth there and some real reasons behind it (repairability) but for 95% of use cases it's just that there's no contest, for a new driver, in an average situation there's no benefit towards going to an older car, and the guy going on about "older cars are the best", while they may have some weird reason that does actually apply to them (and as far as this analogy goes, I think Fortran is a better example than PHP in this case than PHP as for some maths applications it apparently still has an edge but that could have changed) honestly it's just nostalgia/trying to indoctrinate people...
Do you plan on creating a start-up that you intend to scale to a babillion customers? That you intend to hire teams of developers for? Probably not a good idea.
Are you a new programmer trying to figure out which language to learn first? Absolutely not. Python, Java, JavaScript, C# are much more flexible if nothing else. Anybody who tries to convince new programmers to learn PHP is doing them a great disservice.
But I agree with you.
If anything, PHP has proven it works in this regard.
PHP works, but imho starting a new company or career with PHP is a mistake.
Why would it be a mistake?
On the one hand I have a few examples of huge, successful projects written in PHP and I know they are still around 20 years later and haven't been rewritten in another language. I use projects in PHP on a daily basis (Nextcloud, Rainloop, Wordpress) that work well and have been maintained for years. On the other hand I have a few comments calling out PHP without convincing arguments. Something is wrong.
I practice Python and Javascript daily, I've written PHP code 10 years ago, still use some of my code. I occasionally update PHP code on a website I manage. I've seen good things in the new versions.
Should I begin a new project today, I would not rule out PHP that fast. I like Python and Typescript, but PHP projects are often a breeze to install (unzip, done) and survive system upgrades and reboots easily as long as php-fpm runs. Projects in other languages need more babysitting. I know, I also use web software in other languages, including one I author.
PHP is dead simple to write too.
I would probably go for nodejs for something that requires Websockets or SSEs (or a compiled language). Otherwise, I'd seriously consider PHP because it does not require setting up something like uwsgi or celery, write reverse proxy rules, write init service files or running Docker. Put the files in www and it's done. Also no code for managing routes, the file system organization does this for me. No memory leaks, everything is thrown at the end of each request. The architecture is robust.
* It's waning in popularity, new programmers aren't being taught and there isn't a lot of incentive for them to seek it out * Other languages are also good at making websites but many are more popular and more flexible - machine learning, video games, front-end web development, enterprise services (and sure PHP can be "enterprise" but many new cloud/apache projects are java first)
So yeah, I'm not saying PHP is dead...just that it's not a good investment for new developers and it's questionable for new projects.
It depends what location you're in. In Europe there are pockets where PHP is very popular, where learning it can open up the job market.
Not interested in PHP in the slightest, but how is this myth still going around?
Wikipedia, Pornhub, Facebook (initially at least) were all built on PHP. There are hundreds of other examples.
Laravel nowadays has an outstanding reputation and I doubt it's performance is lagging so far behind Django for example.
More generally, after all these years I still need to see a story of a startup that failed because they chose the wrong stack. There are some blog posts with spurious claims in this sense, but really, when has a startup with good product-market fit and a finely designed product ever failed because they chose PHP instead of something else?
Maybe you haven't heard of startups failing because of choosing the wrong stack, but I'll wager you don't hear about most startups failing because...why would you? Also, have you heard of startups re-platforming? Either because the current stack is falling apart or the company is acquired by a bigger fish and they need to integrate with other services so parts end up getting rewritten to Java/C#.
The fact is PHP is good for making websites, and that's all you'd really want to do with it. There are other languages that are good at making websites and they are more popular and have other benefits.
If you are building things with PHP and it's working for you, then awesome. But seriously, why encourage it?
Languages tend to go through a few years of flavour-of-the-week fads (think of the Vue/React/Angular competition, and all the also-rans that we can't remember now). If you get in too early, there's a fair chance you'll bet on the wrong ecosystem, and end up with unsupported dependencies or difficult to maintain code. In the worst case, you scrap the whole thing in six months and write it for a new framework to keep it alive.
PHP went through that phase back when "we've got to support IE6 users" was a legitimate talking point. You can be reasonably confident Wordpress or Laravel are here to stay.
PHP is also fundamentally a hugely battle-tested platform. It's been ran on 486s in the broom closet, and entire rack clusters in data centres. If you have some performance or usability problem, there's a good chance someone else has had it already and worked out a solution. With some new language, your odds of "never seen that before" errors are much higher.
These days I write server code in C++ :(
In comparison, other programming languages are hard to figure out. Python, Ruby, Java etc all need some kind of a package manager to install dependencies (PHP apps are self-contained) and need to have the correct runtime version installed (PHP just needs to be in the general neighborhood of what's required, since most broadly used packages seem to be written in a backwards compatible fashion). This is scary and unfamiliar, and highly technical. If you're deploying on a VPS (because rarely anyone has managed Python/Ruby/Java hosting services), you've now also become the sysadmin with full responsibility for the box, including patching and downtime. Compared with shared PHP hosting, it's bonkers.
Not a fan, but that is definitely a very good argument.
Then you have the myriad of static site hosts that also take 2 clicks to host something without even having to write any code.
Who is writing the code in the first place? They're uploading existing code to a shared host through FTP but then who wrote the code? Is it a prepackaged Wordpress? But then Wordpess hosts already exist.
If the developer is giving them a zip to upload, why can't the developer handle the deployment as well?
You moved the goalposts so far that the example doesn't make any sense anymore.
If we're talking about simple templates to open a store or a simple landing page there are so many no-code options like Wix/Shopify/SquareSpace/Square that I don't think PHP offers any significant advantage.
> package manager to install dependencies (PHP apps are self-contained)
PHP has Composer, which is one of the best things to happen to the ecosystem. Chances are, the piece of software you install will manage its dependencies in this way, and I'd be reluctant to install it if it didn't, as you wouldn't be able to update the software easily.
Don't get me wrong, my whole point is that this 'simplicity' is given in any ecosystem these days.
Except live coding via FTP is something you consider part of the simplicity, then you are stuck with PHP :)
Heroku is fine but imagine you are agency managing 50 small sites. Heroku is like 7usd month minimum? You can pay 350usd month for Heroku or put it all on 20usd VPS and result will be same.
That's why all self-hosted CMSes worth something are in PHP world and there are very few in python/rails/node.
Also its not like PHP devs have been living under a rock for 20 years and don't want nice things. Git deployment is offered even by many shared hostings, people use SFTP+rsync, or things like https://deployer.org/. And there is very active market of server management tools like https://forge.laravel.com/ https://ploi.io/ https://moss.sh/ that combined with attributes of PHP will give you your own little super easy heroku.
And scaling... well most people don't need scale, you scale CMSes by caching anyway. And you can run pretty big scale just on one machine. And if you want automatic extreme scaling it's not like you can't do that with PHP https://vapor.laravel.com/
However the way rails apps works with phusion passenger is exactly what you are explaining. I can run hundreds of apps next to each other on a tiny VM. Once a app is loaded I don't have to rebuild the state on each request, if it is not needed anymore (or rather another app needs the resources more) it gets unloaded again.
Setting up passenger, nginx and git for pushing is also a job of 10 minutes max.
I get there is a market for PHP, I too recommend wordpress when I don't want to code something for someone. I just don't see it's 'simplicity' as argument.
I look at it this way sometimes: there are the interpreted languages, the VM-based languages and then systems languages.
PHP is a good option in the "interpreted" languages category, if your problem domain is web-based, as it includes a lot of built in functionality for web-based problems. It's also open-source, reasonably performant, has an improved type system, has a C-like syntax and enjoys features inherent to a scripting language e.g. fast startup time, so would be a good option for lambdas.
Finally, one of the features that has been unreasonably good about PHP is the shared-nothing request model, which makes running a website on PHP a stable experience, in an imperfect world of weird state issues and libraries that might sometimes have a bug that leaks memory.
There are also other options in the "interpreted" category which I would fully expect people to also look into, however that's not to say PHP isn't a good contender for this space, given learning time is a limited resource.
However I would expect people to know a VM-based language and a systems-based language (or at least a bit of one) in addition.
In Europe there is a lot of PHP. Even in the bigger cities. And as someone who knows a lot of different programming languages, modern PHP with Laravel is pretty hard to compete with on a productivity basis.
- Is the "your app gets initialized and torn down for every request" true for frameworks like Laravel and Symfony?
- Does this model uses OS threads? Does it uses green threads?
And then a few remarks about the language:
- I feel like the Go model is a way better model for server software than async. Since PHP is mostly used for server software, I feel like they shouldn't go with async. Python is currently going through the transition and it's painful and long.
- It feels a bit weird to see how full of objects PHP is. Modern languages (Go, Swift, Rust, TypeScript) tend to use less objects, and more plain imperative code or slightly functional code in my experience.
Yes, though heavy optimization in opcode caching and JIT keeps it fast and the primary process manager today (php-fpm) generally keeps a pool of PHP processes persistent. Each request is initialized from scratch but there's no disk nor interpreter hit after the first.
There are, of course, frameworks that simply handle HTTP requests directly (amphp, swoole) that operate as persistent application servers, so state is maintained.
> Does this model uses OS threads? Does it uses green threads?
No. PHP webserver backends are generally a long-lived forking model.
> I feel like the Go model is a way better model for server software than async
Swoole [1] offers a coroutine and channel model. It's incredibly fast and the techempower benchmarks [2] attest to the raw speed.
> It feels a bit weird to see how full of objects PHP is
Agreed. It's often way over the top with Java-esque OOP complexity. It does depend on the libraries in question but the popular ones are very heavy (Symfony). You can of course write very simple imperative code just fine too.
[1] https://www.swoole.co.uk/
[2] https://www.techempower.com/benchmarks/
https://symfony.com/doc/current/configuration/micro_kernel_t...
Many other PHP projects, such as Laravel and Drupal pick-and-choose Symfony framework components in this way.
[1] e.g. "Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator"
I would have to question how relevant a piece of core plumbing is to a regular user of the framework, as a regular user of the framework would likely never come across this class.
Also if you're working in the domain as a Symfony core developer, the idea of a ContainerConfigurator is not so insane, if you're developing a dependency injection container.
* If you have a memory leak your complete server will get killed some time later when running out of memory * If you have a bug which crashes your web server every running request is killed * You get all the hard-to-find concurrency bugs when multiple requests concurrently can access some objects.
With PHP's model of (1) initializing and destroying all the state on every request and (2) every request running in it's completely isolated virtual space you don't have any of these problems.
And if you really want to have a long-running server with shared space you can have that too, take a look at Laravel Octane.
But I agree with you about the whole "esoteric lisp-based language" comment. It seems like every other day I see something like that here and all I wanna say is "why?" I mean nobody cares about lisp except for the stallman-esque nerds. The best programming language is the cheapest one to create, support, and replace others with. Not cause some random programmer that thinks they know what they're talking about because they don't like it.
Have you played with Shiny (shiny.rstudio.com). If you're building a website for interactive data exploration and analysis, it is very hard to beat.
In the Python ML world only the matrix libraries - numpy and similar APIs like torch.tensor and jax feel natural and click in my brain. The rest - data frame, visualization, scientific libraries; I'm not very sure how to explain it, but it always feels like some context switch is needed between using Python the language, and calling out to these libraries.
But maybe this is just me.
And yes, 4,5k USD/month is massively good salary for Europe.
On the other hand, I see many job offers with salaries being just a joke (idk if they find any good developers for such money)
In eastern and southern europe: that's probably good for a junior engineer, and perhaps average for a senior
In northern europe: that's probably average for a junior, below average for a senior
For example, in Berlin it seems to me that average salaries are around 70k EUR/year (6.6k USD/month) and really good salaries are well above 90k EUR/year (8.5k USD/month).
You can see more data in https://www.levels.fyi, which it is skewed to the high side, but gives you an idea about what good offers are nowadays.
I'd consider a PHP job, but only if they quarantee they don't have any of those legacy maintaining things lying around.
I see your point, but there is lots of legacy code (in any language) laying around and making shit tons of money for their owners - hence the need to maintain these systems.
PHP had no common way to do anything for a long time and you still see it from people writing PHP today.
But I like the idea that these people may exist out there :)
Furthermore if I'm working with JS/TS, hot reloading even makes it so I don't even need to refresh the page. I can even inject code into arbitrary places with the debugger (as if I'm editing the source)!
So, all these other ecosystems are on par with the PHP...
I'm glad PHP adopting ideas from other communities, and that the community is becoming more cohesive, though.
Aside: I used to write PHP before (back in the 3 to 5 days), and worked for a big web hosting provider that had a big shared hosting customer base; PHP was by far the most popular technology in that space.So, I'm not trying to bash on PHP.
With PHP, you install the toolchain, save a file and the page becomes available.
With JS/TS, you install the toolchain, and then enter a complicated process of yarn/npm incantations in the command line to get the project working right. The manual may say "yarn add typescript" but in practice there's always more setup and configuration to be done before it works well.
For "real" projects, there's not that much of a difference between yarn and composer. For getting started, though, the process is a lot more involved.
Another problem is that running Javascript on the backend is almost completely different from normal frontend development. If you want to store state, you end up using the same (or even worse, a similar) programming language with completely different contexts and available libraries and methods. You can't document.createElement in the backend to tell the user that an operation succeeded or failed, even though that's what you'd do if you were working on a frontend file.
With PHP, you can't do frontend, so whenever you write frontend code, you can't get confused. In my opinion, this makes learning PHP backend dev a lot easier. It's only natural that you choose to continue working in the language you've started you development career in. You can see that by the fact that there are still people who swear by VB.NET, despite everything.
The JS ecosystem does have the advantage of coming with a debugger, but PHP users can get the same by hooking their PHP install into the PHPStorm debugger. I think it doesn't matter much which language you use at that point, it's just a tooling preference.
All in all, I think both languages have their uses. If PHP really was as bad as people say it is, it would've died out already.
Locally however it is save, alt-tab, ctrl-r and immediately you see the result. Absolutely no waiting.
These days I rather use Quarkus for this but until Quarkus arrived this was a huge advantage that PHP had over every other language and framework I was aware of.
Also the documentation was fantastic compared to most of the stuff I have had to suffer through on Java, .Net and even React and Angular.
Every thing you may reasonably wonder about was described in a clear, straight forward way and included examples.
Which I suppose is just a fancy way of a copying files to the server.
Modern PHP wears a business suit and wants to buddy the "big boys" (Java/C#) of the world. You'll have deployment pipelines, strong push towards classic OOP, strict type checking etc.
I personally think ruby for instance is leaner in its dev process in most real world projects.
You can have deployment pipelines etc, but if you like, you can still develop the ancient way - it still works.
Now you can put .py files into your www folder, like .php files.
One can also use old school CGI to serve their site, it’s super lightweight and you just upload the file at the right place, for almost any language. But that has been deprecated for the last 2 decades now.
It works for them, but I wont tell random people starting a business now to go with pen and paper, 99% of the time that would be a bad advice when there are much much better alternatives now.
I believe that PHP is the easiest way to just Get Things Done when you're starting out with a programming language. To deploy a website, you sign up for a free account somewhere, often with a free subdomain like mywebsite.cheapwebhosting.com, put the files on there and hit refresh. Seeing a result immediately is very motivating for beginners, and PHP doesn't require knowing anything complex like DOM manipulation to generate web pages the way Javascript does. If there were as many free web hosts that allowed the same ease of use for C# or some other language with inline templating, I'm sure it'd take off just as easily.
The language isn't as bad as people claim either, I think it's on par with languages like Python and Javascript. PHP has its quirks, like using a dollar sign for variables, it's really not that much worse than its competitors. Shorthands like $_POST/GET/SESSION are such a relief to work with compared to the "professional" languages with their frameworks upon frameworks and complex, layered objects representing state. It's a great tool for setting up a simple website, maybe even a very basic web shop, where the "big boys" are complete overkill. A website like HN doesn't need more than a few PHP files to function until it hits a certain scale, and even then scaling up PHP websites is relatively easy.
I think the real reason people hate PHP is because it's a language used by a lot of beginners and intermediate programmers who overestimate their ability and deliver subpar projects that someone else now needs to maintain or rewrite. I wouldn't want to inherit some kind of custom blogging engine written by an intern three years ago in any programming language, and because of its ease of development many PHP programs are just designed badly.
- install/update PHP or go with the outdated version that shipped with their system.
- have a hosting service that will accept random PHP files
- know what their hosting's PHP version/configuration is to match it locally. For instance their hosting will keep the most secure config possible, thus no out of the box fetching of URLs.
- endlessly fight to find syntax errors as they are too new to have a linter. Depending on the PHP version they settled on they won't have error logs in one place but two.
- fight the endless stream of out of date tips and tricks left by 2 decades of PHP programers of various pedigree.
All of these have different variations for different languages, they all have their barriers and dead bodies in the closet. My take is that PHP isn't specially beginner friendly at this point, at least not as friendly as it was when it began.
Making a public website from scratch will be complex anyway, so they might as well go with a saner setup that uses a templating language and not write code right into the HTML. It won't be much harder and they'll have a fighting chance to find up to date tutorial to host their project easily (hosting a rails project on Heroku for instance could be miles easier in that respect)
PHP already has caught up to others with 5.6, these days PHP 8 doesn't lack anything found in other major languages.
What is still confusing is the standard library, but only for people who never worked with C/C++ before - as most of the native PHP standard library actually originates as a verbatim copy of the C/C++ libraries.
There's not a lot that is comparable to the PHP ecosystem when it comes to bespoke web-based e-commerce, or anything to do with bespoke customer or content management.
If you're trying to integrate with some weird 3rd party API, chances are there's going to be something written in PHP, or you can easily pay someone to do it for you.
Not only this, but there are agencies providing long-term support for parts of this ecosystem.
Other languages with strong ecosystems in this area would be Java, or Ruby, I think. I like Java for the same reason, and would probably like Rails. Anything that has "batteries included" is good to me.
IMO that's extremely powerful in its simplicity and while you can get it in other languages, it feels like like a "core competency" for PHP (just like how async code is easier in javascript than in python, because JS kind of had it from day 1)
The original promises syntax and chaining in ES6 were not particularly user friendly.
It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.
> you need an external server
Spoiler, you need an external server for everything on the web; you've just been brainwashed to think serverless is actually that.
So yeah, you technically don't need one for Ruby or Node.js, but I sure would.
Lots of languages and frameworks make it easy to be self-hosted with there own server. In Python, .net, Go, Rust this is quite common.
This means that your app can be a self-contained app + server and the server part can have some business logic as well.
With Go, .net, Rust apps (and potentially others) that's quite nice to be able to produce a single binary app that you can just run anywhere without installing any framework or setting up any external server and it's ready to listen to incoming queries.
That can even be a good enough setup for home things that are not exposed to the web and where setting up reverse proxies could be overkill.
Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.
I only host one PHP app now (Nextcloud) and it has definitely been a bit of a pain in comparison with other things I self host.
Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).
I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.
I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.
In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.
Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.
1. WordPress uses it
2. PHP is far less terrible than I remember (having used it in very early days)
I manage a WP (woocommerce) site for a small business. It's not my day job, it needs to be simple. Most of the "day job" is handled by content management users. I have written a fair amount of plugins though to enable custom functionality and the process is perfectly fine.
I looked at Ruby, I looked at Python, I looked at node. There's nothing as simple and, frankly, as mature aside from commercial platforms like Shopify that charge an arm and leg.
I honestly always wonder: as opposed to what? Let's take my simple requirement, a small business ecommerce store that's not going to look like trash and where non technical users can make pages, edit descriptions, etc.
I can do: WordPress, Magento, or I can pay a SaS provider. Essentially both do it yourself approaches are PHP and Magento has really sabotaged itself with the complicated migration. SaS means higher costs and if I want custom functionality (and yes, the business needs it), it ranges from impossible to possible but a headache.
So here is a business that is now online for a minimal cost for two years, allowing great flexibility for me, while allowing completely non technical users to get crap done.
The two things I can think of quickly, that I like about php, over another, is the ease of code->browser. You have to manage 0 build configurations or pipelines to get what you want working. Just download the files and open a browser. The second, is 100% transparency with third party libraries. Because of the lack of ability to compile, when I download a third party library, I'm getting their actual true source, and can much easier, navigate and understand the library right through the ide, without having to read a bunch of docs online and that it's true to source. Being able to control click into third party libraries is quite liberating.
2. The PHP ecosystem is quite mature, and packages are of good quality in general
3. Dependency management works well. You will rarely end up in a state where your dependencies are incompatible between each other (something that happen often with npm for instance)
4. It's faster than python/perl/ruby
roadrunner is a PHP server developed using golang, utilizing goroutines for high performance.
both used by Laravel Octane, providing very easy integration with the framework.
Other than that, php-fpm & FastCGI allows integration with many interestin webserver including Nginx, Caddy, Lighttpd, etc.
[1] https://github.com/swoole/swoole-src/issues/4434 [2] https://news-web.php.net/php.pecl.dev/17446
If self-hosting, Nginx and FPM is well-tested and very fast.
However, error handling continues to be an issue. It isn't uncommon for PHP to fail silently. That would be one complaint I have against PHP.
> You might have heard people say that PHP was "doing serverless before serverless was a thing", and this is kind of true.
I believe that PHP is...not bad I guess? I'm sure it can make good things. But after reading this I have no idea why I would pick up PHP over any of the other capable tools out there.
I worked with PHP 9-10 years ago. Still not impressed to this day. Why should I use it? Terrible type coercion that can and will catch you with your pants down is my chief complaint -- that alone is enough for me to never touch it again. I want predictable tools, not something I actively have to fight against so I can get my job done. How is this even considered productive?
So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
But companies might want to use PHP, because it has a rich ecosystem, which handles corner cases.
Chances are, if you want to send out bulk email, or connect to a payment provider, there's going to be a library in PHP that allows you to do that, often with long term support from an agency.
A corner-case I recently had was needing to decode an email. There's a function for that: quoted_printable_decode. This is a common situation for PHP. If you have some sort of issue around the web, there's likely to be a PHP solution.
And if you're a small business that needs a bit of bespoke software written, then you can easily hire someone, and know a decade later, you'll be able to hire someone if the requirements change.
Much of this can also be said of the Java ecosystem.
Just recently, I was using a small business that managed their bespoke business process built on a PHP CMS. They don't need 2000 reqs/second.
It's not that I never tried anything else. I got through 8 languages and made what I feel is an informed choice.
> Much of this can also be said of the Java ecosystem.
And yet, so many programmers and companies moved on from both Java and PHP to other tech and are managing very well. The company I work for has mere 6 backenders and we serve millions of visitors regularly without ever hitting >70% CPU on 3-4 servers.
Citing the entrenched state of affairs is not an argument either. It's an appeal to statistics (a good chunk of which are flawed as well).
I'm not going to try and convince anyone to stop using PHP or Java. Truth is, most programmers want stable predictable careers and there's nothing inherently wrong with that. I simply am not in that group.
> So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
I gave some reasons, citing problem domains for which there are stable, supported solutions in PHP. e.g. payment gateways, email handling, and citing the availability of programmers who can support medium bespoke or tailored systems. This isn't an "appeal to statistics" it's a strength about the ecosystem.
Similar to Python having many solutions and libraries built around data science.
> I'm not going to try and convince anyone to stop using PHP or Java.
I thought you were asking a question.
Sure. In that area PHP still more or less dominates. But I thought we were discussing the actual programming?
> I thought you were asking a question.
That's exactly why I said what you quoted me on: to reassert that I am looking for a good answer on "what does PHP do better" and I am not in fact seeking to change hearts per se.
Over my career, I've worked with companies using PHP in sales. One of those had over a million customer subscriptions, the other was a multi-national looking at PHP for a greenfield e-commerce project. I noticed working in Europe some high-growth agencies that use PHP.
> So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
> But I thought we were discussing the actual programming?
Your original question just said "use PHP". PHP is a general purpose web scripting language. It's similar to Python or Ruby. It is generally more performant and later versions have a gradual type system. It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production, as it avoid bugs that can arise around stale state, multi-threading and it keeps running if other libraries have bugs that leak memory.
Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.
Arguably, the thing that would make you use it over Python, or Ruby, is the ecosystem, especially around content management and e-commerce, as the language itself is roughly comparable to others. Also I think there are more agencies that support PHP, rather than Python or Ruby.
I think we have a vastly differing definition of "in production". I'll agree PHP was good enough for plenty of things, and likely still is. But good enough in general to run things in production as it's understood today? You'll find that many people will disagree with you here, not just me.
> Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.
That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now. Happily Erlang/Elixir are having lightweight and transparent parallelism and concurrency for a long time now. Languages like Go and Rust also progressed very well in this area so I am looking to work more with them in the future as well.
---
I think you and I are not aligned on what is "successful" or "good enough". You seem to insist that statistical success speaks something of the merits of a technology, and this is where I and many others disagree: people just adapt to what's given to them. That doesn't say almost anything about if the thing is good or not. People simply get what they can. Back then PHP was available so they took that. The rest is post-hoc rationalization. Stretching the simple and isolated historical fact "people used PHP because there was nothing else viable at the time" to mean that "PHP is good and successful" is where I'll disagree with you.
But yep, we severely digressed from the original discussion. I am OK with that though.
Running software that customers use, directly or indirectly.
I've supported servers running PHP and Java software in production. The shared-nothing per-request nature of PHP meant I didn't have to deal with a bug in a misbehaving library causing memory leaks and taking down the application server.
> That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now.
PHP's problem domain has been web-based e-commerce and content management systems. In this area, PHP powers most of the web. You'd want to use PHP in this field, over other languages. Every improvement around PHP has been to advance this goal, such as the recent addition of gradual typing. There's no question of "catching up" in this area. That it is broadening out into different areas, great.
> You seem to insist that statistical success speaks something of the merits of a technology.
If the technology doesn't have a marketing department, or large companies forcing people to use it, then arguably, this does, as otherwise people would just use something else.
There have also been many other qualitative improvements to PHP over the years. I also mentioned its shared-nothing architecture, which is a qualitative, not statistical aspect behind PHP's success, as it has proven to provide stability in production. People use PHP because in certain problem domains, it is qualitatively, and statistically (assuming you mean, it benefits historically from a wide number of successful, maintained libraries) the best tool for the job.
And that with a language that everyone can use.
> All languages can be used by everyone.
Now consider brainf#ck.
You see? For all practical values of used not every language can be used by everyone.
This is of course an extreme outlier (but absolutely not the worst I think) but there is a spectrum, or rather field of possibilities.
PHP is trivially simple to get started with. A teenager can manage to do it alone.
A simple PHP page 10 years ago on a low-end server using mod_php could do 100k+ rps. Add more logic to it and performance will decrease.
*Python* A disgusting level of flexibility (probably too much). You never really get trapped into anything, you can even (but should not) overwrite functions during runtime. You can make and break all the rules. Supports a number of modalities (often badly). Really killer console-based debugging tools (I love pudb for instance).
*Elixir* Insanely durable data/process model that makes it incredibly difficult to damage a working path through a non-working one. Never have your entire web app crash again. Pattern-matching and message-passing based language makes expansion easy and low risk. Macros are best used carefully but when appropriate are a breath of fresh air.
All the languages are turning complete. By definition you can solve any problem with any of them.
Using ASP and want to calculate an MD5? Oh, you need to pay an add-on for that. Want to send an email? Ditto.
Then there was PHP, with all included (and cheaper hosting, because Linux). I started working on a web shop and after a month ASP was legacy and PHP the new cool thing, together with MySQL instead of using... Access as "database" in ASP.
It was the SQL part of the book that helped me build the SQL skillset that is an integral part of my day job.
Used a book similar to this one:
https://www.thriftbooks.com/w/professional-php4-programming_...
haha. My first ever project as an intern in 2004 was exactly this.
Doesn't all that make you long for the days of ./configure --prefix=/somewhere/sane && sudo install -d -o yourusername /somewhere/sane && make install? Just add empscripten to the tool chain and you can do web things with it, sort of...
[1] https://en.wikipedia.org/wiki/Source-to-source_compiler
If I did that I'd have missed a hell of a lot of cool stuff in life haha
Have a goodun
So yes, let me express my antipathy toward the PHP language and its ecosystem.
I work not "well". It has hundred of issues that are not, and will never be addressed. Like the inconsistent choice of function names, the antic (if not prehistoric) way of extension managing, the clumsiness of xdebugger, the bugs in the PDO library, etc.
I spend 80% of the time trying to figure out "a hack", and spend too much time on php.net & stackoverflow hunting for the right answer.
Particularly, PHP 8.1 has some changes that low key force people to update, such as the use of return types when extending a built-in classes (https://php.watch/versions/8.1/internal-method-return-types).
As someone who still owns their rent coding PHP, I really enjoy the development of the language from php 7 onwards. It certainly feels better in any way compared to the 5.x or even 4.x days.
As long as we do not get another python 2 vs 3 disaster, I am happy.
If having the same code working for a long time is the most important for you then you should probably use java or .net. Maybe c++ also but that is not as popular for building web apps.
It's very hard for me to treat a language seriously when I could write code that simply won't be valid PHP in 2 years time, or worse, behaving differently.
Given the severity of some past PHP vulnerabilities, being on an old version can certainly be a problem.
> I guess they might do it again from 7.x to 8.x, we'll see.
PHP 8 has some _massive_ breaking changes
Then I didn't have enough time to maintain it, and I stopped paying attention to it for a while.
Later I checked my homepage again, the webhosting company updated the PHP version, nothing works anymore. It is not simple to fix, so I gave up.
I am not going to spend the same amount of effort on making my homepage in PHP again. Trust is easier lost than gained.
I would still be willing to code something in PHP for someone else, because hey, if it stops working in a year or two, it's their problem, not mine. But I would warn them that something like this is possible, and in my opinion likely to happen.
Register globals was turned off in later versions of PHP 4. Magic quotes was turned off in PHP 7, released in 2015.
PHP today is no more "unsecure by default" than any other language.