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.
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.
/me clutches pearls
What a travesty! I wish, I, a lowly, stupid PHP developer was smart enough to know about the Actor model!
/s
What about https://www.php.net/manual/en/ref.shmop.php ?
> - 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.
The best semi-official documentation I have found is http://www.phpinternalsbook.com/, but it is incomplete. Some important chapters are just blank, eg http://www.phpinternalsbook.com/php7/internal_types/zvals/me.... A lot of questions I can only answer by grepping the source code of the extensions in the PHP distribution itself.
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.
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.
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?
is a synchronous thread, as described above above. By design.
So I meant one thread per request at the php-fpm level, not Nginx/HTTPD level.
* Edit for spelling
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.
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.
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.
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.
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...
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.
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.
99.9% of web apps are CRUD.
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.
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.
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”.
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
It's all about simplicity.
In a web app you "multithread" using the web server...
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.
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.
[citation needed]
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.).
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.
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 for that reason that JSX is the first way-to-splat-HTML-out that hasn't made my skin crawl in...pretty much ever.)
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.
That said I'm not sure it'd be as easy to do hiccup in pure JS because names aren't a first class data type there
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.
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.
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.)
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.”
– Michael Crichton (1942-2008)
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 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.
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.
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.
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 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?
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.
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.
In which case you’re back again in PHP land.
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 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.
Nobody is forced to write Haskell or Rust, you have to actively look for such positions.
Then again, this doesn't explain why the number #1 language (Python) is so liked...
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.
I think skill and knowledge of the coders is vastly more important then the language choice... you can write insecure, slow code in any language.
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.
Lately modern PHP frameworks have so a lot of dependencies too. So both stacks are getting fatter as their capabilities grow.
> 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.
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.
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?
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.
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?
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.
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.
Why not Django or Rails?
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.
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.
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.
>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 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.
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.
[0]: https://symfony.com/doc/current/doctrine.html
[1]: https://www.doctrine-project.org/projects/doctrine-orm/en/2....
[0]: https://www.php.net/manual/en/language.generators.overview.p...
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.
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.
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.
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.
Surely Django & Rails are also comparable to something like Laravel?
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?
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?
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.
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.
This just shows a lack of understanding of modern PHP. REST APIs are dead simple in PHP using Slim, Lumen, or Symfony REST.
Symfony, Laravel, Drupal and Wordpress would be reasons.
For example "foo"==TRUE, "foo"==0 and TRUE !=0 are logically consistent now?
Or json_encode no longer returns null for invalid input?
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.
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.
PLT doesn't care whether "the business" cares.
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.
if(gettype($a) !== "...") { return false; }
switch($a) { ... }Also, PHP allows you to add explicit type casting to case statements. e.g.,
case (string) 1: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.
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.
If we just look at [3] above, we see these: https://trends.builtwith.com/framework/Django-Language https://trends.builtwith.com/framework/Ruby-on-Rails
Django, at least on that site, seems to be quite far off. Rails, at least on that site, is ahead of PHP.
Ok, I'll rephrase that:
Django and RoR aren't that far off.
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.
Thanks for this detailed comment and the historical background, it is very informational!
"foo" == TRUE, and "foo" == 0, but TRUE != 0
NULL < -1, and NULL == 0
PHP sez:
Parse error: syntax error, unexpected (T_PAAMAYIM_NEKUDOTAYIM)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.
I think, the reason is, Facebook poured a load of money/time into PHP. Otherwise it would probably on life-support right now.
I'm saying that back in the days it looked like it will go downhill, but then a big player used it and that saved it.
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.
https://www.youtube.com/watch?v=TOveFBc9AyI
https://voicesoftheelephpant.com/2019/07/16/interview-with-s...
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.
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 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.
You mean that you don't know how to: https://github.com/amphp/amp
> 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.
I think you can.
https://dev.to/webong/using-asynchronous-processes-in-php-7i...
Funny that you mention Squarespace as replacing PHP when they themselves are a big PHP shop.
This is evidenced in their open-source GitHub projects: https://github.com/squarespace
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.)
* Database migrations
* Database seeding
* Views/HTML rendering
* Logging capabilities (configurable backends like rotating log files, syslog, Slack 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.
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.
A.k.a., Kotlin. :p
In all seriousness, though. The only thing PHP still has over Java is that when I say my function takes Foo type, you can't give it null instead.
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 ;)
... Just to avoid confusion
> Hashing
> Encryption
> CLI commands with option/argument parsing, colored output, progress bars etc. (Do you mean a management console? All of them have it.)
Except for those, Django has every single one.
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
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 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.
[1]: https://docs.djangoproject.com/en/3.0/howto/custom-managemen...
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.
Django.
Revel.
Actix.
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)
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.
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.
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.
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