The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN.
Here are some facts:
- Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language)
- PHP has more active contributors than it ever had [2]
- Laravel is one of the most used frameworks in the world [3]
Then I see statements like "PHP only exists today because of legacies being maintained". Can't provide stats on this, but neither can the people who make these statements. Might be just because I'm a PHP dev myself but I see a lot of new projects started with the above frameworks.
And last, people compare it to languages like Rust or Go since they consider those are "innovative". I hope everyone understands that a language is fit for a certain type of task. PHP was created for website development, and in that area neither Go or Rust are even close to matching it in terms of maturity.
I may be biased but for me, choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core, and except for these two I wouldn't seriously consider any other competitor for starting a new project. Unless, of course, that project is "for fun" and you want to experiment with new technologies.
You claim "misinformation, false claims and unsupported statements" while you yourself only appeal to popularity and habit. Those are not directly correlated to quality. It simply means that PHP in the eyes of the businessmen is the safer choice due to a much bigger hiring pool. The popularity and adoption have a snowballing effect; once a certain critical mass is achieved then the whole thing sustains itself.
Every reasonable programmer will agree with you that different languages serve different niches. Nowadays however there are several mature and solid web frameworks in other languages, thus PHP is very far from the only -- or the best -- contender in this area.
And yes, you are biased. That's quite okay. I can also make a ton of smaller projects in 2-3 days with Elixir's Phoenix -- some that have a smaller scope I can also do with Rust's Rocket even. But I don't claim they are the "no-brainer" choice. You should not too.
Finally, implying that choosing anything other than PHP makes the project a "for fun" endeavour is disrespectful and does not do your argument any favours.
- No proper connection pooling with circuit breakers.
- No proper multithreading (that works in web environment) or parallelism in general.
- Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server).
- Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible.
The reason for this is because PHP doesn't support many things that are expected in any other language.
PHP C API is hard to understand, hard to use, and documentation is subpar.
- There is no way to easily share memory between processes. You have to rely on APCu (hack), because this cannot be implemented in PHP.
- Did I mention that almost anything can block? ODBC? PDO? Some 3rd party library? Even set_time_limit cannot help you here. Handling this gracefully is close to impossible.
It is when discussing the merits of a given language, and the assumption is "a person knows the language under discussion".
I.e., for the criticism to not apply in this context, a solid PHP developer...has to also be a solid C developer. Given the context is "using PHP", the former is likely, the latter, not so likely. Exactly how likely I don't know (I don't use PHP, so don't really have an opinion anywaay), but most discussions I've seen around PHP don't also presume the adoption of C.
Maybe you are not familiar with PHP multithreading in recent times but I have been using https://github.com/krakjoe/pthreads and works perfectly. No process forking.
Haven't been following php in years, but from back in the day I remember many different approaches trying to introduce threads and none could guarantee safety for the fundamental reason that the language itself is implemented unsafely. The runtime was done in C with unsafe features from the start. So process forking was the only sane reason to run php. I don't know how much of that is still true, though.
No native support for concurrency operators, no real event loop implementation, lack built-in support for non-blocking IO...
I do Elixir regularly and Actor Model is not something PHP developers know
Is this just a long way of saying it doesn’t have “async” because threads are a perfectly fine concurrency primitive that you can build event loops on top of.
> - No proper connection pooling with circuit breakers.
PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design.
> - No proper multithreading (that works in web environment) or parallelism in general.
I once asked Rasmus about this face-to-face, during one of his presentations, specifically his thoughts about the pThread extension (https://www.php.net/manual/en/intro.pthreads.php), and he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
> - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server).
Well, it depends on your code of course, but pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling? Seems like a strange example. And as mentioned above, no (excluding optional pThreads) support for asynchronous threads in the language, so...?
> - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible.
Ok now you have just thrown away one of the main benefits of PHP. Remember, Rasmus is a C programmer, not a PHP programmer, so he wanted to leverage that HUGE library of existing C-code from his new scripting language, from the very beginning, deliberately by design.
> The reason for this is because PHP doesn't support many things that are expected in any other language.
Yes it does, via the C-extensions, see above.
> PHP C API is hard to understand, hard to use, and documentation is subpar.
Yes programming in C is hard.
> - There is no way to easily share memory between processes. You have to rely on APCu (hack), because this cannot be implemented in PHP.
Deliberate design choice, "shared nothing architecture", stateless between requests, as above.
> - Did I mention that almost anything can block? ODBC? PDO? Some 3rd party library? Even set_time_limit cannot help you here. Handling this gracefully is close to impossible.
Yes because each request is a synchronous thread, as described above above. By design.
I'm not anti-PHP, so I'm not supporting the grandparent post in general. But as someone who is working on a PHP extension right now, I agree that PHP's C API is under-documented.
I don't think this is just a case of "programming in C is hard." Some C APIs are amazingly well-documented, especially Lua. If you open up Lua's reference manual (https://www.lua.org/manual/5.3/manual.html#4), it explains just about everything you need to know to write good C extensions. Every public function, macro, and constant is documented. Python's C API is pretty well-documented too.
> Well, it depends on your code of course, but pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling? Seems like a strange example. And as mentioned above, no (excluding optional pThreads) support for asynchronous threads in the language, so...?
What to proceed with? Well, any other code of course! Does all code in a current task depend on writing something to a database or reading from it? What if you need to get data from multiple sources? It would be stupid to wait for every single connection to be made sequentially, instead of proceeding with the next one.
This is just one example. This is actually what Node is often lauded for, making a lot of use of single cores, due to putting one "task" at rest and asynchronously proceeding with the next, not blocking.
I once asked Rasmus about this face-to-face, during one of his presentations, specifically his thoughts about the pThread extension (https://www.php.net/manual/en/intro.pthreads.php), and he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
if each web server thread that serves a request ends up spawning a full PHP process then it's not a mute point.
pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling?
proceed with all the rest of the bootstrapping code in parallel instead of blocking and waiting for each.
is a synchronous thread, as described above above. By design.
it's a synchronized full forked process. Because the runtime was written using memory unsafe C features from the start. By design doesn't excuse it being a bad design.
It's php-fpm persistent threads (seperate Daemon listening on port or socket), not web server threads, just to be specific. You have a lot of control of how many PHP threads you will allow per web node using php-fpm, very reliable tech. The days of mod_php are long gone.
So I meant one thread per request at the php-fpm level, not Nginx/HTTPD level.
Still, my understanding is that php-fpm spawns processes, not threads. What is "persistent" is the php-fpm daemon itself that's connected to nginx, but each request spawns a whole process which has to bootstrap your whole framework every time. That's the reason frameworks like symfony run almost mandatorily with something like opcache.
Oh I see, yes you are correct each request will bootstrap your PHP code stack framework each time (mitigate with opcache). Seems weird I know, but it goes back to that "shared nothing" principal: nothing is kept in memory between requests. On the plus side of that principal: nothing is kept in memory between requests that is not currently being used.
Coming from a Java background into PHP, this really confused me at first, until I started to think about PHP's approach as some kind of super-agressive garbage collection: everything gets released in that reqest thread once it's completed.
It's a fundemental design choice of the language that you have to embrace if you want to use PHP (I love it now, simplifies so much), or move on to another language.
> PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design.
A bit ironic that you compare it to microservices, because that exact property of PHP makes it massively unsuitable for microservices and scaling, because it requires another layer in between the microservice platform handling the scaling, and the actual application.
PHP has it's uses, but I wouldn't go beyond a classic monolith or "backend/frontend" style application with it, with very little, manual scaling. If you go beyond that, you could probably manage to do that with a proper architecture and doing wonky stuff, but would it be a good fit? Absolutely not.
I've been hearing that "PHP does not scale" arguement for many, many, years, in many, many, variations.
When you really have to scale, infrastructure, resources, and networks will rapidly overtake any concerns around your choice of language. You can develop crappy architectures in any language, and the inverse is true.
Not my experience. At scale, once you go down the 'cloud native' (kubernetes) path, the infrastructure part becomes relatively straight-forward, but PHP's weaknesses become very apparent.
Doesn't work very well with message queues. Sure, pushing messages is not a problem, but consuming? Something has to do it? But it won't be written in PHP. It doesn't work very well with SQL databases, and with that I mean not the querying etc, but connection pooling, so the database server doesn't suddenly gets flooded by thousands of connections because a service is autoscaled due to heavier load (and sadly, that's a real-world example that brought down a database cluster). Tracing is doable, but not ideal, metrics are hacky due to the need of weird extensions to support shared memory, or rely on an external database such as Redis, which kinda defeats the point of metrics being lightweight. And tuning the PHP runtime almost rivals the JRE...
> but pretty hard to proceed with some code that works with a DB when the connection can't be established
When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc. You probably have background threads that do cache invalidation, queue management, etc.
You frequently have to be more reliable than your database.
> he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
I use multiple threads in a single request flow frequently. Dispatching requests to other services or data stores, updating in-memory caches or queues (not Redis, but living within the app itself), etc. It's an important tool.
> Ok now you have just thrown away one of the main benefits of PHP. Remember, Rasmus is a C programmer, not a PHP programmer, so he wanted to leverage that HUGE library of existing C-code from his new scripting language, from the very beginning, deliberately by design.
Good for him. I don't see why that matters for anyone else. It's ugly and inconsistent, takes time to memorize, and leads to errors.
> Yes because each request is a synchronous thread, as described above above. By design.
This limits you to writing basic CRUD. And so many other languages offer this.
> When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc.
You would query those first surely, before loading the DB? Regardless, I've been using Redis and Memcache for years from PHP, so mute point.
> I use multiple threads in a single request flow frequently.
So how do you track those? And for how long do they live after the parent request has been processed, or do they block the parent? Gets complicated quickly.
> It's ugly and inconsistent, takes time to memorize, and leads to errors.
Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code.
> This limits you to writing basic CRUD. And so many other languages offer this.
> You would query those first surely, before loading the DB? Regardless, I've been using Redis and Memcache for years from PHP, so mute point.
You probably want to report a degraded status so any traffic that can be bled off into another cluster can do so.
> So how do you track those?
There's a thread pool.
> And for how long do they live after the parent request has been processed.
They might live on after the request flow if they're still doing work.
> or do they block the parent?
Depends on the job and the nature of the API.
> Gets complicated quickly.
That's engineering.
> Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code.
That's why I buy a lot of things. It's also one of many reasons why I don't buy PHP.
> 99.9% of web apps are CRUD.
Now that platforms have taken over, I don't think this is the case. Large systems have sophisticated needs that don't always map to a traditional relational data store. PubSub, feeds, queues, concurrency, eventual consistency, vector clocks, etc.
Platforms are going to eat the long tail in the search for growth.
> The reason for this is because PHP doesn't support many things that are expected in any other language.
And the reason for this is that those parts are handled by web servers and php doesn't need to handle them. Isolation decision that simplifies things significantly infrastructure wise and that allowed for shared hosting to exist - which in turn brought the costs down and made web as popular and massive as it is today.
BTW, this architecture is not that different from what node and others are doing. Instead of having a language/framework that acts as a web server (but too simple, so you still need nginx in front), and then you need a queue service to delegate the jobs, you have a web server that delegates the jobs (requests) to isolated php processes. Model is the same and that's the model that's used everywhere today, just that the moving parts are partitioned a bit differently in different languages.
Of course, it's not a perfect solution to every problem, but works very good for any not-real-time web site/app and in the end RoR, Django, Symfony, etc. they all work in a very similar way (minus the syntactical nuances). For a massive traffic or language level high parallelism just use something else, no one argues against that.
> - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible.
You want this in any scripting language if you don’t want memory use and cycles to balloon out of control for simple tasks. Most any scripting language looking for performance is going “how can I GTFO of myself and into C (or assembly, or maybe these days Rust I guess, in some circles) as fast as possible”.
i think it's where the glue goes. do you implement an algorithm/write a generic library in c and then glue it to your high level language in your high level language, or do you write a plugin for your high level language in c?
in both cases you need to understand pointers and function pointers and the difference between your integer type and a c int, but in one case you're at home while you do it. in one case, you could plug in to any existing c library without writing additional c, so if the problem is already solved you just use the ffi and you're done. in the other case, your problem is just beginning
Most of the comments against PHP are from developers that wrote PHP<5.4 long time ago as their first or second language. PHP had a bad ecosystem with lots of bad practices being a norm.
There are still some issues but considering the current state of language, frameworks, libraries, and the ecosystem, it's very practical and productive environment to build any project.
I've been doing Typescript, Scala, and recently also Go in last few years. Scala and Go have decent language design and I'm a fan of both of them. But, when it comes to productivity and ecosystem they don't come anywhere close to PHP. If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel.
I think there is a huge difference between web sites and web applications. Most large applications today uses SPA and an api. The api can be done in any backend language and there is not many obvious benfits of using php but some clear drawbacks.
If you just want to create a web site quickly then php works fine but on the other hand you can do it quickly with js, c# or Typescript also.
> Most large applications today uses SPA and an api.
I’ve been thinking a lot about this over the last year+. Is this true? Because the deployment model is 1000x more straightforward for CRA vs NextJS (nuxtjs, etc.).
One of the great things about PHP is the development has always taken backward compatibility into mind.. so while true it's not the PHP you know, it still pretty much knows the PHP you knew.
> If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel.
Fair enough, and same applies to Ruby on Rails.
Let's not conflate "easy and quick to launch an MVP" with "sustainable for long-term development" however. There are many stories on the net how people started with something as basic as WordPress or Rails but had to rewrite in Phoenix or one of Python's frameworks down the line because the maintenance burden of the MVP-grade technology was too heavy.
True, but I still haven't heard of anyone having to rewrite Symfony or Laravel project because of the frameworks themselves, usually it's poor design choices that could have happened in Django or RoR or Express as well (and that happens all the time, I've seen a lot of node projects that sucked because of lack of planning and we had to practically rewrite them from a scratch). No framework can save you from being careless (nor it should IMHO). In the end, unless you're building something really super popular it really doesn't matter which framework one chooses as long you learn how to properly use it and you don;t suck at programming... it's just vim vs. emacs type of problem, it's simply a personal preference, both are great, just use what you enjoy the most...
> it's just vim vs. emacs type of problem, it's simply a personal preference, both are great, just use what you enjoy the most...
To a large degree, but not completely.
Some frameworks (actually the runtimes of the languages) allow for much easier and quicker scaling and/or deployment compared to others. But businesses usually prefer to burn money for that as opposed to making an informed choice early on.
It's amusing to me to see all the hate for PHP, especially when the original lazy gripe was that people hated when faced with code that was mixed with templates. So completely different than the dominant modern front-end frameworks.
JSX just reverses the story, it's js with islands of html tags thrown in it instead of being html with code in it... in the end when you look at an average presentation component it's still like 90% html tags and some js mixed all together...
JSX is not, and I mean this emphatically not, "HTML tags". They're a tree of objects. That they sometimes represent HTML is orthogonal to why it's fantastic.
To elide all of the power and powerformance that JSX provides in the situations where it's appropriate as just "HTML tags" fundamentally misunderstands what they are and why they are powerful.
Data structures are more than text. This is a good thing.
GP could've easily been talking about the many other libraries/frameworks that DO use templating, though: Template Syntax in Angular/Vue, Glimmer in Ember, etc.
It's even more amusing how gross a generalisation you are making. I for one dislike PHP for all its little nasty surprises like implicit type conversion. Even 15 years ago I had zero problems with code and templates mixed in a file.
I do not do PHP and only have done a bit a long time ago, but I chuckle at the statement that nobody starts any project in PHP, only to find that a huge amount of new sites are wordpress sites, and they are a gateway to PHP. And do not discard WordPress, because it is amazing in how you can have a productive web site with no programing knowledge. After your site actually generates value then you can hire programmers to create more value. Bam, PHP to the forefront.
I do asp.Net core for personal projects these days and I am so jealous of the fusion theme builders for WordPress plus the huge Eco system of plug-ins.
My day job is in embedded and systems engineering, so web is not even my thing, but I find it incredible a workhorse tool like PHP gets so much disdain. Reminds me of the answers Theo de Radt, gave to the enthusiasts: nobody cares about how cool a tool is if nobody is using it. PHP is used by a lot of people, so it is more important than my new favorite darling Nim. Even if Nim sounds awesome its useless and irrelevant from a non enthusiast point of view.
I was paid to build a Wordpress extension once. It was the most miserable programming experience of my life.
Wordpress is no doubt a powerful force on the web. As a no-code website-creation environment, it's fine. Maybe even good. But as a library, it is godawful.
Writing modern php 7.2+ and creating a WordPress plugin is akin to time traveling. The experience in WordPress is not so great but they have a commitment to backwards compatibility. So I get it. But ya, I agree with this statement.
>The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN.
What if the assumed quality is an illusion and every discussion is actually as misinformed as this one, you just lack the knowledge to recognize it? Which doesn't have to be a bad thing since the signal to noise ratio on hn can still be better than somewhere else.
(There is actually a name for this idea, I am unfortunately unable to find it.)
“Briefly stated, the Gell-Mann Amnesia effect is as follows. You open the newspaper to an article on some subject you know well. In Murray’s case, physics. In mine, show business. You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward—reversing cause and effect. I call these the “wet streets cause rain” stories. Paper’s full of them.
In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know.”
> What if the assumed quality is an illusion and every discussion is actually as misinformed as this one, you just lack the knowledge to recognize it?
That would not be the entire explanation:
- I almost have bragging rights on certain topics and still find the discussions about said topics here on this site mostly good.
- Other people do actually have serious bragging rights and still continue to show up, so I guess HN isn't that bad.
Edit: although some of the reason for the last point could be the same as the reason why parents change diapers as pointed out a few hours or so ago: https://news.ycombinator.com/item?id=23077102 ;-)
Can't speak for others but I've worked on many legacy PHP codebases over the years, it has never been a pleasant experience. Even when it's a PHP 7 codebase the same bad practices from PHP 5 and earlier are all present and accounted for. As are the subtle bugs stemming from an inconsistent standard library and PHPs approach to error handling. I'm sure that there's plenty of good PHP code out there, maybe I've just been unlucky.
Can't speak for others but I've worked on many legacy C++ codebases over the years, it has never been a pleasant experience. Even when it's a C++ 17 codebase the same bad practices from C++ 11 and earlier are all present and accounted for. As are the subtle bugs stemming from an inconsistent standard library and C++'s approach to verbose error handling. I'm sure that there's plenty of good C++ code out there, maybe I've just been unlucky.
I can literally copy and paste what you said replacing it with any language and end up being correct.
Every single language on a legacy code base will have good code and bad code. It has NOTHING to do with the language. It has to do with what the code is and who originally developed it.
> I can literally copy and paste what you said replacing it with any language and end up being correct.
This is the best point in this thread, IMHO.
I think it also is due to the fact that PHP is a fairly easy language for a non-coder to pick up little-by-little. One can easily start using it for doing simple things, like injecting dynamic data into a web page. From there one can learn to scale up to full web apps.
I think this lower barrier of entry makes a lot of developers feel insecure. A lot of coders think they are blessed with some sort of special ability to write code. They seem themselves as elite and they use elite tools. When some kid comes in with some PHP snippets and generates a lot of value from that they complain that their code sucks, the language sucks, the developers suck, blah blah.
In my 20 years of writing code (starting with PHP) I have learned the lesson over and over again that while writing code commercially the fact that the language has feature X or that it forces certain patterns means almost nothing. Sure, your developers might feel better about themselves but that is about it.
Onramp is gentle... to a point. While I'm a fan of PHP for what it is, there are still plenty of footguns. Probably more than modern statically typed languages.
> Probably more than modern statically typed languages.
True, but most people considering PHP probably aren't considering statically typed languages. They're probably comparing it to JavaScript, Ruby, and Python. PHP holds it's own surprisingly well in that comparison. It certainly has it's fair share of quirks, but so do the others.
I haven't used Spring, but I had high hopes for ASP.Net (C# is a very well designed language) and found that not only was the ecosystem around it decidedly lacking, and even the core libraries like EntityFramework were much less flexible and well designed than I am used to in the PHP/JavaScript ecosystems. And they didn't seem be that actively maintained either.
PHP usually has a good library for most things. JavaScript usually has 3-5 good choices (but nothing rails-like). .NET often seemed to have nothing, or only proprietary options.
> I think it also is due to the fact that PHP is a fairly easy language for a non-coder to pick up little-by-little. One can easily start using it for doing simple things, like injecting dynamic data into a web page. From there one can learn to scale up to full web apps.
I personally started using PHP because, at the time, the free hosting servers only had support for it. Otherwise, I could probably have picked python, ruby (or even perl). I wasn't a non-coder, but I think that these languages may be self-taught with the same ease as PHP (well, maybe not perl).
> In my 20 years of writing code (starting with PHP) I have learned the lesson over and over again that while writing code commercially the fact that the language has feature X or that it forces certain patterns means almost nothing. Sure, your developers might feel better about themselves but that is about it.
But, isn't that the whole point of using PHP 7.4 over, say, PHP 3 (besides evaluation speed)? Would you code in PHP 3 today, if PHP had not evolved at all?
No? What you said makes no sense.
C++ library is consistent, and the error handling is via exceptions, which means not verbose at all, for most cases.
For C++, you want to complain about unreadable error messages, long compilation times, verbose type declarations, and use-after-free bugs.
Each language is different, and has a different trade off. A good developer can use multiple languages: C++ when you have lots of non-trivial data processing, Python for numeric and complex scripts, bash for bootstrapping and simple scripts, and so on.
> And last, people compare it to languages like Rust or Go since they consider those are "innovative". I hope everyone understands that a language is fit for a certain type of task. PHP was created for website development, and in that area neither Go or Rust are even close to matching it in terms of maturity.
I'm not disagreeing with you, but "website development" is a very broad category. For example, if you definitely need a website with server-side logic and database connections, yes, that's where PHP will shine. However, if you need a more or less static website for your restaurant or portfolio, is it really as straightforward to say "PHP is for website development, write your website in PHP"?
I want to be very clear that I'm differentiating between use cases here, but for something like a technical documentation website, a status page or something similar that does not require server-side logic and databases, I would much prefer using Hugo or some other type of static site generator, and not because PHP is bad but because we're still talking about "website development" but just not necessarily the kind of website that PHP was made to build.
That being said, there are of course static site generators in PHP as well (and probably every other language out there), but Hugo has a special place in my heart just because of the speed of it.
For a more or less static website, what’s probably the best bet, and has been the standard for many years, largely because it allows the non technical restaurant owner to easily update and make changes, is Wordpress.
Can you elaborate on why you would recommend Wordpress as the "best bet" for a "more or less static site"? I feel like I'm of the completely opposite opinion, that introducing something as modular and dependent as Wordpress for something "more or less static" is just asking for trouble down the line.
In my mind a "more or less static website" will not require a database, it will not require logic server-side, and it will not require the possibility to add-on plugins for extra functionality.
What's beautiful to me about static websites is that the threat vector is now suddenly nothing but the web server, and when you're serving static web pages that's a pretty small threat vector if you've configured it correctly. As soon as you blur the line between "web site" and "web application" and start including things like databases, forms and API:s you're in a completely different territory and I kind of feel like you should choose that because you really, really need it. Not just as a default.
WP is not in anyway static (without plugins) and you will quickly realize that when your site deals with a non-trivial amount of traffic and it completely seizes up.
WP hasn't been a good choice for small business owners for a long time - web security is hard, and hardening a WP install is not simple. There's a ton of options out there that do everything WP does without the overhead: squarespace, weebly, wix, shopify, etc.
I can't really understand the hate towards php in general, never was able to understand it.
I started programming in PHP and then moved to c# and now mostly JS, but never really understood the motivations behind people bashing on PHP. Like, some of my friends that today mostly program in React/Nextjs praise the framework as something amazing and the SSR as something really innovative, and - honestly - it resembles PHP more than ever, but if you ask them about PHP they will immediately say it is a "bad language" and "a joke".
Laravel, as you stated, is a really amazing framework, but some people are carrying baggage from the time of PHP4 or something even older and never really tried to see current/modern PHP and some other people just built their idea of the language around it because it was the cool thing to do.
as a Ruby/Rails guy, I feel the same way. Seems like Rails became the top stack to shit on to feel better about your stack these days.
People are just tribal. We need to feel superior to the "other" to feel better about ourselves.
Funny, I remember everyone hating on PHP when they moved to RoR, and now they hate that are and moving on. Its almost as if they just need things to hate so they can rewrite code. its very cyclical IMO.
The elitism of learning a new language and then mocking those that haven't put in the same time and effort to row in the exact same direction, has always amused me. Ive never judged anyone for what tools they use to get their job done, but apparently i am a rare breed in that i am more concerned with the output then the language choice.
Kinda like how people used to hate typed compiled languages and migrated to scripted dynamic languages en masse. Then they discovered they want performance of compiled language so they built JIT into their interpreters, eventually adding compilers as well into their languages. Then they also realized that enforcing types are actually good, so they built typing support into their languages, finally coming full circle after 20 years.
I see it both ways. While java can never let go of types, the language is doing what it can to reduce the verbosity that is inherent with types (by e.g introducing inferred types, lambdas etc). I can't say that dynamic languages stopped being dynamic. Yes, there's typescript. But there's a shit ton of dynamic code out there, being written at this very moment probably.
This and the parent comments are assuming that all language criticism boils down to tribalism/elitism and not problems with the language itself, as if all PLs are the same, and the choice to use them is arbitrary.
I mean the choice isn't literally arbitrary but it matters a lot less than the ecosystem and you can't really make a wrong choice as .NET, JS, PHP, Java, Ruby, Python, Go, $ReasonablyPopularLang are all plenty productive.
Sure, but there are legitimate criticisms around types, complexity, security, maintainability, scalability and performance where the language choice can matter. Certainly when the project gets large.
I've been (re-)learning Rails now that it's at version 6 instead of... 2.x, I think, when I last tried it? I've been joking that now that Rails is no longer cool, it means the people left are probably settling down to do serious work.
While I think you're right about the elitism hype cycle, I do think Rails and PHP have something in common, though -- they were systems that people who really weren't that interested in learning how to program leapt into in droves, because they were both perceived as "anyone can learn to code" technologies. And that led to an awful lot of bad code written with PHP and with Rails, which in turn contributed to the buzz about both turning sour.
They both try to lower the bar for a person to become a productive web developer. Dhh (Rails creator) calls it "conceptual compression". But in reality, to build anything half mature you not only have to know how to program, you also have to understand the concepts Rails supposedly compresses. The complexity is still there. The best example I have for this fallacy is the notion that ActiveRecord can make SQL obsolete thus make the framework easier for beginners. Dhh advocates this and it's absolute horse shit.
But yes, both Rails and php are beginner friendly, that has pros and cons and comes with a reputation.
no PHP framework is similar to the thing that NextJS/Reactis doing. The output is the same (well, isn’t the point of web framework is to spit out HTML?) but the methodology is totally different.
Not at all. I have worked with both for a long time and I can clearly see the differences. They are used for different purposes. The people comparing any PHP frameworks to NextJS have not been very experienced with frontend development, IMO.
Not necessarily. I recently rewrote an old web application written in php and jquery with django, react and typescript. The new application has roughly the same LoC count while having more features and better interactivity.
> PHP only exists today because of legacies being maintained
> people compare it to languages like Rust or Go since they consider those are "innovative"
PHP is getting old enough for developers today to be unaware of the history of web development. If you don't know the history, then you haven't seen the twists and turns it has taken. If you don't know the twists and turns, then you don't see how everything from the past relates to the state of the present.
Perhaps the greatest accomplishment of PHP is that the ecosystem so thoroughly solved a certain approach of web development that the rest of the world could move on to try these other ideas (which are of questionable effectiveness.) There's only so many web frameworks, content management systems and general web development libraries that you can build before you start to realize what waste of time it is to keep reinventing the wheel. PHP has an ecosystem which is still strong (and growing) because there's no need to recreate what PHP has done so well.
Wordpress as an example is not going to be replaced. You can't replace Wordpress by building something in a different language. The code base represents mind blowing knowledge which has gone into solving such problems which have nothing to do with a specific programming language. Nobody cares that you can recreate some basic thing with the new shiny. The programming language isn't the problem.
Now Wordpress is possibly reinventing the CMS with Gutenberg (like it or not) and it's not the programming language which is making it possible or hindering. PHP is a great platform to build on.
As your system grows, then your problems change. The tools required to tackle those problems change as well. This is true of everything. You can't manage a Google the same way that you manage a 2 pizza team. To get to that scale, the systems need to change many times over. PHP solved a wide problem, but it's not perfect and it's not one size fits all. Go is great at solving other problems, and it's a generalist when applied to the web domain. It's not a good comparison.
We haven't even started on the business side of decision making. If I want a web presence, this thread is doing nothing for me. I'm just going to fire up Wordpress and move to the next step. Or Laravel if I want a fast prototype, etc.
Seeing how important this history has been in my own area of expertise makes me think I better start hitting the history books which would be important for my other areas of life. If you don't know your history, then you're handicapped when discussing the present.
Just to interject — WordPress’ origins are indeed PHP, but most modern WordPress development, especially Gutenberg — is really JavaScript. And that’s the reality, for better or worse. Many longtime WP devs are struggling with this reality.
In fact, I would posit that many of the complaints about PHP come from WordPress’s widespread usage and its slowness to adopt modern PHP features (and to be fair, I do understand that slowness. If you power such a huge portion of the web, making breaking changes to things that could impact tens of millions of sites on the name of modernization is difficult to reconcile). If/when PHP becomes just a legacy part of WordPress, it’ll be interesting to see what impact (of any) that has on the languages perception.
> but most modern WordPress development, especially Gutenberg — is really JavaScript
As are probably most other discussed ecosystems in this thread. Most people doing Go for web development are probably writing JS heavy front-ends which interact with API endpoints on the Go driven back-end.
> If/when PHP becomes just a legacy part of WordPress, it’ll be interesting to see what impact (of any) that has on the languages perception.
What would it be replaced with and why?
Gutenberg still interacts with a PHP back-end. There will always (until web drastically changes) be a need for something to do the API handling. Would Automattic push the community to build that back-end using Go? Node?
A lot of the common complaints about PHP are merely echoing the wildly outdated and misinformed "PHP: A fractal of bad design" that has been circulating for the better part of the last decade.
Unfortunately people tend to uncritically repeat whatever it says without actually paying any mind to the facts that, 1) it's 8 years old, 2) it's flat out wrong about a lot of its claims, 3) it's evidently written by a guy who has no idea what PHP is even intended to be.
In regards to your last point, I believe PHP was intended to be a quick and dirty templating language for C programs. Right?
But if we're not using it for that purpose anymore, why would we want a programming language that grew haphazardly out of a templating language and is suffused with the quirks of that legacy? Yes, it's better than a decade ago and getting better all the time, but is it good yet? Does it have any advantage over more coherently designed languages?
PHP was intended to be a quick and dirty templating language for the web, not for C programs. It was always intended to be directly embedded in HTML pages; remember, it came from the era when the assumption was that most pages were static and you only needed to embed a bit of dynamic code to make everything awesome. A natural side effect of this is that PHP programs aren't like programs in any other language: technically, they're a web framework and a templating language right out of the box, and they always start execution from ground zero at the start of an HTTP request. In some ways this is great, but in other ways it, well, isn't; implementing a front controller pattern for your MVC framework means writing code that subverts that design, as well as loading configuration and performing initialization for the entire application on every request. (Yes, I know modern PHP caches opcodes and data and I'm sure many modern frameworks are very clever about lazy loading, but no matter the cleverness they may employ, PHP frameworks simply have to do more work per request than frameworks written in languages that get all the setup and configuration out of the way once.
While the criticism that the "Fractal of Bad Design" post is eight years old is fair, the criticism that the author "doesn't understand PHP" isn't; it's very clearly written by someone who understands PHP and is frustrated by it. Not all of the criticisms are still true, but PHP's huge popularity means that it's very difficult for them to change the language design in ways that truly break backward compatibility.
PHP's biggest advantages, I think:
- it's actually still very fast, particularly if you use a well-optimized framework or (gasp) don't use a framework at all
- it's super easy to deploy, especially for small-scale sites where "first, build a Docker container" sounds like the tech equivalent of taking the Harrier jet to pop over to the grocery store
- it's got a pretty robust ecosystem around it at this point
In my extremely subjective opinion the closer you can come to PHP's laser-targeted ideal of "minimize the setup and just get going," the better off you are, and if you find yourself routinely invoking multiple factories to create dependencies to inject into your inflected reflected dejected container it may be time to either investigate a dynamic language that is not trying to become Java or to just, you know, use Java, but again, that's just me.
Even with all of that, PHP still has strange quirks that aren't exactly obvious and are head-scratchers. Like the implicit type inference. One prominent example is that if all the keys in your "string" array are actually number strings like "123" and "456" then PHP will silently convert them to integers.
WTF?
So what is "PHP intended to be" in this case? And how is the above behaviour the sensible thing to do?
Whatever PHP "was intended to be", this is a gotcha that is absolutely unnecessary and sticks out like a sore thumb in today's ecosystem of stricter and more predictable and stable languages.
Let's not forget that commercial programming should not be about joining tribes that share your personal philosophy. It's about getting a job done. Predictability and stability help a lot with that.
I've worked a lot with PHP and Java (Spring MVC & Spring Boot), and have made a few personal projects with Django. It's nowhere near as easy to get running and secure for a production environment, mainly because you have to deal with the WSGI server. There are tons of options (gunicorn, uWSGI, CherryPy, mod_wsgi if you want to go that route, etc...) and you're likely developing locally using a test server that's not suited for prod like werkzeug.
PHP runs right out of the box. As long as apache is running and you have an index.php file in your www directory, it just runs. Spring Boot is a pleasure to deploy as well with embedded tomcat, it's possibly even simpler than PHP for local development because you can just give a jar to someone and it works no differently than it would in production.
idk, seems like a very narrow area to get fixated on (deployment/local development)? I do think Django is less complicated than Spring. You don't have the whole dependency injection lifecycle thing to grasp which isn't easy for someone who never seen it before.
Django and PHP are closer in spirit than Spring, also due to dynamic types.
I agree that Spring has a steeper learning curve than Django, but I disagree that Django is more similar to modern PHP frameworks than Spring.
Django isn't MVC, it's an entirely different architecture. Symfony framework is heavily inspired by Spring [1], and modern frameworks like Laravel heavily influenced by it and extensively use its libraries.
>You don't have the whole dependency injection lifecycle thing to grasp which isn't easy for someone who never seen it before.
Laravel's core is built on a DI container and extensively uses that throughout. Service providers [2] are a key concept to Laravel, which requires you to directly interact with the DI container.
Ah, that's new! had no idea PHP copied this concept from java. Rails completely avoids dependency injection.
You know what, if the php community starts to heavily type annotate and use a framework like Symfony, I start to fail to see the point of using that and not java.
Indeed. PHP has been trying so hard for so long to be a dynamically-typed Java I don't know why they don't just rebrand as DJava or something like that. I've never known any commonly-used language relinquish its own identity the way PHP has.
>I've never known any commonly-used language relinquish its own identity the way PHP has.
What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can't find an answer that doesn't point to poor design as to why in Java a Stack is a class but Queue is an interface. Java also didn't get generics until v5, which is now probably one of the most definitive features of the language. Java has changed a lot since its inception. If it weren't for modules and (especially jlink) being introduced in java 9 we'd still be dealing with massive production jars. Java has changed a ton and so has PHP, both for the better.
I disagree. PHP was always supposed to be beginner friendly, fast to prototype, dynamic etc. Java was never any of these things. Having it's major frameworks become so heavily inspired by Spring isn't what PHP used to be.
And again, if I have a type annotated codebase which is more and more a Spring clone, why wouldn't I just use Spring? What's the upshot to go with PHP + Symfony then?
>I disagree. PHP was always supposed to be beginner friendly, fast to prototype, dynamic etc.
>having it's major frameworks become so heavily inspired by Spring isn't what PHP used to be.
Inspired by doesn't mean the same as. It's no different than any other non-DI frameworks unless you want to write framework-specific packages. Laravel has DI under the hood but you don't have to write annotations nor structure your code in a certain way to be able to use it. It does all of that for you.
>And again, if I have a type annotated codebase which is more and more a Spring clone, why wouldn't I just use Spring? What's the upshot to go with PHP + Symfony then?
They're far easier to use with less overhead. You don't need to know tons of annotations and configurations to get requests to behave a certain way. You've already admitted earlier that you've never used Laravel nor Symfony, so I'm not sure why you're arguing about their ease of use when you don't have experience with either. They're significantly easier to use than Spring.
I'm referring mainly to the idiomatic fanfold PSR doc comments which litter PHP codebases along with the head-scratching practice of inserting a blank line between each line of code, the upshot of which is that you're lucky to be able to read 10 lines of code on a screen without scrolling.
Those "complaints" aren't even focused on the language but instead the developer. I still don't know what your original comment was about other than seemingly being irritated PHP isn't still in the same state it was 15 years ago.
I've moved on from PHP some 5 years ago. I'm not missing the language. But damn I'm missing Symfony!
I prefer Scala to PHP, the language is much more expressive. When you want to replace a bit of core functionality, in Symfony, you extend the desired class, add it to the dependency injection container, and you're done.
In the Play framework, I once wanted to make a one-line change to the routing. When it turned out I'd have to touch 30+ files which have hardcoded dependencies on each other, I quickly gave up.
This is exactly my experience as well. Moved from PHP to Scala about 6 years ago.
Symfony is absolutely amazing. For example, you can import a UserBundle from github, extend the original service class, change a couple of lines and then you have a fully functional user auth system without to rewrite/wire a bunch of things.
Although I don’t enjoy writing PHP anymore, I do miss how mature it is.
Check out Rails (ruby) and Phoenix (Elixir)(Rails' successor, personal favorite of mine). Many frameworks on many languages tried to mimic rails but most failed to achieve desired level of polishing/comfort/completeness/etc
The really nice thing of Symfony framework is database schema mapping and migrations, which have compatibility with numerous database systems and provides abstraction layer [0], that among many options of interfaces have quite handy YAML-formatted schema mapping [1]. Nothing extraordinary these days but it is really stable and simple to use.
Do you ever profile doctrine? I found its overhead to be 10x the actual time of my average query. Most of the time is spent hydrating. I wonder how people can put up with such a level of performance reduction and still claim they are using decent tools.
Of course! I believe almost all PHP devs noticed, they have terrible slowdown by Doctrine and used XDebug to check where is the problem. I am not PHP dev anymore and I hope it has improved a lot since my last adventure with this ORM but I'd still advocate to not use it on client-facing interface - you can use Doctrine only for database management (CLI), while for web interface use raw PDO or equivalent (Eloquent). You can also use cache or transform page into static-site. Sky is the limit.
Oh doctrine, those were the days... I spent a couple years working on a project that was eventually rewritten in rails because there was a memory leak that required restarting the server ever night via cron.
Yeah, PHP scripts in CRON, especially those using some relational database were my nemesis that time too. The nice thing, which in PHP 5.5 was introduced is generators, that almost completely resolved the problem with memory leakage in such scripts IMHO.
people living in the sv | start-up bubble. folks tend to forget there's dozens of websites in mainstreet that run on php. they also think everyone out there using microservices etc. nah, people just kicking dozens of laravel monoliths every part of the world. getting shit done. & getting paid. I don't use php, but I will admit the world runs on PHP, not Go, Node.js or any of the hipster shit.
As someone who freelance php and do on-site go coding on daily basis, modern PHP is amazing (symfony/slim is everything I want).
One simple improvement I would love to see is namespace grouping in standard library. Go has all related functions inside some package. Go pls let me do http.notfound<tab/enter> = http.StatusNotFound. But in php even with inteli I need to google some function/const name.
Majority of the HN commenters argue irrelevant points or are trolls and have never gone deep in any technology to be an expert and comment about it. I've seen absolutely moronic comments here. You should see the comments on 'React' or 'Java'. I'm pretty sure most have never written a "hello world" equivalent in it. It's cool to hate something popular.
Some of commenters are "ex" php develops. For me PHP was painfull but I didn't know that until I moved on to Ruby and now Go. I would never go back to PHP programming(i tried few years ago) just like I would not go back to Windows(except for budget or political reasons). PHP was fun back in the day because you could host it anywhere and truth be told it was an easy scripting language to learn but I don't see many reasons to use it today. Not that you can't build great products or scale it but I can no longer enjoy programming in PHP.
I rarely see comments like yours. You clearly mention that you used PHP a few years ago, so anyone reading your criticism will have that context and will want to try the newer version. Again, those who criticize should mention when they last used a language/framework and exactly what they didn't like about it. I've seen tomes written making fun of Javascript's type coercion when any "professional" JavaScript developer knows that the answer almost always is "strict equality".
I have similar experience. Left when it was still 5.* something.
Now I mainly do TypeScript/JavaScript and some Rust on the side.
To me, PHP was more of a limiter rather than painful experience (it was a bit painful though). I couldn't imagine how to even make a chat app.
If not for my moving out of PHP to NodeJS now I wouldn't be a software architect and explore the rest of the fun and challenging part of computing domain.
I started out with PHP at a very very young age and eventually moved on to other platforms (mainly Python). Not looking to question your experience - but actually recalling my own. Making a chat app was one of the first things I did. It was a super basic CRUD app mixing HTML and some code, refreshing the page every few secs, thanks to some meta tags.
Of course, it used frames, so that the "send message" part didn't clear every time it refreshed… those were the days! Eventually, my fancy chat app delivered a much better user experience, thanks to an amazing (back then!) JS library — jQuery. I built my first "API" that way! (It didn't use XML or JSON - it just returned chunks of HTML that were appended to a div).
Pure PHP gets annoying when you're dealing with complex data models, or when you're building a combination of frontend plus backend batch processing. Frameworks such as Laravel make this much much nicer to deal with IMHO. Of course, PHP is far from perfect, and its quirks can cause OCD and frustration to some people… :-)
But thanks to PHP (and also thanks to how lenient and chaotic it was), I was able to create very early on without needing to worry about software patterns (I had no clue what MVC was back then!), strict code formatting, learning how to deploy an app (just upload the code and off you go), and so on. PHP got me into programming — and it's also propelled some big-name sites and apps, so I guess it deserves some credit there as well.
Http polling came across my mind, but I always thought "No I won't do that". But in my noob mind it was full of http overhead and it must be ws like interaction. Apparently it was a thing, Facebook and a lot others use it.
And laravel, it was everything I knew. I really liked it, the orm was superb, the template engine was superb. It has it downside though, the big amount of code need to be parsed.
> The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core, and except for these two I wouldn't seriously consider any other competitor for starting a new project
Surely Django & Rails are also comparable to something like Laravel?
Being unpopular is one of the strengths of php. They rarely break stuff to make it look cool. Your 10 or 20 year old project can keep running, keep making money, allowing you to "learn the shiny stuff you ll never use"
There are some clueless people posting their ignorant opinions here, like some dude was hating on the guy that invented XML, sure XML might not be the best tool for everything but I can't see yaml or json to be better for documents, the thing XML was created for (but the guy probably has no idea what XML is, how it is used correctly),
probably could be a good interview question to see who is inexperienced but has a giant ego and thinks he knows much.
Go and Rust were designed for other things... why wouldn't you compare it to the big language that was actually designed to compete in the same space as PHP? NodeJS.
Front end devs are already programming in JS, so there's less adoption cost than PHP. I can't think of a single reason to use PHP over Node (I know both, and have delivered projects in both).
The comparison to .Net and Spring makes me think you might be a bit behind the curve. Have you tried Node?
Node developer here, but... two notes about your comment concern me a little.
1. "I can't think of a single reason to use PHP over Node" this is fine but can you think of a single reason to use Node over PHP. Is adoption cost the only one?
2. "you might be a bit behind the curve" while the original commenter was talking about PHP being "modern" and dimissing talk of it existing because of legacies, criticising someone for being "behind the curve" does smell a lot like that "must jump on every shiny new thing regardles of merit" mentality that drives a lot of the JS ecosystem. What are the material benefits of being on or ahead of the curve in this case?
1. Off the top of my head: SSR of JS apps, performance, better security track record. It also fits in the modern architecture better: you can certainly write a rest API in PHP, but that's not typically what you would use PHP for... and if you're going to write a react, vue, etc app, you're likely writing an api also.
2. This is not my attitude at all. I've been programming since the 90s.. In the past I've maintained PHP apps for years; maintained a custom web framework for 17 years; I still have sites running that use jQuery.
It's certainly true the JS ecosystem has that mentality... but that does not mean every JS tool can be dismissed with that thinking. NodeJS is 11 years old... it's not a shiny new thing anymore.
> you can certainly write a rest API in PHP, but that's not typically what you would use PHP for
Definitely not true in my experience. lot's of people are writing REST apis in PHP.
> NodeJS is 11 years old... it's not a shiny new thing anymore.
I write Node stuff for work at $dayjob, and lot's of stuff is great. But it still has nothing that's close to competing with Rails/Django/Laravel in terms of completeness.
He's right. PHP is a templating engine. So if you're not going to render pages server side, it's not the main use case for php. I'm a php developer and that useless lonely <?php tag at the beginning of my json service files bothers me
I used to use node too, professionally and personally. There's nothing in the Node.js world that matches the vastness of libraries that enable you to be productive as in the PHP world. you surely, can't compare Express.js to Laravel. Node.js security libraries are lacking.
Some of it is still true, some of it isn't true anymore and some of it simply isn't very relevant.
Comparison still isn't transitive. Not very relevant in the real world because you simply don't use "==" unless you know what you're doing.
json_decode still returns null on invalid input, so you either have to use the JSON_THROW_ON_ERROR option to make it throw an exception instead or use json_last_error().
Both are unfortunate, of course, but it's hard to fix mistakes made 25 years ago.
And for many of us, these 25 year old warts are a benefit...
Rather than just "fixing" json_decode and breaking backwards compatibility, old code still works.
The business doesn't care about the new shiny. When someone pays to have a simple site developed, they don't want to be paying a contractor in a year to have a bunch of stuff updated so the language it's written in is "more correct" or whatever the overriding reason is to change this. That is completely tangential to what they care about.
I recently went through "modernizing" a 15 year old, 1.93 million line php 5.x app.
We put in a shim for the mysql_ extension as it had been depreciated with 7.x, and fixed up maybe a dozen places where it was doing something exceptionally wacky and then tested like crazy and sent it out the door. Works fine.
The business doesn't care that the code is shit. They care that it makes them a million dollars a month and no matter how gross it is there's no defensible rationale as to why they should stop doing things that make them more money for the next 2-3 years while a team goes through and rebuilds the entire thing to be "more correct".
Something like pyenv/nvm/etc doesn't exist for PHP. You can just install the latest version and with very few exceptions whatever code/library/etc you find will just work. There's a lot more value in that in the real world than "fixing" json_decode.
I like PHP, less and less since I started with it in the 90s. Largely because of the current stewardship and syntactical changes. Many languages move forward rapidly. A difference between PHP and, say, Python is that PHP seems to move more slowly to the same end. There are still trivially fixable problems that would qualify as breaking changes. Seems lazy. Instead, we have a bunch of hand wringing because those who make the releases are heavily involved with projects that move slowly out of fear...ostensibly because they have customers they don't want to antagonize. They might jump to another framework or language.
You don't need to use switches. In fact, I'd argue that if blocks are better if you're evaluating against variable data types. Alternatively, if you really, really want to use a switch statement and loose typing might cause issues, it's pretty easy to compare types before the switch statement, e.g,
When you have dynamically typed languages, whether to coerce or not is a design decision with usability trade-offs. Javascript exhibits pretty similar behavior with switch statements for exactly the same reason: it also has two types of equality comparisons.
Also, PHP allows you to add explicit type casting to case statements. e.g.,
An argument I've heard advanced for both PHP and JS is that their evil is well-documented and well-understood (e.g. one of the Facebook efforts was to write an extensive spec for PHP). Contrast this with, say, Python, which is much more nicely designed, but implementation-defined and with some gotcha areas with poorly understood and documented behavior - rarely encountered, but when encountered, hard to grok or avoid, also because they can readily keep changing from version to version (some of the corner case details of slots come to mind as an example).
I can see a pragmatic point there - anything has warts, the warts you know and don't move are easier to contend with (and lint for). I'd still pick Python for most projects in that comparison, but at a certain scale of effort I'd possibly begin to wonder about the trade-offs.
I really like languages like Rust and Go and they certainly are good languages and I would love to use either on a regular basis as a freelance webdev.
But with two recent projects I‘ve worked on neither would be even feasible.
In one there was a requirement to generate custom designed PDFs, and in the other I had to implement authentication via SAML.
Other language ecosystems that would be feasible in these cases: Nodejs, .NET, Java or Clojure because it can live in either of those.
PHP doesn’t just have mature, battle tested and well documented web-frameworks. It also has libraries which do complex things that are very unattractive like PDF generation/manipulation and complicated standards like SAML.
"Laravel Up and Running"[0] is a popular choice. Lumen is just Laravel with a few features stripped out of the framework. They both use the same underlying packages.
The thing is, when I started using PHP in 1999, PHP had real advantages that no other eco-system offered. Regarding functionality, it had an "all in one" philosophy, whereas Perl had exactly the opposite attitude. With Perl, the first thing you had to do was research which modules you would have to download and install, but with PHP you could just start writing code. This was in the era before modern package managers, so it was a very big deal. PHP was open source, so it was a good choice relative to classic ASP. Worst of all, other languages, such as Java, were engaging in an orgy of unnecessary complexity, especially when it came to frameworks, of which Struts was perhaps the most awful exemplar. PHP was the first language to make automatic adaptations to the world of the Web, including loading $_POST and $_GET variables automatically -- some of these decisions were later seen to be huge security liabilities and so they were ended.
Above all else, circa 2000 we could still rely on Moore's Law and therefore we could rely on a single CPU getting faster and faster every year. But once Moore's Law came to an end, it became increasingly important to be able to leverage concurrency, and PHP had no real story around concurrency (except the course-grained method of starting a new process).
PHP 4 was a very easy language to learn. It did not have many Object Oriented features, instead it encouraged a simple style of simple functions. Ironically, when it came to objects, the default behavior was "pass by value" so PHP 4 was, in a sense, an immutable language, long before that became a popular development style (tragically, it was not optimized to manage memory in a manner that would allow ambitious use of its immutable qualities).
Later, PHP developed an intense envy of languages that were seen as "enterprise ready languages". This lead to a lot of nonsense. First of all, PHP 4 was already good enough that it could be used in an enterprise, but this fact was ignored. Second of all, PHP 5 suddenly adopted a lot of Object Oriented features which added a lot of complexity to the language, but without offering the benefits that might have come from using a language like Java, such as compile time checks.
I used PHP from 1999 to 2011. I built my first and second startups using mostly PHP. However, in the year 2020, I can not imagine why anyone would use PHP. It no longer offers the simplicity that it offered in 2000. It no longer offers the straightforward procedural style that it allowed in 2000. It's "all in one" philosophy is no longer an advantage because now every language has a modern package manager that makes it easy to include whatever is needed. Nowadays, with Javascript, you just type "npm install" and you get every module that you need. And yet PHP still doesn't offer some of what a complex language like Java or C# might offer, especially regarding strict typing or compile time checks or run time efficiency, or a separate set of runtime flags for a compiled version. PHP has become a weird mutant, imitating the more complex languages but without offering their benefits.
And crucially, the other languages have not been stagnant. The community around Java eventually gave up on Struts and started developing light-weight frameworks that made development much easier. And there sprang up dozens of languages that run on the JVM and which offer a wealth of good ideas about how to do modern development. (I became a huge fan of Clojure.)
I seriously can not imagine why anyone would use PHP now. It no longer offers simplicity, but developers don't gain much from all the extra complexity that's been added.
[Added] A final point: this article makes it seem like Composer is something of a victory for PHP: now PHP has a modern package manager just like all the other languages. But this strikes me as a defeat rather than a victory. Circa 2000 I loved PHP because of its "all in one" philosophy. If that style of automatic inclusion is no longer possible for PHP, and therefore PHP needs to become just like all the other languages out there, how does that reflect well on PHP? One more unique strength that PHP once had is now gone.
You may have missed it, but with PHP 7 the language has even more shifted towards stricter typing paradigms. People use strict comparison, typed properties, typed arguments, etc. Couple that with one of the popular static analysis tools and you'll never see any such errors.
>And last, people compare it to languages like Rust or Go since they consider those are "innovative"
No, they do not. The entire appeal of go is that there is zero innovation at all. It is the most plain, boring, ordinary language around. It does absolutely nothing different or neat or new or special. Instead, it focus on being simple, easy and fast. Just like PHP apologists keep claiming about PHP. The difference is go was developed by competent software developers, so it isn't a broken, buggy, inconsistent mess.
>PHP was created for website development
And yet it is outclassed for that purpose by general purpose languages like go.
>and in that area neither Go or Rust are even close to matching it in terms of maturity.
Age is not maturity. PHP is old. It is less terrible than it was 20 years ago, but it is still worse that any other language except javascript.
Facebook poured loads of money/time into HHVM. While I'm sure PHP also got benefits, your "Otherwise it would probably on life-support right now. " argument fits perfectly on the rest of the biased unsupported arguments.
> FB poured a ton of money into Hack/HHVM. Which didn't directly benefit PHP
Facebook may not have directly funded PHP, but I know for sure at least one of the HHVM/Hack devs (Sara Golemon)is also a huge contributor to the PHP core.
PHP isn't being replaced by Rust or Go. It's being replaced by Medium, Wix, and Squarespace.
At this point, the predominant reason it's still undergoing active development is that there is a metric ton of legacy PHP code. As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up.
You're defending the language from an emotional standpoint.
> choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core
This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.
Choosing PHP will be like choosing Python 2. In fact, that's my 2030 prediction.
> As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up.
People have been calling for PHP's death, or saying PHP is a dying language, for as long as the internet has been around.
It's always the same arguments, that $newHipLanguage will replace it.
Then you actually do some research and understand just how much of the internet is still powered by PHP and will continue to do so for the forseeable future.
So, I'm still waiting for PHP's death. Or for this same predictable comment in 2030.
> It's always the same arguments, that $newHipLanguage will replace it.
It's not that a new language will replace it. It's that the people that hire PHP to solve their problem will now use a platform with no code to manage.
Engineers writing platforms will choose languages other than PHP to write them. You can't spin up multiple request threads to make concurrent non-blocking queries in PHP.
It's not built into the language? How can we be sure this project with 2k Github stars won't segfault, memleak, deadlock, or have some other horrible bug [1]? I haven't done full due diligence, but I'm already suspicious. The open tickets don't look good [2].
> You mean that you don't know how to
I'm not convinced you found an appropriate answer either.
In any case, this should be a language feature.
[1] It looks like it relies on bindings to an unofficial native code extension.
> This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.
Lots of languages have HTTP tools and frameworks, but not many of them are even comparable in scope to Symfony or Laravel. Out of curiosity, can anyone point me at some frameworks in other languages that have the following things built-in?
* Route matching and dispatch
* URL generation (generate a URL for some route) including signed and temporary URLs
* Middlewares
* Abstractions for dealing with incoming HTTP requests (getting headers, body, uploaded files etc.)
* Abstractions for creating and sending HTTP responses (headers, body etc.)
* CSRF protection
* Database drivers for a couple of backends (MySQL, PostgreSQL, SQLite etc.)
* Sessions with different storage backends (filesystem, Redis etc.)
* Request validation ("this field is required, has to be a string, between x and y characters long" etc.)
* Translation and localization
* Broadcasting through WebSockets
* Caching with a couple of backends (filesystem, database, Redis etc.)
* Email sending with a couple of backends (SMTP, Mailgun, SES etc.)
* Notifications with different channels (Email, SMS etc.) and backends (SMTP, Mailgun, Twilio etc.)
* Job queues with different backends (database, Redis, SQS etc.)
* Scheduled jobs
* Authentication (different flavors like regular sessions, API tokens etc.)
* Authorization
* Hashing
* Encryption
* Query builder
* ORM with relations between objects, JSON serialization etc.
* CLI commands with option/argument parsing, colored output, progress bars etc.
* Events, including async handling of events
* File storage with a couple of backends (local filesystem, S3 etc.)
* Pagination
* Payment integration
* Full text search with different backends (database, Algolia etc.)
This is basically the feature set of Laravel, I probably missed some things too.
And I don't mean "oh yeah I'm sure there's a library for that" - I mean fully integrated, first-party, tested, dead simple to use and available by default.
Maybe I'm wrong, but I seriously doubt this just exists in any language.
Spring Boot has most of the important parts of this. And super easy to call a library for anything else, or write 10-20 lines of code yourself.
This is all in a performant, reliable and secure compiled language (Java). Language improvements and modern frameworks have also addressed the long-winded code which used to be an issue.
Yes, as mentioned in my other reply, I think Rails is probably the closest competitor and can do most (although not everything) of what Laravel can. Django is the third option I think comes very close.
Admittedly, limiting the selection to first-party code might be a bit unfair to frameworks that maybe simply rely more on community-built extensions, but I have to draw the line somewhere, otherwise I guess every framework theoretically "supports" everything through some third-party module that may or may not work ;)
You have to understand, all of that is irrelevant! Because PHP is old and shitty, it mixes camel_case and SnakeCase and the order of arguments in the standard library is inconsistent! Bah.
Hashing: Support for securely creating and verifying cryptographic hashes, like you'd need for password hashing.
Encryption: Support for securely encrypting, signing, decrypting and verifying arbitrary payloads. In Laravel, you can do:
$plaintext = 'foobar';
$encrypted = $encrypter->encrypt($plaintext); // this will encrypt the plain text, generate a MAC and combine everything into a base64 encoded payload
$decrypted = $encrypter->decrypt($encrypted); // this will decode the payload, verify its MAC and decrypt it, giving you back the original plain text
$decrypted === $plaintext; // true
As for CLI commands, I meant the ability to easily create your own commands. Here's [1] the relevant Laravel docs, for example. You can create commands and they will have access to all the things you can use in a HTTP context too, other than the actual HTTP stuff like the current HTTP request, because there obviously isn't one. So, for example, you could write a command that would use the ORM to perform some maintenance tasks on your database.
You mean, an crypto library exported by the framework instead of you specifically importing it? I don't see the gain (as a consequence, I have no idea if other frameworks do that).
RoR and Django both have extensible management commands, and all frameworks that I have ever seen allow you to create independent CLI commands (it's on PHP that the CLI is a second class citizen).
I think having good, secure, easy to use and hard to misuse crypto makes a ton of sense for any framework. The framework needs these internally anyway (to offer encrypted sessions for example), so you might as well expose them to the developer too.
I might have missed it, but I couldn't find any documentation on how to create custom commands in RoR. For Django I found [1] (through "python manage.py" from what I understand) and that does look like it's more or less the same as Laravel's "php artisan", with commands provided by the framework as well as the ability to add your own.
Anyway, I wasn't trying to attack RoR or Django, as those are actually the best alternatives to Laravel I know of. I worked on an existing Django project for a bit and while I don't like Python, Django seemed just fine to me for the most part. I did want to express my disagreement when it comes to the original claim of "any framework in any language can do what PHP frameworks can do" though.
> I did want to express my disagreement when it comes to the original claim of "any framework in any language can do what PHP frameworks can do" though.
Oh, a complete agreement on that.
This conversation sidelined from some people talking about Java, .Net, Go and Rust. None have anything similar to the big web frameworks. And while I'm not completely sure about Rust, I do believe that none even can have it.
RoR and Django are probably the closest (Laravel was inspired by RoR). Still, I don't think they support all those features.
Like I can't find any official RoR support for payments, full text search, encryption, pagination, scheduled tasks or building CLI commands.
With Django, full text search seems limited. It supports PostgreSQL, but I couldn't find first-party integration for Algolia, Solr, Elasticsearch etc. or a generic way to add backends (pluggable drivers) for them. There's support for WebSockets through Django Channels, but it seems a lot more basic than Laravel's broadcasting system. No official support for queued jobs or schedules?
Revel doesn't seem to have support for building CLI commands, encryption, emails, pagination etc. Apparently, any kind of database access or ORM isn't even first-party?
The inclusion of Actix in this list confuses me. From what I understand, Actix isn't a web framework at all, it's more like a foundation for using the actor model.
(I didn't exhaustively analyze everything, there's certainly more things missing from some of those frameworks)
Why would RoR bake payments support into the framework? RoR is there to tackle common web application tasks, payments is there for maybe 30% of web apps / services. There's an active debate on what popular libraries should be included in Rails, and all the features you listed can be found in libraries if they aren't in Rails already.
> Why would RoR bake payments support into the framework?
I'm not saying they should, just comparing features for the sake of demonstrating that the functionality that's present in modern PHP frameworks isn't readily available in just any random framework in any random language.
This is the same kind of argument used to prove that Macs are actually cheaper than PCs. Start from the hardware specs of a particular Mac model and configure a PC to match those exactly. It will probably be more expensive than the Mac.
The thing is that nobody would choose that configuration for the PC under normal circumstances. Normally you would spec it based on your actual use case and the PC would end up both cheaper than the Mac and better suited to the use case.
I'm not sure that example is entirely true. A PC would probably still be cheaper, assuming you don't insist on getting exactly the same components and are OK with, say, substituting the Mac's RAM supplied by vendor X with an equivalent product from vendor Y (same specs).
Sorry, the point I was originally trying to make might have gotten lost in all the discussion about specific features.
It was in response to this:
>> choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core
> This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.
The way I read it, this comment claims that everything that can be done in PHP using PHP frameworks could also be done in almost any other language using one or several frameworks written in that language. In my experience, this simply isn't true. There are other frameworks in other languages that have a feature set similar/equal/maybe superior to what Symfony or Laravel offer in PHP, but those are very rare. Like "there's maybe 2 or 3 of them in existence" kind of rare. Rails, Django, maybe one or two more? It's a short list. Again, not exactly "almost every language" and all that.
Of course, any language could have frameworks offering those kinds of features, but in reality, most simply don't. For a new web project, PHP, Ruby or Python are still fine choices if you're comfortable using those languages. There's nothing wrong with using, say, Go instead. But to claim that Go (just using it as an example here, not trying to criticize Go in particular) just has one or several web frameworks lying around that can do what Laravel, Rails or Django can is simply dishonest.
also, wtf payment integration? if i need payment integration, there are myriad of libraries to chose. i don't need my web framework to decide that for me.
I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).
Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building.
In reality, the difference is in how easy it is to hire developers, the package library, overall ecosystem and developer experience, or: how can I make a great product.
I'm a PHP "hater", so take this for what it's worth.
You are very close to implying that the language doesn't matter if you can hire developers and there are a lot of good packages in the ecosystem.
Having worked on several PHP projects (Most being version 7.0+ and zero of them being older than 5.3), the languages is STILL full of gotchas, and it's a huge drag on productivity. I assert that this DOES matter. Even basic stuff like trying to use the default "array" as a dictionary has absolutely ridiculous issues like if you try to use a string as a key, but it is a string of digits. It will automagically convert your string to an int and totally F-up your dictionary.
I've actually been bitten by that one. And it showed up in production, because I didn't know or care what the string keys might be. Who the hell would've guessed that behavior after working with non-broken languages before?
Inb4 "That just means you're dumb. Just use SPL. You can write bad code in any language."
I've used Symfony. It's good. I haven't used Laravel. I assume it's also good. I still don't know why you'd choose to start a project in PHP today when there are great libraries in many other languages that are not as broken as PHP.
Honestly, PHP 7+ is not horrible, but it's also not better than anything else... In fact, the very best PHP code you can write today looks basically the same as the best Java code you could've written a decade ago.
> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary
I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.
It's a real-life problem. I just recently stepped in it while working on some software that interfaces with imap. A couple of folders were named "2018" and "2019" and common array*() operations kept blowing up with those keys.
There are native-php workarounds and if you're very very careful you can probably maybe encounter this and code around it without triggering any of the strange behaviors, but it's a minefield.
I'm not new to PHP, either. I think by chance people just usually don't encounter the circumstances for this particular bad behavior, but when it happens, it's really bad. Array keys shouldn't be getting implicitly typecasted.
My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected.
I've been bitten by it and also stuff like 800=="8E2".
I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I have wondered whether something about PHP, or something that it lacks, makes PHP projects easier to estimate.
Ease of deployment? Batteries included standard library? Pragmatic community? Surprisingly adequate performance? It never seems like enough to overcome the obvious deficits. I can neither ignore my own experience nor convince anyone that it's actually great.
I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful.
It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light of those immensely popular languages, I could see why someone might not think that any of the deficiencies are deal-breakers.
Maybe, in my case since I am currently in the non-PHP phase of my alternating PHP/non-PHP job history. PHP has been less than 50% of what I've done (the rest being far more on-trend, if you will) though disproportionately represented among successful and profitable projects.
The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude.
The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.
With other languages there's some hope of a free lunch and it engages our tendency to optimism.
Asking as someone who's mostly only written PHP (and some javascript, more recently): can you expand on this? What kind of "hope of a free lunch" is there with other languages?
I think there are a few, and maybe I am the only one who has ever been foolish enough to think these things or incompetent enough not to achieve them.
The first is the promise of DSLs and meta programming, where you can tune the syntax of the language to more naturally express your problem domain. When this works it's beautiful, but sometimes it is a distraction and makes the code difficult to debug.
The second, which is conceptually very different but I find it can play out similarly, are rich type systems where you can hopefully build up your application as a series of well defined type relations and transformations. Again, when this works you get really robust, reliable, and easy to modify software but there are often cross cutting concerns or business practices that break the model.
Edit: when I talk about a free lunch or a silver bullet, I am often thinking about the writing of Fred Brooks.
As someone who's worked heavily in C++/Java and tends toward functional programming approaches I enjoy PHP. There are some features in the language you should avoid, variable-variables being one of the ones that makes logic very difficult to decipher - but C, C++ and Java all have those - and Javascript has the wonderful combination of substr & substring. The useful portions of PHP are extremely powerful, having access to magic functions, a much more advanced concept of a local symbol table and a surprisingly good approach to inheritance & composition all end up bringing down code maintenance when well applied to provide clearly intentioned logic.
Going a bit off-topic, but I can't imagine doing "functional" programming in PHP or Java. C++ has const and top-level functions (PHP kind of does, but the autoloader...). It has (real) generics. It has move semantics, which is great for functional pipelines.
I do functional programming in C# and used to do it in Java at university. C# makes it marginally more pleasant but in general it’s pretty feasible, people will just look at you funny.
Just to tease it out more. What do you mean by functional? I assume that you design your classes to be immutable (only getters with defensive copies when needed). Do you also keep most business logic as pure, static methods on non-data-holding classes?
That's about as far as you can go with Java, I guess, but honestly, now that I type that out, I guess that does get you pretty far...
Yes, classes are just POCOs (sometimes with some sealed subclasses, to hack sum types) and business logic is static functions in separate classes. Like I said, C# makes this somewhat easier, with things like readonly fields, get-only auto-properties, System.Collections.Immutable, readonly structs, pattern matching, etc. With Java you have to take more care to encapsulate things properly, though I’m excited for records coming into the language.
The most salient problem is the fact that the languages do not distinguish between references and values (aka “mutability by default”) which means that the compiler will not maintain those invariants for you unless you annotate things specifically, and the authors of the libraries you use do the same.
My overall preference is for F#, which is ironically a better object oriented language than C#, by virtue of using ML-like syntax instead of C-like. Nonetheless, C# is a passable functional programming language these days, and the language designers keep adding more functional-inspired features with every release.
Yes, that did sound condescending. I'm both a defender and detractor of JavaScript. I'm mostly a detractor of PHP, but could possibly defend it once in a while if I see misinformation.
Peter Norvig at some point came to the realization that the deficiencies of Python relative to Lisp were not deal-breakers, and I don't think that stemmed from his limited experience.
Perhaps it was condescending, but it was, first of all, not intended to be malicious. I have had the luxury of having used a lot of programming languages for various projects. The first N years of my career, I used mostly C++ and Python. I didn't like Python much and was pretty convinced that C++ was the pinnacle of programming languages.
Since then I've done (real, professional, for-profit) projects in PHP, Go, Java, Kotlin, Swift, Rust, JavaScript, Elixir, and Clojure.
So when I work on PHP and Java I can feel what they're missing. It's simply the luxury of having experienced working in (what I consider to be) better languages. Clojure and Elixir were not my cup of tea, but I still find them to be better quality languages than JavaScript.
I have met many developers in my life. Some with quite a lot of experience. The VAST majority of them have only ever worked in a handful of very similar languages. Mostly the ones I listed originally (I forgot C# in the list, but that's more-or-less Java++). If I'd only ever used PHP and Java I would literally not know what a good type system looks like. It's ignorance, but not stupidity.
And I'm talking about people I have much respect for. People who I acknowledge are smarter than me. That doesn't mean I don't know anything they don't, though. And if they've only used PHP and Java, then I know some things they might not. That's all.
EDIT: Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.
> Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.
Your comment wasn't about people who like PHP. Your comment was about people who defend JS or PHP to the minimal extent of saying their deficiencies are not deal-breakers.
There are people with broad experience who are willing to accept deficiencies of a particular language if the context is right.
(I don't actually know what the right context would be for PHP; I'm more stating a general principle.)
I suppose you're right. I did not mean people who shrug and say "Yeah, PHP sucks, but I'll defend its use here for X reason."
I was more, in my head, describing people who say "Well, all languages have issues." or "You can write good/bad code in any language." or whatever other bottom-of-the-barrel defenses I often hear and read.
Is "powerful" really even the right description? I can't even do a map + filter without looping through the array twice. Ew. I guess I'll just stick with the primitive foreach loop (which leaves a dangling allocated object after you use it... sigh).
I agree that the issue mentioned above isn't that bad - as a long time PHP developer (and PHP admirer) one gotcha that still really annoys me is persistence of key refs outside of foreach loops and I present this eval[1] as a wonderful example of why you should really prefer array_map for mutating array values or be very pedantic about unsetting variables when you leave a foreach using ref loop.
Except that if you do anything other than mapping, you start taking a performance hit. If you want to use array_map with array_filter, you're now iterating your array twice. Also, if you ever use array_filter, you almost certainly need to wrap it in array_values, so now you're looping N times.
It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.
I've done plenty of PHP programming (including modern) in the past. I'm excited about recent developments.
Not sure about the productivity claim. I once wrote from scratch (frameworks excluded) backend and frontend (version 1) of a multi-tenant, cloud-based video-sharing platform with PHP as the backend (aws cloud) in a matter of weeks.
I once wrote, from scratch (frameworks excluded), an entire backend (and front-end) of version 1 of a hybrid mobile app (backend in PHP) for a medium-size logistics company in a matter of less than 2 months.
I have other examples, but life is too short trying to convince "haters" that they might not be 100% correct.
I was the only developer on both of those projects. Your mileage may vary :)
PHP has excellent development experience. After updating your code, you can just reload the page. That's it. It's seamless. This is something that I sorely miss now that I'm a .NET developer.
Also, the PHP ecosystem is friendly to beginners. Compare these authentication docs for a PHP project vs a .NET project:
I think in all the critical pain points all relatively popular languages used for web development have a well thought out story. I think there's nothing about the "pipeline" that's a huge bottleneck for a well-seasoned developer anymore. At least there shouldn't be. It's more about (a) getting things spec'd out well, and (b) execution.
So the claim was that PHP "gotchas" are a drain on productivity. I'm not trying to compare with other languages, but I think my anecdata shows that, at least in my case, when you understand the tools PHP can be a very productive one.
Certainly gotchas are a drain on productivity. But I don't think this applies more to PHP than any other language I've used. The fact is, if you are less familiar with the language then you won't be as productive.
I personally spend a lot of time hopping among technologies and I always lean heavily on documentation. PHP has pretty good documentation, and this helps a lot in my opinion. I would guess that a lot of developers don't read the docs and just assume that something in a less-familiar language will work exactly like they expect it to, and then call this a "gotcha" when it doesn't.
For a huge, huge potion of all work done by web developers day to day around the globe the language doesn't matter if the framework is productive and secure by default.
Most of it won't survive a handful of years at best and most companies won't ever benefit from the attitude of some developers that ever developer on ever task should be writing FAANG level code.
What 3nds yo happening it matter what you do is the next agency / person comes along and claims its not fit for purpose any more and redoes it 'better' and the cycle continues of low value
The PHP deal-breaker is that it casts[0] string keys that contain "valid decimal integers" to "the integer type"?
Seems like a fairly minor language quirk (of which almost every language has) rather than a huge feature that makes one want to avoid the language at all cost.
Of course, feel free to make your own choice when picking a language, but I don't think this is a compelling reason why one would always want to avoid using PHP for their web backend.
Most people don't use a production version of php.ini, I'm fairly certain you can turn this off and on in there. I've only run into this on my personal projects (where I don't care too much about the configuration) but never at work.
It takes 5 seconds on Google to find a myriad complaints about weird, unexpected, and downright incorrect things that PHP does. That wasn't the point of my reply. The point was that language choice CAN affect productivity. And having a bunch of gotchas is something that will negatively affect productivity. I simply gave the first example that popped into my head that actually tripped me up.
Assuming you thought to test using a string that's all digits. You have to know about PHP's brokenness to even think to check that. In a sane language, it doesn't matter what the contents of the strings are, they're just strings.
I wonder how many developers hate PHP because one is just supposed to hate PHP.
I'm sure there are many with well-thought-out reasoning though, like seen in this thread.
It's useful to keep an open mind about things though. I'm probably more a PHP fan, but I can't say that I'm a huge fan of its programming style. It's much more enjoyable to me to churn out applications in .NET or in Ruby, but it's hard to argue with the speed at which I can develop in PHP or with the level of support online for doing so.
I think you're missing a third group of PHP haters that's actually a majority: those who've used PHP, sometimes extensively, and built up a backlog of "this is stupid" bits in their head about it. They don't have deeply reflective reasons or a strong theoretical basis for hating it, they've just suffered with it for a good while, found some better alternative, and are now sceptical that any amount of improvement will be able to outweigh the friction they "know" will be there if they try to come back.
So the anti-PHP feeling for this group is broad but shallow. Here's what I think is interesting: JavaScript is here right now. Like PHP, it's incredibly popular, almost mandatory to know in some degreee, and using it for any length of time causes one to build up a catalog of "WTF?" and workarounds and "use this library instead" and a constant churn of "it's great if you use <some framework or conceptual approach> on top of it".
I used PHP a lot, and found it quite pleasant with Laravel, but the latent pool of distaste means I'll never go back. I work heavily with JS now, and can feel that wide puddle of "why do I have to put up with this?" spreading, even while other parts are really good.
I don't know how you overcome this, broadly. Perhaps it doesn't matter, because I think this group (and I'm part of it) blows with the wind more than most, and if the winds shift back, we'll probably come along.
Yeah I mean the exact super dictionary bug that GP mentions also haunts Javascript, everything will be converted to string. But if you use Map and Set...
As you said, there's almost always a solution to avoid the pitfalls but that makes you more and more "unhappy" with the language over time. I'm one of the rare people who can answer most JS trick-questions correctly, and that puddle has been building for many years (let's say more than 10).
On the other side, I'm very pragmatic and using tools like ESLint and Typescript (well that's just JS with SUPER pragmatic typing in my eyes) started to make it a joy again in the last few years. I hope the trend continues. I can't say the same for my PHP experience.
That's a really good point. Nothing is perfect, and frameworks are no different, so after awhile the friction points come to the fore.
Also, I have a theory that with the more common languages, you obviously find a much broader user base of beginner-level programmers, or, worse, programmers who just don't care about quality, which translates to more dysfunctional code in the community in general. My coworker at one company did not have good things to say about PHP, but when he had to take over a PHP project of mine when I left the company, he said it was some of the most well-written PHP he's ever seen -- organized, easy to follow and modify, etc. He didn't even realize PHP could be written in an eloquent fashion. (Not to brag, I've written plenty of bad code too.) Point being that if all you see in a certain language is jumbled spaghetti code, it's easy to think of it as a bad language.
A good programmer should be able to create eloquent code in any language.
Edit: Realized after posting I may have sounded like I thought you were not a good programmer -- that's not what I was saying at all! You can write eloquent code and still be frustrated with what the framework or community forces upon you.
It would be interesting to see a ranking of programming languages by the rate at which they accrue ill-will with continued use :)
It's a very good point: the more widespread a language, the larger the proportion of users will be beginners, who will almost certainly confuse their own inexperience with language-driven frustration (again, c.f. JavaScript). My pet theory on the broad appeal of PHP is that it coincided with the easy availability of shared hosting accounts where PHP was the default scripting environment available. The barrier to entry for blogs, shopping carts, forums, everything was incredibly low, leading to an explosion of software, tutorials, walkthroughs, and community that was heavily slanted towards beginners, dilettants and "low end" programmers". I made a living as one for several years, doing PHP for $5-10k jobs, and there was endless small-business work in this segment.
If modpython had worked as well as modphp, the world might look very different today.
I think this is probably an example of the larger tendency of people to overrate the importance of whatever it is they directly work with, and its effect on their workflow. Like a carpenter insisting that using a certain brand of hammer has an effect on the habitability of the resulting house.
After years of using a lot of products and seeing which ones succeed and which ones fail, I question whether there's much of a connection between code quality and product success, assuming of course that the code isn't bad enough that it prevents the use of the product.
Heck, I'm not even sure there's a strong correlation between basic product function and success, at least in the enterprise space; I've seen a number of successful products that barely even work. Seems like market positioning and sales are the bigger factor.
> I think this is probably an example of the larger tendency of people to overrate the importance of whatever it is they directly work with, and its effect on their workflow. Like a carpenter insisting that using a certain brand of hammer has an effect on the habitability of the resulting house.
One brand of hammer causes RSI. This brand of hammer tends to bend nails unless they're made of titanium alloy at 80% higher cost. The houses built are basically fine, but they have quirks as a result of the builders trying to avoid having to use nails. You lose 10% of your workforce after every project to medical leave and burnout. Everything is fine because people keep buying houses (there's a shortage).
Coming from Java, the one pet peeve I have is the automatic type conversion. I just find that I never really know what my variables are _really_ holding.
It's one of those foundational issues that I just can't get over.
...but it's my personal problem - I don't hate PHP.
In all new work we require static typing on method parameters and defined return types. Of course, if your type is 'array' it could be an array of anything but we also try to avoid that and use collection classes. It honestly feels a lot like Java now, without the compile step.
We do similar (strict_types, declare parameter and return types, etc), but don't go as far as the Java-style collection classes except where absolutely necessary.
As a mostly-acceptable alternative, we just type hint as array and document the actual containing types in the phpdoc block and run phan for static analysis to catch any potential screwups.
/**
* Method for converting Foos into Bars
*
* @param Foo[] $foos
* @return Bar[]
*/
function convertFoosToBars(array $foos): array
{
// ...
}
In theory this isn't perfect. In practice we haven't run into any issues yet.
>I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).
I wouldn't be surprised if many of them don't even have that experience. I've found a lot of people just parrot whatever someone else wrote or said without much thought. The tribalism within the development community is approaching what you'll find with in gaming, sports and even politics.
Not gonna lie my #1 complaint is that PHP jobs on average pay like shit in comparison to most other things. I don't want to work with it solely because it has no value on my resume.
That being said the biggest argument for PHP is productivity and I just prefer Ruby + Rails for that. Honestly though I will say I find PHP more pleasant to work with than Python these days.
>I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).
Think this is true. I am one of those php haters, although I wouldn't trash it. I worked with 4 and 5 and the transition between the two, so it is a while ago. I am not fondly remembering that time and have moved to other branches than web development to evade it.
That being said, if I would go back to web development, I would have a look at it. Why not?
Why would I ever want to use it again after php5? It might be better now but the competition is so much better than what php5 was that I have zero reason to revisit the language.
Some people simply have reasonable standards. I tried for years to hire a PHP dev. I never found a single one. I found tons of people who had PHP on their resume, and not a single one of them was anything close to competent. PHP only makes hiring easy if you don't care about the quality of work that gets done. I can hire a million PHP monkeys, but everyone who has the right combination of intelligence and conscientiousness to be a competent software developer moves on from PHP after 2 or 3 years as they discover what it is.
Facebook, Slack, Etsy, the list goes on. In fact, I think all thosr companies are actually hiring right now, unlike many of those advanced non-PHP shops.
The parent post complained about the quality not salary level of PHP programmers, though. The parent wants a quality PHP programmer, you want to keep salaries down - there is an acceptable tradeoff, somewhere.
Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not months.
Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.
* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.
Well Ruby is OOP, is it gonna be super easy for me to get a java web development job? All things being equal a hiring company will go for someone with 3 years java experience over my 8 years Ruby experience.
Facebook has no choice since no one knows their language, but most other companies will hire someone with the particular experience of their stack if possible.
No, facebook doesn't. The good programmers facebook hires don't work on the legacy PHP code. They do stuff like sigma. Also, I am not describing a problem, I am pointing out that their perceived problem doesn't exist. If I can hire a good programmer and make them write PHP, I could also hire the good programmer and let them write in a tolerable language, so the mythical "its easy to find PHP devs and impossible to find anything else devs" claim is out the window.
Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt.
PHP's raison d'être remains its ease of getting an instance running on a webserver. But with fewer people self-hosting these days, that has become less an advantage. And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Pascal, COBOL, Oracle DB and PHP today seems like technologies that only stick around because they are legacies being maintained, not because people start new grand projects with them. Would Wordpress have chosen PHP if they started today?
Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well?
Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling, fast reload/build time, built in string templating, simplified variable syntax (auto, var), etc
I can go on, but if you already framed the question to the disadvantage of one party you will not really get a fair answer.
Other languages haven't caught up on PHP about ease of deployment.
If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed.
On the other hand, language structure is quite behind others but can't blame when it had been around since 20+ years ago.
The new type hinting is so basic, not sure how realistically useful it is compared to typing in TypeScript.
Thats hot patching, not reloading as I've come to know it in the web development world.
Hot reloading works the same for all languages I know, which is a hardcoded port pushing notifications to clients that they should reload the browser.
The client is mostly a js library or a browser plugins. Either works.
I know it's also used differently in some contexts, but they wouldn't apply here as far as I can tell. There aren't any long running processes that need to reload the code after all. It's only read when is actually executed. Which is never unless you use the hot reloading I was talking about earlier... Or trigger it manually, making it a regular reload.
You're entirely missing the point by focusing on why someone may or may not have used the wrong words - with an application written in many other languages, you have to do something special to be able to update some server-side code and have that new code be run when you next hit the server.
If pointing out that he's using the wrong technical term is 'missing the point', I'm not sure there was one to begin with.
most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild.
yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability.
there is really very little difference if you ignore the fact that it gets hard with the codesize and the environment in which the service is deployed in. the language is almost always the smallest challenge.
and fwiw, i'm definitely not "against" php in any way. i think ssr script languages are wonderful for easy development - especially if you combine them with something like intercoolerJS for interactivity. extremely easy to get started and you're even able to make ssr-"components" by just fetching each segment separately, which isn't really any overhead with HTTP2 nowadays.
I can, on my local server, change the code, hit it again, and have my changes reflected in what happens. Doing that with Python, Node.JS, Ruby, or Java requires extra configuration. That's the point.
Rewriting a bunch of text files isn't atomic, so you need to take a planned outage or atomically rename the source dir so you don't serve 5xx errors from parsing half-written source. At that point you might as well have a deploy process, which can be as simple as "rsync && mv" into each host.
Not sure if you even understand what you're talking about.
As for node.js, I set up pm2 to watch for file changes and restart ts-node process and this takes a few seconds, which is slower than I can hit alt-tab back to the browser, which is annoying to see 'Bad Gateway' error page quite often, not to mention embarrassing to explain and help set it up to someone new to other languages than PHP.
PHP is instant and I'd like to know if there's a solution in node.js that can do the same.
Hot reload is trivial in Common Lisp, and only marginally less so in Elixir. Turns out it's just not enough of a differentiator to actually tip the scales.
Go itself is also not a revolutionary language, actually the fact that it isn't revolutionary is one of it's "raisons d'etre". Go is mixing up various popular concepts into a reasonably compact package.
Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.
Am I the only one scratching their head at this argument in 2020? 15 years ago when shared hosting was more common I would buy it, but I just don't find myself wasting time on figuring deployments out in other languages/frameworks. By far the biggest time sink in that area is setting up continuous integration and monitoring/alerting systems, and those problems are exactly the same regardless of language.
I remember reading about Ghost.org team members saying that if they had chosen PHP instead of Node.js when they got started, they'd be much further along in their roadmap [0].
PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go.
Another big bonus for PHP to me is: there are plenty of people who are comfortable with it. Most things aren't genius-scientist-required kind of things where you lock some genius in a room for eighteen months and they revolutionize the industry. Most things are pretty average and you just need somebody with a good understanding of the problem and experience to do them. You'll want plenty of those people to get things done, and using a very common tool helps with having a large pool of people you can call upon.
Generally lower quality talent. That's half the reason PHP got its abysmal reputation. Brilliant programmers using PHP must be annoyed that they're thusly tarnished. I suppose that's not so different from JS. To the flames with both of them, though, I find them genuinely depressing languages to work with.
Which is totally fine btw. Most work isn't "we're engineering a new motor for a F1 race car", most work is "this car's motor is broken, replace it". You don't need a CS degree and brilliance to write code that deals with databases and APIs, which is the super majority of code.
You need smart people that spend a lot of time on difficult problems to create strategies that are easy to follow and tooling that is easy to use. And then you just need a lot of people using those tools and applying those strategies to real world problems.
What good is it if you have something that allows those that fully grasp it to write things ten times as fast, but you only have 10 people that can actually do that? I'd much rather pick something where I have ten million people that can use it, the output is just so much higher, and you don't get single points of failure because the one guy in your city that knows that language and does freelance work has decided to move on to a different language.
Our abstractions become the basis of our imagination - do we want developers to think and experience joy? Do we want their minds to spark and innovate and solve and embrace the full power of computing? Can anything compare with the illuminating glow of a powerful abstraction that reveals a new technique - perhaps not 'world changing' - that improves our software and our programmatic structures?
I guess we don't, actually. Oh well. :').
You make a perfectly reasonable business point.
And business is, imho, not just "for profit", but society in general. I feel about it similar as I feel about wood working mastery. Creating incredible joints with extreme attention to detail and a lot of experience fascinates me. But to build furniture for more than one person a year, I'd prefer nails, power tools and a bunch of people that are experienced enough not to nail parts of their body to the wood.
If we want to provide something to the masses, we'll have to provide something that can be used by the masses, not just by a highly trained elite. PHP is mass production development. It's not necessarily elegant (though you can do a lot in it, it doesn't have to be as messy as WP is), but it gets the job done AND it empowers large groups by being easy to learn and not requiring advanced understanding before you can actually achieve something with it.
I do still believe that we want experts that do the kind of work you're describing though. But I believe they shouldn't distance themselves from the ordinary people, but instead find their elegant solutions and then give them a handle so that the uninitiated can use them. Tooling is leverage, individually but even more so collectively. Imho, if you're a brilliant computer scientist and you work on "normal" real world problems, you're wasting your talent. Even if you find the greatest thing that runs 100 times as fast as the previous one, you've sped up one thing out of a million. Instead, build something that'll enable normal people to speed up their projects by factor two, your impact will be immeasurable.
PHP does a terrible job of weeding out the terrible hack programmers. For some reason, people have no problem going into a PHP codebase and monkeying around with it, where something like Rails or Java will at least intimidate them and make them think twice.
This.
I was using TypeScript for anything that looked like I'll be the sole maintainer but for something that could last for 10+ years, I started it out as PHP as I may not be the only maintainer one day and can't ask the client to look for more specialized talents for no good reason.
Well yeah, if you would pick one technology that even PHP would compare favourably too, it would be Node... my thoughts on Node were always: just because Google built V8, which makes it possible to run JS fast enough to use it in the backend, doesn't mean that you have to do it.
Regarding frameworks: of course PHP has an advantage there, because it's a more mature ecosystem. But frameworks written in PHP like Symfony or Laravel tend to forget that they are based on a scripting language (which years of optimization have made very fast for a scripting language, but still), so using their features extensively will slow down your application...
PHP still remains incredibly accessible, the documentation and legacy of problem solving means you can find help for any problem you'll encounter and the lack of complicated tooling makes it easy to focus on the problems that matter.
There is also a maturity in the tooling and community for PHP that doesn't exist in newer, better languages. There's no shortage of developers, and moreso nowadays there's also a huge body of best practices that embody good software engineering.
If what you want is a monolithic standalone web application paired with SQL, I'd argue PHP is a pragmatic choice from a business point of view. I would also argue that a monolithic web application is all the vast majority of companies need.
The biggest source of bad software and failing to meet business requirements in my experience has been following the industry's whim and rebuilding every time the wind blows in a new tech stack. If you're a PHP shop delivering web applications, you will be able to do that successfully for years to come. Picking the "right" language is a wild goose chase, just be good at the language you choose and you'll be able to deliver good software reliably.
Most of the time you do not chose a language or ecosystem because it has some cool syntax or some new feature. As an example if you need to do X you look at what solves X the best, if I can do X by installing say ffmpeg and write a bash script I will do that and not cry that bash does not have some cool feature.
I think languages like PHP, Java, C++ appeal for people that solve hard problem where the fact that you have a giant ecosystem of existing libraries and a large number of existing developers compensates the fact that the language is not "cool" or is missing some feature that you probably don't need anyway or workaround it with a library.
X sometimes stands for problems above technical problem, such as:
- Existing team is comfortable with using PHP
- Existing project is tightly coupled PHP monolith
- Existing project cannot be migrated to other language fast enough if needed
All are valid and justifiable reasons. Learning new language is not the easiest and we should think of the people.
I must emphasis though, all party must not freeze in time. They should learn to adapt. PHP is getting smaller. The decline is slow enough to let people migrate or jump ship but fast enough that it is recognizable.
Demands are growing for languages and environments which provide more than PHP, simplest examples would be granular websocket connection control, explicit process control, whitelist-by-default security, rise of cloud and edge computing, and of course, trends, "cool new stuffs" which is not always good for everybody, but always exciting especially for the naives.
There might be a day Java is getting replaced due its huge memory usage or its tendency to be verbose and hard to read. Golang is a contender for the memory usage side of the spectrum, NodeJS is the contender for the ease of use side of the spectrum.
There might be a day C++ is getting replaced due to its "harder to write secure code". C++20 is quite cool, but there's a new cool kid Rust where you most probably won't write bad code, can be actually faster than C++ / C in some cases, and can run on browsers.
May all programmers of old languages survive and thrive and in the new world.
Sure, but sometimes X is something like you have a video and you want to use the GPU to analyze it and the best library for that is in C and there are great python bindings. So a professional developer would use C or Python and not waste his client time by trying to create it's own unmaintainable CoolLang bindings (where this dev is just now learning CoolLang and there are not that many people that know CoolLang).
Even for new projects, say you have a desktop app and you want to let the users submit some data and save it on your server(like feedback or crash reports), you can do this on your server with 1 PHP file and a few lines of code, no dependencies on 300 packages.
You installed a framework Spring for a simple feature to grab some text from a POST request and dump it into a database.
Since in general you don't have thousands of users sending feedback at the same time I don't need a framework and if you know how to correctly create SQL statements you don't need a framework for SQL. There is nothing to log, if the db call fails you can put some text in a log file or do a curl to a different url to notify you.
It will also be probably faster then a Java framework since you don't have a function call stack 30 levels deep (not a Java issue , all magic frameworks including PHP one have such giant call stacks)
It depends on the customer, will they give you a server dedicated for your Java framework so you can handle at maximum 5 POST request per day or will day give you access to the existing website they have for the company, that already has PHP,mysql installed. Honestly you are not doing the fair thing for the customer if you ask for a new server because you want to use your prefered tool and not the best thing for this job.
Btw my scenario was about sending feedback ro stack traces, this are just text, no giant file uploads and nothing insecure about it.
Yes, and all three of them has very good backwards combability, one of the most underestimated features in a language for developers but one of the most important ones for building a stable business.
I recently upgraded a huge legacy codebase from PHP 5.2 (released 2006) to PHP 7.4 (released 2019) with relatively few changes, mostly changing the use of deprecated functions & misuse of variable references.
> But with fewer people self-hosting these days, that has become less an advantage.
I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.
> And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Did they? How?
With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to. No other environment matches that - and no other environment is supported by those hosters. If you want to run something else - like Ruby, which I prefer to use, or something that creates a binary for you - you are looking at a completely different type of hosting. Digitalocean, Heroku - and that's not as easy, if the application is not provided as a one-click-install.
> With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to
Let's not idealize things. For moderately complex apps, even back in the days, this falls pretty fast: missing PHP modules in default distro installation, PECL/Pear extensions, hosters messing with the php.ini in bad ways, etc. And now the dependency management and deployement systems pushing you to access a shell on your server...
The only issue of that I still encounter is hosters misconfiguring the php.ini, rarely.
There is no shell accessible on these servers, it's on the project to include all dependencies. Composer in this world is strictly not for users, but only for developers. That's a good thing.
Oh how I hated the fact that php.ini could change so much of the PHP behaviour... can't say I miss those days.
Also, I don't know about now because I left this ecosystem long ago, but it was very common for apps to bundle their own custom installer scripts (access a webpage, fill a form and so on). Certainly useful for the users but it was never standard and required a lot of work for the developers (and came with their own requirements and bugs).
But I like some of the recent additions to the language. At least the PHP Team keeps up with the competition.
This is changing now. There are no new php.ini changes that would affect how the parser or VM works. The lessons from things like safe_mode and register_globals are learned so well.
> I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.
From my experience, the share of people who can only deploy PHP is steadily shrinking. PHP remains the default, and popular, but easily deploying other languages is becoming more feasible, and we're shipping docker containers with Python/Go/Node/whatever code a lot more often these days.
I'll concede that PHP focused hosting solutions such as your traditional shared webpage hosting environment is better at hosting PHP than any other language, and sure there are less services out there that lets you deploy code "as easy as PHP".
I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on.
And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell. Then only thing that makes this harder is having to kill the server and restart on deployment. I dont find that to be that much harder.
It's not really a question of money, the VPS where you can do what you want can even be cheaper.
> And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell.
I mean, it's not like I'm not doing that for myself. Even my PHP blog is not with a traditional hoster. But there are many things that can go wrong there - for the ruby example starting with the ruby versions, additional system dependencies. And then you need something to make the app restart after a reboot (supervisor is thankfully excellent), and probably a nginx in front of the webapp, and letsencrypt, and does your VPS take care of backups? Each task not impossible, but in total vastly more complex. Some users can handle that, many don't.
I just did some freelance work on a wordpress site (and I'm involved with a different PHP blog engine, serendipity), and it's so nice when the setup that those PHP projects present you with is clear and straightforward, and on top of that everything that might be complicated even a mediocre hoster had years to solve now.
memory_limit is the upper bound you "allow" PHP to allocate. You can allocate more than the available RAM, and have your OS swap or PHP crash.
Pretty much every shared host I had to work with (I've been freelancing for a few years), have been terrible, except for two platforms, both of them were expensive and aimed at particular PHP software.
> PHP's raison d'être remains its ease of getting an instance running on a webserver. But with fewer people self-hosting these days, that has become less an advantage. And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
And if you are doing something moderately complex/serious/modern you probably need/want composer anyway - because uploading all of the million files via FTP is cumberstone (let's not even get into the versioning/modern deployment practices). Then you are at shell already and not that far away from other language deployments.
I think that's kind of part of the point though -- PHP provides a gentle slope from "single HTML file" to "big project".
You can start with a plain HTML page and go "Hey, I want to do X" and just throw some code in the middle of the page. When you decide you need a database, MySQL is right there and easy to use. When you decide you need some libraries, you can just download and `include()` them. All of this can just be FTP'd up to some server somewhere.
As this grows bigger, there are tools like composer and frameworks/libraries like Laravel and Symfony. You can still FTP those, but once that gets painful you can start to learn the bit of *nix skills it takes to start managing this different ways.
At no point have you had to worry about nginx/apache/supervisor/anything else. But whenever you're ready, that's all there too.
This is basically the path at least one guy I know took to going from working in a totally non-technical industry to building a massive (almost 2 million lines at this point) application that allowed people in the industry to stop working with a bunch of exploitative big name companies and instead self-manage and earn more money. And now that product makes a bunch of money for him.
And then there's the scales that places like Twitter/Facebook/etc took it.
I think the big thing that always gets missed here is PHP's... egalitarian nature. Yes, at some point it just ends up a in some ways less-good version of other things. But it provides an incredible opportunity for people who aren't engineers to realize their ideas without immediately becoming overwhelmed with needing to learn a huge amount of foundational knowledge before they can lay down their first line of useful code, and seeing that through to crazy places.
A question I ask myself often is what niche does a language fill, and it seems a little like the traditional niche of PHP has been eroded away in the last decade. Many of the things that gave PHP an edge (ease of deployment, templating within your HTML files, direct SQL queries) are no longer considered the correct approach.
At the same time PHP is trying to reinvent itself by adopting a strong type system and experimenting with async and long running processes. But these are niches that are already filled better by other languages (Java/C#, Node, Go), so it feels like they are fighting an uphill battle. But maybe it is that tenacity of the language to stay relevant that makes it attractive to a younger generation of developers and decision makers.
Greenfield projects are much less important than brownfield projects. After all, a project is new only for the first few months of its existence. After that, it all becomes legacy code :-)
And techs with mainstream adoption in the post DotCom bust era, especially if they're free and Open Source, will be around for decades. A newbie PHP programmer in 2020 will most likely be able to retire in 2065 as a veteran PHP programmer, if he/she so wishes.
> Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages.
Of the first programming languages that cater to novices to some degree (which is important to project health, because excessive gatekeeping is toxic), PHP was the first to make Curve25519 and Argon2id widely available (through the sodium extension). (7.2)
Even with the "just use FFI" mindset of other languages, the experience is janky at best.
For example: Before sodium-plus [1] came along (which was something I created, so I'm removing it from the table for my criticism of the JS crypto ecosystem), JavaScript required knowing which of the following packages to install: [2] [3] [4]
There was no guidance available anywhere. Some of these APIs were suitable for browsers, others for mobile devices, and still others for server-side JavaScript. And their APIs were subtly incompatible with each other.
Java's in a similar situation [5] today.
> Java (Java Native Access): libsodium-jna
> Java (Android): Lazysodium for Android
> Java (Android): Libstodium
> Java (Android): Robosodium
> Java (Android): libsodium-JNI
> Java: Apache Tuweni (crypto module)
> Java: Lazysodium for Java
> Java: jsodium
> Java: Kalium
Yikes.
With PHP7, you just had to update to the latest version (and make sure your OS package vendor isn't huffing or eating glue, which was rare but still existent) and you had it.
There are probably still languages and runtimes today that make using modern cryptography (Ed25519, X25519, etc.) a miserable experience.
Miserable experiences moving to modern cryptography keep peoples' projects trapped in an early 2000's RSA-PKCS#1v1.5 + AES-CBC hellscape reminiscent of SSLv3 but somehow worse.
Thus, I would argue that what PHP did with libsodium counts as revolutionary.
Your move, $languagesThatHackerNewsFindSexierThanPHP
Rust and Go for writing a cusomizable CMS like Wordpress, really? Also PHP playing catch up and not breaking up my stuff with every point release is just fine. It means stability, maturity. Even Node.js has LTS releases.
Dart is more suited for this type of thing if one wants a new and shiny statically typed language with great performance.
Do the two overalp in their niches at all? You'd write a web server in Rust. But is there much effort put into Rust web frameworks?
It's just a weird comparison. PHP is competitive with JS, Python, Ruby and even Java. But Rust? That's C/C++/D territory. And Go is somewhere in between.
There is lots of effort by Rust devs, even if the libraries are not as mature or easy. I don't believe you meant to be disrespectful here. I think better a better words could be any of manpower, maturity, or time.
I've been using PHP professionally since ~1999. I remember ripping the Perl fanboys in the early 2000's until the foundations of PHP started to crumble with what are issues that stick in peoples minds today; so I do wonder if we brought it on ourselves sometimes. But PHP moved on carefully to preserve backwards compatibility. I still have a SaaS first developed back in 2005 on the latest version of PHP that's happily ticking over with the minimal of maintenance required - the code base is horrendous but that's because a developer I had with me at the time made a massive case for "software design patterns" that he crowbarred into every nook and cranny regardless of if it was required or not.
I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.
> Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.
So just out of curiosity, if you hypothetically did start learning web development today from scratch, what would you spend time learning instead of PHP?
When I started I struggled with browser inconsistencies. Over the years Javascript has come a long way and whilst I'm not 100% sold on node.js, I like the idea of using the same language across front and backend so likely would have gone down that road.
If after 20 years of PHP experience you arrived at "not 100% sold on node.js" as your most likely alternative, that to me more than anything else signals a strong, ongoing vote for PHP :)
There is plenty to dislike about javascript but modern versions are really quite nice. We're about to ship our first node backend having been largely a django shop up until now. There is loads to miss about django and python, but it is so nice to not have the context switching between languages and paradigms. It may not be for everyone, but if you're doing modern web, I think the starting point has become javascript everywhere, and then moving away from that on a use-case basis.
Piggybacking to say that if you're just starting out, I'd recommend choosing _anything_, as in, your choice of programming language ecosystem is ancillary to learning the broader technologies and patterns common to web applications. Know somebody who knows PHP you can bug? Use PHP. Find the idea of writing Python exciting? Use Python. Really like the tutorial / book you found for Ruby? Use Ruby. It doesn't matter.
As someone who has programmed PHP professionally for 13+ years (and also JS and Python) I have never run into anyone who can place a solid argument since the PHP 7 + Laravel.
-- Let me clarify, PHP is useful with context. For building web apps. Each language has its best-uses. Laravel has the strongest ecosystem and community out of any language/framework combo I've seen.
I can literally setup and deploy a laravel application on a horizontally scaled setup with CI & autodeploy within an hour -- while maintaining industry standards.
PHP had its problems -- historically, but so did most languages. Do you remember Javascript before Node/React? Or before jQuery/Prototype? It was _trash_.
The biggest "con" to using PHP is that it's "bad" for the resume, no one is excited about it, so when looking to hire for it, most developers don't feel inspired by it -- which is a serious consideration depending on your circumstance.
All my projects require PHP 7.4, and it's such a joy to write the modern almost-strict typed, namespaced, and code that is often inter-operable, tested with a nice testing framework, and managed with an excellent dependency manager.
I have my reservations against Laravel though. Its excessive use of static methods is not my appetite, and its rapid release cycle gives less headroom to keep track in contrast to Symfony for example, which follows Semver strictly.
What's wrong with the static methods? And do you mean beyond helpers?
Laravel gets a major update about once a year from what I've followed (disclosure: I've been to Laracon twice, you could probably classify me as fanboy) -- I _haven't_ used Symfony, but I have enjoyed the rapid release cycle of Larave. It also generally takes 20-30 minutes to update to the latest major release, and if not, there is a service for $10 or so to update it for you
Javascript is still trash. What with the insane amount of configuration and build tools, extremely small standard library forcing you to use third party modules which may or may not have tens of security issues and the dependency hell it brings with it. I can go on and on.
I was raised in the darkness, so things don’t often look as bad as they are to me. Regardless, the clear distinction between PHP and JavaScript seems to be that I can choose whether or not I’d like to use one but not the other (and no, wasm doesn’t count because it still requires JS).
For me, I just don’t why I’d choose to use it for a green field project. Sure, it’s better now, but people have warned me to stay away from the boogeyman lurking within. Maybe it’s there, maybe it’s not. But why should I take the risk if it’s pretty much the same as other modern languages that might have cool stuff.
I agree to the point you're mentioning industry standard. PHP is not considered in the enterprise environment, simply for all it's flaws and it's security vulnerabilities and still has the same problems as before. Most languages don't have those problems.
PHP as a language had inherently insecure designs such as register_globals and RCE in unserialize().
When working on reviews, it's often as easy as grepping for "unserialize" and working your way from there for an easy bounty.
However, PHP has matured a lot. There is not a hint of register_globals as of now, and we have proper serializers, in addition to RCE-free improvements to original unserialize().
With native support for proper password hashing, sodium, and other improvements lately, one could argue that PHP is one of the most secure languages out there.
I've been using PHP for over 15 years and always liked it. There is no other webserver language that's so easy to use and so deployable while still being fast.
But for larger projects the available frameworks are just okayish. I think Symfony is closest to what a good framework should be. But every time I use it I wish it would be like .NET
Today .NET core is also available on Linux and very easy to deploy so I don't think I will ever start a big project in PHP again.
But for quick smaller and CMS[1] projects PHP is still my goto language.
What if you’re looking for a great way into .net web dev on Linux? I’ve been struggling to find a good guide that combines dev env, deployment and a good web framework. Any advice?
I have quite a bit of xp with Python (Django/flask) and less with php.
Most can be done via de command line but an editor like VisualStudioCode could be handy. Personally I use Jetbrain's Rider as IDE on Ubuntu.
Deploying can be done via the `dotnet publish` command. But tools like Teamcity can also be very useful. When you built a webapp it includes the Kestrel webserver. So it is just a matter of running the app and navigating to the port it listens to.
.NET core is a complete set of tools to create console apps, (web)APIs and webApps. This includes the .NET framework.
.net has proper debugging working compared to node.js, has great standard library, can develop 3d games, servers, mobile apps, web apps, machine learning ,desktop apps and even (some) embedded devices.
Great instrumentation and support with quality updates from MS and the community.
The IDE is superb and free (community edition at least), drag & drop desktop & mobile app development (if you wish).
I've worked with PHP for about 4 years (5.x - 7.0 days), .net for the next 6 years and node.js for the last 1 year, and every day i work with node.js i wish i could switch everything to .net because it's sooo much better & smoother experience, and everything just works together so well.
Honestly, as a PHP hater that got much more experience in .Net than PHP, it both were the only options, I would go with Laravel without any doubt.
C# is an inflexible language that just can not have a modern web framework on it. MS extended it with hard-coded functionality to closely emulate a framework and did an ok job on it, but it emulates a closed down, inflexible framework that is stuck in time. It's not a disaster, but it doesn't compare to the stuff that has kept evolving for the last decade.
It saddens me to see some of the (largely baseless and otherwise largely historical) hate for PHP. I use Hack in my day job, which has at this point diverged from PHP, and I like it for the most part.
The thing that PHP does right that so few languages do is having a stateless core in the webserver. This is an incredibly efficient approach to serving HTTP traffic. Consider the startup cost issues with Java, or Rails' single request at a time model or even Python's startup (and GIL).
The second thing PHP does right is it request scopes everything. Simply throw away everything you created when the request ends. No dangling references and memory leaks (pretty much) like you get with stateful Java services (eg whatever servlets is now).
And the third is no multithreading in the core API. Starting and synchronizing threads is incredibly difficult to get right and adds a huge overhead to everything with little gain when you're just servicing an HTTP request, almost all of the time.
Hack has 2 things PHP7 doesn't quite have that I'd miss:
> The thing that PHP does right that so few languages do is having a stateless core in the webserver.
I never understood why the HN crowd always ignored this massive benefit of PHP, in a world where it's becoming clearer everyday that keeping things stateless across the stack provides many benefits towards managing complex systems.
Most of the interesting things I’ve worked on would fall down if you couldn’t cache some stuff across requests, like database connections. If every request requires a new TCP connection, even if to something lightweight and fast like a local pgbouncer instance, requests are going to be a lot slower (and the time spent context switching from userspace to kernelspace and back a lot higher) than if you could reuse one from an in-memory pool.
I love stateless stuff and have started moving a lot of things to Lambdas where appropriate, but I wouldn’t use a completely stateless setup for handling large numbers of requests per unit time.
Sure, but then it's no longer purely stateless, and honestly no more isolated than, say, a Django app (assuming it hasn't been deliberately broken to share state across requests).
It's still completely stateless from the dev standpoint (even if it's not truly stateless under the hood). It's more like a caches connection if that makes sense.
Because this is not always a benefit. Want to cache something in between requests? You have to use memcached/redis. Want to have some background or periodic processing? Set up cronjobs, and/or use an external job queue system.
Sure, if you're writing a simple CRUD app with and RDBMS backend it can be just fine. But when you're dealing with more complex work just being able to start a goroutine or use an in-memory cache structure is so much nicer than having to deal with external systems.
Request processing in Java (or any other sane language) is Request-scoped.
The Request is a variable, the Response is a variable, they're only in local scope?
And any data the developer uses will also be local -- and thus stateless -- unless they go out of their way to share something. (Caches are a common example, but harder in PHP since nothing by default is shareable.)
You don't need to deal with threads if you're seeking PHP-equivalent functionality.
And if you did need to deal with threads, I find your claims about overheads & difficulty hard to read without a little skepticism. An idle thread is faster to start than spawning a process, an uncontended synchronization takes only 20-250 CPU cycles (ie. a modest number of nanoseconds), and a thread pool can be sensibly managed in 2-3 lines of code.
I think what the comment really means by "request scoped" is that the PHP process is totally torn down after each request. In Java you can mutate global state as its running. You can leak memory until you OOM.
One unfortunate side effect is PHP's choice to use the word "global" for what isn't really global but request scope. The "global variables are bad" folks look down on the PHP global scope just because of the name.
Tearing down the entire request after processing is (IMHO) a remarkable effective approach.
I don't know. I think that global variables, even in PHP, are still poor software engineering. It still, very much, makes the code harder to reason about and debug. In fact, my understanding of the anti-global-vars rhetoric is that it's very much about understanding and debugging.
Tbh, that's done in modern PHP frameworks as well. ReactPHP & Co rely on you not using global variables, Symfony's architecture is built for that as well. You don't want to incur the startup cost for every request, because it's very slow.
This doesn't matter a lot in single requests of course, but once you're writing APIs that get considerable traffic, you'll want to cut out those 50ms and the load.
I have been coding in PHP for 15 years (not exclusively) and indeed many things had to improve.
Nevertheless, many other languages also had to. Just as an example, PHP had a much more mature vendor requirements system than Go and years before!
What I see many people tend to fail to observe is that a language is also good as the amount of value it can being to the business and in that PHP was and still is phenomenal.
Anyhow, I'm really happy to see how it has evolved.
I've been programming in PHP since 2007 and I absolutely love it. I've long ignored the hate for it here. I worked hard and followed best practices to get good at PHP.
In 2015, I started writing "projectionist" software in PHP to completely automate my home theatre.
I was a projectionist at three different theatres for about half a decade. I spoke with old-timers to really get it right and have been tweaking this script regularly ever since.
I've got a Netflix-style website for my movie collection. I can watch a feature either in my browser or choose to play it in the cinema. I can even schedule a feature for 7:00pm and it will wake-up 30 minutes before with music and nice lighting, assemble all the dancing hot dog ads and trailers, play it, turn the lights on for the credits, and shut itself down 30 minutes after.
The little ODROID running the whole theatre opens a chat room connection over XMPP with my servers so it can respond to controls in the app, whether I'm adjusting lighting or sound levels, putting it in Desktop mode, or manually controlling the curtain and projector.
I just ignore the PHP hate because I find it extremely powerful- it can do everything I could ever need. I also always want to keep an open mind.
Unfortunately, no, I haven't published the source code. I'd maybe like to commercialize it in the future, but it would require either some tech to compile PHP or would need to be re-written.
I think it's a really simple system overall... It uses XMPPHP (updated for PHP 7) and otherwise it's just a lot of loops, network calls, and proc_* functions.
It keeps getting declared dead, but then, keeps rising from the grave.
I wrote PHP for a long time (more than 20 years). Many, many thousands of lines of it. I got fairly good at it. I wrote my last big application in it about a year and a half ago (PHP 7.3, I think). It's a great application, but no one would want it, as it does the same thing lots of big SaaS does.
Except one single person wrote it, from soup to nuts (no dependencies), in about six months -part time- (it was sort of a "thesis" project for me, as I was re-learning my engineering discipline), and it's quite good quality. So I guess PHP is good for something. I just open-sourced the application, and more or less sent it out to stud.
That said, I never really liked the language, and am glad to have seen the back of it. I write full-time in Swift, nowadays, and would be thrilled to never write PHP ever again.
Despite all the hate, though, it's a perfectly good language; especially with all the stuff added in 7+.
This may sound hurtful but hear me out - One thing worth mentioning why someone would not want to use PHP in 2020 is that a PHP programmer is looked down upon by other programmers.
And im saying this without hate or malice. I love PHP since I was a PHP dev from 5.2 - 7.0. I built PHP libraries and WordPress plugins that have helped many people. Ive since moved to Node because PHP jobs have dried up in my country.
PHP devs arent respected which is sad because we all belong to the same programming community. And PHP has contributed a lot to the proliferation of websites. At the end of the day programming languages dont matter to businesses as long as it gets the job done at a reasonabe cost.
In fairness the wheel has turned and node developers are seen as not respected. If you haven't moved to go/rust/serverless by 2018 the cool market has moved.
When I got started in 2000, php developers weren't as smart as perl developers. Then it was asp. No serious business would use php over asp. Java developers always had this attutiude but they were always treated as second class from c++ developers who were treated bad by c developers who were using a toy language compared to asm.
At some point 2006/2007 php became cool. But then the facebook movie came out and php was uncool again. Ruby on rails was better (unless you were twitter and wanted to scale). Then node. Go. Serverless.
PHP has always been anticool and looked down on. You need a strong sense of self to get involved.
As a fun, tongue-in-cheek project, someone should build a website with this timeline of languages going from cool to uncool.
For people who are busy with life and work, but who want to learn a new cool language, it would answer the question "what's the cool thing right now?". You look at the timeline, it's language X.
This also enables fun future oniony articles like "Go no longer cool", "Rust going the way of the dinosaur", "C++ is the new kid on the block", "Node.js is dead, long live X" etc.
Haters gonna hate. Node.js programmers are looked down upon too by go programmers. C programmers are an anachronism, haskell is for academic navel gazing etc. Small minds think their favorite language is the best because they can't see outside their own problem domain.
Languages are tools that suit different needs. Use the best tool for the job, pay attention to industry trends so you don't become a Cobol dinosaur with no job prospects. Switching to node is a good career move but it won't be your last. Node has incredible momentum and developer mindshare. You can accomplish a lot with it but node projects are difficult to maintain.
I look down upon people who look down upon people for their technology choices and would never willingly work with such assholes. Your point is irrelevant because those are people I have no interest in working with. To look down upon others (rather than a language) indicates that one is a complete idiot, asshole, and someone I'd rather not meet. Better those people self select out of my life when they hear php because they would clearly be a detriment to me and to anyone who isn't a moron like them. Not to mention unprofessional, naive, and arrogant.
I've worked with PHP since 5.4, and to me the language has not been the obstacle, it has been my own skill-level that has held me back, and still is - I lack very much the core architectural skills in getting forward as a developer, among many other things.
I've seen some codebases using an even older version, and I think I can understand where people are coming from with their angst towards the language - but I think we should look at ourselves before we jump to the bandvagon of just hating something blindly - I remember being part of the "Apple sucks" group for no other reason than hype, and now I've used one for years as a work machine.
I got back into web development in the last year or so. Previously I did mostly Python/Django and then 5 years of something unrelated to dev. Now I'm working in a fairly typical PHP/Wordpress mixed joint, and now I understand why PHP has the bad rep - because it allows/tolerates/even encourages bad practices (and beyond the usual "shoot yourself in the leg" we can see in other popular/common languages). And I guess that is one of the reasons why a lot of libraries/plugins/php code out there is simply bad. For example: Seeing heavy mixing of PHP code and HTML output in 2020 is a horrible sight for me (and it's waaay to common in what I saw).
Of course you can write good code in modern PHP, but you can write really bad stuff too - more (at least imho) than in other popular languages. And then the whole ecosystem "drags you down" and gives PHP a bad rep -> but I don't think it's totally undeserved.
On a similar note, this actually compelled me to try Rust/something similar instead of just going straight back to Python (which I still love tbh).
The thing I hate about php is the inconsistency and unpredictability for new-to-php developers.
camelCase? snake_case? nocase? Who knows what the global function will be.
And who knows what order the arguments should go in. Sometimes the array is first, sometimes not (in array iterating functions like map).
The thing that got my goat the most however was that referencing an undefined variable merely caused a warning, but referencing an undefined key in an array borked it.
And what's with arrays and maps being the same thing?!
FYI when you start a PHP project you need to change your dev machine php.ini to be super strict, so all warrnings should just error out.
The inconsistency seems to have it's logic and at that time was consistent and made sense, you need a good IDE to help with this. Using PHPStorm and then using PHPDoc to define your functions parameters and return type is a joy, the IDE will catch your type mistakes, show you where you missed to catch an exception and it will code complete stuff.
It never made sense. The original hash bucketing mechanism for the function lookup in PHP was the length of the name of the function, so each new function was named a specific length to ensure the function list was evenly distributed across the hash table.
Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.
Thanks for the tips! I suspect PHPStorm/Doc may be the only one that flies for the legacy codebase I sometimes get involved with - turning warnings into errors would be suicidal...
You don't turn warnings into error on production but it will help to have them enabled on your local machine, otherwise errors are ignored and you would waste your time debugging weird issues. You can do this per file too using the "ini_set" https://www.php.net/manual/en/function.ini-set.php
This has been my experience too. Ten+ years ago I had already concluded that the biggest problem PHP has is the community. Googling for "php mysql" you still end up on w3schools and the like where SQL injection is still not emphasized. Everyone was making their own frameworks and software from scratch. My last foray into PHP, and my realization that it's not actually all bad, was working in Zend Framework (iirc this was also when Ruby on Rails was fairly new and gaining popularity fast).
I haven't touched it (beyond very basic edits on my website, wordpress etc) for over a decade, but recently I inherited an older codebase at my new job. The existing codebase is an absolute mess, worse than the shit posted in those tutorials I mentioned.
But as part of the job (beyond rebuilding the application), I also had to add a big new feature to the application, a REST API. Keep in mind that due to constraints on the systems we install on, it had to be made in PHP 5.2 or 5.3 - one difference being that the older version doesn't even support an array creation shorthand (`$var = []`).
I could keep interactions with the existing codebase to a minimum. The rest was... actually surprisingly all right, thanks to me knowing what a REST API is and how to structure an application properly.
I did have to basically write my own framework (sigh) because pretty much nothing is still available that works on pre-array-shorthand-versions of PHP, but it was fairly minimal; an off-the-shelf router and URL matcher (can't be arsed with writing that myself), middleware for authentication, and a simple class structure to encapsulate different output formats (json, csv, streaming plain text).
Granted, this old version of PHP is seriously rough around the edges, and at the time it already represented great advancements in the language. I mean before 5.4 the language didn't even have a function to set the HTTP response code (you had to write the header manually).
Why do these discussions always end up in some black/white dicotomy? Are there situations where PHP is a valid part of a tech stack? Sure. Are there places where, if you could choose, PHP is not a good choice in the stack, Yup.
My personal view of it is that it is part of our eco-system and will not go away, how eager some of us may be to have it disappear, so seeing it getting better as a platform should make the world a little better for a lot of people that need to use it in systems that are built with parts in PHP.I cant see how that is a bad thing.
The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?
Few of the people I worked with have only one tool in their belt, and they can work in any language. We all have some favorable setup that we think is best for us/others to use in order to build better software with quicker iterations. But all of us (hopefully) also know that few, if any, stacks are 100% solid and consistent after a couple of years. There is always some parts that we wish would not exist, some script that magically does stuff that we do not dare to touch, some service that is written in some fancy language by that awesome dev that worked here 10 years ago or some really central part of our software that is written in Python, talking to a module written in C that needs to be compiled with a specific compiler that went dead 4 years ago. Even if we dream about the perfect system that just works (LIKE I WANT IT) and has a fantastic setup, it is only at specific snapshots of time systems work like that. Time, people, organizations, product requirements, marketing efforts, buzz, hacks, fixes, playfulness, boredom etc all makes system degrade over time and while it is important to manage these debts, it is more or less impossible to have a system in a state where it will always have the tech stack you want right now. That way, we will always have to address bugs in PHP, old Python-versions, rage over custom compiled nginx or whatever. Whether or not PHP is a good language or not is a meta-discussion IMO. If languages that are used by a lot of people gets better over time, that is awesome in my book. Having a perfect tech stack with only funny/new/fancy/awesome tech is at best an interesting mind experiment.
As soon as you hit a certain level of complexity in your solution/software/whatever, you will be using multiple languages. You'll have scripts written in Bash, front-ends using PHP, back-ends using C or whatever. You are definitely correct that there is no black and white here, all software just needs to be "good enough" to actually solve a problem and be worth paying for.
If PHP being slow stops you from being "good enough" then it's very likely that you can just isolate the part where PHP isn't doing a good job, re-write that in another language and keep the parts where PHP is working fine.
> The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?
Because, if others use it, I have a higher chance of also having to use it.
I do not use Java and JS at work because of my like or dislike of these languages; I use them at work because, many years ago, whoever started the project I'm working at chose these languages. Had they chosen Python or Ruby or C# or anything else, I would have to use these languages. And it does not apply only to work: if I want to contribute to the Linux kernel, I have to do it in C; if I want to contribute to LibreOffice, I have to do it in C++; if I want to contribute to MediaWiki, I have to do it in PHP; and so on.
Convincing others to not use a poor language reduces the chance of myself having to deal with it later.
I guess the "poor" in "poor language" is in the eye of the beholder and I get your point. Have you found yourself lucky in convincing the world in not using any language yet?
people make fun of php all the time... just see the comments in this thread.
people forget though that wordpress, drupal, joomla and magento are all written in php and most likely accounts for 70% or so of all the websites online today.
php is going to be around despite all the negativity and fanboyism of other languages. you can't go wrong with knowing php if you always want something to fall back on if you need a job. while coding wordpress websites isn't the greatest job in the world, it is a job and be thankful for that especially during these times.
PHP -> much better that people often give it credit for
I've hardly ever used PHP over the course of my 20 year career, being mostly on C, Java and JavaScript, but on the few times that I have, I have always been really impressed with all aspects of the experience.
Whatever academic semantic deficiencies PHP might have, there is no more accessible language for making web site backends with and its sad that so many people are discouraged from using it.
I'm a PHP dev and I'm pretty happy with the language, especially some of the things introduced in recent versions. I think it's a fine choice for anything that doesn't fall in the "low-level, high-performance" or "mobile/desktop app" categories.
For web applications, I think PHP's idea of a clean slate for every request also makes a lot of sense and immensely simplifies development. I can write a simple PHP application that handles thousands of concurrent requests without even thinking about threading, synchronization, memory leaks or anything like that because handling that stuff is basically built-in.
PHP has a really good ecosystem. A framework like Laravel can do just about anything you'd need in an application out of the box. Routing, rendering HTML, generating URLs, handling sessions, logging, validating requests, an ORM, translations, encryption, sending emails, queues, schedules, caching - it's all there. I've never seen anything quite as fully-featured in any other language. On Packagist, I can find packages for pretty much anything from clients for obscure SOAP APIs to libraries for handling GraphQL. There's also a lot of great tooling, with a good package manager, static analysis tools like Psalm, code formatters etc. Also, PhpStorm is a fantastic IDE.
Outside of PHP, I mostly have experience with Java and JS.
If you know Java, modern PHP isn't all that different. Java has some nice stuff that I hope we'll get in PHP some day (generics is the big one). I built an application using the Play framework (Java version) a couple years ago and it was quite similar to modern PHP frameworks. However, there was always a bit more complexity with Java. Everything was just slightly more complicated. So with the trade-off basically being performance (which is better in Java) vs. ease of use and developer experience (which I think is better in PHP), I'd choose PHP most of the time.
Now, when comparing it to JS, I'm really glad I mostly get work with PHP instead of JS. I know this might sound strange coming from a PHP developer, but holy shit, JS is a mess. When writing JS, I'm constantly going between "oh, nice, this is really easy to do with Vue" and "what the fuck does that error even mean, how am I supposed to find any problem buried under several layers of bundlers, polyfills, loaders, transpilers and reactive frontend black magic?". If JS wasn't the only thing that works in a browser, I would avoid it like the plague.
Funny, while I see that many people enjoy the features that come with this maturity (and I am happy for those people of course), I long for the simplicity of the classic style PHP.
Personally, I do not enjoy the Java-style 'enterprisey' direction of PHP. I don't like types, anonymous functions, treats and all the other fancy stuff. To be honest, I think I myself would still be happy with PHP4. I use thin scripts, almost no classes, alternative PHP template syntax and I am completely frameworkless. But I guess I am just a nihilist ;-).
I do like the enterprisey direction personally, mostly because it works so well with a good IDE. I'm using PHPStorm and once you've got your project set up, code completion/suggestion and inspections are something I love.
Depicts language feature, PHP ecosystem is dying. For me, an example is latest MediaWiki syntax highlight extension dropped GeSHi (PHP) which is not updated anymore, to pygments (Python) using a sub process.
I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature.
I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an ecosystem (GeSHi was used everywhere few years ago), but it looks like no-one is working on it anymore so MediaWiki did an strong technological move to use Python via a sub process.
This kind of move (dropping a existing natively written tool for a tool from another language) shows how bad the ecosystem situation is.
This is a side effect of open source. GeSHi, and many others, suddenly stop getting maintained, and more often than not, project ownership doesn't get passed down.
This problem isn't unique to PHP. I have seen this is many projects across all kinds of different languages and tooling.
Unfortunately, if there's no good alternative written in PHP, MediaWiki could have either reimplement it from scratch. In my opinion, GeSHi isn't the best implementation of a syntax highlighter, so I get their reason to not adopt it. Writing a syntax highlighter from scratch isn't a trivial task either.
None of this says that the PHP ecosystem is dying though. MediaWiki isn't going to suddenly move away from PHP. Nor will many, many of the other big name projects that are still built on top PHP, and as long as there are big name projects, PHP ecosystem will continue to evolve.
I will say choosing a Python sub-process at the sacrifice of portability (considering how many people simply run this on a PHP webhoster) is quite surprising.
That's not a side effect of open source: it's a side effect of any dependency. If you were using foxpro, any google service, apis from companies bought by Apple, etc then the dependencies stop being maintained or vanish altogether.
Would it be feasible to write a PHP equivalent to emscripten, so that one could export software compiled from any frontend language (including, e.g. the WASM representation) as a php object that can be run directly by mod_php?
It should be possible, but I'm not sure if PHP has the kind of community drive behind it to make it a realistic option.
Or a necessary one – emscripten's main use case is "everyone has a browser", but there's very few PHP hosting offerings where you can't shell out and just run straight native code (in your own little isolated sandbox).
I use php daily. Mostly Symfony/Laravel stuff. There are still some stuff it needs what other languages have. (Can't really right now remember all the stuff i stumble upon sometimes which gives me the feeling "damn if i could do this like i do it in rust/java/cpp/(w/e)")
Maybe the worst thing is the composer (it's slow.)
It's sad that php as such a bad rep that I figured I should say "I code in Go. Php? Yeah I can do that too" so I don't get some eye rolling and an instant prejudice I'm a cheap coder.
For it's age php is great and pretty easy to setup (having to intall separate modules for imagemagick and cryptography is just a tiny assle). Composer should really solve it's large memory usage problems, but other than that it's pretty good.
It's really good for it's intended purposes and is getting a lot better in latest versions.
If it's modern PHP specifically, are you saying that both languages are adding a bunch of the same things? That doesn't really sound like one language turning into the other.
Whether you like or hate PHP, it has achieved something that no other language has done - made it easy to host a dynamic website or app on the server. Other languages may claim to be 'web-friendly' (e.g. Python, Ruby) but when it comes to ease of deployment, they are anything but 'web-friendly' or easy.
This is what programmer and blogger Jeff Atwood - who isn't a fan of PHP - has written about PHP:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option"
He wrote that in 2012. It's 2020 and I can't think of any other language that has caught up with PHP's ease of deployment. If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP?
>If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP?
Anything with containers. Docker was a real game-changer here.
For hosting companies, PHP has a unique benefit: A single installation which scales with the load. Most Python, .NET, Java, NodeJS, Docker, whatever require to run a seperate executable for each site permanently (producing a basic workload / memory consumption / security mgmt needs / ... ).
In that sense, PHP is like a early variant of Lambda ;) When there would be a universal, simple-install, simple-use, low-requirement version of Lambda (incl. Gateway etc) we would see a easier hosting market for all the languages beyond the public clouds.
>In our dashboard you will find pre-configured Open Source apps like WordPress, Plone and other. They are all based on the official docker images and can be deployed with just one click.
They had to write an installer ecosystem around installing docker images, whereas with PHP and most stock server configs you can SSH a file into a server and you're pretty much done.
Still if I want to write a simple web app in < 1 day, I would definitely use PHP.
In such a manual workflow ("you can SSH a file into a server"), you still have to setup at least URL rewriting in nginx for any PHP app using routing (which is basically everything using any PHP framework or micro-framework).
Plus if the deployed app has its own domain/subdomain, you need to set that up, set up TLS certs etc., so it is really no different in the end. You either configure nginx to proxy all requests for some domain to an index.php file, or you proxy them to a locally running container (where you also don't have to worry about versions of software installed on that server, clashes between different apps, etc.).
Commercial PHP webhosts also have an "installer" for automating all of this, provisioning databases, etc.
A lot of this can also be automated by various Kubernetes controllers (DNS configuration, TLS cert provisioning, databases, volumes, backups, monitoring etc.) if you already have a cluster. And for packaging installable apps, there is Helm and its charts (e.g. https://hub.helm.sh/charts/bitnami/ghost), you can also manage them from a GUI dashboard (https://kubeapps.com/) or even from a git repo (https://argoproj.github.io/argo-cd/) if you want to have a repeatable history of all changes to the environment, updates, etc.
Literally, just start `docker run` with a proper restart policy, set up a proxy_pass on nginx and you're good to go (unless the app requires external services, databases, etc., but you have the same problem with PHP).
Plus you don't have to worry about things like "do I have the correct PHP version for all my apps?" or "do I have the necessary PHP extensions installed in the system-global PHP?
>And surely you must be joking when comparing Kubernetes' complex configuration to anything else.
Setting up a Kubernetes cluster is indeed complex. Installing apps into an already configured cluster (e.g. ordered as a service from someone) is not (unless the app itself is complex of course).
I was comparing it to the automation tools that "traditional" webhosts have for installing and managing application deployment, replying to a comment above ("They had to write an installer ecosystem..."). If you just want to have one VPS with nginx on port 80/443 and run apps there, you don't need any of that stuff. The container images are the same either way.
Many of the features highlighted in that article as "new" are from PHP 5.x, so it reads more like a list written by someone who has been out of touch with PHP development for a number of years.
Did you actually read the article or just the headings? Any features that pre-date 7.x are discussed as being 5.x features and, where applicable, the author expands on how it's been further refined / improved upon in 7.x releases
Yes I read it, why accuse me of not doing so? The main block of sample code is highlighting OOP features in PHP, but PHP has had most of those features since 5.3, e.g. namespaces, so my point still stands. Those features are not part of "PHP showing its maturity in release 7.4", but have been around since at least 2009, so why lead with that example?
When objects were first introduced in PHP 4, the implementation was essentially an array with function references and was horribly problematic. The fundamental problems of that implementation were thankfully addressed with the release of PHP 5, featuring an entirely rethought object implementation. In the versions that have come since, up through version the current 7.4 releases, numerous interesting language features for object-oriented programming (OOP) have emerged.
I suspect you're narrowing the scope of what this article was intended to cover. It is not just a look at PHP 7.4; it's just using the recent PHP release as an excuse for a look back at the history of the language:
With PHP 7.4.5 released in April, it's worthwhile to take a look at modern PHP, how it has evolved to address the criticisms of the past, and what lies ahead in its future.
I accept it mentions that in the content, I guess its the title I find misleading. You can see on this very HN thread, lots of confused replies are falsely equating those features as new developments.
My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now, so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
This meme of people on HN judging articles entirely on their title really needs to die.
> My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now
You keep saying that and I keep replying that nobody was ever arguing otherwise.
> so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
Again, they wasn't. You just assumed they did; presumably because you just read the title and the pre block and skipped over all the rest of the content.
Many emotional language bashing comments here, and everything between „php is dead“ to „php is awesome now“.
Personally I liked that php has an ultra low entrance bar: shared hosting for $2, ftp deployment, no advanced syntax to understand. When starting work in teams instead of solo and coding nontrivial business rules, this ease of doing died for me. Moved on.
Many years of JavaScript, doing nodejs since 0.4, it was just like having superpowers and doing isomorphic things. Mixing things every other month with coffeescript, babel, typescript and trying a different framework for every new project. What once felt refreshing is now just exhausting and JS projects tends to end in rewrite loops.
Before/Inbetween/After there were many languages, from C at university, to C#, Ruby, Go, ... . Mostly the tech didn‘t change much, but over time emotions change for me. Longest streak of love had ruby, shortest had Go (just a few weeks before it became disgusting for me). I believe thats Personal and different for everyone.
After all my reflections I finally settled with just two choices of techstacks: Elixir/Phoenix for all things Web and Rust for everything else.
Writing highlevel businesscode , interactive exploration of things, CRUD things and realtime frontends in Phoenix is a breeze. But this ease of use has tradeoffs as always, I always feel that this dynamic code is somewhat „fluffy“, but ist seems that this is a key to prototype and ship things rapidly.
When i do want to do things that feel more „substantial“/„meaningful“ than just assembling yet another web product, I Switch to Rust. Producing a statically linked, crosscompiled binary that is „proven“ to work after discussing with the compiler is deeply satisfying for me. Unlike those „fluff“ / yet-another-web-product work.
Full Circle to PHP: awesome to see static typing available now! But this alone doesn’t make it feel so heavily baremetal for me, still fluffy with types bolted on. It is the fastest php ever, but still in the ballpark of scripting languages. It has mature, productive frameworks, but Phoenix feels superior and leading the way (next rails? Dunno), so why bother if php plays catch up to moving targets?
Software Development has become somewhat like fashion now, and PHP looks like those jeans jackets people had in east germany. Not inherently bad, fully functional for its purpose, but once you experience the taste of freedom in the western world you insist to have „real“ things. Best metaphor I can think of, but as stated: most discussions here are highly emotional, and it’s hard to put that in words.
Tried PHP again (using it since the 3.x days off and on) a few years ago and didn't dislike it. It would be great if types were even better enforced. But then again I could have been working with Microsoft MVC instead and have an even better experience, especially in terms of autocomplete in an IDE (because C# has stronger types and they are more logical to find by trial and error, like typing a . after a string value), something which I highly value.
But I still think PHP is really cool when you just want to hack something together and indeed like many people said before run it anywhere without headache. You can output formatted text really easily. Other languages are way more formal about output. I hacked together a song recommendation and voting system for my marriage website in a few hours and people loved it.
I very rarely write PHP and will probably never have to use these features, but I think that the combination of the FFI and preloading can be quite a powerful thing.
PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.
Alas, I feel the same way. After much thought this weekend, I concluded that it was time to move on from PHP. I decided against the any other scripted language (Ruby, Python), as it felt like more of the same.
Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust.
I really want to like Rust more, but the library support, and the jobs in my area just aren't there (yet?).
Kotlin is really a fantastic language even without IntelliJ but with IntelliJ it makes these older languages feel archaic. Once you've had this level of explicit typing & null checking, code navigation, and refactoring that really works its very hard to go back.
Kotlin also feels like a pretty safe bet since both Google & Jetbrains are backing it.
No garbage collection, doesn't compile to Javascript[0] and everything on Android is moving to Kotlin anyway.
Just to be clear, my reasons stated above is why I'm moving to Kotlin. I make no claim that other people should or would want the same things. I've realised that I like languages with explicit strict typing, and that allow for a greater level of expressiveness at the cost of a higher intrinsic complexity and the comprehension that requires.
One of the main benefits of PHP for web serving, is the "shared nothing" architecture.
By operating as a non-threaded application, entire categories of bugs and security holes are avoided.
Are there situations where threads could genuinely help? Sure, there is always an exception to any rule, but for the vast majority of projects where PHP is used, I don't believe threading would achieve much in terms of performance gains.
There are very few places where PHP cannot do strict comparisons.
The first example in that article even highlights that `in_array` has a `$strict` parameter.
I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.
Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety.
On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat it, too.
There really aren't that many places to remember, and there is copious amounts of developer tooling available to identify, and in some cases even fix the issues automatically.
I don't recall ever seeing any kind of dev tooling that can just automatically fix thread safety issues.
What do you mean by concurrency here? JS like async or Java/C# like threads? And why would concurrency help in problems where PHP is involved, in the problems I solve with PHP I don't think I ever needed async. For unning more things in parallel like processing 1000 RSS feeds you can spawn 10 scripts that run in parallel and if one crashes the others still continue to work(I had experienced crashes with some RSS XML files crashing the built-in XML parser).
Anything that will block the server. Fetching data from an external API, doing some kind of expensive computation, sending an email etc. You can either handling this Node style with blocking i/o, throw the work onto a background queue like Sidekiq, or use a language with first-class concurrency support like Golang or Kotlin. To me Kotlin feels like a far nicer and more scalable language than Golang.
I like this about PHP, you don't have a callback hell. I don't disagree with you just sharing my experience here, we might work on different kind of problems.
I work on highly concurrent backends that handle 100k requests per second across a cluster, and PHP will never work in those situations. Any time you have to orchestrate multiple data store or service calls in the background, you don't want to block.
Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage.
PHP bakes you into a very simple request flow. There's so much more you can build if you get out of that manner of thinking.
Yes, I never disagreed with that, best tool for the job. But your problem is not the usual stuff that web projects are about.
Edit: FYI I have experience with other languages too, so if at my work I use PHP does not imply that I am some inexperienced person that has no idea how other languages work. I do not have experience with your domain of high concurrency, low latency stuff but I worked with threads, and thread pools and multi-processes programs(it happened that some thread would segfault and bring the app down so we had to use background processes instead of threads) .
Just curious what problem are you trying to solve, I never had the need for different threads to communicate in PHP, most of the time in my work a user makes a request, and a PHp scripts does something like update the database or does some searching/working and returns a result.
What if that request was a document upload and your system is calling out some external api or processing for long enough such that you’d rather return now and update later when the job finishes. Maybe through Ajax or a redirect.
The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Ajax endpoint that processes a chunk at a time...) and the when I asked a marketing friend of mine who works with Wordpress he said that redis is an “advanced requirement” and I should keep things simple.
In Django land I’ve always set up queues even just to send emails because it keeps things snappy.
For that kind of problem we create a database table. then you schedule there your work tasks and background scripts will fetch jobs from the database and run them. This also works great if the third party is busy or fails, the background jobs are set to attempt a few times before giving up.
What solution would you prefer for this kind of jobs? launching a new thread directly? or have a worker project always running and send to it the job directly?
.... As you identified at the end, the correct solution for this problem is a job queue. There is nothing about PHP that prevents the use of a job queue - in fact the shared-nothing, process-per-request model almost encourages the developer to offload as much work as possible to a job queue..
Using Wordpress (or it's plugins) as any kind of reference for what PHP is capable of, is like using McDonalds as the basis for a cook book.
If putting a job/event into a queue, or writing a log entry is taking so long that you need a separate thread just to enqueue/log that entry, something is dreadfully wrong with your application.
Ironically, the root cause that made me think of that example was AWS.
The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms.
There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.
I do. However, the process would have stuck around until it finished. It wouldn't have changed our overall RPS at all.
Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.
I'm there with you about Kotlin. I started with PHP last "last generation" and was pretty bored with it. Kotlin was a breath of fresh air. Also, if you like some similar to Laravel/Symfony for Kotlin, give Alpas a try: https://alpas.dev/
You can defined what types/interfaces methods needs to return, what types/interfaces variables must have, what types/interfaces the method arguments needs to have.
It also supports class inheritance, abstract classes, interface classes, class traits, etc.
It does, and using PHP in strict mode, in combination with tools like phpstan is what led me to looking for a language that is even better in that regard.
If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.
However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.
Nah. The JVM must go; we have Docker and the universal platform are Linux ELF binaries so the entire "bytecode" concept makes sense for the compiler (i.e. LLVM), but no longer at runtime. It's just bloat.
Bytecode is simple enough to alter at load time. This gives you aspect-oriented programming and instrumentation of everything that statically linked binaries have never offered. And I don't think anything compares to the JVM's GC throughout yet; why roll your own if it's slow?
Kotlin native might eventually make the JVM superfluous but for now there are a lot of benefits to being on the JVM including great performance, a huge ecosystem of Java libraries, and very battle hardened monitoring and debugging tools.
Considering the GP commenter started with an emphasis on concurrency, Elixir's concurrency features (thanks to the Erlang VM) are totally different than what Python can offer, namely isolated processes (scheduled in the VM so like green threads) where you can write blocking or CPU intensive code without worrying about blocking the other processes and where GC is per-process. With Python you (AFAIK) run into the GIL when threading or you fork OS processes that are heavyweight so you can't do that for every request or you'll fall down. Or you have to write async code which can still only saturate one core.
Not saying Elixir is the answer to everything but that's where it differs in the concurrency sector. It doesn't have static typing though, which is a requirement for some.
so is PHP worth learning right now? and what is the job prospect looking like? if I study the language for the next few months what is the lickely scenario I will find a career in it.. I actually enjoy and like PHP unlike other people idk what it is about the languauge it looks fun and enjoyable to play with . Plus it's simple and easy opens doors to more complex languages later on down the road
There will be work for PHP developers for many years to come. It will not be the sexiest work, but you'll get paid to write code, and any day being paid to write code is better than any day not being paid, or a day being paid to do something you don't enjoy.
I stopped coding it professionally almost 20 years ago (!), but it was a great foundation to a ton of stuff, and going back through the release notes and modern frameworks I'm actually thinking I might use it for a few side projects.
Don't let anybody put you off, I say if it appeals to you that you should go and learn it and get some work with it.
If I was looking for a job as a developer, I probably would not go with PHP. But if I had a new saas that I wanted to build and turn I to a business, I would seriously consider using php to get to a rapid mvp.
I ended up using PHP while I worked in a design shop, as it was extremely easy to both implement designs in and easy for low-tech clients to run.
It wasn’t bad. Good docs, reasonably easy to run & deploy (except Wordpress). I don’t think I’ll ever use it again more due to career reasons, temperamentally I prefer the backend, but given the same circumstances I’d use it again.
Is it possible to write long-running processes well in PHP today? Is the memory management of PHP up to the task? Or is it all a *cgi-based execution model? This question still is what makes it hard to place PHP. Basically all "high perf"/"high load" applications of it I know about run under PHP-FPM or webserver modules or uwsgi.
Long-running processes are definitely possible. You obviously have to be a bit more careful not to leak memory.
It's common to have things like queue workers implemented as long-running CLI processes. I just checked one of our services at work and there's a queue process that has been running for more than 4 months. There might be others that have been running even longer, but I don't feel like checking every service right now ;)
Projects like Swoole or ReactPHP are trying to make similar things possible for serving web requests too.
As someone who started my career in PHP in 2002 and switched to Rails in 2008, I can say I do not miss PHP. I still maintain my old apps only because of the high pay associated, not because it is joyful. PHP's version of "mature" does not match other modern langs, not even close imho.
Ah, it's like old times again. Nowadays all the language-snob threads are directed towards JavaScript, but I remember the days when PHP was the language of choice for what HN considers the inferior programmer. Fun memories, all this thread is missing is a link to the fractal of bad design rant.
It's not language quality and merits per se that are important. It's much about establishing status within a tribe that counts. PHP is seen as a low status language because many junior or moderately skilled programmers use it. Rust is a popular language among up and coming young programmers because they expect to over throw the dominance of older C++ programmers. Haskell is for the high priests if that is your path to power and status.
Can anybody comment on the state of Unicode in PHP?
I dimly remember that "proper" Unicode support was planned for PHP 6, and being one of the features that delayed that version, and contributed to it being skipped altogether.
My startups running on PHP and I definitely don't regret it. The language is simple, you have easy access to talent, knowledge, and thousands of mature libraries. Most of the times boring is better.
What put me off PHP for life was the assumption by employers and recruiters that PHP rates are at least 20% lower than for JS, Rails or Django. PHP just isn't respected professionally.
PHP has a lot going for it. It is popular, fast, has a nice syntax and a ton of useful functionality baked right into the language.
The main weakness I see in PHP is the lack of modules. PHP provides namespaces to avoid name conflicts. First of all, that does not completely root out naming conflicts. The developer who puts a namescpace into their code can only hope that it does not clash with someone else's.
Secondly, it makes it necessary that both, the code that provides reusable functionality and the code that uses it have to deal with the issue of namespaces.
A module system like Python and Javascript have is superior to this. Then only the user of the reusable code decides where to put it into the namespace.
For web backend, being able to ship a single binary, such as what Rust and Go can provide, is really nice. I don't see PHP as a more compelling solution than either of those languages.
Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools.
I do not see what the use case for PHP is in 2020.
PHP has one of the most abhorrent language syntax designs this side of Perl, and the standard library is wildly inconsistent.
I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
Think of a simple landing page with a form to save data from a form and send out an email with confirmation.
In PHP you just need to add to your HTML page a few lines of PHP code and copy it using scp to any share server hosting that costs 4 dollars a year.
No "automation", no "cloud", no REST APIs, no WSGI/Gunicorn, etc. just plain Apache with mod_php enabled, which is available everywhere. I don't think anything can beat PHP productivity for such simple usecases.
Aren't there a zillion online services that provides that product out of the box, most likely for free, only requiring a browser and some monkey clicks around? -> No PHP, HTML or web server.
As someone who works with PHP reasonably often, I'd say you have a very limited view of what PHP is actually used for in 2020, if you think 3 hosted blog services will replace it.
The majority of PHP usages tend to be, frankly, unsophisticated Wordpress, WooCommerce, Magento, and Drupal sites that are hacked up to support e-commerce. These needs can now be met by a vast array of ecom and omnichannel platforms.
> Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools.
Python has a ridiculous time it needs to start up, it is not suited for any batch task that requires a lot of process creation.
> PHP has one of the most abhorrent language syntax designs this side of Perl and the standard library is wildly inconsistent.
At least it has a standard library that is both usable (in contrast to the JS ecosystem, remember left-pad?) and actually not that inconsistent if you have experience in developing C - most of what is described as "inconsistent" comes right from there.
And: the stdlib of PHP can easily be expanded upon by a rich variety of Composer libraries that can easily be deployed. Let's compare that to... Java, for example. Three popular dependency managers (and build tools): Ant, Maven, Gradle. Plus classpath worries if you're using Tomcat or other application servers which means you also have their libraries in the mix.
Changing code in production? In PHP it's as easy as changing the file using rsync and automatically all new incoming requests will use the new code, vs Java where you have to restart the server (which for large project means minutes of downtime).
> being able to ship a single binary, such as what Rust and Go can provide, is really nice
Unless you're distributing your binary to 3rd parties, why?
If you really don't want to deploy changes to e.g. a single/small number of controller or template files as independent file changes, build your PHP app into a .phar archive, and deploy that.
I don't specifically think PHP, when run (IMO) the best way it can be, is "easier to deploy" but I also don't think it's harder either.
I'm going to ignore your other comments because they're personal opinions and while you express them as facts, I realise you probably mean them as statements of opinion.
But the last part, I just don't understand:
> I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
Who is the "we" in this statement? You clearly don't like it personally, so why does it affect you, at all? I'm not a huge fan of Java, but I don't go around claiming that it should "die" or that humanity is somehow worse off because it exists.
There's no such thing as a client-side PHP application, so it doesn't even compare to e.g. genuine concern over tech choices that are 'forced' upon users of a website (e.g. Flash, SilverLight, ActiveX, javacript bloat, etc). If the backend part of the system does what it needs to do, the language/framework/runtime it's written in/with is meaningless.
At the same time, being able to install new or change existing software just by uploading some files to a cheap webhost is not to be dismissed as easily.
Most webhosts provide some kind of support for containers don’t they? Perhaps I’m completely missing the point here? I’ll readily admit that Im young enough to have used docker to deploy apps nearly everywhere I worked. Is php useful for ultra low cost websites? Is it low maintenance? Is that the appeal? Genuine question.
I don't think I even disagree with you here, but to use arguments for version control as your arguments for docker images and static binaries seems odd.
All three of the issues you raise would be solved by involving a VCS somewhere in your FTP deployment.
Incidentally, claiming that either option is "no more difficult" than FTP upload or even using VCS is either disingenuous or at least a little blinkered. FTP can work as simply as copying files between "folders", I've successfully taught my non-techy parents to use FTP. Setting up docker images or static binaries requires significantly more understanding of what's going on but of course provide speed, consistency and scalability benefits.
Many small businesses just want to get online, how does a container help them? Actually it doesn't.
Containers definitely has its place, but there hundred of thousands problems out there that needs to be solved for a low cost, otherwise it will never be solved, and a container will just increase that cost with little or no gain for the customer.
I see on their website they are on version 7.x, and have documentation online there also for 6.x, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, 5.1, 5.0, and 4.2.
For those with a conservative server software approach who install a Linux distro that will have long term support and then stick with it up until near the end of that long term, and stick with the version of PHP that came with the distro, we have to go back to 5.5 or 5.4 or maybe even earlier to get a Laravel that works with our PHP.
(Symfony appears to be at 5.3, with 4.4 and 3.4 still maintained. 3.4 will work with most major distros that are still in LTS, except I'm not sure about RHEL. 4.4 has the same requirements as Laravel 5.6, and so misses out on some existing LTS distros).
i would probably look at updating and keeping a more secure OS that can run modern software. Asking a framework to maintain a version of their framework for a version of PHP that is no longer supported, is not realistic.
also laravel is open source, if you want to update an old version because you want to run unsupported software, you are welcome to do it yourself also.
I'm starting a new project in PHP now. I've used the language for a long time, I think starting with the 3.x days, and it's come a long way. There's a lot of good things about it.
But.
I recently joked in frustration that I missed the days when PHP was a cargo cult version of Perl rather than a cargo cult version of Java. It's a joke, it's not a fully fair criticism, but I can't help but feel there's some truth to it. PHP is a fast dynamic language literally designed for embedding in web pages, with a batteries included mindset that shoves all sorts of useful things into the language itself (yes, kind of haphazardly and occasionally in slipshod fashion). If I want to know what the path of the request is, for instance, I could just do:
"Okay, Chipotle, but that's just one more line, stop whining." Sure, but it's three lines that instantiates a Request object that in turn instantiates Stream and Uri objects and importa two Traits and implements, I don't know, let's say four? four Interfaces, and--
"Come on, it's still fast." Yes! Sure But you know what's faster? Looking at the $_SERVER variable. I can't help but paraphrase a famous quote:
Some people, when confronted with a problem, think "I know, I'll use a design pattern." Now they have two problems.
I know. I know. Using factories and dependency injection containers and tying yourself into knots to avoid anything that remotely looks like a global makes things testable and composable and decoupled, but it is so freaking heavyweight compared to other dynamic languages. Python's Flask web framework has a global context object just called "g", which is essentially a singleton that lets you arbitrarily store properties on it, not just variables but database connections. OMG GLOBAL RUN AWAY AAAA no, you know what? It's fine. Yes, in some sense it's probably more dangerous because someone could come along and blow away your database connection by overwriting the "g.db" property, but maybe sometimes the simpler answer is "well, don't do that."
Look, I've used Symfony, and CakePHP, and Laravel 4. I think I even contributed a test to Laravel 4's testing framework way back when. They're great. And I'm not saying "let's all just throw out objects and all separations of concern and mix HTML and business logic like it's 1999, baby." But PHP is virtually a framework on its own, and at times it feels like many smart people have put a great deal of effort into building entirely different frameworks on top of it, paradigms that PHP wasn't intended to fit into.
So for my new project, I'm just... rolling it all from scratch. I don't have a composer.json file because I don't need PHP-FIG compatibility--although the four-line autoloader I have would technically load any PSR-4 compatible module if I wanted to. It's using the front controller pattern, it has regex-based routing, it has a simple template system with layouts, it has request and response objects, it uses type hinting. It's probably not super great, but it's... kind of refreshing to write this way.
I love PHP despite its warts, and it's great that it's learned so much from Enterprise JavaBeanServerNetSwingPattern land. But I admit I'm kinda hoping for it all to get a little more relaxed about, you know, still being a dynamic language.
PHP is great. Nothing comes near as close when you just want to shit some SQL-queries onto a page, or add some basic interactivity. Just drop your scripts in /var/www and let apache do the rest. It's like magic.
For me it's too late. I used PHP when it wasn't "mature" yet and hated it. There something blocking me now from ever going back to check it, no matter what its new features might be.
I cut my teeth on it years ago, I don't hate on it for cheap jokes. That said I don't know why anyone would pick it to start a new project in 2020. We've been lucky to have so many new and established options that are better in almost everyway.
I think it depends on the types of project or the target of the said project.
Recently I had to develop a very small CMS that manages personal web pages and it was a requirement that it could be installed very easily (i.e., by copying a single file) on virtually any hosting provider. PHP was (and is) still the natural candidate for such projects.
If my project is "big enough" to warrant something like Laravel, I would just pick Rails or Phoenix over it any day.
I find both those languages much better to work in and I just feel like I'm getting things done way faster. If its smaller than that, I'dd definitly just pick go or node with express or go maybe.
I work with PHP 5 days a week through work and even a few years into it, i still do not like it. Its feels like a mess compared to the other languages I work with for my own projects. Even when working with something like Laravel which do mask a bunch of the pain points of the language, it still feels cumbersome IMO.
you can run PHP pretty much anywhere, even the cheapest VPS probably has PHP, as well as all managed hosting. For python, go or other languages it can be more tricky if you're looking for cheap hosting / VPS
With docker containers and the numerous PaaS/FaaS runtimes, does that really matter? You can run anything just about anywhere these days, cheaply or even for free.
For average business owners who buy a WordPress template and some 5€ hosting in order to set up a business card web site on their own, on the other hand, it matters a lot. So if your project targets that group of people then PHP is pretty much the only option; anything more complicated than an FTP upload/MySQL import is pretty much to advanced for them and they generally aren't interested in learning new skills just to get a web site online.
Who's doing that anymore? Either you (or your staff) are technical enough to manage installing a web framework on a server, or you use any of the numerous managed sites instead. (Squarespace, Wix, Webflow, Wordpress.com, Shopify, Facebook, etc)
The last thing a non-techie business owner needs is to worry about setting up a random server with bad PHP code.
There's plenty of businesses selling business card web sites built on WordPress. They usually install it on whatever hosting the customer orders and then leaves the rest up to the customer.
If you're starting with WebDev in 2020, choose Go or Rust. Concurrency & safety + simple deployable static ELF binaries > weak typing and legacy bloat.
Why would I use Rust for Web dev or anything else that is not some low level system programming? I mean if you want to write some toy project and want to learn sure, but for a serious project I would chose something that uses a higher level programming language, that has a big and stable standard library and that also has a big community made , well tested libraries to work with.
Of course. Why change that for zero gain? Powershell does too.
Can you point to some research that scientifically proves that the use of dollar sign in variable names makes it harder to solve computer science problems?
1. Waste of time and mental cycles: forces the programmer to do the parser's job because the language designer was too lazy to build in the logic to recognize variables.
2. Carpal tunnel syndrome, especially on keyboards where "$" can only be reached via shift.
1. Personally I find it easier to read variable names prefixed with dollar signs, it differentiates variables from other symbols, which makes them very easy to find, especially now when many languages gives information overload by lots of type information etc. My eyes can scan code faster.
I wrote my very first webapp in PHP when I was a teenager, and my first dozen paid apps shortly thereafter as a consultant. PHP was a lot worse then, but still has a lot of the same fundamental issues that it won’t ever be able to escape without becoming a different language.
I think it’s a good first tinkering language for people around that age: sort of like BASIC, but for the web.
I am glad PHP is still around; it is a very useful signal on the resume or CV of someone who uses it a lot.
It’s sort of like c# in that regard (exception granted for vertical-specific devs who work professionally to ship commercial apps with Unity), or Visual Basic before it.
Same goes for heavy Java outside of Google/Amazon backend, or outside of Android.
Most of these people are desktop Windows users by choice, too. It’s a very specific type of techie. Perhaps one day I should make an ishkur-style taxonomy. :D
I think this is also why almost all forum software is written in PHP.
I still can't see how it can be "mature" if it offers an iterable returnable type like in the article example yet doesn't indicate the type of the object it is returning!
It has type hints for function parameters and return types but not for arrays. This makes it useless to me.
I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments to hint to an IDE is not a real solution.
It's still just a vector<void* > in C++ parlance. Nobody would take you seriously if you said "just add comments to indicate what your void* might be" in a large codebase.
I still can't see how C++ can be "mature" if you have to indicate the type of object it is returning!
I know everybody will say "just add a type declaration so the compiler can interpret it" but this should be a feature of the language. Just adding type declarations to hint to a compiler is not a real solution.
But it's not a hint to the compiler. It's stating a fact to the compiler. It'll stop compilation.
If I have a basket of fruit, all the items in that basket container are fruit. I can't put anything other than fruit in it. It's a basket of fruit. I know how to interact with the fruit due to its type.
If I am able to put dung into my basket, my fruit is spoiled and I cannot assume how to interact with the objects in the basket.
This is a PHP array without types at the array level. I can put dung into it and have no idea how to interact with it.
Or are you saying that a container of any type is perfectly acceptable? Did the other languages (C++, C#, Java) get it wrong?
eg. on this line can you tell me what the array holds and how I interact with it? What does array $operations hold?
> But it's not a hint to the compiler. It's stating a fact to the compiler. It'll stop compilation.
So, if I type out that something's a Banana, and the compiler stops and tells me it's actually an Apple, why did I need to type anything?
> Did the other languages (C++, C#, Java) get it wrong?
I can only speak for Java, but here goes. Here's something that compiles without warning and crashes at runtime:
Fruit[] basket = new Apple[] { new Apple(), new Apple() };
basket[0] = new Apple();
basket[1] = new Banana(); // Crash here
You and I know Dung doesn't belong in a basket, but Java sure doesn't. It will not warn about me comparing Fruit to Dung, nor is there a way to ask the compiler to warn me that I forgot to handle Banana:
void handleFruit(Fruit fruit) {
if (fruit instanceof Apple) {
System.out.println("Apple");
} else if (fruit instanceof Dung) {
System.out.println("Dung");
}
}
Here's another one:
void foo() {
Fruit[] basket = new Apple[] { new Apple(), new Apple() };
handleFruit(basket[0]);
handleFruit(new Apple();
}
void handleFruit(Fruit fruit) {
System.out.println("Do I get called?";
}
void handleFruit(Apple apple) {
System.out.println("Or do I?";
}
In the first code sample we established that the basket could only contain Apples, but now when you handle something from the basket, it's apparently any Fruit.
And when you handleFruit an Apple, there's no warning that the compiler is making a choice between the two acceptable handleFruit functions.
Anyway, just like me, this Bucket<Dung> is full of shit. Time to dump it all out. I could put it in the compost, or in the veggie garden. Anywhere that contains Dung. Likewise, the Fruit could go in a Bowl, or a Cupboard.
Here's a first pass at it:
interface Transfer<F, T> {
void dump(F from, T to);
}
class FertiliseGarden implements Transfer<Bucket, Garden> {
public void dump(Bucket from, Garden to) {
}
}
class PutAwayFruit implements Transfer<Basket, Cupboard> {
public void dump(Basket from, Cupboard to) {
}
}
It compiles, but it's missing the only safety check I really cared about - the contents must match (even if the containers vary!) Let's introduce another type variable X to assert this:
Now it asserts what I want it to assert, but it doesn't compile.
I can't call how Java handles the above stuff as 'wrong', since that's stating it too objectively. I can only say I disagree with the above design decisions (if they were deliberate) or I find fault with them (if they just turned out that way).
Yes that Java example is bad and terrible. I'm honestly amazed you can do Fruit[] basket = new Apple[]. That's terrible.
You can't do that in C++. You can slice objects but you'll get a warning in any good compiler.
I would like to know the type of the object I am working with else it'd be "auto everything" in C++ and it makes the code unreadable.
That's basically what I am finding objectionable about PHP because you've got types added as return types from functions, and also types for parameters and you can enable strict checks for the types but none of it makes any sense when you can just get an array of unknown/any type.
It's like a C++ vector of void pointers that you can cast to whatever you'd like it to be and that's really bad. It's also not very maintainable, particularly in large codebases.
It's a strange oversight in PHP given the type "safety" enforced elsewhere. I suspect they just aren't doing it because so much code would break.
I would like to see this typed array introduced so you can look at horrible codebases like the Magento example (there's loads of it) and see at a glance what you're dealing within instead of "an array of unknown type".
I will use your FertiliseGarden function shortly, thanks.
Here are some facts:
- Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language)
- PHP has more active contributors than it ever had [2]
- Laravel is one of the most used frameworks in the world [3]
Then I see statements like "PHP only exists today because of legacies being maintained". Can't provide stats on this, but neither can the people who make these statements. Might be just because I'm a PHP dev myself but I see a lot of new projects started with the above frameworks.
And last, people compare it to languages like Rust or Go since they consider those are "innovative". I hope everyone understands that a language is fit for a certain type of task. PHP was created for website development, and in that area neither Go or Rust are even close to matching it in terms of maturity.
I may be biased but for me, choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core, and except for these two I wouldn't seriously consider any other competitor for starting a new project. Unless, of course, that project is "for fun" and you want to experiment with new technologies.
[1] https://symfony.com/blog/symfony-was-the-backend-framework-w...
[2] https://github.com/php/php-src/pulse
[3] https://trends.builtwith.com/framework/Laravel