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