PHP is probably the best language for server side webdev today. Still insanely easy to deploy, lots of features at the language level, and the frameworks that are available are very sophisticated. Whether you like Laravel or not, it’s influence is spreading to other frameworks within PHP and other languages. Also, Laravel has some of the best docs in OSS, period.
I think WordPress is pushing other projects forward as well. The tech stack over there doesn’t move nearly as fast, but the UX is still pretty good out of the box and with the enterprise clients I work with on a daily basis, they all still love WP.
Back to PHP proper for a minute, the language is fast. There are efforts being made to run PHP on Serverless infrastructure or with continuous process environments. New features are added to the language on a regular basis as evidenced by this post and others. The defacto package manager, Composer, is also world class.
It’s a good time to be a PHP dev!
As a final point, I’ll throw out some of my worries. I’ve been writing PHP since 2010~ as a high schooler fooling around.
The “Java-fication” of PHP is real. There is a push for more types and type related features. These aren’t bad in isolation, but as they move deeper into the core of the language, there is a risk of breaking legacy apps. Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. I’m not advocating keeping 100% compatibility forever, but recent versions have played more fast and loose with breaking changes. We’ve done a decent job of carrying the entire community onto new versions and that will be important for continued adoption.
Take a look at the open RFCs for more details. I think there is value for pulling good ideas from other languages, but we don’t need every idea from every language.
> I think WordPress is pushing other projects forward as well.
If anything, it's holding PHP back. I don't often work with WordPress projects, but when I have to, it makes me want to cry with how backwards they are. WordPress doesn't even have a real routing system!
Furthermore, its ecosystem just seems to encourage really, really bad things, like user-editable templates, PHP code "snippets" stored in the database, images which should be in themes stored as post attachments instead, and just general lack of respect for the idea of separating code and content. Almost every "plug-in" or template is crippled and begging for license fees and/or throwing spammy "notifications" all over the admin interface. I know this sort of stuff are more culture issues than code ones, but they're still problems, and ones you only really see happening in WordPress sites.
I get angry when a client comes to me with a bundle of WordPress mess and asks me to fix or improve something. It's shameful and disrespectful to take a client's money and give them a WordPress site in return. Do these people actually not realize there's far better things out there?
> It's shameful and disrespectful to take a client's money and give them a WordPress site in return
If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that?
I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time. It's better to have 10 code snippets to achieve 10 fixes, than 10 plugins to address those same fixes.
There must be a lot of developers out there paying their rent and feeding the cat from Wordpress plugin subscription earnings. While this does encourage the spammy ecosystem, it also encourages competition between plugin authors to maintain and develop quality plugins that do the job.
> Do these people actually not realize there's far better things out there?
I'd be interested to hear what good replacements there are for Wordpress+WooCommerce? I find WooCommerce slows down Wordpress, regardless of caching plugins and other tricks. It's annoying, and I'm genuinely interested in alternatives with as much flexibility and support?
> PHP is probably the best language for server side webdev today.
What are your credentials with non-PHP, non-JS/TS languages? Have you written some Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those languages are different to some extend, they take fresh approaches, they contain new ideas and are scrape throat well designed.
I find most cheering for PHP and JS have very little exposure to other camps of software development.
> PHP is probably the best language for server side webdev today.
I'm telling you (opinion ahead), it most likely is not. And most likely will never be. It simply has too many fundamental design errors that have long known solutions, are near impossible to fix in PHP/JS and are fixed-by-design in other languages that also have good tooling for web-dev.
This is not just PHP/JS. But since we are looking at "the best lang for webdev" I limit myself the these and this use case.
When discussing server side web dev, I think the most important aspect is the ecosystem and libraries/frameworks available as much as the language itself.
> Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure?
OCaml is an excellent language depending on what you are intending to do. I can't imagine though that it would be a pleasant generic server side.
The same would apply to most languages on your list, except perhaps Clojure who has an excellent ecosystem thanks to the JVM. But then, is Clojure a good webdev language ? maybe ? I only toyed with it for a very short time, but I don't see it on par with PHP or ruby for instance.
In my opinion, what makes a "language" the best for webdev is not its syntax. It is the ecosystem, the libraries, the amount of people that know it, the learning curve, the editor plugins available, the frameworks, etc.
Ocaml? Elm? Clojure? Haskell?. That's fun for side projects, not for real business.
Your response is a perfect example of why these discussions are so difficult. What makes a language “good” depends heavily on your priorities and perspective.
I love Clojure, it’s so well designed. Haskell is hard to beat in terms of academic type correctness. But what if I’m trying to build a web app and my priorities were, ease of hiring and productivity, especially for junior devs, and a big ecosystem. Does Clojure win here against PHP? That’s a much harder argument to make. Would anyone say Rust is a better web development language than PHP?
All these tools have trade-offs. PHP is a fantastic choice for web development, the rough edges are becoming increasingly minimal with each successive version.
I’ve personally tried projects in Ruby, Elixir, and node. PHP has been the best experience for me across both dev and production. Elixir has an excellent local environment story though!
> The defacto package manager, Composer, is also world class.
Composer suddenly got good, didn't it! Composer 1.x was one of my pain points I think.
I can't think of many things that really bug me much anymore.
Null coalescing operators and named parameters are the kinds of things that make me happy.
I also adore Laravel (and particularly Lighthouse).
But what I really like about PHP is the humility and maturity of the whole endeavour. It's really typified by Rasmus Lerdorf who openly critiques his own abilities and seeks out smart people.
> There are efforts being made to run PHP on Serverless infrastructure
This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.
> This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.
Yes, but now you have to pay for every requests made to your app instead of just paying $4 a month for a shared Apache server and I also have to architecture my PHP app in a rigid way to fit whatever "serverless" execution model the SAAS runs with.
> Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite.
This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.
Just anecdata. My SO is currently working for a very small regional dairy producer (think 18 people total). Naturally they have a website no one really knows how to handle. My SO needed to update stuff, received the login info and the first thing we saw was WordPress stating that php5.6 is too old and should be updated.
After some arguing with the company that is payed to manage their IT environment she got them to finally update the php version and now the server is running 8.1.
I was glad that at least wp was up to date. Current wp running on quite old php version and exactly nothing broke with the update.
I was positively surprised. Would have expected more problems from my experience with other projects in other languages.
Something I pick on with PHP is because requests are so isolated, it doesn't have a good story for pooling SQL and HTTP connections. Its model really limits you when it comes to sharing resources between requests.
It's possible to have persistent MySQL connections, but there's all kinds of caveats; MySQL connections are stateful, so bad things can happen, and the performance benefits are only very slight. https://www.php.net/manual/en/features.persistent-connection...
This is indeed a downside but there are workarounds -- The wikimedia foundation put out a good blog post talking about getting HTTP connection pooling for PHP
We handle 50-60 million monthly page views (comments embed requests) in our commenting system using PHP/Laravel, NGINX (2 load balanced servers), Redis (for queues and caching), and MYSQL.
All performance issues we have ever encountered were always related to the database - never had an issue with PHP or Laravel.
However, we use Node.js for websockets. Though there are some improvements in PHP for event-driven development (like ReactPHP [1]), it was quite hard to find proper documentation and help to build a production-ready WebSocket server. So, we ended up using Node.js for that.
The new features added to PHP in the latest versions are great. Type hinting and return types are really helpful in writing better code. I hope there will be an addition to type hint advanced data structures (ex: Arrays of Objects) in a future version.
We handle a couple million daily users, educational online reading product used by K12 schools worldwide.
Internal framework PHP monolith, nginx, Aurora MySQL, redis, Memcache, internally developed message queue, handful of small Go microservices.
While we're largely hosted on AWS, some countries require us not to be, namely China, where are product lives on servers run by the government. We've kept are infrastructure non-AWS compatible.
For our US installation, monolith scales up to 50+ servers during the day and down to a minimum of 2 at night.
We use AWS elastic beanstalk mostly, so just auto scaling EC2 servers running nginx, RDS serverless, SQS worker queues etc. Front end is static hosted on S3/cloud front. Handles up to ~100k orders per day.
I spent a decade writing PHP. I think the language is fine, but the lack of a real concurrency model (event loop or threads) pushed me to other languages for web dev.
Aside, but I hate ligatures in code. If I didn't know what they were, I would have no idea what the blog's representation of a fat arrow => or a triple equals were. As it is, I still have to translate them before I fully get it.
I remember when I saw the access operator "->" for the firsr time written as just a single connected right pointing arrow on a whiteboard as part of my first intro to programming class and being so confused about what button I was missing on my keyboard!
I wholeheartedly agree. I don’t think I will ever understand why people want to mess with legibility in a craft that is so heavily dependent on using correct characters in correct places.
Author here, I agree. I use ligatures mostly because I write JS and it's not that annoying. Now that I wrote something about PHP it's a bit problematic.
I tried to like ligature coding fonts. I really wanted to like them. Ligatures are a really cool feature of prose fonts, and often even make text more readable. And they looked cool when I first encountered them in code. But every font I’ve tried with these ligatures added cognitive load in practice. And now I find the same when I see them in code examples.
Maybe there’s a way to do them “right”, where they have the same positive impact on code readability. But I haven’t found a font yet which pulls that off.
I’m not a font designer, so this is just using my imagination, but I suspect they’d work better if they still left some space in the monospace grid rather than fully spanning multiple characters. Eg => looks like an arrow but with a very fine gap (1px at any size? maybe 1 device pixel on high DPI at smaller sizes?) between the characters.
I think the hate for ligatures is overblown. You'll only encounter them in code, so you should instantly realize what they represent. I can understand _preferring_ to not have ligatures enabled, but hating them entirely seems unwarranted.
I mean, I don't hate them, but when I was reading this code, I came across a section that had what I presume was "===" (three equals signs) but it was three vertical lines the length of em-dashes stacked on top of one another, and this looks like absolutely nothing I can type.
And, I think that's really my objection to coding-specific ligatures. When you're used to them, you can "instantly realize what they represent," but they're rarely as clear as simply displaying the characters that you type. Historically, ligatures come from slightly tweaking the aesthetics of letter pairs or triplets to be (subjectively) more readable, never in ways that obscure the actual characters. Coding ligatures are arguably designed to obscure the actual characters being typed. That might be relatively inoffensive, like joining the characters in "=>" to make it look like an arrow, but it's not materially helpful -- and sometimes, like the Three Mystery Lines, it's actively puzzling.
It’s an opinion. About typography. I can’t understand having an opinion that another person shouldn’t have whatever opinion about typography they want.
I've probably written some version of this comment over dozen times throughout the years when discussion about PHP rears its head (note that I'm fond of PHP):
PHP as a language is... okay. It's been modernized to include many of the faculties a developer would expect of a language in 2022. But honestly, I'm ready for the "improvements" to the language to stop. The closer you get to C# or Java the more obvious it is that PHP will never catch up! It's not that it has to catch up, rather, that few people actually choose PHP because the language is so great. If you were choosing a your stack based on "which language offers us the most features or highest ability to express our problem" you wouldn't be choosing PHP!
Here's the secret: PHP is probably the best language for server side webdev because of the runtime! It's so dead simple to develop and deploy PHP. I mean the language itself is basically a web framework right? How many other languages automatically parse an HTTP request and hand it to you by default? Or offer built-in templating semantics for composing HTML? Or have request routing by default? I don't know of another one. That's why I, and many others, choose PHP!
You know what I'd like to see? The trajectory of PHP's development change to lean in to the above -- to focus development on improving the reasons why it is chosen in the first place! I don't need a C# with slightly different syntax (or named parameters). I'd like:
- Improved templating semantics
- A better module system
- A way to bake routing into each file (overwriting the default semantics)
- Adding a built-in service-locator pattern/DI
- A way to make PHP scripts more testable
What I'm saying is just make it a better framework by default. I know I know... "Laravel this, Symfony that, have you heard of Slim?". Yes... I get it. There are community-made solutions to the above problems. And you know what? They won't be as performant or integrated as if the runtime itself was upgraded to make them obsolete. It's not like routing and DI are that complicated (the two most obvious reasons frameworks are employed).
I like that I can write a simple API in PHP without pulling in a single dependency! It makes so many things easier (the right things too). Now let's just extend that to all of the basic facets a modern web framework offers!
The odds of those things being worked into php-src are very, very small. Most of the time there has been discussion on these topics on the internals mailing list, it was clear that the majority favored keeping those things in userland.
The problem with templating systems, routers, DI containers, testing frameworks, etc.. is that they are all very opinionated. There is no one way to do it, and each implementation has upsides and downsides.
On top of that, the PHP ecosystem is so mature that for each of the possible implementations of these features, there is a stable, production-ready and actively maintained library/framework. Why reinvent the wheel?
An important detail is that most of these frameworks have also built a business around their product, which means that people are being paid to work on them. How would the financial situation work if you moved all that into the core?
For me, the current situation is close to the ideal one. For example, the recent addition of fibers into the core in PHP 8.1 was a logical step to allow cooperative multi-threading. It will be used by great userland frameworks like Revolt, Amp, ReactPHP and more. The full event loop feature would be too heavy for the core.
+ Composer is so great that installing any of these packages is a breeze anyway.
I used to look down on PHP, but after being forced to use it for a while I begrudgingly came to admire it for all the reasons that you've pointed out. And I started using PHP by choice, generally for writing small scripts (no frameworks or libraries) that I could "deploy" simply by copying the .php file into /var/www. It's a very productive language when used as intended.
PHP scripts on shared webhosting was the original "serverless" and you didn't have to be too careful about object lifetimes and leaking database connections because as soon as the request was finished the entire process was nuked from orbit.
But "modern PHP" is the complete antithesis of everything that I grew to admire about PHP because it's just another Java or C# with awful syntax and weird equality rules and gigantic frameworks with thousands of classes and interfaces.
I would very much like to see a version of PHP that dropped all the nasty namespace and object-oriented misfeatures and just focused on cleaning up the language semantics and enhancing the built-in framework features...
> because of the runtime! It's so dead simple to develop and deploy PHP.
As someone who had to deploy PHP applications: hell no. For developers it might be easy, but for admins, the runtime is nowhere near good. Sure if you think deploying your site using scp, already discovered rsync to do this, or even use the cutting edge way of deploying by using a git checkout on the server, you might think it's great. But that's how you take down sites or have service interruption.
The problem is not that it cannot be done right, the problem is that the runtime enables and even promotes such bad practices, and makes doing it properly harder than it should be. And then we don't go into php extensions, performance tuning, profiling, scaling, ...
I deploy PHP applications all the time! I simply cannot share your sentiment though.
I cannot think of an easier deployment paradigm than what essentially amounts to a copy and paste in the simplest case (i.e. what we should strive for), and maybe one or two more steps in a more complex case (e.g. `composer install`).
An entire PHP installation can literally be copied and pasted onto another machine and "just work"(though you may need to fiddle with some paths in the .ini). Similarly PHP is fast enough that it's unlikely to ever be the bottleneck in terms of performance/scaling for 99% of use-cases.
I suppose I can agree that PHP may lend itself well to certain kinds of "bad practices", but that's true for any system if not managed well.
Used PHP for many years for high volume web applications. My biggest gripe is you (at least had to) run php behind another server (nginx, Apache) which meant your "scope" is always restricted to serving the current request.
If you want to do something like share some heavily read data across processes you need to then introduce memcahe/redis in to your stack, whereas in something like Go this can be done in your application code. This also means PHP is a nightmare for connection management to others resources like your database - if you autoscale your API you are in a very vulnerable place for maxing out connections on your database as every client request needs to create it's own. You can solve this with something like Envoy I think, but again it's adding more complexity to your stack, more tools to configure and deploy.
This was my main issue with PHP. I found the language itself fine to be honest. Not the most elegant but hardly as bad as people make out.
Next time you need to take a look at PHP, those two problems can be solved by php-apcu for caching and proxysql running side-by-side with php-fpm on each server.
I see comments like this an it always confuses me. AFAIK pooling or proxying a DB is actually worse for concurrent performance, because as soon as you hit the connection limit threads start waiting. It almost always makes sense to increase your DB capacity, or move hot data to a cache.
Latency just connecting to PostgreSQL (in my case) sucks anyway, so I end up having a connection pooler between PHP and the database in production just for the latency's sake, even if I don't care about scaling.
The only thing stopping me from using PHP is just I’ve been burned in the past by massive breaking changes going up in major and even minor versions. Granted they are major releases, but the amount of work to bring existing code up to “code” is a gargantuan amount of work. I’ve dealt with similar issues in Ruby as well as Rails, but it wasn’t too hard to fix and even older syntax is happily accepted without deprecation messages. With PHP, I’ve had to cleanup very verbose code (often from older open-source packages or software) and spent hours and hours cleaning up breaking changes.
Not sure how long ago you used PHP, but backwards compatability has in my opinion been excellent for at least 15 years. A ~500k LOC PHP project has basically been effortless to keep up to date with the latest versions. From what I can remember I've only done search and replace a couple of times in that period.
Well, code I wrote in 2006 still runs in production today, with very minor changes. I can't really be happier about backwards compatibility story. :)
I guess I started writing PHP when PHP 5 was already a thing, didn't depend on any third party code, and used PDO from the start, so... I guess I was lucky to pick the right abstractions.
The PHP 4->5 migration was harsh (but that was 2008 if I am not mistaken, the big 4.4 deadline was on 2008-08-08 and I've not heard anyone curse since then.
The backwards compatibility story has been much better lately in php, including across major versions. There were some bad practices with previous versions that had to be cleaned up, unfortunately.
$ php -a
php > echo $foo;
Notice: Undefined variable: foo in php shell code on line 1
> This is only a notice error, and PHP will happily carry on. This can be confusing for those coming from “exception-heavy” languages, because referencing a missing variable in Python for example will throw an exception:
> The only real difference is that Python will freak out over any small thing, so that developers can be super sure any potential issue or edge-case is caught, whereas PHP will keep on processing unless something extreme happens, at which point it will throw an error and report it.
This is the kind of mentality that scares me about PHP. The author is saying that an undefined variable is just a small thing, nothing to be worried about and the correct behavior is not to "freak out" about it and just carry on. And only stop if something "extreme" happens.
Am I crazy to think that this is crazy? I can't think of a case where continuing with program execution after referencing an undefined variable is a good thing. Trying to use an undefined variable is a bug, a potentially very serious one, so I prefer my language to stop me from writing this bug, not just "note" it.
I thought about not responding to avert judgement, but how is this not ok for 99% of all websites? Where an "undefined variable" is very much a "small thing"?
I mean, we have ways to catch those errors, its just that when they do appear in prod its usually because the project is so low impact (99%) that the budget for testing and whatnot is nonexistant (and the reasons for that vary from project to project, of course).
My experience suggests that, were this error to appear in a more complex component (say a shopping cart or notification system) these "non-entirely static-content-based" parts usually are either separate projects or have their own adequately-sized test code.
"But this is not a website, its a complex web app" - then PHP was probably not the most sound technical choice from the start.
"But this teaches bad practices" - practices are always evolving, new languages appear from time to time. I'd rather work on fixing real world problems.
"But PHP is old!" - so is Java... besides, another name for "old technology" is "stable tecnology".
In short, it is best if there are no errors in your code (haha yeah right..). If there are any, and its a website written in PHP acessing an undefined variable, it is probably a small thing. And if its critical that it does not happen, its usually an engineering blunder. Not the language's fault.
Every time a PHP post makes it to the HN frontpage, there's a ton of people saying how easy it is to pick up, build a project on, and deploy. I sometimes wondered "hm, maybe I was wrong about it, I might try it out". I had no idea it had skeletons like this hidden in the closet.
One day I hope PHP will come up with a more user friendly template literal system. I love the javascript template literal system since single quotes and double quotes are all fine, and you can add variables, ternaries, and even functions inside of your template literal.
With PHP there's no one great way to write templates, there's all just kinda clunky ways (e.g. heredoc or using double quote strings with variables inside).
Readit News
I think WordPress is pushing other projects forward as well. The tech stack over there doesn’t move nearly as fast, but the UX is still pretty good out of the box and with the enterprise clients I work with on a daily basis, they all still love WP.
Back to PHP proper for a minute, the language is fast. There are efforts being made to run PHP on Serverless infrastructure or with continuous process environments. New features are added to the language on a regular basis as evidenced by this post and others. The defacto package manager, Composer, is also world class.
It’s a good time to be a PHP dev!
As a final point, I’ll throw out some of my worries. I’ve been writing PHP since 2010~ as a high schooler fooling around.
The “Java-fication” of PHP is real. There is a push for more types and type related features. These aren’t bad in isolation, but as they move deeper into the core of the language, there is a risk of breaking legacy apps. Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. I’m not advocating keeping 100% compatibility forever, but recent versions have played more fast and loose with breaking changes. We’ve done a decent job of carrying the entire community onto new versions and that will be important for continued adoption.
Take a look at the open RFCs for more details. I think there is value for pulling good ideas from other languages, but we don’t need every idea from every language.
Here’s to another 20 years of PHP!
If anything, it's holding PHP back. I don't often work with WordPress projects, but when I have to, it makes me want to cry with how backwards they are. WordPress doesn't even have a real routing system!
Furthermore, its ecosystem just seems to encourage really, really bad things, like user-editable templates, PHP code "snippets" stored in the database, images which should be in themes stored as post attachments instead, and just general lack of respect for the idea of separating code and content. Almost every "plug-in" or template is crippled and begging for license fees and/or throwing spammy "notifications" all over the admin interface. I know this sort of stuff are more culture issues than code ones, but they're still problems, and ones you only really see happening in WordPress sites.
I get angry when a client comes to me with a bundle of WordPress mess and asks me to fix or improve something. It's shameful and disrespectful to take a client's money and give them a WordPress site in return. Do these people actually not realize there's far better things out there?
If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that?
I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time. It's better to have 10 code snippets to achieve 10 fixes, than 10 plugins to address those same fixes.
There must be a lot of developers out there paying their rent and feeding the cat from Wordpress plugin subscription earnings. While this does encourage the spammy ecosystem, it also encourages competition between plugin authors to maintain and develop quality plugins that do the job.
> Do these people actually not realize there's far better things out there?
I'd be interested to hear what good replacements there are for Wordpress+WooCommerce? I find WooCommerce slows down Wordpress, regardless of caching plugins and other tricks. It's annoying, and I'm genuinely interested in alternatives with as much flexibility and support?
What are your credentials with non-PHP, non-JS/TS languages? Have you written some Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those languages are different to some extend, they take fresh approaches, they contain new ideas and are scrape throat well designed.
I find most cheering for PHP and JS have very little exposure to other camps of software development.
> PHP is probably the best language for server side webdev today.
I'm telling you (opinion ahead), it most likely is not. And most likely will never be. It simply has too many fundamental design errors that have long known solutions, are near impossible to fix in PHP/JS and are fixed-by-design in other languages that also have good tooling for web-dev.
This is not just PHP/JS. But since we are looking at "the best lang for webdev" I limit myself the these and this use case.
I understand you have invested time in other languages, we all have but lets focus on facts not fears of your choice of language seeming less popular.
> Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure?
OCaml is an excellent language depending on what you are intending to do. I can't imagine though that it would be a pleasant generic server side.
From a very quick search, it looks like to even connect to Postgres you'd have to manage yourself the connection pools ? https://medium.com/@bobbypriambodo/interfacing-ocaml-and-pos...
The same would apply to most languages on your list, except perhaps Clojure who has an excellent ecosystem thanks to the JVM. But then, is Clojure a good webdev language ? maybe ? I only toyed with it for a very short time, but I don't see it on par with PHP or ruby for instance.
Ocaml? Elm? Clojure? Haskell?. That's fun for side projects, not for real business.
I love Clojure, it’s so well designed. Haskell is hard to beat in terms of academic type correctness. But what if I’m trying to build a web app and my priorities were, ease of hiring and productivity, especially for junior devs, and a big ecosystem. Does Clojure win here against PHP? That’s a much harder argument to make. Would anyone say Rust is a better web development language than PHP?
All these tools have trade-offs. PHP is a fantastic choice for web development, the rough edges are becoming increasingly minimal with each successive version.
Nah, I like to get shit done and make buckets of money.
Composer suddenly got good, didn't it! Composer 1.x was one of my pain points I think.
I can't think of many things that really bug me much anymore.
Null coalescing operators and named parameters are the kinds of things that make me happy.
I also adore Laravel (and particularly Lighthouse).
But what I really like about PHP is the humility and maturity of the whole endeavour. It's really typified by Rasmus Lerdorf who openly critiques his own abilities and seeks out smart people.
This attitude of “what is the best” promotes cargo culting and should stop.
The terse certainty in your response is ironic, is it not?
Considering the parent post frames that as opinion with the word "probably" and then makes a case for the opinion.
This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.
Yes, but now you have to pay for every requests made to your app instead of just paying $4 a month for a shared Apache server and I also have to architecture my PHP app in a rigid way to fit whatever "serverless" execution model the SAAS runs with.
Deleted Comment
This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.
After some arguing with the company that is payed to manage their IT environment she got them to finally update the php version and now the server is running 8.1.
I was glad that at least wp was up to date. Current wp running on quite old php version and exactly nothing broke with the update.
I was positively surprised. Would have expected more problems from my experience with other projects in other languages.
https://techblog.wikimedia.org/2020/10/26/impact-of-using-ht...
TLDR they used envoy proxy as a sidecar container. So to your point its a pain but still achievable
All performance issues we have ever encountered were always related to the database - never had an issue with PHP or Laravel.
However, we use Node.js for websockets. Though there are some improvements in PHP for event-driven development (like ReactPHP [1]), it was quite hard to find proper documentation and help to build a production-ready WebSocket server. So, we ended up using Node.js for that.
The new features added to PHP in the latest versions are great. Type hinting and return types are really helpful in writing better code. I hope there will be an addition to type hint advanced data structures (ex: Arrays of Objects) in a future version.
[1] https://reactphp.org/
Internal framework PHP monolith, nginx, Aurora MySQL, redis, Memcache, internally developed message queue, handful of small Go microservices.
While we're largely hosted on AWS, some countries require us not to be, namely China, where are product lives on servers run by the government. We've kept are infrastructure non-AWS compatible.
For our US installation, monolith scales up to 50+ servers during the day and down to a minimum of 2 at night.
- Laravel
- Redis
- PostgreSQL
- Nginx+ php_fpm
Deleted Comment
Dead Comment
Maybe there’s a way to do them “right”, where they have the same positive impact on code readability. But I haven’t found a font yet which pulls that off.
I’m not a font designer, so this is just using my imagination, but I suspect they’d work better if they still left some space in the monospace grid rather than fully spanning multiple characters. Eg => looks like an arrow but with a very fine gap (1px at any size? maybe 1 device pixel on high DPI at smaller sizes?) between the characters.
And, I think that's really my objection to coding-specific ligatures. When you're used to them, you can "instantly realize what they represent," but they're rarely as clear as simply displaying the characters that you type. Historically, ligatures come from slightly tweaking the aesthetics of letter pairs or triplets to be (subjectively) more readable, never in ways that obscure the actual characters. Coding ligatures are arguably designed to obscure the actual characters being typed. That might be relatively inoffensive, like joining the characters in "=>" to make it look like an arrow, but it's not materially helpful -- and sometimes, like the Three Mystery Lines, it's actively puzzling.
Often doesn't work in practice. I cannot instantly distinguish
• ‖ from ligated ||
• … from ligated ...
• ⁂ from ligated ***
• ⁇ from ligated ??
• → from ligated ->
• ↜ from ligated <~
• ↠ from ligated ->>
• ⇒ from ligated =>
• ⇔ from ligated <=>
• ⇜ from ligated <~~
• ∨ from ligated \/
• ∷ from ligated ::
• ≔ from ligated :=
• ≠ from ligated !=
• ≤ from ligated <=
• ≪ from ligated <<
• ⊢ from ligated |-
• ⋄ from ligated <>
• ⋘ from ligated <<<
• ◁ from ligated <|
• ⩵ from ligated ==
• × from ligated x with hex digits following
& al., but I have to examine the characters in kcharselect, a REPL or similar.
PHP as a language is... okay. It's been modernized to include many of the faculties a developer would expect of a language in 2022. But honestly, I'm ready for the "improvements" to the language to stop. The closer you get to C# or Java the more obvious it is that PHP will never catch up! It's not that it has to catch up, rather, that few people actually choose PHP because the language is so great. If you were choosing a your stack based on "which language offers us the most features or highest ability to express our problem" you wouldn't be choosing PHP!
Here's the secret: PHP is probably the best language for server side webdev because of the runtime! It's so dead simple to develop and deploy PHP. I mean the language itself is basically a web framework right? How many other languages automatically parse an HTTP request and hand it to you by default? Or offer built-in templating semantics for composing HTML? Or have request routing by default? I don't know of another one. That's why I, and many others, choose PHP!
You know what I'd like to see? The trajectory of PHP's development change to lean in to the above -- to focus development on improving the reasons why it is chosen in the first place! I don't need a C# with slightly different syntax (or named parameters). I'd like:
- Improved templating semantics
- A better module system
- A way to bake routing into each file (overwriting the default semantics)
- Adding a built-in service-locator pattern/DI
- A way to make PHP scripts more testable
What I'm saying is just make it a better framework by default. I know I know... "Laravel this, Symfony that, have you heard of Slim?". Yes... I get it. There are community-made solutions to the above problems. And you know what? They won't be as performant or integrated as if the runtime itself was upgraded to make them obsolete. It's not like routing and DI are that complicated (the two most obvious reasons frameworks are employed).
I like that I can write a simple API in PHP without pulling in a single dependency! It makes so many things easier (the right things too). Now let's just extend that to all of the basic facets a modern web framework offers!
The problem with templating systems, routers, DI containers, testing frameworks, etc.. is that they are all very opinionated. There is no one way to do it, and each implementation has upsides and downsides.
On top of that, the PHP ecosystem is so mature that for each of the possible implementations of these features, there is a stable, production-ready and actively maintained library/framework. Why reinvent the wheel?
An important detail is that most of these frameworks have also built a business around their product, which means that people are being paid to work on them. How would the financial situation work if you moved all that into the core?
For me, the current situation is close to the ideal one. For example, the recent addition of fibers into the core in PHP 8.1 was a logical step to allow cooperative multi-threading. It will be used by great userland frameworks like Revolt, Amp, ReactPHP and more. The full event loop feature would be too heavy for the core.
+ Composer is so great that installing any of these packages is a breeze anyway.
PHP scripts on shared webhosting was the original "serverless" and you didn't have to be too careful about object lifetimes and leaking database connections because as soon as the request was finished the entire process was nuked from orbit.
But "modern PHP" is the complete antithesis of everything that I grew to admire about PHP because it's just another Java or C# with awful syntax and weird equality rules and gigantic frameworks with thousands of classes and interfaces.
I would very much like to see a version of PHP that dropped all the nasty namespace and object-oriented misfeatures and just focused on cleaning up the language semantics and enhancing the built-in framework features...
As someone who had to deploy PHP applications: hell no. For developers it might be easy, but for admins, the runtime is nowhere near good. Sure if you think deploying your site using scp, already discovered rsync to do this, or even use the cutting edge way of deploying by using a git checkout on the server, you might think it's great. But that's how you take down sites or have service interruption.
The problem is not that it cannot be done right, the problem is that the runtime enables and even promotes such bad practices, and makes doing it properly harder than it should be. And then we don't go into php extensions, performance tuning, profiling, scaling, ...
I cannot think of an easier deployment paradigm than what essentially amounts to a copy and paste in the simplest case (i.e. what we should strive for), and maybe one or two more steps in a more complex case (e.g. `composer install`).
An entire PHP installation can literally be copied and pasted onto another machine and "just work"(though you may need to fiddle with some paths in the .ini). Similarly PHP is fast enough that it's unlikely to ever be the bottleneck in terms of performance/scaling for 99% of use-cases.
I suppose I can agree that PHP may lend itself well to certain kinds of "bad practices", but that's true for any system if not managed well.
If you want to do something like share some heavily read data across processes you need to then introduce memcahe/redis in to your stack, whereas in something like Go this can be done in your application code. This also means PHP is a nightmare for connection management to others resources like your database - if you autoscale your API you are in a very vulnerable place for maxing out connections on your database as every client request needs to create it's own. You can solve this with something like Envoy I think, but again it's adding more complexity to your stack, more tools to configure and deploy.
This was my main issue with PHP. I found the language itself fine to be honest. Not the most elegant but hardly as bad as people make out.
And that solves both issues at once.
[1] https://openswoole.com/
I guess I started writing PHP when PHP 5 was already a thing, didn't depend on any third party code, and used PDO from the start, so... I guess I was lucky to pick the right abstractions.
> The only real difference is that Python will freak out over any small thing, so that developers can be super sure any potential issue or edge-case is caught, whereas PHP will keep on processing unless something extreme happens, at which point it will throw an error and report it.
This is the kind of mentality that scares me about PHP. The author is saying that an undefined variable is just a small thing, nothing to be worried about and the correct behavior is not to "freak out" about it and just carry on. And only stop if something "extreme" happens.
Am I crazy to think that this is crazy? I can't think of a case where continuing with program execution after referencing an undefined variable is a good thing. Trying to use an undefined variable is a bug, a potentially very serious one, so I prefer my language to stop me from writing this bug, not just "note" it.
I mean, we have ways to catch those errors, its just that when they do appear in prod its usually because the project is so low impact (99%) that the budget for testing and whatnot is nonexistant (and the reasons for that vary from project to project, of course).
My experience suggests that, were this error to appear in a more complex component (say a shopping cart or notification system) these "non-entirely static-content-based" parts usually are either separate projects or have their own adequately-sized test code.
"But this is not a website, its a complex web app" - then PHP was probably not the most sound technical choice from the start.
"But this teaches bad practices" - practices are always evolving, new languages appear from time to time. I'd rather work on fixing real world problems.
"But PHP is old!" - so is Java... besides, another name for "old technology" is "stable tecnology".
In short, it is best if there are no errors in your code (haha yeah right..). If there are any, and its a website written in PHP acessing an undefined variable, it is probably a small thing. And if its critical that it does not happen, its usually an engineering blunder. Not the language's fault.
In particular, this exact case you're talking about is being voted on right now, to promote it to an error instead in PHP 9.0: https://wiki.php.net/rfc/undefined_variable_error_promotion
It's looking like the vote will pass (as of writing, 33 to 8 ~= 80%, and 67% is needed).
https://github.com/laravel/framework/blob/master/src/Illumin...
For other frameworks, you can convert warnings into exceptions with 3 lines by implementing a custom error handler.
Every time a PHP post makes it to the HN frontpage, there's a ton of people saying how easy it is to pick up, build a project on, and deploy. I sometimes wondered "hm, maybe I was wrong about it, I might try it out". I had no idea it had skeletons like this hidden in the closet.
With PHP there's no one great way to write templates, there's all just kinda clunky ways (e.g. heredoc or using double quote strings with variables inside).