PHP is worth learning and using
bulletproofphp.devI'll be honest. I really don't like PHP. However when I was running a coding workshop, very frequently people would ask:
"How do I make a web page talk to a database?"
I'd say: Well, you know that HTML file? Rename it to become a PHP file and you're almost there!
As pretty much all cheap hosting already offers support for PHP (and MySQL for that matter) this would almost always work.
I would love to be able to do this with NodeJS, but imagine teaching that to an absolute beginner. The conversation would have to begin with hosting platforms / SSH / server management / reverse proxies etc....
You hit the nail on the head, this is exactly why I fell in love with PHP. I learnt it back in the PHP4 days, and it just seemed like the perfectly straightforward way to do web.
In a similar fashion, I abstracted away the database connection, query and returning of results into one lazy-inited function, so talking to the database really was just like
I worked a lot with other languages, none feeling as natural to me as this one, aside from Ruby.<?=q("select name from users where id = $userid") ?>Be careful as this syntax can potentially introduce SQL injections.
PHP's parameterization features in PDO can be abstracted so you can turn this into:
It's still pretty concise and is much safer.$vars = array(":userid" => $userid); q("select name from users where id = :userid", $vars);Two further alternatives for improved expressiveness:
Recommend using single quotes for SQL (command) literals, rather than doublequotes. This helps with discouraging string interpolation (" ... WHERE col = $value "). This also helps very much with SQL quoting object names (tables, columns, indexes, etc) - SQL specifies doublequote (") as the quoting character; for example 'SELECT COUNT(users.id) AS "Number of users" FROM users', or 'CREATE VIEW "My daily report" AS SELECT SUM("count") FROM "some strange table" LEFT JOIN ...'.q('select name from users where id = :userid', compact('userid')); q('select name from users where id = ?', [ $userid ]);Parameterized queries and statements are great. They solve problems where the paramaterized queries are used. However care must be taken, a script running on the database after information has been entered can still inject long after the initial parameterized statement put it into the database if that script itself does not use parameterized queries, making a SQL injection still work, in a delayed way.
PHP: the original progressive enhancement.
It's still far behind PHP[0], but with Next.js/blitz.js I think we're going in the right direction.
[0]: as in, I would have nightmares trying to introduce beginners to full JS stack vs I would have nightmares thinking what they will end up coding when they easily become dangerous with PHP (which is I guess why there are so many bad PHP codebases: it's super easy to start)
You need to try swoole/ openswoole - it brings golang style concurrency to php. you dont need to use nginx/apache and it beats node in performance tests.
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.
For people of a certain age and job history, the worst code they've ever inherited was written in PHP.
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.
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.
> I don't think any JS code can be worse than old PHP code.
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
I've heard of JS referred to as "PHP with cooler shoes". I smirked.
As far as I know, you can't monkey-patch anything in PHP, but you can in JS[1]. That alone might make JS the more dangerous of the two languages.
1. https://www.audero.it/blog/2016/12/05/monkey-patching-javasc...
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.
I don't know man, cleaning up legacy PHP can be kinda fun, but when I work with some batshit insane piece of JS I feel like I'm going psychotic.
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”].
> So think of PHP less as a "bad language" and more of a code smell.
Surely that depends on when the PHP in question was originally written.
Clearly you've never inherited anything written in Perl.
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.
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.
10+ is not that long time ago. There was already Zend Framework. And for some basic API using framework may be overkill anyway.
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.
It‘s also the essence of "serverless" so that model seems almost prescient.
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.
I’m curious what metric you’re using to determine that a majority of the web is running on PHP.
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?
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.
Php has developed a lot in a decade.
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.
gettype($x) is "array". you can annotate a type as being an `array`. How does that help me exactly?$x = [1,null,'xxxx', collect([])];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).
> In my opinion, a worse problem with PHP is that classes properties are dynamic.
There's a current RFC that is aiming to deprecate this 'feature'.
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 can build almost anything with any language.
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.
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.
> 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.
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.
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.
And even moreso for the embedded space
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.
C++, though, agreed.
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.
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.
Shoutout to Elixir/Phoenix for a (performant) backend.
This would ba a great Ask HN
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 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.
and the best part is they're probably javascript developers that don't understand the hell they're living in.
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
So your response to the haters is to be a hater yourself? Why can't we just get along?
Now, why’d you have to get JavaScript involved? Can’t something else be a punching bag?
You’re writing style is unique and grabbed my attention. Any tips to write like that?
You didn’t use “I” at all, but it seems likely there are some other rules going on here.
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.
Thanks for the insight!
> Any tips to write like that?
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 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.
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.
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)
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.
I don't find this to be true at all.
> 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.
What are you talking about?
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.
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.
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.
PHP has a built in web server you can launch from the CLI and run the script. `php -S <address:port>`
The kind of optimizations you would do in an application server would prevent you from scaling pass a single server
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.
My bad, I didn't know that about PHP build in server
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.
Nextcloud is more complex than most PHP apps.
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.
Before being async as in async/await Javascript was also async as in having an external event loop and being event driven.
Yup. Go too, but the programmer doesn't need to know it.
That's not quite a language feature though: one can write (Fast)CGI or similar programs in any common language.
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.
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?
That makes sense, thanks! It has indeed been run in a loop from the start despite the poor ergonomics - I did not think of it in that light.
async/await is just syntax sugar around promises which are a just a nice way of organizing callbacks, so yes I'd say it's true.
Probably more accurate to say it was async from day one. Which people probably realized the first time they had to deal with setTimeout
The original promises syntax and chaining in ES6 were not particularly user friendly.
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"?
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.
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.
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)
OP is correct, you still can develop like this with PHP, and no the ship has not sailed for many.
You can have deployment pipelines etc, but if you like, you can still develop the ancient way - it still works.
Well I can still develop like this in ASP.NET if I wanted to and probably and many other languages/frameworks too, so it's not exactly unique.
apt-get install libapache2-mod-python
Now you can put .py files into your www folder, like .php files.
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.
Odd, I'm getting Perl/CGI gigs still. I should tell them to rewrite to...what's cool 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.
Having a ci/cd pipeline is much different than having to setup and maintain local environment build pipelines.
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.
I deploy with a git pull
Which I suppose is just a fancy way of a copying files to the server.
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.
Same. And git doesn't care if I add a build process or not, or which language I am pushing.
It is kind of just a fancy way to copy but at the same time gives you versioned deployments, rollbacks etc.
I use PHP this way and I think it's great :)
> even if the language is truly terrible.
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.
Frankly my reasons for using it boil down to:
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 would not recommend anyone to use WordPress in 2021, though. WordPress maybe simple to setup, it's part of what gave PHP its bad reputation.
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.
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).
But maybe this is just me.
Good jobs though? Lots of PHP jobs in Canada, but the salary is nearly universally always laughably low.
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)
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 also live in the EU, and 4,5k is not a massively good salary for a programmer in my country (Denmark). This is usually what a junior is paid.
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.
Is the 4,5k before or after tax?
4,5 K USD/month is 54K USD/year gross which is 47K EUR/year gross. That's not massively good salary across ALL Europe.
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
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.
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.
I see. Well personally I never witnessed such a product owner. My whole carrier with PHP legacy code evolved around 'never touch a running system'
But I like the idea that these people may exist out there :)
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.
> 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.
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)
4. It's faster than python/perl/ruby
I really don't understand all the PHP dismissal on HN. As a language it has continued to evolve in meaningful ways, especially with the latest releases. Companies like Facebook are built on PHP (yes, they extended with Hack, but most of the benefits are available in PHP 8 now without the downsides).
Coming from a C background, I found PHP easy to step into as many of of the underlying libraries and common functions are wrapped and available in PHP (with similar names).
One thing I've noticed is people who code in PHP for work or projects don't bother to come on here and try and defend the language. It's underrepresented, but maybe the groupthink ship against PHP has sailed here a long time ago, they don't bother. Or perhaps, more likely, they are too busy creating.
While I primarily program in python these days I have two major open source PHP projects (millions of downloads each). I was also part of the standards group that tried to modernize some aspects of PHP (to various degrees of success).
In general I would never bring them up on this site. It's just not worth my time or effort. I've even gone so far as to ask people who have posted my blog posts here to take them down. Hacker News has one of the worst groupthink cases in tech, where if you speak against various core beliefs you get absolutely hammered with trolls both on the site and off of it. Having a reasonable discussion about the pros and cons of PHP is just not something this site is capable of supporting.
> Hacker News has one of the worst groupthink cases in tech, where if you speak against various core beliefs you get absolutely hammered with trolls both on the site and off of it.
Aside from PHP, can you think of any other topics that can be problematic in this regard? So far i haven't personally run into any that would get me disproportionate amounts of negative votes, however i find myself curious about it. The only i could personally think of would be Perl and the discussions surrounding its history.
Perhaps i've just been lucky so far, or maybe you can tackle some of those topics by phrasing your points as questions or just pointing out that those are subjective views, instead of absolute truths, thus stimulating a discussion, rather a clash of opinions.
Personally, i think that sites like Habr or some Reddit communities could be more biased as far as discussions about topics go, due to the specialization present (e.g. a blockchain centric subreddit might not be receptive of criticism, even if constructive), however i've also heard similar things about Team Blind, whereas my HN experience has generally been fairly pleasant.
Just mention the chat program Telegram. You will have 200+ people immediately dissect everything that its creator ever said and did. Which I don't mind at all but you can see extremely anti-Russian sentiments straight from the middle of the Cold War. Very puzzling. There's not even good factual discussion most of the time.
For bonus points, do state one provable and visible fact: that Signal (the program that's always recommended as a replacement for Telegram in HN) is not completely open source either, and then suddenly even more people appear to explain to you how that's somehow okay for Signal but not for Telegram. Even more puzzling.
Another one: mention Rust, no matter how. Somehow you're suddenly a zealot, you work with a "flavor of the week" language apparently (nevermind that it's at least 10 years old), and you also feel the need to tell everyone about it everywhere you go, and let's also not forget that C++ can do everything that Rust can and you're a bad programmer for not realizing it. I learn so many new things about myself every time I mention Rust around here! (warning: this was sarcasm)
HN isn't as neutral and factual as you might be imagining it. I've seen ugly and shameless appeals to authority by very prominent and high-profile members of this community.
Answering this question is tricky because any answer is essentially inviting trolling. This community has both extremely technical people as well as a variety of people who basically live on 4chan (and there is quite an overlap between the two) so things can get dicey in that regard.
Just some hivemind topics-
* Free Speech. This community tends to be extremist about this, which in turn means anything that can be construed as limiting free speech will, somewhat ironically, not result in a productive conversation.
* Corporate Libertarianism. This community also tends to be extremely pro-corporate, and there's a lot of "if you don't like it work somewhere else". That being said I've seen some push back against this lately.
* Meritocracy. If you challenge the idea that silicon valley is a meritocracy people seem to get really upset.
I would definitely say that there are reddit communities that are worse, and some that are better.
Thank you for your input! While the SV bit probably isn't relevant to any of the topics that i might touch upon, I'll keep that in mind.
That said, in regards to freedom of speech, i feel like some of Bryan Lunduke's (just as an example) arguments wouldn't necessarily invite hostility, despite their delicateness - such as the idea of de-anonymizing the internet and what implications that could have and what it'd look like.
Of course, it might invite prolonged discussions with no clear conclusion, because there are just societally complex topics with layered tradeoffs where no one can definitively cover all of them, but in my eyes that's not necessarily bad, as long as everyone remains civil.
I know I've certainly been wrong about a lot of things, though thankfully people so far have corrected me and let me better myself.
Cryptocurrency.
I work mostly in PHP for my day job, and honestly even I can understand people being dismissive of PHP. It undeniably has many advantages you and others mentioned, but equally undeniably it was from the very beginning a huge kludge (famously, its creator only intended today's "PHP language" as a template language, and when its scope gradually grew to a "full-fledged" language, nobody really cared about consistency). And this is a legacy which they have since tried their best to shake off, but they will of course never be able to get rid of it completely.
Also, same as many other open source languages, there seems to be a tendency to pick up every language extension someone proposes hoping that it might win over some developers, but I'm not really convinced. Does PHP really need a "match" control structure (https://www.php.net/manual/en/control-structures.match.php) when it already has good ol' "switch" and "if/else"? Of course, I also like the more flexible (Pascal/)Go-style switch statement better than the "classic" C-style one, but maybe they should have given it some more thought years ago instead of slavishly following C/C++ then and inconveniencing thousands of developers by introducing a new keyword now?
Same background and that's the same I used to think years ago before learning Python, after Python and after reading awful spaghetti code in PHP 15 years ago I ended up hating it, I haven't touched nor read PHP code since then, maybe now it's better? but really with all the PLs we have available today, at least to me there's no incentive to touch nor read it again.
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.
Oh well we are about to break most of said 10 year old web sites.
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).
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.
I like PHP and still use it today. But never in my life heard PHP is cool. Am I missing something?
Well, early 2000s it was definitely 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.
Used a book similar to this one:
https://www.thriftbooks.com/w/professional-php4-programming_...
"Access as database in ASP"
haha. My first ever project as an intern in 2004 was exactly this.
They're making a rhetoric against JS style of development... Though I question what they mean by fake compilers...
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...
transpilers*
If people call something "cool" - that's actually a red flag for me.
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.
How's that policy working out for you?
If I did that I'd have missed a hell of a lot of cool stuff in life haha
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.
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.
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.
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.
PHP 8 has some _massive_ breaking changes
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 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.
Most arguments against PHP miss the point. You know why you should use PHP? Because it's fun and you can get something running much quicker than figuring out the Elixir, Ruby, Rust, whatever ecosystem and paradigm. Maybe PHP is not so good at WebSockets or async worker threads, but most projects don't need that. There's no shame in doing long polling, users can't tell the difference anyway!
PHP shines when you're trying to get a server-rendered web app off the ground. It's the VB6 of the web. Nothing else matches its development velocity, from keyboard to working code.
I used to believe this, but...
But that's just not true.
All the things you mentioned are a yum/apt/nix/pacman/ install away on Linux, and probably as simple to install on macOS. I'm sure Windows has installers for these, too.
So, it's no harder to develop in them than it is in PHP.
You could argue it's cheaper because you don't have to pay for a shared hosting provider to host your files. However that's a bit moot since even back in the day there were LAMP stack Vagrantfiles that would automate this local setup.
Also, when speaking about dev velocity or time-to-start: you forgot JavaScript, which probably has much greater development velocity than anything else.
Furthermore, PHP is rarely just PHP in production. PHP also comes with various runtime modes (CGI, FPM, etc), .htaccess rules (or nginx equivalents), a bunch of runtime language and feature toggles that are partially controlled by the system (ie your hosting provider), and some can be controlled by the application.
The ephemeral process nature of the language makes some tasks very difficult to do in a performant way (but there's caching, so that's at least mitigated).
I've seen so many developers (worked for a hosting company) come complain to us about slow servers when in fact they'd just be doing silly stuff. And it was hard to blame them, because the language encourages that model, and the "performant" was was usually orders of magnitude more difficult to implement (ie indexing, image resizing, or most types of batch processing).
I'll not go into the horrors of how easy it is to mishandle file uploads in PHP (there's plenty of those around) and how many times people got easily hacked this way.
I went on a rant, but didn't mean to. I don't have anything against PHP, it's got a valuable and relevant place on the the web. It's important to many people, and like you said you find it fun, which I think is important for our productivity as devs.
However, I think this recurring misconceptions how easy PHP is to develop in needs to stop. PHP comes with a lot of complexities. Worst kind of complexity to learn: hidden complexity.
I can't think of a single in-use tech/language that does not have a lot of complexities. And by definition, these will almost certainly be 'hidden complexities' for someone coming in to that ecosystem.
What's been useful about PHP (and many other stacks) is that the good ideas from other worlds usually get assimilated in over time. PHP is not always at the bleeding edge with respect to language development, but that's just fine. The PHP ecosystems often adopt/adapt useful ideas/techniques from other ecosystems relatively rapidly, and that's just fine too.
> I can't think of a single in-use tech/language that does not have a lot of complexities. And by definition, these will almost certainly be 'hidden complexities' for someone coming in to that ecosystem.
You're 100% right.
My original comment focuses on PHP because I was specifically addressing the "PHP is the easiest to develop in" idea.
I realise that it might seem a bit too critical maybe because PHP was the only topic in it, but I didn't mean it to come off like that. Hopefully I redeemed PHP a little bit in the follow-up comment! :D
At the end of the day: every ecosystem/language has its own "that shadowy place over there" :P
I think fun is important but I see nodejs and rails as equal to php in the easy and fun part. Maybe python too, have not used it enough.
If we are talking about building large web applications then performance, maintainability and other things may start to be more important than fun and then c#, java, go and others can be really good solutions.
One person’s complexity is another person’s valuable job skill. PHP and Apache aren’t hard to setup and configure if you know how it works.
I completely agree that being able to navigate an ecosystem's complexity is a skill.
I didn't mean to imply that other languages don't have complexities. All ecosystems come with their own boons and complexity issues (hidden or upfront). The thing I wanted to address is the general idea of "PHP is the simplest to develop in, it's just uploading a file" (paraphrasing) shouldn't be taken at face value, and that's why I pointed out some of the complexities when working with PHP that PHP developers tend to forget (or some ignore).
But, because PHP is so easy to get started with, a lot of the complexity initially gets hidden away, and sometimes people learn about it the hard way.
JavaScript used to be much the same, but it has gotten better in the recent years. Maybe PHP has gotten better in this aspect too, but I could be ignorant because I've not been keeping up with PHP as much
With a hosting provider that already has PHP installed, you can simply upload a file to a folder and serve it over the web with no special expertise.
PHP makes it easy for beginners and amateur programmers to get something working without knowing much.
Because of the low-barrier to entry and simple hosting setup people have written a lot of crap PHP code over the years. I know, I see it and work with it.
Amateurs and well-meaning power-users can get some web pages up and running easier with PHP than with almost anything else, so while inexperienced programmers can write bad code in any language a large number of them choose PHP.
None of those facts mean PHP is not suitable for "real" development and "real" programmers. It is not obsolete or dying. A professional programmer who knows how to build production-quality web sites can get great results from PHP. That requires putting in the same time and effort needed to learn any other language and set of tools.
> The ephemeral process nature of the language makes some tasks very difficult to do in a performant way (but there's caching, so that's at least mitigated).
I'd rather say that this is actually one of the biggest selling points for PHP. Opcache and JIT works great, and reduces the overhead, but ironically, PHP is great for serverless applications.
Your comment on file uploads in PHP reminded me of the remote code execution via automatic file metadata parsing vulnerability built into PHP that happened a couple years ago.
If you don’t manage your own servers I don’t think you can call yourself a professional developer. “My hosting provider doesn’t let me do X” is a lame excuse with cloud servers in the $10/mo range.
I do a lot of work with PHP, both legacy and new code. The number one mistake I see with PHP sites set up by amateurs or cheap hosting services is running Apache+PHP on the same server as MySQL or Postgres. Separate those and performance and stability problems go away. That’s because relational databases consume as much memory as they can get, not because PHP is inherently slow or unstable.
This is the classic "everyone who does not know how to X is not a real Y". Every single software dev can make such a list. Very few reflect on the fact that no two of those lists look the same.
You can't know everything. Programming is about abstraction; so abstracting away devops is a feature (in some contexts), lack of that is a downside (in some contexts).
No one can know everything. We can all learn things we need to know. Or we can post about how something we don’t know is gross, complicated, broken.
That sounds about as nonsensical as saying "If you don‘t draw your own icons I don't think you can call yourself a professional developer". Very few developers actually do both of those things. If you said "If you couldn‘t learn how to run your own servers…" I could possibly see that.
The distinction I was making was between companies, teams, developers who use cheap hosting services and then bash PHP when the problem is they don’t control the hosting environment. “I can’t change my PHP or Apache config because I pay $5/mo to HostGator” is not a good reason to complain about PHP.
> If you don’t manage your own servers I don’t think you can call yourself a professional developer. “My hosting provider doesn’t let me do X” is a lame excuse with cloud servers in the $10/mo range.
Hosting (as a service, and shared hosting) is a very complicated business if you want to do it right.
Also, when picking hosting providers, there are many things that factor into this. Social, political, and economic status are one thing (of the dev and the client). Another thing that comes to mind is the client's (or sometimes even dev's) location/jurisdiction (or the website's audience).
The availability/locality plays a giant role in selection in non-western countries. For example, some European countries/ISPS have super-fast internet within them or up to the closest IX (internet exchange), but horrendous speeds towards anything beyond the IX; sometimes these are intentional (alas, curse politics) sometimes they're not.
We had many clients that would migrate to us because they had these issues with previous providers because we were different from other hosting providers.
Disclaimer: I used to work for a hosting company
Yes, hosting can get complicated. A production web site should run in a production-quality environment, not on some $5/mo shared setup that doesn’t let you control the PHP/Apache/nginx environment. If that’s your setup you will run into issues eventually, just like you would if you couldn’t change the settings on your work computer.
Surely you also have to figure out the PHP ecosystem and paradigm if you don't have experience in it? In any case, I fail to see how PHP is more fun than, say, Python. I have done a few projects in PHP and I would take Python in a heartbeat. To me this seems like a clear case of Stockholm syndrome, but what do I know... Maybe I'm missing something.
There are other solutions to long polling now. You can use Pusher, ReactPHP or Amp (https://amphp.org/) to use websockets with php instead.
Until someone implements long polling in wordpress and has to load the whole framework for every poll. This can never be the right approach
I've noticed some good bits in PHP, there's indeed a low level thing to it; it's not trying to find the new paradigm. Their cli tools are often nice and to the point (rare quality). But the language per se doesn't seem to bring a lot compared to python in terms of expressiveness, and the regular bugs are still worrisome to me.
I would guess nodejs has the same development velocity. And you can just copy js files into a server that has node to build a web application.
You mention it in passing, how much ruby on rails experience have you ?
That made me laugh, thanks.
PHP is a lot better. But it still has a lot of the same old issues when you look beneath the service. Good luck remembering what all the str* functions they invented do and what order their arguments are in. Same for the array functions (don't get me started on implode's three signatures - but that's mostly fixed in 8!).
And may His Noodly Appendages help you if you come across a function being used which has no documentation and a single decade-old comment from someone asking how it works...
And so, to plaster over it's many flaws, people start layering framework upon framework upon framework, each of which slows down the language significantly from all those shiny PHP performance benchmarks you see. And then they wonder why their shiny "what's an array? we need to transit 20 different chained method calls for that" is so slow...
And half of them are documented even more poorly than PHP itself. At least their code is in the same language you're already writing, though.
The argument order flaw is never going away. BC. It's a super minor thing.
The non-documented functions are often rare and very minor and obivous functions.
This layering framework on top of frameworks sounds made up. Mostly people either use Symfony or Laravel. There aren't layers of frameworks. Your example is nonsensical. Frameworks are slower than simple code, this is true for every language.
And Symfony and Laravel are both well documented.
This comment overall seems to be written by someone who has come in with very little knowledge on PHP worked on a project for 3-4 months. When you work those style projects you're often working on poorly constructed projects. I'm pretty sure I can jump in on a project written in any language that has been poorly constructed and I will end up going wtf.
I am well aware that it is never going away. I wouldn't call it minor, it's an extremely common source of bugs.
The non-documented functions are indeed often rare. That's all that can be said about them. They're about as obvious, on average, as the rest of PHP's functions are obvious.
Sure, until you want to have a UI framework, and an API framework, and ...
LOL @ Laravel being well documented. There's a tutorial and there's autogen API docs. And that's it.
This comment overall seems to be written by someone who has worked with PHP for a few years and thinks he knows everything there is to know about it.
I've been using PHP since PHP3 and professionally since PHP4, but thanks.
Are str and array parameter order the only problem people have with PHP these days? Seems to be the only argument I come across now anyway
Nice work PHP
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.
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.
Why would you pick any other language instead of PHP for web dev?
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?
If you're happy with Elixir, just use Elixir.
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.
> If you're happy with Elixir, just use Elixir.
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.
You asked
> 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.
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.
I haven't worked in PHP for years but 2000request/second doesn't sound unreasonable for PHP either?
And that with a language that everyone can use.
2k requests might range from nothing to to hard, depending on what the page does.
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.
I feel you could be exaggerating just a little. :D
All languages can be used by everyone.
That is probably false for all practical values of "used".
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.
Here's what you originally wrote:
> 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.
Is there now a reliable non-hacky way to do threads or async, to run queries to multiple dbs or backend systems simultaneously in PHP?
Roadrunner or Swoole. Integrated into Laravel as Laravel Octane. Depends what is your definition of hacky.
Maybe Amp - https://amphp.org/
Other than the semi-hacky pclose(popen(call to db))? Not really.
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.
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).
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'm not sure I'd build a website or something with R
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.
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.
I like PHP, it pays the bills.
I also like other languages, some because they are a pleasure to use, or give me an opportunity to learn something new... but mostly because they pay the bills.
I don't think there is anything wrong with that, these are just the tools of the software engineer, nothing more. We use the tools that are appropriate for the job, no reason to make it into something deeper than that.
| php is fast.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
it's faster than python, but my grandma is too and she died in 1993. However, function calls are extremely slow. If you would bench something like a naieve fibonacci implementation (or ackermann's function) you would be surprised.
(naieve fibonacci) like this:
just did some measurements on my laptop:<?php function fib($n) { if($n === 0) { return 1;} if($n === 1) { return 1;} $r = fib($n-1) + fib($n-2); return $r; } $n= (int) $argv[1]; $r = fib($n); printf("%d %d\n",$n,$r);
(edit: added php version in table. )| Language | n | time(s) | |----------------------+----+---------| | php (7.4.25) | 42 | 422.0 | | python3 | 42 | 90.0 | | haskell (ghc -O3) | 42 | 13.8 | | f# | 42 | 5.6 | | ts | 42 | 2.8 | | ocaml (ocamlopt -O3) | 42 | 0.98 | | C (gcc -O3) | 42 | 0.66 |This is what I get locally:
I suspect that you're doing something very wrong, like running PHP with an active debugger or similar.time php fib.php 42 23s time python3 fib.py 42 1m1sIf we're talking in comparison to slow interpreted languages like Python, then function calls in PHP are not particularly expensive. Debuggers can make them quite expensive though.
Edit: Just to note, PHP's execution time drops to 4s with enabled JIT.
Likely. I tried the benchmark and saw runtimes of over 5 minutes before realizing that XDebug was active and in develop mode. Adding `-d xdebug.mode=off` dropped it to 26s. That was with `opcache.jit` in the (default?) `tracing` mode. Turning it off didn't change the runtime, which is a bit puzzling. This is all with PHP8 on macOS, although I tried 8.1RC in docker and saw similar results.
Something doesn't quite add up across everyone's results here, but the extremely slow result at the top of the thread is almost certainly a debugger slowing things down.
Edit: I was missing `opcache.jit_buffer_size`, and saw the runtime drop to under ten seconds with that correctly configured.
I also get around 23s, PHP 7.4.5
How is php 422 seconds? Are you basing that off the return value of the function? FWIW, I get 57 seconds when I run your function with PHP 7.4 using microtime().
that was PHP 7.4.25
Yes this is a microbenchmark. Yes, I know binet's formula... Yes it's weird function calls are so slow in php.
with php 8.0 (jit enabled) you get something like 120s (for n= 42)
naieve and micro benchmarks is not meaningful in 95% of cases. Did you run on the CLI with -dopcache.enable_cli=1 for example?
Opcache avoids the compilation step. It's not relevant in this case (compilation ~0.01s out of ~400s).
Microbenchmarks are meaningful as long as one doesn't read too much from them. This benchmark shows that PHP seems to have a problem with recurrent calls.
Is JIT enabled and configured for PHP?
Is that still true when using PHP 8.0 with JIT enabled?
https://twitter.com/ArkadiuszKondas/status/11196548025800212...
Was curious. The same implementation as /u/toolslive:
PHP 8.0.12: $ time php fib.php 42 42 433494437 real 0m29.274s user 0m29.003s sys 0m0.105s $ time php -dopcache.enable_cli=1 fib.php 42 42 433494437 real 0m26.341s user 0m26.179s sys 0m0.058s ---------------------------------------- PHP 7.3.5: $ time php fib.php 42 42 433494437 real 10m23.573s user 10m16.592s sys 0m1.828s ---------------------------------------- Settings for PHP 8: PHP Version => 8.0.12 auto_globals_jit => On => On pcre.jit => 1 => 1 opcache.jit => tracing => tracing opcache.jit_bisect_limit => 0 => 0 opcache.jit_blacklist_root_trace => 16 => 16 opcache.jit_blacklist_side_trace => 8 => 8 opcache.jit_buffer_size => 0 => 0 opcache.jit_debug => 0 => 0 opcache.jit_hot_func => 127 => 127 opcache.jit_hot_loop => 64 => 64 opcache.jit_hot_return => 8 => 8 opcache.jit_hot_side_exit => 8 => 8 opcache.jit_max_exit_counters => 8192 => 8192 opcache.jit_max_loop_unrolls => 8 => 8 opcache.jit_max_polymorphic_calls => 2 => 2 opcache.jit_max_recursive_calls => 2 => 2 opcache.jit_max_recursive_returns => 2 => 2 opcache.jit_max_root_traces => 1024 => 1024 opcache.jit_max_side_traces => 128 => 128 opcache.jit_prof_threshold => 0.005 => 0.005
I have stopped trusting the aforementioned link because they play dirty games with benchmarks, most of the times.
Let me give you an example;
andhttps://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-python3-2.html
The Python code uses ctypes, thus the unfair marginal difference.https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-perl-4.htmlI have seen the same unjust comparison with the majority of the examples and decided to stop relying on this page for validating programming language performance.
> … because they play dirty games with benchmarks, most of the times
No they do not.
Let me give you an example:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
*** You ignored the Python code that does not use ctypes.
> I have seen the same unjust comparison with the majority of the examples…
No you have not.
There are 10 different tasks.
pidigits accepts the use of third-party libraries (GMP)
regex-redux accepts the use of third-party libraries (PCRE)
That's 2 out of 10.
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...
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.
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.
It does, but it's mostly transparent to the user. I've never had to think about it when I was installing WordPress.
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.
All shared hosts already come with LAMP pre-configured. You just plug already supplied credentials into the WordPress setup page and that's it.
So does ex. heroku for all the other languages, and that actually scales. As well as most shared hosters offering node and rails.
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 :)
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/
I was just using generic examples.
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.
So true. The time to market is unbeatable in PHP.
Not a fan, but that is definitely a very good argument.
This argument may have worked in the years before Heroku (or Docker even) but it’s really outdated in 2021.
Then you have the myriad of static site hosts that also take 2 clicks to host something without even having to write any code.
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 believe at least one of the options you listed is actually built with PHP (Shopify).
Perhaps, but you don't have to know or care about that that to use it.
Same with WordPress. You install it (or have it installed) once, and then never think about what language it's written in.
Shopify is famously a Rails shop, but it is likely that a couple of the products on that list are built in PHP.
Shopify is Rails actually. I think Magento and Prestashop are PHP
Shopify is famously a Rails application no?
Yes
Does this really hold true in an App Service world? Just load your repo and go.
I'm talking about the kind of small org that doesn't know what a software repo is - zero technical experience at all, except for the very basics.
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.
jQuery changed my life.
These days I write server code in C++ :(
Why so sad, that sounds like a huge improvement over webdev. Modern C++ is a joy to work with.
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 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.
If you like PHP, great.
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.
> 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?
Except Facebook literally did that :)
But I agree with you.
Wikipedia too. And probably many WordPress websites with a lot of traffic.
If anything, PHP has proven it works in this regard.
Facebook and Wikipedia were both founded ~20 years ago, think they would make that same decision today?
PHP works, but imho starting a new company or career with PHP is a mistake.
I don't know, why not?
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.
Couple reasons:
* 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.
Also Slack, Etsy, Baidu (4th most visited site on the planet), Box, MailChimp, Spotify to name a few more that seem to be doing ok.
Yep, almost 20 years ago and it's been both a technical and hiring problem for them ever since.
Is there any large tech company without technical and hiring problems?
Why make it worse by choosing backend-only web languages with bad reputations?
> Anybody who tries to convince new programmers to learn PHP is doing them a great disservice.
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.
> 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.
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.
This seems like a desperate attempt to justify not moving on from a language whose death knell rang a long time ago.
You might as well try to convince me I should start my next business with cutting edge software written in Fortran or COBOL.
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.
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).
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.
> Do you write that site in Go?
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.
> Do you write that site in Go?
Yes! https://gohugo.io/ would be a great choice for that kind of thing.
But you don't write Go if you use hugo?
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.
That would likely then require a developer to update the content. Not ideal for a marketing website.
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.
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.
Do you write that site in Go?
Honestly if all I needed was a marketing site and a place to host my documentation, I would 'write' it in something like Squarespace.
Somewhat related, what's the Go laravel/rails/django equivalent?
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 :)
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 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 people are out here voluntarily writing server-side javascript code, I see no reason to call PHP dead
what are your feelings about server side typescript?
it's quite a nice language, and for many many cases is certainly fast enough these days.
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.
Is there a preferable language?
I've never regretted the time I took to learn PHP. No matter how bad the language may seem, it paid my bills for a long while. It's one those tools that to keep in your back pocket until you need. Keep in mind what it's good for and what it doesn't do so well.
That said, php's online documentation is one of my "gold standards" for what good language documentation should provide. (At least it was the last time I had to reference it.)
I really like how the documentation also includes a huge amount of user contributed notes that demonstrate various alternate examples as pointing out certain caveats/nuances.
This seems like a false dichotomy.
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.
> 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.
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
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.
Opportunity cost.
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.
Not that I code in PHP anymore, and I havent for years (felt like I had to say that).
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!
> 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.
> 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.
Different tools for different job
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.
There is never a best language. You make it sound like PHP is almost worthless in 2021 which is also not true.
There is probably a set of "good languages to learn" for every individual. There are two good reasons to learn a programming language:
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.
PHP was my gateway to understanding C. It wasn't my first, but it definitely helped me learn more computer fundamentals than other languages.
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.
I felt like PHP set me back as a first language (many moons ago). It just works so differently to other languages.
Can you pinpoint anything in PHP that allowed you to gain such knowledge better than whatever your first language was?
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.
But, what is, if not php? Do you shoot for what has had longevity, or what's rising?
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.
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.
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...
From brutal experience I can tell you that's also been true for PHP programmers for a long time.
Maybe still. But I'm pretty sure 5-10 years from now PHP devs will be in demand since everyone is moving to Node/Go/Other Hype.
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.
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.
Encouraging new programmers to learn Java isn't cruel? "Son, today is the first day of a long journey into enterprise software development. Yay"
It is cruel, and something Universities have been doing forever.
You prefer customizing wordpress?
I'm still seeing shared hosts offer PHP everywhere at very cheap prices.
That's not true for Java or C#.
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.
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.
Fine: python, ruby, go, rust, elixir, c, java, javascript, plenty more.
Pick whatever you want. Just don't pick a language that is known to be on it's last legs.
Purely from the outside (I don't really use either), ruby looks more dead than PHP nowadays.
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.
Do all of these make it faster than PHP?
> Do all of these make it faster than PHP?
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.
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.
Ok, so similarly "dead" (or not) as PHP.
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
PHP is used far more than Ruby. Wordpress alone dwarfes any Ruby usage.
I guess it depends how you quantify it, but I was thinking Shopify's use of Rails would have started competing for %
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.
Compare what the PHP jobs pay or the career path they put you on compared to elixir or ruby. Not even the same ball park. Not even the same sport.
I bill £650 a day for 'PHP development'.
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)
> Compare what the PHP jobs pay
Where? At Facebook? Or somewhere else?
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.
Hack isn't PHP anymore...
> Just don't pick a language that is known to be on it's last legs.
I’ve heard that exact sentiment over and over since the RoR community aggressively started with their anti-php agenda in about 2006.
Funny, Ruby seems like the language that's most obviously in decline right now. (Though as a Scala fan I shouldn't throw too many stones).
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.
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
- typescript
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.
Well lets start with things I do like about PHP. I like that they had the web use case in mind right from the start and this shows in stdlib APIs PHP offers. For example database interaction, image uploads, cookies etc. Many languages need that via a framework but PHP is ready to go from the start.
What I do not like is the syntax. Call me picky but referencing attributes with -> instead of a dot (.) is ugly to my eyes and I prefer JS, Ruby or Python when it comes to the pure look of the code.
Generally I'm not a fan of dynamically typed languages because I just feel way more productive when I have proper code completion and type safety.
In general whatever works for you and makes you happy is good enough.
:)
It's fine for the web. I used it for years. Not a great general purpose language though, if for no other reason than the ecosystem is focussed on the web.
Great article for PHP devs too. I've spent a lot of time in PHP over the years and found there is a bunch of stuff I didn't know about.
Agreed! I didn't know about this project for payment gateways from the article: https://github.com/thephpleague/omnipay
I am surprised when [1] Python or [2] Ruby is recommended over PHP at the very least from a performance standpoint. PHP has a lot of built in standard library utilities and it's execution model is so simple for both web applications and scripting system automation jobs.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
PHP is still very popular in EU. In my experience, the consensus of PHP is completely different than what some of the people still post here.
I have used PHP for years. I like it too. Its tight integration with http is nice.
The PHP language can be used as a templating language itself:
<?php
$user = 'root';
?>
<p>
Hello <?= $user ?>
</p>I think* with ASP.NET Razor Pages. You can do the same thing as:
@page @{ var user = "root"; } <p> Hello @user </p>Razor is awesome... It has this productivity of PHP while being consistent and have the benefit of being conceived later.
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.
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.
Please, do not do that. Use an actual templating language which automatically escapes output.
I have a few questions:
- 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.
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.
Sorry, I should have clarified "heavy" in terms of the level of OOP [1] insanity but yeah Symfony is very modular.
[1] e.g. "Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator"
> in terms of the level of OOP [1] insanity
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.
Look at what I was replying to. The guy commented about the amount of OOP in PHP.
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.
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.
Nine years ago I decided to use plain old PHP and MySQL to build a self-hosted analytics platform[0], and to this date I still think this was the best decision I could make. Even though nowadays cloud, Docker, Golang, Node.js, Kubernetes are all the rage, most of the websites and hosting providers are still running on PHP/MySQL, which means running the platform can be done on the same server and customers can try it without having to learn to deploy to the "cloud".
Not only this, but PHP/MySQL is such a reproductible stack, if the code is properly written you can run the same app on tens of different server configurations (Windows, Ubuntu, CentOS, various versions of MySQL and PHP) without having to change anything.
<?php echo "oh you!"; ?>
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.
There's nothing platform-specific about C# and Kotlin.
In theory, true. In practise, they are most popularly used for the Microsoft and Android ecosystems, respectively. I’ve reworded it to platform-oriented.
I'm not sure what you mean by 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.
Ok, I'm just trying to understand. Not trying to make you create a scientific classiciation :D I just disagree as a .NET developer.
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…
And there's a reason why people are generally not doing web stuff in python or rust.
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.
Sure, a small minority of sites are partially written in python.
Tons of sites are written exclusively in Python. Django alone has 60k stars and 25k forks on Github. That about the same as Laravel.
A quick search came up with an order of magnitude more sites in laravel than django. And combined are still a small fraction of sites on the internet.
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.
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.
I use a hammer for nails and a screwdriver for screws.
It is, but not as "worth it" as python
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.
As someone actually did (re)learn PHP (last time I used PHP was PHP4) last year for a gig, I would probably say no. Don't get me wrong, it is a much better language now and Laravel is a great framework. With the two you can no doubt build fantastic applications. But I didn't feel it was 'better' in any way than anything else. With Python, Go, Rust, Elixir, TypeScript etc. I can all point to a thing they do and say "if you are solving this sort of problem, then this language is the right choice because of X, and worth learning". With PHP I just couldn't find that.
I always suspect modern php makes the language nicer but actually reduces it's core feature, the ease of use.
Don't get me wrong, I would not like to use older php these days. But just throwing 2 files onto an ftp was always php's biggest strength. It somewhat retains that for "installing" php, which still is often just "copy to server" which makes it really nice for users. But I feel it mostly lost that ease of use for people learning to program.
Now, it is still a solid language considering performance and such. It has proven itself to be. But without the easy way from zero to programmer, I am also not sure it is a better choice than anything else. Especially since it always had so many terrible footguns and at least in my opinion is also atrocious to look at.
Here's one: If you want your operations to be as easy as they can be (LAMP), go with PHP.
I had exactly the same experience. Yes, it has improved, but, no, I did not see any reason for using PHP over any other language (Ruby, Python, JS who all have their own selling points).
off-topic, but: Go and Rust seem to aim for the same space (system programming), so when is one preferable to the other, in your opinion?
> Early PHP was not intended to be a new programming language, and grew organically, with Lerdorf noting in retrospect: "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." [0]
This might be an unpopular opinion but I think PHP gained mindshare in the early days because Coldfusion (CFML) was neither free nor open source.
To me personally PHP is the cheapest way of building a dynamic website. Just a few euros/dollars a month will get you a shared web hosting plan with full support for the LAMP stack & free email.
That was true in 2004. Today you get a virtual server for five bucks a month. Feel free to run ANY stack you prefer.
Virtual server is great except now you are reponsible for server management, SSL certificates, backups, DB, firewall configuration, mail server, etc. I don't want any of that which brings me to PaaS providers like Heroku and Vercel where the cost is many times higher.
I learned web programming on PHP, and a ton of anti-patterns well. Making a single script with a very rich stdlib is quite handy, as well as "just running it" on your desktop instantly. However scaling out large projects in a performant way, doing big refactors, or mature server programming, I'd pick nearly any other tool today.
Disclaimer: I still maintain my PHP site from '08, so I'm current on trends.
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.
You guys think a hell of a lot about your hammers
It's a tool, use it or don't. Why do we have this weird slap fight every 2 months? It's so weird
Because we use our hammers 40 hours per week. If you use something that much it is perfectly normal to have opinions.
I haven't commented on this thread until now (I left PHP so many years ago, I have nothing to add) but are you suggesting to never discuss with other peers about the available tools for the job? Could you be more specific on your proposal?
No, I'm not suggesting that. I am suggesting that the same conversation happens over and over again
"PHP is good now!" "No it isn't!" "That was PHP 4!" "array and string functions" "abstract it with a framework" "PHP is slow" "It isn't" "it is look benchmarks nobody will ever need"
See y'all in 2 months haha
My team has been using the Slim Framework for years and it has servered us well. It is a microframework and follows most of the PSR standards so it is possible to replace libraries with relative ease.
This actually convinced me that PHP isn't as bad as it used to be. Though it's still not all that inviting, knowing Python, Typescript, F# etc...
From Pyjokes: Coding in PHP is like peeing in a swimming pool. Everybody has done it, but it's best not to talk about it.
PHP needs a proper type system with generic support, and would be a killer programming language
I'm aware of Hack, but I don't have full control over the stack, so having all these features included in core PHP would be the only way in my case.
I heard that Php is unsecure by default. Wonder what's the state of that?
There used to be bad defaults, such as "magic quotes" and "register globals".
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.
Depends on how you use it. It's always been dependent on the programmer.
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).
swoole is a pretty interesting alternative as it allows asynchronous programming in PHP.
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.
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
[1] https://github.com/swoole/swoole-src/issues/4434 [2] https://news-web.php.net/php.pecl.dev/17446
Roadrunner looks cool, thanks for the recommendation!
Litespeed, or Apache+mod_lsapi are excellent alternatives.
If self-hosting, Nginx and FPM is well-tested and very fast.
PHP maybe worth learning and using for building websites, but PHP is one of the worst languages to learn for someone who is interested in learning programming as a hobby, interest or career.
There is also a proposal about generics: https://wiki.php.net/rfc/generics
There are package managers, yes, but probably you won't need one. Because of the mighty standard library. Thats a big advantage, compared to the tiny-package-mess at npm.
If you haven't worked in PHP, you don't know what you are talking about. You only think you know what you have heard.
I have worked in PHP recently and it is still a pretty bad language. Not as bad as it used to be but still pretty bad.
Someone has experience with hyperf?[0]
After learning and developing with PHP, even with the new stuff, I would never choose to use it for anything.
I've been using this language since 2002. Still good for most kind of tasks in web.
PHP is great as long as you accept it 100% for what it is - a shitty language.
Have you used a version of php from the past decade? Or are you conflating a bad framework or codebase with a bad language?
Yes, it's like an old Model T Ford from the early 1900s that has had a turbocharger, air conditioning, a new stereo, a subwoofer, roof rack for a bike, roof rack for a tent, grounding straps, trailer hookup, clean water system, etc.. bolted onto it.
At some point you ask yourself - why did I do all of this to a Model T? Sure, it has some modern facilities but the language itself was never designed and so none of it feels cohesive. The syntax is off-putting. It's just a ton of nightmare for what reason? Why? There are so many other languages to choose from and PHP has no competitive advantage other than $3/mo GoDaddy hosting.
You have to give up arguing.
The PHP dev will look at a Model T DIY'd into "The Homer", and beside it a 2016 Toyota Corolla.
The PHP dev will argue, sincerely, that The Homer is just as practical of a daily driver as the Corolla. You have to just walk away from this kind of person.
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.
what's new in programming language theory since the 70s?
Javascript is hot trash, and frameworks die so frequently I have never bothered to learn a single one. I'd still recommend javascript over PHP.
Learning is always good...
This conversation gets so vitriolic every year or so when it comes up. I'm temped to go argue in the threads, bust instead I'll just share my (recent) experience with PHP in case anyone is actually on the fence rather than here to flame.
I started out doing PHP back in the everything-is-WordPress heyday. It was easy to SSH/FTP directly into sites and edit things live, and that was also a very normal thing to do. I got good at PHP and felt kind of defensive when people said how bad it sucked. Right tool for the job and all that. But, after some time doing it, I knew I wanted to break out of my PHP shell and learn another language. For some reason I felt like I could only pick one more language to learn, so I was hesitant to do so. I ended up going with Ruby. Only then did I understood what all the crap talk about PHP was about. It's probably both a language problem and an ecosystem problem. The ridiculous, complicated iteration over deeply-nested array-dictionary-combo data structures with various counters stuck in local variables here and there that I had previously considered normal vanished before Ruby's sleek Enumerable module. Of course you can code better PHP and avoid writing those kludges, but as a junior coder, that's the thing that stuck out to me when I switched from a PHP shop to a Ruby shop. Kludges and the worst inherited Frankenstein projects of my career. I swore I'd never work on PHP code again.
I spent several years doing Ruby, and along the way picked up several other languages and now can't fathom why I originally had such hesitation to pick one to learn. After gaining enough experience to be a senior engineer, a friend recruited me for a job doing PHP. This was at a big company with tens of thousands of enterprise customers, high-scale stuff. The money was good, and I had heard a lot about how PHP had cleaned up its act since the 4.x days. It's object oriented now and has a proper standard lib! I spent 3 years there, and I have to say the engineering talent there was good. Many ideas from other languages like Ruby's Enumerable had been replicated in our toolkit.
However, the vast majority of the code was still weird data structures that are unique to PHP development because of its lack's both real arrays and real dictionaries. PHP has indeed acquired standard lib, but many pieces of it still have a crap implementation. It's like they went out of their way to make lousy APIs for things like dates, times, and durations. In every other language I've used, you can easily compare time durations (is 1 hour longer than 1 minute?). PHP DateIntervals are not comparable. The API for creating a new DateTime object at a specific date is still to pass in a specially formatted string. Or, if you don't like that, you can create a DateTime for "now" and then mutate it to set the date. They may be adding language features to catch it up with other languages, but it seems like they're obstinately doing it in the most PHP-like way possible
Long-lived resources like database connections, Redis connections, etc. plagued us. We had a whole middleware in our stack dedicated to holding open proxy connections to things like MySQL. The thing that PHP enthusiasts say make it so attractive (edit, save, refresh) also bites you in the ass because PHP processes spin up and die with each request. There is no long-lived process holding onto those resources.
As of 7.3, It was still the same old PHP I knew back in 4.0. It's still crap and this time I swear I'll never work on PHP code again ;)
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.
php is very easy to use,it saved a lot of my time,I have used PHP to created a simple Social networking site: alovez.com ,this is my homepage on my website: https://www.alovez.com/bing
The only argument is: you can deploy your PHP app on any 1$ shared hosting plan. Just copy the files and you’re done.
And yes, PHP is not as bad as it used to be anymore.
Apart from that, I don’t see a lot of benefits.