IMO that's extremely powerful in its simplicity and while you can get it in other languages, it feels like like a "core competency" for PHP (just like how async code is easier in javascript than in python, because JS kind of had it from day 1)
The original promises syntax and chaining in ES6 were not particularly user friendly.
It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.
> you need an external server
Spoiler, you need an external server for everything on the web; you've just been brainwashed to think serverless is actually that.
So yeah, you technically don't need one for Ruby or Node.js, but I sure would.
Lots of languages and frameworks make it easy to be self-hosted with there own server. In Python, .net, Go, Rust this is quite common.
This means that your app can be a self-contained app + server and the server part can have some business logic as well.
With Go, .net, Rust apps (and potentially others) that's quite nice to be able to produce a single binary app that you can just run anywhere without installing any framework or setting up any external server and it's ready to listen to incoming queries.
That can even be a good enough setup for home things that are not exposed to the web and where setting up reverse proxies could be overkill.
Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.
I only host one PHP app now (Nextcloud) and it has definitely been a bit of a pain in comparison with other things I self host.
Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).
I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.
I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.
In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.
Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.
Furthermore if I'm working with JS/TS, hot reloading even makes it so I don't even need to refresh the page. I can even inject code into arbitrary places with the debugger (as if I'm editing the source)!
So, all these other ecosystems are on par with the PHP...
I'm glad PHP adopting ideas from other communities, and that the community is becoming more cohesive, though.
Aside: I used to write PHP before (back in the 3 to 5 days), and worked for a big web hosting provider that had a big shared hosting customer base; PHP was by far the most popular technology in that space.So, I'm not trying to bash on PHP.
With PHP, you install the toolchain, save a file and the page becomes available.
With JS/TS, you install the toolchain, and then enter a complicated process of yarn/npm incantations in the command line to get the project working right. The manual may say "yarn add typescript" but in practice there's always more setup and configuration to be done before it works well.
For "real" projects, there's not that much of a difference between yarn and composer. For getting started, though, the process is a lot more involved.
Another problem is that running Javascript on the backend is almost completely different from normal frontend development. If you want to store state, you end up using the same (or even worse, a similar) programming language with completely different contexts and available libraries and methods. You can't document.createElement in the backend to tell the user that an operation succeeded or failed, even though that's what you'd do if you were working on a frontend file.
With PHP, you can't do frontend, so whenever you write frontend code, you can't get confused. In my opinion, this makes learning PHP backend dev a lot easier. It's only natural that you choose to continue working in the language you've started you development career in. You can see that by the fact that there are still people who swear by VB.NET, despite everything.
The JS ecosystem does have the advantage of coming with a debugger, but PHP users can get the same by hooking their PHP install into the PHPStorm debugger. I think it doesn't matter much which language you use at that point, it's just a tooling preference.
All in all, I think both languages have their uses. If PHP really was as bad as people say it is, it would've died out already.
Locally however it is save, alt-tab, ctrl-r and immediately you see the result. Absolutely no waiting.
These days I rather use Quarkus for this but until Quarkus arrived this was a huge advantage that PHP had over every other language and framework I was aware of.
Also the documentation was fantastic compared to most of the stuff I have had to suffer through on Java, .Net and even React and Angular.
Every thing you may reasonably wonder about was described in a clear, straight forward way and included examples.
Which I suppose is just a fancy way of a copying files to the server.
Modern PHP wears a business suit and wants to buddy the "big boys" (Java/C#) of the world. You'll have deployment pipelines, strong push towards classic OOP, strict type checking etc.
I personally think ruby for instance is leaner in its dev process in most real world projects.
You can have deployment pipelines etc, but if you like, you can still develop the ancient way - it still works.
Now you can put .py files into your www folder, like .php files.
One can also use old school CGI to serve their site, it’s super lightweight and you just upload the file at the right place, for almost any language. But that has been deprecated for the last 2 decades now.
It works for them, but I wont tell random people starting a business now to go with pen and paper, 99% of the time that would be a bad advice when there are much much better alternatives now.
I believe that PHP is the easiest way to just Get Things Done when you're starting out with a programming language. To deploy a website, you sign up for a free account somewhere, often with a free subdomain like mywebsite.cheapwebhosting.com, put the files on there and hit refresh. Seeing a result immediately is very motivating for beginners, and PHP doesn't require knowing anything complex like DOM manipulation to generate web pages the way Javascript does. If there were as many free web hosts that allowed the same ease of use for C# or some other language with inline templating, I'm sure it'd take off just as easily.
The language isn't as bad as people claim either, I think it's on par with languages like Python and Javascript. PHP has its quirks, like using a dollar sign for variables, it's really not that much worse than its competitors. Shorthands like $_POST/GET/SESSION are such a relief to work with compared to the "professional" languages with their frameworks upon frameworks and complex, layered objects representing state. It's a great tool for setting up a simple website, maybe even a very basic web shop, where the "big boys" are complete overkill. A website like HN doesn't need more than a few PHP files to function until it hits a certain scale, and even then scaling up PHP websites is relatively easy.
I think the real reason people hate PHP is because it's a language used by a lot of beginners and intermediate programmers who overestimate their ability and deliver subpar projects that someone else now needs to maintain or rewrite. I wouldn't want to inherit some kind of custom blogging engine written by an intern three years ago in any programming language, and because of its ease of development many PHP programs are just designed badly.
- install/update PHP or go with the outdated version that shipped with their system.
- have a hosting service that will accept random PHP files
- know what their hosting's PHP version/configuration is to match it locally. For instance their hosting will keep the most secure config possible, thus no out of the box fetching of URLs.
- endlessly fight to find syntax errors as they are too new to have a linter. Depending on the PHP version they settled on they won't have error logs in one place but two.
- fight the endless stream of out of date tips and tricks left by 2 decades of PHP programers of various pedigree.
All of these have different variations for different languages, they all have their barriers and dead bodies in the closet. My take is that PHP isn't specially beginner friendly at this point, at least not as friendly as it was when it began.
Making a public website from scratch will be complex anyway, so they might as well go with a saner setup that uses a templating language and not write code right into the HTML. It won't be much harder and they'll have a fighting chance to find up to date tutorial to host their project easily (hosting a rails project on Heroku for instance could be miles easier in that respect)
PHP already has caught up to others with 5.6, these days PHP 8 doesn't lack anything found in other major languages.
What is still confusing is the standard library, but only for people who never worked with C/C++ before - as most of the native PHP standard library actually originates as a verbatim copy of the C/C++ libraries.
1. WordPress uses it
2. PHP is far less terrible than I remember (having used it in very early days)
I manage a WP (woocommerce) site for a small business. It's not my day job, it needs to be simple. Most of the "day job" is handled by content management users. I have written a fair amount of plugins though to enable custom functionality and the process is perfectly fine.
I looked at Ruby, I looked at Python, I looked at node. There's nothing as simple and, frankly, as mature aside from commercial platforms like Shopify that charge an arm and leg.
I honestly always wonder: as opposed to what? Let's take my simple requirement, a small business ecommerce store that's not going to look like trash and where non technical users can make pages, edit descriptions, etc.
I can do: WordPress, Magento, or I can pay a SaS provider. Essentially both do it yourself approaches are PHP and Magento has really sabotaged itself with the complicated migration. SaS means higher costs and if I want custom functionality (and yes, the business needs it), it ranges from impossible to possible but a headache.
So here is a business that is now online for a minimal cost for two years, allowing great flexibility for me, while allowing completely non technical users to get crap done.
The two things I can think of quickly, that I like about php, over another, is the ease of code->browser. You have to manage 0 build configurations or pipelines to get what you want working. Just download the files and open a browser. The second, is 100% transparency with third party libraries. Because of the lack of ability to compile, when I download a third party library, I'm getting their actual true source, and can much easier, navigate and understand the library right through the ide, without having to read a bunch of docs online and that it's true to source. Being able to control click into third party libraries is quite liberating.
But maybe this is just me.
And yes, 4,5k USD/month is massively good salary for Europe.
On the other hand, I see many job offers with salaries being just a joke (idk if they find any good developers for such money)
In eastern and southern europe: that's probably good for a junior engineer, and perhaps average for a senior
In northern europe: that's probably average for a junior, below average for a senior
For example, in Berlin it seems to me that average salaries are around 70k EUR/year (6.6k USD/month) and really good salaries are well above 90k EUR/year (8.5k USD/month).
You can see more data in https://www.levels.fyi, which it is skewed to the high side, but gives you an idea about what good offers are nowadays.
I'd consider a PHP job, but only if they quarantee they don't have any of those legacy maintaining things lying around.
I see your point, but there is lots of legacy code (in any language) laying around and making shit tons of money for their owners - hence the need to maintain these systems.
PHP had no common way to do anything for a long time and you still see it from people writing PHP today.
But I like the idea that these people may exist out there :)
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.
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