Hacker News new | past | comments | ask | show | jobs | submit login

Before you call me a troll, know that I worked with PHP for two+ years maintaining both legacy codebases and writing new code with Laravel.

My question is: why would anyone want to start something new with PHP in 2021? Is there anything that it does better than any other language/ecosystem? I feel like the community is full of (but not exclusively composed of—there are some gems like Caleb Porzio who write good stuff) people who just care about hacking something together and, as long as it works, it's fine. They care nothing about elegance and have but a dim conception of larger CS/SE principles.

For example, why would you write something in PHP when you've got an excellent choice between Ruby/Rails or Elixir/Phoenix/LiveView, both of which are fantastic, and, especially in the case of the Elixir/Phoenix stack, really developer friendly, easy to set up and deploy, etc. and also have solid foundations?

I'm glad to see PHP getting better—it will certainly improve life for those maintaining old PHP projects that are agile enough to upgrade—but I really see no reason to not choose a better tool in this day and age.

(You may now call me a troll if you see fit. I stand by what I said though. :-)




Look at the abject failure of Discourse. If it had been written in PHP then it would have completely replaced all current forum software. But the devs there hate PHP and went for a modern stack which is all but impossible to install except for tech professionals.

In other words, they chose a tech stack which suited them as developers, and not which suited the end users of the software.

End users love PHP because you copy the files into a folder. That's why it's so popular. That fact that you are talking about architectural "elegance" shows how removed you are from understanding the needs of the end user.


>End users love PHP because you copy the files into a folder. That's why it's so popular.

As a person involved with a PHP + MySQL open source CMS, this is the pull quote for me.

The vast majority of web hosting I've experienced in the last 20 years offers PHP + MySQL out of the box, even on the crummy, ancient end of the spectrum.

Related to this, knowing that just about any flavour of hosting can run the CMS in real terms is enough to keep the development in check so a wider audience can use it. There's not much point in us adding extra features if the minimum ride height is beyond the reach of most users.


Exactly. I run a lot of services on a lot of servers for 10+ years now. Only the non-PHP projects (postal, zammad, otrs, elasticsearch, graylog from the top of my head) are hard to maintain and/or to install. And most of them need much, much more hardware to run, than any PHP software I installed. For example my zabbix installation with billions of records needs much less CPU and RAM than my zammad installation with a few thousand tickets. PHP is an ugly language and I refuse to work without a fine-tuned phpstorm installation. But on the server side PHP is just working fine under all conditions.


You mean simply running Discourse (a Rails app) is so complicated no one wants to do it? And if it was simply PHP boom business would have been booming ? I find that a bit hard to believe.


Deploying a Rails apps is, in general, harder than deploying a PHP app.

I'm not convinced that Discourse is the right example here, though. Arguably the actual steps for installing Discourse aren't significantly more complicated than WordPress's install, because they've gone out of their way to make it as easy as possible. (It does suffer from "you must use Docker for this," which would likely intimidate non-techies who could otherwise suffer through a WP install, though.) Also, I don't think Discourse can remotely be described as an abject failure, given that virtually every forum I've seen go up in the last five or six years runs on it, and I can think of more than a few sites that migrated to it from legacy PHP forums in that time.


> Also, I don't think Discourse can remotely be described as an abject failure, given that virtually every forum I've seen go up in the last five or six years runs on it

Two thoughts and personal observations on that:

1. Nobody was ever fired for buying IBM. In my impression it's usually deployed as default for and esp. by very tech affine communities. It was the new, hot - and is now save - thing in town.

2. You see postings boasting how the Discourse forum is now powered by a new six core 8 GB RAM server improving performance ... for 200 concurrent active users and 80k posts. Yes, Discourse offers a lot of flashy features, but that's just borderline disgusting.


> how the Discourse forum is now powered by a new six core 8 GB RAM server improving performance ... for 200 concurrent active users and 80k posts.

I guess companies that use Discourse and have huge traffic can pay a bit more, nothing wrong with that.


> I guess companies that use Discourse and have huge traffic can pay a bit more, nothing wrong with that.

The point being that said numbers aren't big traffic, they should be handled by a Raspi.

But for the sake of argument: Discourse is a painless move upwards for big budget and/or big knowledge entities. Nothing wrong with that.

On the other hand Discourse isn't a replacement for low cost, decentralized, easy to deploy, engine-diverse, low knowledge communities which were served by a multitude of PHP solutions in the past.

There's an economic argument for a growing divide between "communities as a service" ala Facebook and high hurdle deployments ala Discourse, but one doesn't have to be happy about this development.


So not sure I'm following, the php solution can handle huge traffic at a low cost with a conmparable feature set? How do they achieve that then? Taking a look at phpBB it looks like they are not using a framework (e.g https://github.com/phpbb/phpbb/blob/master/phpBB/posting.php). This is good for performance but pretty shitty for an OSS proeject, anyone looking to contribute here needs to start from scratch. Discourse happens to have 4x as many contributors. Also I can't imagine the feature set of the 2 projects is even remotely similar.


To be more fair, the PHP forums tend to be much older codebases, before standout frameworks and index.php front controllers.

Much like Wordpress and phpMyAdmin, these projects are basically victims of their own success.


> This is good for performance but pretty shitty for an OSS proeject

I don't see how. The repository seems to be quite active and has plenty of current pull requests.


The fact that there's no framework, you basically start learning the new codebase from scratch. With Rails I have a good chance of fixing a bug just by knowing the structure.


Well, an entirely non-profit -- at this point, in fact, unincorporated, with no assets to speak of at all -- writing group that I'm part of migrated their forum in 2019 from a PHP forum package (I think SMF, although I wouldn't swear to that) to Discourse, and it runs just fine on what I'm fairly sure is a $10/month Digital Ocean droplet.

I don't doubt that Discourse requires more resources than most PHP forum packages do, but it doesn't need that much more.


What's harder about deploying a Rails app? Generally interested. How does it go in Laravel land then? Rails have quite a few dependencis (Node, webpack), how is Laravel handling front end?


I'll preface this by saying I'm probably getting a little ahead of my skis. :) But, I think the issue is less how modern PHP is handling all those modern dependencies and more how "old" PHP didn't make you, the person installing the application, have to know anything about them. Those old-style apps, which include WordPress and many forum software packages, get "deployed" by

1. Downloading the application archive and uncompressing it

2. Creating a MySQL database according to the documentation

3. Either editing a small config file to give the application the database credentials, or even just going to the application's index page and filling in the details on a first run experience

And... that's it. Rails has no comparable experience, unless -- like Discourse -- you put in a lot of work to get it there.

Laravel -- and Symfony -- work basically like other "modern" frameworks do, for both good and bad. Laravel has "Mix," built on webpack, for instance. So if you're looking for that in PHP, it's there, but that's kind of a tradeoff in the context of small sites deployed/managed by a single person -- a use case that I think modern webdevs sometimes lose sight of. If we go back to the example of forums, those are very often that "one person wants to host a forum for their community" kinds of things. (And I'd like to see more of us get back to self-hosted blogs -- which is part of what led me down the road of "can you write something in a not-PHP language that's still easy for someone who doesn't know anything about web development to deploy and run." The answer still seems to be "reply hazy; ask again later.")


Developers underestimate how difficult it can be to deploy server-side code for web apps or dynamic websites, particularly for less-technically minded users.

As other posters have mentioned, PHP code can be as simple as uploading files to a folder on a server using a GUI FTP app. (And for some non-technical users, even that might be too complicated).

By the way, Jeff Attwood (co-founder of Stack Overflow and one of the founders of Discourse), had this to say about PHP:

"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option." [1]

When did he say this? 2012.

It's now 2021 and has anything changed? Not really. Yes, we have Docker, Cloudtron, or Sandstorm etc but none of these are simple or easy to install or use. (A developer's definition of 'simple' and 'easy' bears no relation to the real definitions of these words).

Whatever you think of PHP, consider the following question: what language can match or beat PHP for ease of server-side deployment?

[1] https://blog.codinghorror.com/the-php-singularity/


But almost no one writes php alone. Maybe hobbyists or Wordpress users. When we talk about actual applications that talk to a db - people use frameworks. Is deploying a Laravel app so much cheaper or different than a Rails app? Yes if all you need a wordpress website PHP is obviously the way to go. If you're an app developer PHP loses this edge quite quickly. Also I'm not sure an ftp setup is easier than Heroku.


You "CAN" upload laravel to bluehost or any shared host and it will work, you may need to cut a few bits, or use external services for redis/sqs/etc if you want to use those things, or you could just use file/database for sessions/caching/etc.

I mean I started laravel on shared hosting, why did I use laravel for most of my career? Because the job I was hired for was to build a custom CRM for a book business, I was learning Rails so I spent 2 weeks on a rails prototype...

Boss gave me access to their hostgator account - shared hosting and told me to install it there. I stared blankly at them, um... okay.

Rails version I built in didn't match and I couldn't figure out for the life of me how to make it work...

Laravel 4.2 was almost a complete 1:1 match (in terms of directory structure) to rails and the language was just a bit different so porting what I had to laravel was a cinch and I had it done in 3 days and up on hostgator. No problems.

Also if you're like me and you freelance/consult, there's a TON more business in existing software/legacy than there is in new builds. Wordpress, Shopify, Laravel, Drupal, Magento, Salesforce are probably the FAANG of freelance platforms to learn to earn income from.

PHP is also generally faster than Ruby, and with Swoole it's sooo much faster (even than elixir/phoenix), so really why not use laravel/php. There's also tons of great packages out there and tutorials. The community is freaking HUGE.

Rails you even have to roll your own auth system or use devise which is a PITA. Laravel it's more opinionated but it's built for you including 2fa, social/oauth, etc..

Which isn't to say I wouldn't use fancier langs, I'm jumping at the bit to build some backend apis in rust or go for the hell of it, but only when I'm the decision maker as CEO/CTO on a side-project. For bread and butter I'll stick w/ what I know I can get paid for which is PHP/Laravel/Wordpress/Vue/Livewire/etc.


Shopify is Ruby based btw... But I'm not taking anything from PHP, it's a sound career choice with lots of big platforms (Wordpress/Magento). Just not sure I understand the deployment story. Deploying Laravel should be as easy or hard as deploying Rails.


Shopify is hosted.


> But almost no one writes php alone. Maybe hobbyists or Wordpress users.

What about that one guy who made https://remoteok.io/ using a single PHP file with no frameworks or libraries?

According to this live chart https://remoteok.io/open he made $88,000 last month from it alone with a 90%+ profit margin.

But more importantly it's a site that technically functions well and looks appealing. End users really don't care about which tech stack you used to build your site, they just want it to be fast, look nice and be easy to use which is achievable with pretty much any language or framework nowadays.


I don't know what this proves. Most people who talk to a db and grow their app will go for a framework, are you disputing that fact?


It 'proves' that a lot of people, yours truly included, do not use frameworks


As a front-end developer I can agree with that.

Many times when I've wanted to install something for my needs, like forum engine or something similar, I was looking only for an PHP option.

Why?

Because it really is a copy-paste process with typing credentials to your database into dedicated file. No need to know any language/framework-specific commands, and no need to be overwhelmed by missing dependencies.

And in huge addition to that, simple PHP hosting is extremely cheap - for years I've been paying for my personal server ~$20 PER YEAR, where servers that enables you to use Node/Ruby etc. costs around at least $10 per month. This is a huge game changer for me.


Discourse is a pretty complicated piece of software (relatively). They do: mailing list, discussion forum, long-form chat room, This isn't gonna be some static blog, it's feature heavy. It needs redis, it needs some real-time chat capabilities etc etc. Also the choice to use a framework (Rails in this instance) was sound since it's complicated. So when comparing deployments you need to compare it to the php equivalent (Laravel). I think deployment and memory footprint are gonna be quite similar then.


So is facebook, and they wrote a lot of PHP for their first decade.


Have you tried installing Discourse? It's not that straightforward. And then there's also the issue that you need a working e-mail setup, even if you only want to set up a local test environment.


And how would php solve the e-mail setup issue? I'm not saying it's straightfoward and I don't know Discourse at all. If they have dependencies like redis etc then yes it's gonna be more complicated. Just don't think a framework like Laravel would have been easier.


Obviously if the project requires working emails, PHP cannot solve it. If I understand the parent comment correctly, what it says is that sending mails with PHP is usually less problematic than other languages (IIRC from the last time that I used PHP -several years ago- their mail() function works OOTB almost everywhere, even on shared hosting, and is usually used by default or as a fallback).


End users love PHP because you copy the files into a folder.

That's certainly how people deployed web apps built by other people a decade ago, but these days isn't it more common to use something like Docker?

Deploying a containerized app should be pretty much the same no matter what language it's written in. And Discourse does have a Docker container (https://github.com/discourse/discourse_docker), so I'm not sure the underlying language explains why it isn't popular.


Non technical people won't use Docker, it's too complicated. Unless you make some environment as easy and widespread as your typical CPANEL shared hosting, you won't compete with PHP for that kind of end-user.


But isn't all cloud offerings basically a better cpanel with docker or kube or whatever?

Don't get me wrong, as a developer I hate the bloat, but as a UX/UI PoV you can install a lot of shit that's dockerized pretty easily...

sandstorm.io is a cool way to self-host open source projects for example


Can I download your non-PHP app, copy and paste into a folder, and get it running after 5 clicks? More important, are the majority of apps of non PHP langs like this?

Most PHP apps out there are dump easy to use. That's not the case even for Python.


The absolute minimum amount of knowledge needed for this sort of thing is how to get files onto a server. Lots of people capable of that have absolutely no idea what Docker is or how it works. Lots of people know what it is, and what it does, but have not ever actually used it (like me!). If I was going to install some server software, and saw Docker, it would put me off — great, I have to learn Docker now?

Docker probably is a better way of doing things, but it’s another layer.


I don't use shared hosting anymore (vultr or do mostly now), but I also don't generally use docker...

There's limitations and bloat involved with containers that I don't like. I'd rather just configure nginx/letsencrypt and create some bash scripts to make deployments work...

I'll often pair this with jenkins or come ci or use deployer for deployments that don't tear down the old until the new is green, and keeps a few snapshots, but personally I don't like docker much, even my dev environment uses nginx and no docker.


The "copy into a folder" is true because PHP is usually configured within HTTPd, but it's also true for any other script that is configured to be loaded on demand (CGI, Python). But you still need to manage a server unless the server is manager for you. However, shared hosting used to offer HTTPd+PHP only. With other languages usually you have to manage the server cycle by yourself, that's why it's not easy as copy-paste.


I would avoid PHP and Ruby just the same, but for very different reasons.

Anyway regarding deploying, these days Go is available. It's probably the easiest one to deploy, just copy the binary to the server.


There are many reasons to use PHP:

- you have already a dev team that are good PHP developers, it is stupid to switch to Python or Ruby , you lose their experience and any chance of reusing existing PHp code you have. The dev team probably knows JS so node might be an option.

- maybe you want to build something super simple, like some third party needs to send you a notification event and you want to record that event with other third party API. You can do this with one PHP file , one a super cheap hosting , with code that is simple and clear.

IMO all the dynamic backed languages are at the same level, so if you are experienced in PHP environment there is not enough compelling reason to erase this advantage to start from scratch with Python, Ruby or node.


> You can do this with one PHP file , one a super cheap hosting , with code that is simple and clear.

This. PHP is basically Functions-as-a-Service over commoditized virtual hosting. Maybe we need a toolchain that can transpile down to PHP, starting from more common languages with better development workflow.


> with better development workflow

What languages have better development workflow? I'm myself biased towards repl-driven development with Clojure, but for example Rust's or Go's development workflow is a lot worse than PHP.

PHP: write file to disk, reload webpage/run curl

Rust/Go: write file to disk, compile file, run binary, reload webpage/run curl

The popularity of PHP is not hard to understand when it comes to ease of development.


honestly, that argument died when Hot Reload became a thing ... something like 10 years ago? you dont reload pages, they automagically reload whenever you either save or the compilation finished.

unless you want to check your pure JSON api itself... but why arent you writing a test making sure of your behaviour there? its literally both less effort and assures you of the correct behaviour in the future as well.


>> Go's development workflow is a lot worse than PHP.

I beg to differ.

- Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.

- You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.

- Different servers (apache, nginx, etc) give you yet another thing to configure.

From my very old past experience, PHP development gives you more headaches than Go.


> - Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.

Seems you just know more Go than PHP, which is fine of course. No language has "more runtime errors" than other languages, just developers of varying skill-levels in that particular platform

> - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.

And you don't get errors when assets you use in your Go program is missing? Only difference is that PHP compiles when you hit the webpage, instead of a separate step, so you'll get the error when trying to load the page, not when running "go build".

> - Different servers (apache, nginx, etc) give you yet another thing to configure.

Just like in Go, you don't have to use a separate server in order to develop. Just fire up the PHP development server that PHP ships with.


> Seems you just know more Go than PHP, which is fine of course. No language has "more runtime errors" than other languages, just developers of varying skill-levels in that particular platform

A type system reduces the risk of runtime errors, because it doesn't let you write code with undefined behaviour such as indexing a null. Depending on the implementation, it can even force you to handle all possible failures explicitly so that execution always completes. With languages such as rust or Haskell it's feasible to write complex code with almost complete confidence it won't hit any runtime errors, excluding resource exhaustion or machine failure of course.

On the other hand you could argue that logic errors depend on the skill of the programmer and not the language.


Right now, PHP is only missing typed local variables. Class fields are typed, function arguments are typed, function returns are typed. And local variables can be typed for static analysis purposes with `/* @var $str string */` annotation.

I'd add generics to that list, but Go doesn't have them either, so not really a point for discussion.


FYI you can get a lot of this checks in PHP too if you annotate your code. It is built in in the IDEs too so there is no extra work for you. Sure you can make errors but I do it for productivity reasons, I can perform refactoring like "Rename", "Find Usage" in PHP exactly as in Java, it is much pleasant then the situation on front end.


> - Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.

With type hints you can eliminate a lot of runtime errors these days.

> - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.

When using Composer, specify the extensions and the PHP language level you need in "composer.json", and it will barf during deployment at the composer install stage.

The only thing Composer can't check is configuration parameters (e.g. max execution time, memory limit).

> - Different servers (apache, nginx, etc) give you yet another thing to configure.

Not much anymore, at least Debian and Ubuntu integrate all three major web servers (apache, nginx, lighttpd) pretty much out of the box.


Me personally if I would be asked something like "we can;t use PHP starting from tomorrow for our backend crap, what should we use?"

I would say node or if we need to use a static language would be Java. And the choice is not about the language but about the entire ecosystem(libraries, tools, developers, documentation)

Using type hints and a good IDE there are not many type related issue slipping in the code.


You can also do it in one golang file. Or one python file. Or one nodejs file.

With PHP you have more moving parts, Apache/Nginx with their configuration and then the PHP script. With golang/rust/python/nodejs you have direct access to the webserver and more control, but the same simplicity.


>With PHP you have more moving parts, Apache/Nginx with their configuration and then the PHP script. With golang/rust/python/nodejs you have direct access to the webserver and more control, but the same simplicity.

From my limited node experience I had to setup Nginx too and then connect it with node, and setup some manager like "pm" to keep the things running.

When people say PHP is simple to setup they mean the customer buys some web hosting, and then puts the files there (at most you setup the db credentails and table names ). The customer will not need to hire a sys-admin that will have to use latest docker stuff or try to fix the issue that your customers runs RedHat but the developer wants to use X npm package but X needs some new npm and node version and now the sysadmin needs to make it somehow work.

I am not saying PHP is superior, if you are expert in Java, .Net, Python etc continue using that if it makes sense, in reverse if you (your team) are PHP experts then it is a waste to not exploit that experience. You might say that you should fire the good PHP developers that worked for you for years and take a chance on finding some CoolLang experts, from my experience is not easy to find good developers(in all dimensions not only good at reciting best practices), developers that you know that will not leave after 1 year because they want to work on new shit, developers that like to do their job for the end product , for the customer satisfaction and not just like to code because the language is cool, the framework is popular, the IDE colors are shiny and for the CV. If you have a good developer or team , use it.


The OP I responded to was about having a quick script up and running. Of course for a fully fledged app you might have a reverse proxy or similar.

Also PM is just a simple hypervisor, it doesn't have any logic, while Apache and Nginx do.


Are you talking about the dev workflow?

My point was that I already have a cheap webhosting, with a domain and email and I can now just login into cpanel and paste a script.

As a developer as other mentioned there are ways to run stuff from CLI, so IMO PHP is pretty equal with python or ruby , not sure there is a general clear winer so it always depends on the project and the team.

But if you are a new dev and you don't know any of the languages I would say start with Python, even if I prefer the C syntax. I got into PHP indirectly, I worked on desktop applications and I was asked to help with a web project so I learned it by doing (but I was already experienced so I did know what are some good practices), in the end desktop applications are no longer popular so I am still working on SPAs


php -S

if you want a quick script up and running


For someone who's not developer, PHP is way more simple to deal with. Upload to your FTP, follow some script or edit config file, get it up and running.

That's much more complicated with virtually every other language.

I mean, this has been going for decades, I didn't think it was up for debate. There's close to zero sysadmin skills required for dealing with PHP hostings, most of them have CPanel or something similar, most of them are very cheap, and there are plenty.

There's nothing similar for Python or any other language.


Vhost doesn't give you that kind of access, AIUI. They simply serve multiple users from shared webserver infrastructure using Host: header to disambiguate. (User-specific paths like www.vhost.com/~foobaruser/ used to be an option, but modern web security mechanisms rely on the base domain as an indicator of site-level 'context'.) That makes it quite isomorphic to lightweight "serverless" cloud hosting.


For development you don't need apache/nginx: https://www.php.net/manual/en/features.commandline.webserver...


> Or one nodejs file

And 98726354 packages that get pulled when you `npm i express`


Haxe does this https://haxe.org/

Is it a better language with better workflow? Maybe. But I do know there are people using it in just this way.


You can ask the same for any language, not only PHP:

- Why would anyone want to start something new with Ruby?

- Why would anyone want to start something new with Elixir?

You can choose any reason to pick a language, do you want a language with a lot of demand in the job market, learn Javascript, you will see a lot of frontend open positions, even more React open positions if you want to specialize in something.

Do you want a lively developer community, choose any language, I learned Java, PHP, Javascript and Ruby and all of them always had helpful people and a lot of courses to help me learn and try to code with good practices.

Answering the question seriously (assuming this is not trolling) here are some reasons to start something new with PHP in 2021:

1. Learning PHP 8 and a popular framework like Laravel will make easier to get a job on some small and medium companies. In the last job I had in a consulting firm, customers were asking for more Laravel developers to the point they accepted outsourcing because there was not enough talented Laravel developers in the US to cover the demand. There are thousands of bad PHP and Laravel developers, but there is not enough supply of good ones, so if you are talented and follow best practices, choosing PHP will make you shine between all those average developers.

2. I probably won't develop anything new with PHP 8 this year, but there are a lot of existing libraries and frameworks (Laravel and Symfony for example) that will benefit from implementing the new features of the language (reducing mess or making code more concise and readable). For the end user of those libraries and frameworks, very little will change since the interfaces don't change too much in order to allow backwards compatibility, so the existing ecosystem is a great reason to use PHP.


> Ruby

It has a very mature web dev ecosystem around Rails. It: is quick-to-learn, is OO to the bone, is FP where is fits with the OO, is easy to read, has little quirks.

Personally I'd go with something with stronger types, no "null" and proper sum types. But if you are cool with dynamic typing: Ruby is a great choice.

> Elixir

Ruby-like syntax (some advantages just mentioned) and BEAM runtime. Yields very scalable apps.

I do thing GP raises a valid concern. PHP is not for new apps, or even better put: for new teams. It's just too quirky and does not have the native browser support the other super popular + super quirky language JavaScript has.

As as a comparison: who'd start an app in Perl these days? Or COBOL?

At some point a language may be considered "legacy".


> is quick-to-learn, is OO to the bone, is FP where is fits with the OO, is easy to read, has little quirks.

Exactly same applies to PHP - without FP part but in exchange one is getting enormous, gargantuan ecosystem of libraries, developers, hosting, language oriented and designed to rapidly deliver result and easiest deployments out there.

Todays PHP is good, may be not trendy and hip right now, elitists may snark a bit but it's good language to deliver products.


Full of quirks (there's a whole subreddit for that /r/lolphp), not OO to the bone (more like tagged on), hellish to read, no proper FP stuff.

You may call people categorizing PHP as legacy "elitist", but big shops that use a lot of PHP are heavily investing in other tech (yes I look at FB).

> it's good language to deliver products.

Never said it was not. But it is not, anno 2021, a good language to start a new project in. Not as bad as Perl and COBOL, but still legacy.

It seems you have identified a lot with that language, and I see this often. Usually this happens to people who have little experience with other languages. The defend it like it is their home.


> It seems you have identified a lot with that language, and I see this often. Usually this happens to people who have little experience with other languages. The defend it like it is their home.

My take on this topic comes from extremely pragmatic and focused on results angle: delivering product. Not sure what about 2 sentences I wrote allows you to make broad assumptions about my experience, I don't feel need or desire do describe it here but it's not only my own opinion [0]

I think that Reddit "lolcontent" could be not good metric to use when deciding what should be used for building software.

[0] https://news.ycombinator.com/item?id=26830757


> Not sure what about 2 sentences I wrote allows you to make broad assumptions about my experience

That you defend PHP like it is your home. We can deliver a product in Perl, but it's a bad choice these days. Unless... someone is reaaaaly well acquainted with Perl and little else.

Hence I suspect that's whats going on here. As I've seen this happen many times before, also outside of programming.

> allows you to make broad assumptions

I voiced my suspicion based on your defensiveness. That's all.


I'd love to debate the use of PHP vs. Ruby and Elixir, but your arguments basically are:

- The community is full of people who just care about hacking something together.

- Ruby/Elixir are fantastic, developer friendly, and have solid foundations.

The first happens with every popular scripting platform. Is JS community full of PhDs?

The second is highly subjective. Ruby is problematic, because it's supported by one framework which is showing its age, and the language itself has lagged behind in performance, which matters increasingly for web workloads. Elixir is a niche dialect of a niche language (Erlang). Don't get me wrong, Erlang is amazing. But you don't need Erlang to set-up a blog.

It seems the major reason going against PHP are:

- WordPress and the entire ecosystem around it sucks. Well, sure, but PHP has more frameworks with big mindshare like Symfony. It's not a "Ruby on Rails" situation.

- The meme about hating PHP is big. Everyone loves to hate PHP and Basic. Even when Visual Basic .NET evolved to be basically no different than C#, the meme of hating it lived on. Same with PHP.

The thing with memes is they're not rational. So fighting them with rational arguments is pointless. If peer approval matters to you, then code PHP in secret or don't code in it. If shipping projects matters more, PHP is a pretty good option for most websites.


Moving from PHP to ruby, language speed has never happened to be a subject.

During coffee time banter, sure, but in real performance related issues, what we face came down to query optimizing, cache management, algorithmic issues and data pre-processing.

We didn’t even hit the “let’s write this in C” moment nor debated about moving parts of the code to faster systems/libraries. I’m not saying it will never ever happen, just that ruby’s sheer speed doesn’t seem to have a practical impact other than slightly higher hosting cost perhaps.


I'm sure that's the case. But as we break down the arguments that PHP sucks one by one, it's not performance, it's not libraries, it's not this, it's not that. How about this article "PHP a fractal of bad design", oh most of those no longer apply to PHP.

What's left? The slightly unwieldy syntax (still C-like, so close enough), and the bad reputation driven by memes.


I didn’t touch PHP 7+ for kore than hobby projects so things might have changed, but to me PHP’s main issue (and to some extent JS) was the need for a strong defensive coding discipline.

There is no specific flaw that is a roadblock, just a ton of things you know you shouldn’t do, cases you need to guard against, and base functions we effectively banned from our codebase. I still like PHP, and just moved for unrelated reasons, but I think that’s a specificity of the language (as a side effect, good PHP devs also easily become good JS devs in my experience)


> the need for a strong defensive coding discipline.

PHP 7/8 have a lot more typings, it's still optional but you can require your code to use strict typings, and you can use a static analyzer like psalm to basically recommend best practices, add a few tests and your code is pretty damn solid and passes most "smell" tests and generally won't break often or as often as something in python, ruby, go.

Mix in swoole and you went from 200 reqs/sec to 6k which is about 2k more than elixir, so really just about every issue php ever had is basically replaced by just more "mature" architecture.

If you know advanced php, and the new features/best practices etc and use good tooling then php is an awesome language.


It's not "language speed", it's memory consumption per request that makes the biggest difference in practice.


The two are heavily correlated, though.


> Elixir is a niche dialect of a niche language (Erlang).

Nitpick: Elixir is not a dialect of Erlang. It doesn't even compile to Erlang, but directly to the BEAM bytecode.

Erlang and Elixir are very different languages. Think of it as Java and Groovy. Erlang is old, battle-tested, explicit and verbose to a fault (which stops being a fault when you try to maintain a decade+ old code) and is used mainly for writing large systems with very specific requirements. Elixir is younger, tries to be less verbose, adds magic completely absent from Erlang, and is intended to be used more like a traditional scripting language in addition to also covering the Erlang use case.


> Even when Visual Basic .NET evolved to be basically no different than C#, the meme of hating it lived on

VB.NET is worst language on VB family, because it's totally degraded weird version of C#. I don't say VB6/VBS/VBA is cool, but it had some advantages compared to other languages.


> My question is: why would anyone want to start something new with PHP in 2021? Is there anything that it does better than any other language/ecosystem?

Well, on Twitter the other day, I asked, only partly tongue-in-cheek:

> Even in 2021, any new server-side web app with even a vain hope of being installed by people who are tech savvy but not modern web nerds should probably still be written in PHP. True or false?

The "false" responses cited things like "it doesn’t matter what you write it in as long as it runs cleanly in a Docker container" and "Node is widespread enough I think it goes beyond 'modern web nerd' at this point," and they might be right -- but I'm not certain they are.

So, I guess I'd suggest that maybe the answer to your first question ("why start something new with PHP in 2021") doesn't actually depend on getting an unqualified "yes" answer to your second question ("is there anything it does better"). If I was starting a project that I wanted to have installed by the kinds of people who will not use the word "deploy" instead of "install," if you take my meaning, then I'd at least seriously entertain whether it should be in PHP.

Now, for the kinds of projects I think get talked about on HN (e.g., actual paid jobs), this is more of a fair question. I appreciate Laravel and Symfony, but PHP in 2021 has traded the feeling of being a cargo cult version of Perl for the feeling of being a cargo cult version of Java. If I do write a new project in PHP, it's probably not going to be with any existing framework, because even the lightest one feels like endless mazes of "get a Request object from a RequestFactory by instantiating a dependency injection container and passing it to a RequestFactoryFactory".


> I appreciate Laravel and Symfony, but PHP in 2021 has traded the feeling of being a cargo cult version of Perl for the feeling of being a cargo cult version of Java.

As a Symfony dev I agree. And the process to convert PHP into a Java-esqe Kotlin-esque language is continuing. Why not use a different language if you like it rather than change PHP?

> If I do write a new project in PHP, it's probably not going to be with any existing framework, because even the lightest one feels like endless mazes of "get a Request object from a RequestFactory by instantiating a dependency injection container and passing it to a RequestFactoryFactory".

I'll be interested to hear what you come up with. Two anecdotes:

1. I had to touch some PHP code I wrote many years ago based on the ColdFusion "Fusebox" architecture. It's missing some nice abstractions but unlike Symfony et al there was so little code I could understand what every line did within minutes. Parts of Symfony's internals are still magic to me (complicated by compiler passes).

2. I was asked to look at replacing a decade-old internal PHP app, the kind people look down on built using jQuery UI AJAX-powered datagrids and raw PHP. There were multiple problems like SQL injection but the app responded incredibly fast. I had to warn them that the replacement would feel slower unless they drastically increased the hosting, because a modern, engineered framework would've only finished booting up by the time this one was returning data.


"the process to convert PHP into a Java-esqe Kotlin-esque language is continuing"

My observation is also that PHP is growing too much in language size. Depending on one's viewpoint, this can be seen as either matching the feature and syntax bloat of other languages, or taming the language to make it "saner".


The beauty of PHP is that you can still choose how complex you want your application to grow - and that you can adapt if needs change.

You can do everything from a one-file hacked together shell scripts (which I love to do because bash is just plain annoying sometimes, especially for stuff that has to work on OS X and Linux with their not-so-small differences in coreutils) to enterprise-style architected software in Symfony or Laravel.


> As a Symfony dev I agree. And the process to convert PHP into a Java-esqe Kotlin-esque language is continuing. Why not use a different language if you like it rather than change PHP?

The audacity of PHP 5.3 developers. How dared they! The audacity of PHP 5.4 developers. How dared they! The audacity of PHP 5.5 developers. How dared they! The audacity of PHP 5.6 developers. How dared they! The audacity of PHP 7.0 developers. How dared they! The audacity of PHP 7.1 developers. How dared they! The audacity of PHP 7.2 developers. How dared they! The audacity of PHP 7.3 developers. How dared they! The audacity of PHP 7.4 developers. How dared they! The audacity of PHP 8.0 developers. How dared they! The audacity of PHP 8.1 developers. How dared they!

/s

(sorry, couldn't help. this particular argument is sooooo silly...)


> Why not use a different language if you like it rather than change PHP?

I don't disagree in principal, but I'm struggling to think of much that isn't totally optional. For example, you can still completely ignore the type system.

There have been some BC breaks lately, but it's mostly around footguns that should never have been like that in the first place.


> endless mazes of "get a Request object from a RequestFactory

Comet to the rescue: https://github.com/gotzmann/comet


> My question is: why would anyone want to start something new with PHP in 2021?

Same reason as any, familiarity. Not all people, even in software, enjoy learning new stuff.

PHP might be the only language they ever learned and it has paid their bills for over a decade. No point in learning anything new unless it's absolutely required.

As long as major pieces of software are written in PHP, those people will have a steady job.


- shared nothing architecture - single threaded code execution context - copy files deploy

I was a PHP developer for over 15 years and those three concepts do more to lower the barrier to entry than any other language I’ve come across, and are constantly underestimated in their power to enable developers to concentrate on the business logic of their program.


Indeed, there's nothing like just logging in to a linux box you got access at school or pay $1/mo for and typing 'nano public_html/index.php' - stuff Just Works.

Trying to get a python/ruby framework working in the same env, without root access? Whoooo boy. 20 years in the business and I still refuse to do that crap. FastCGI and the like just never work properly the first time in shared hosting.

You need virtual environments to keep dependencies at bay, debugging is a pain if the web server and fcgi process don't communicate properly. Most likely you won't have access to error.log so good luck figuring out why everything returns HTTP 500.

While you're still figuring out how to get helloworld.py to respond, the dude with PHP is already done.


idk if we're talking about ease of getting started Heroku kinda made it as easy as it can get (started with Ruby but now supports all languages).


You still need Heroku for that while there are a literal boatload of PHP shared-hosting providers.


That's the answer.

It encompasses every aspect: familiarity, usability, low learning curve, low time to market, enablement, and, eventually, greater margins.


copy files deploy

That one is not great, unlike first two points. For one, larger bespoke programms need CI (and would benefit from CD). There is linting/type checking/testing to be done.

Secondly, "copy files deploy" is cheating. Somebody else did the job (hoster) and we are claiming that it is somehow benefit of PHP itself. Well? Did hoster do nothing? Really nothing at all? Nope. On top of that. Performant set up for PHP nowadays do not look that much differently then say, setup for Python.

Two first points are very good. Shared nothing architecture preclude existence of subtle bugs. While multi-threading in mutable, imperative code is the definition of subtle bugs. Those two keep PHP relevant and even on top of it's game (in certain domains).


There's a whole industry of "IT professionals" who can't actually write code or do heavy sysadmin, but still can help small businesses with their internet needs. They can drag and drop wordpress/magento files in an FTP client, they can figure out the right plugins to meet the customer's need, and so on. Programmers like to look down on these people but they do great work that makes their customers happy. In fact, I bet they often deliver the same business value faster than the average programmer might.

This entire industry wouldn't exist if PHP wasn't so easy to deploy and if there weren't great open source projects such as Wordpress and Magento particularly targeted at that way of working.

It's not just "easy deployment", that's underselling PHP. It's "enabling an entire industry to exist" and also "letting small businesses pick a middle ground between hiring super expensive professional programmers or being limited to what Wix/Shopify have out of the box".

Wix and Shopify and Webflow and so on are getting better and more powerful, but I'm convinced it's going to take a long time before they replaced PHP in powering the majority of the web.

I agree with a sibling comment that Discourse could well have joined the ranks of WordPress and Magento by now, if only they'd chosen the right language.


PHP is often a good business decision because there is no shortage of affordable devs to help manage the code. If you're building a small, low-margin business, it may be the best choice. I hate writing PHP btw.


For lost cost Wordpress stuff sure, but for higher end senior type work I think it's worse than other languages.

While this is obviously location dependent, over the last year or so I've had dozens of calls from recruiters asking me to come work on PHP (mostly Symfony and Laravel) applications, and telling me they just can't find competent senior and lead devs.


Yep, resonates with me. At the same time, these jobs pay very little compared to other stacks. Go figure why they can't find people :-)


PHP/Laravel is a higher level of abstraction. With Laravel specifically, it's the closest thing I've seen to writing web-app business logic directly in English. Sure, like any abstraction, it comes at a cost. Your applications would be more performant and CS-theoretically-elegant if written in C++ or Elixir/Phoenix. But you would spend a lot more time digging into segfaults, manipulating databases, and writing CRUD form boilerplate, which is far removed from your business logic.

I chose PHP for my recent startup -- despite being less experienced with PHP. The speed of development in Laravel is insane, because most of the framework is focused on making the common features of web apps more convenient. Coupled with static analysis tools and IDE helpers, all of the Laravel magic is actually understood by your IDE (PHPStorm). I've worked with Python and NodeJS for most of my career, and I've never seen this level of dev tooling. My newest project was in Laravel. I was able to ship the whole thing in half of the time it would've taken me in Django or some NodeJS framework, simply because the Laravel "magic" around databases, forms, CRUD, IDE helpers, ORM and scheduling and task queues is so fantastic.


> Your applications would be more performant and CS-theoretically-elegant if written in C++ or Elixir/Phoenix. But you would spend a lot more time digging into segfaults, manipulating databases, and writing CRUD form boilerplate, which is far removed from your business logic.

With C++, absolutely. With Elixir/Phoenix? I never have to debug low-level issues. I also don’t have to waste time debugging stupid scope stuff and dumb data structure inconsistencies that PHP is full of.

> “magic” around databases, forms, CRUD, … scheduling and task queues…

“The bill comes due…” As long as you’ve got a small scope, sure, that might work. Maintenance on magic gets harder though. If the magic is what you need, you might want to take a closer look at the Phoenix system. Ecto’s DSL is just as easy as an ORM in the simple case, but is far more composable and robust in the complex cases. For simple jobs, you can just leverage the BEAM for task scheduling—I needed a little task run every 5 minutes; all it took was a dozen lines of simple code—no Redis needed! Just as “magic” feeling, but better architected and maintainable in the long-run.


The first comment in this thread already answered your question.

>I would say that Laravel is an extremely high quality framework (on par with and even in some ways better than Rails) that nobody should be ashamed to use.

And add to that PHP both a language and its VM get way more improvement than Ruby.


How do you measure this improvement compared to Ruby? At least in Ruby/Rails case it's backed by Shopify, which isn't very far from being as big as Oracle (market cap wise). Shopify invests heavily into Rails and in Ruby. Other big companies are Stripe (Ruby only), Github etc. But Shopify is the big deal since it's becoming a FAANG stock as of late. Now for sure PHP has a big following, good companies based on it (though Facebook kinda forked away from it afaik) and people contributing to it but I wouldn't be so quick to say it's improving better or faster.


>At least in Ruby/Rails case it's backed by Shopify,

Recently backed. Backed in the sense as investment into it. Ruby and Rails now finally have capital behind it for investment. Ruby JIT being worked on specifically designed for Rails from Shopify, running on Master with better QA etc. But they are comparatively recent.

Most of these improvement will take time. PHP on the other hadn't are already seeing those improvement today. And they were work that has been going on for past 4 - 5 years. So in that sense it is improving faster.


That's not really a rebuttal though.

He asked why it's better, not the same as.


I was recently asked to do a simple order page for a company where I know a guy. It would be a simple page with a few web forms, emailing the order to them. That's all they needed. I chose PHP because:

1. Even though I haven't used it in a while it is super simple to get in to. 2. They did not pay me to learn new stuff. They did not need a fancy web framework. They don't care about code elegance. 3. They already had a web site hosted on server with PHP. 4. Development environment is easy to setup locally (just download a portable PHP dev env and run). Everything is built in. 5. Passing it on to them, it's just a few text files to upload that they can easily modify as needed. Nothing to compile.

In short, it's just the simplest way to do it sometimes (KISS). And not all projects are big enough to justify more complex solutions.


Sounds like (3) is the only strong argument for using PHP in this case. In particular, as a developer you should care about elegance (2), and python (flask) could have solved all other points as easy had they not already been using PHP.


> that I worked with PHP for two+ years maintaining both legacy codebases and writing new code with Laravel.

might seem like trolling, but from what I've seen, Laravel encourages bad developer practices such as static code etc, while Symfony encourages good OOP practices. so Laravel in itself is attracting specific audience with different priorities than Symfony, so it may explain your main complaint about PHP code which cannot be treated as same. I mean Laravel is written in PHP but it does not mean that same code practices are used in other frameworks/projects.


As a PHP developer, this is spot on. I'm biased, though. I believe symfony is a vital component of modern PHP.


We recently picked PHP for a large web application. The usual choices at our teams are Java11, Golang, and Typescript (+ a few teams that use Kotlin, C# and Rust). Many team members however also had experience with PHP in their career, but the main reason for us to pick PHP was Laravel's ecosystem really. The amount of features and scaffoldings that you get out of the box is just crazy. It gives you proper authentication for both web and APIs with 2FA and everything out of the box. Plus billing integration with recurring billing support and everything you need for payments, and also team management features ready in 5mins. And then you add another package for building administration panels (it's called Laravel Nova) which costs nothing comparing to alternatives for Java and deliveries much better development experience. It has been almost a year and no regrets so far.

I think it easily saves you 6 months of development time if you want to build a web app or a website beyond a static page. The ecosystem is very stable and reliable. So why not?

I encourage you to watch some of the introduction videos that they produce to show their ecosystem. That's how we were convinced to start investigating it. We spent a couple of weeks to make everyone productive with it. We had to catch up with all PHP7+ features and read Laravel docs. I think we will still build a lot with Java and Golang, but not for WEB. I don't see a better alternative for building web apps or front-end projects.

We don't however mention it in our portfolio or even on our job listing. It's apparently not cool for a publicly traded enterprise to say that we also use PHP.


You‘re right, it‘s insane what Laravel‘s ecosystem has to offer out of the box. However, most of these features save you lots of development time AND are free to use. What makes me unhappy here is that a company and its employees benefit from these ‚free‘ features and at the same time they don‘t condescend to mention it in their portfolio or even job listing because it‘s not cool enough.


> the Elixir/Phoenix stack, really developer friendly

I do PHP/Symfony and Elixir/Phoenix and really it's more nuanced than that.

Really if I don't need things that are suited for the BEAM/Elixir/Phoenix I'll probably be more productive with PHP/Symfony, especially for CRUD: the strict type system is better, the templating is better, the framework includes way more functionalities, the static analysis is better, PhpStorm with the Symfony plugin is amazing, even the docs are better.

But yeah, the app will probably be slower (but probably less than you think nowadays) and coding will be less fun ;)


I think if you can integrate swoole with coroutines in the right places, some benchmarks may have it faster than phoenix even... and I know laravel has had swoole packages, but recently with octane has made it more central which is good because a lot of issues were with maintaining state with requests and multiple threads as well as database changes.


> why would anyone want to start something new with PHP in 2021?

What can you make in X language than I can't make in PHP? And vice versa?

Don't get me wrong, I fully support the "select the right tool for the job", there are obviously better languages and frameworks for different kind of tasks, but let's just consider the context in what PHP is usually used in.

I get that people dislike a syntax. I loathe Python, basically because indentation actually controls how and whether your software works and I can't use indentation for organizing the readability of my code.

But that doesn't mean that I would ever argue against the use of Python; again - what can you make in Python that I can't make in PHP? And the other way around still.

inb4 "But PHP doesn't do async" - [fibers](https://wiki.php.net/rfc/fibers) is a start on that journey. We've managed so far.


I have experience with JS (node) and PHP, and between the two I would choose PHP for any real website. I appreciate a lot of things JS gets right (including PNPM vs Composer), but Node is far less reliable and IMO PHP is the better language.

My Rails friends all recommend against using Rails for any new projects. I never bothered to get the laundry list, as that is enough to convince me not to learn a new language.

I wouldn't use Go or any language that requires compilation.

I don't know anyone who uses Elixir, which is enough to keep me away. I worked with Cold Fusion and with Erlang in the past. When I got stuck, finding someone to help me was not fun (with CF I even paid for consulting) and existing libraries were few and incomplete. (Although I enjoyed Erlang as a language).

For me, PHP is a go-to language for new projects, and it has become quick enough, stable enough, and complete enough to hit the check boxes I need.


I don't get why your Rails Friends would not recommend it for new projects. Care to elaborate?


I've worked with it for a little over a decade and I have to agree with you. It's a lot better than it used to be, it's just not very good. That said, the reason people use it is for it's popularity: It's easy to get into and almost everyone can write it badly. Much like javascript.


>For example, why would you write something in PHP when you've got an excellent choice between Ruby/Rails or Elixir/Phoenix/LiveView

You can make a simple website on PHP in ~30 lines of code (routing + boilerplate template) with nothing more than a text editor. It will have no dependencies beyond standard PHP modules, so you could then migrate this website to hundreds of cheap shared hosting providers just by copying files via FTP or SCP. It will run fast even on server with crap hardware. There is nothing remotely similar in any other language. All other solutions are less portable, require way more configuration and more infrastructure on the dev side.

...

~15 years ago I made a website for a certain community using PHP. I still maintain it. On my own time, on my own dime. It doesn't cost much, thanks to properties I described above. So it's still operational. Think about that next time you talk about "maintainability" and "stability".

...

I'd love to have the same ergonomics of deployment with other languages. You can make it work. Jetty + Apache Velocity, for example, can "feel" similar to PHP. But there are no hundreds of providers who will manage this for you with little to no configuration.


You have kind of answered you own question:

"people who just care about hacking something together and, as long as it works, it's fine."

If you need to hack something fast, deploy it using SCP on a cheap hosting then PHP is a very reasonable choice. The only thing which is needed is Apache PHP module enabled. No need to think about ports, starting some additional server, doing proxies, etc.

Registration form? In PHP you just need to open a file, add <? tag, 5 lines and you call database, another 5 to send email with SMTP server and you are done. No need for application generators, templates engines, DB abstraction layers. Fancy functional programing language not needed, basic knowledge of some C-like language suffice to hack something fast.

Obviously such application will have maintenance issues, etc. but very often this just does not matter.


PHP is just very simple and powerful. Check out levels making 100k per month with a single php file: https://twitter.com/levelsio/status/1381709793769979906?s=21


So, one reason to use PHP instead of Ruby is that you will need 100x fewer servers. When you need 100x fewer servers you might also need 100% fewer devops people.


Care to back that up or are you just trolling?


"If you have a hammer, every problem looks like a nail."

Both PHP and the success of Web applications are inextricably tied to each other. It's easy to pick up and easy to run. Others commenters have already expanded on these advantages.

PHP has treated the Web as a first citizen before anything else for the longest time. It sits on the crossroads of I/O over HTTP(S) and it's really good at what it does. The massive amounts PHP frameworks are testament to that.

Even so, moving away from that vantage point, the story shifts quickly. The rise of the Web doesn't just imply managing / processing HTTP(S) I/O - building a simple web interface, a simple REST/JSON API,... - it also means managing the complexity of data management. Data migrations, transformations, juggling processing jobs, tying API's together,... are the bane of many a PHP developer.

Many a PHP framework provide API's to do background processing via PHP scripts you run on the command line. There are plenty of PHP libraries out there to make things easier as well.

Thing is, languages like Go or Elixir run circles around PHP when it comes to things like concurrency, multi-threading and robustness. Python's idiomatic approach to data munging makes it more suitable then PHP to deal with complex textual as well as binary datasets.

PHP absolutely has it place for several classes of business problems. But definitely not for everything. Having spend a decade in PHP consultancy, I've witnessed several client projects suffer heavy delays or fall through because an entire business domain got shoehorned in PHP, and - worse - in specific PHP frameworks that bring their own additional layers of complex abstraction.

The latter is not a fault exclusive to PHP or developers who solely specialize in writing PHP, or even a specific PHP framework. Rather, it's caused by complex biases and social dynamics that tend to lead towards a narrow-minded tool-centric approach of complex business challenges.

Just like a hammer, PHP is a tool with a limited set of use cases. Just like any language.


I think the points from "Taking PHP Seriously" are still interesting. https://www.infoq.com/presentations/php-history/

The argument is that PHP's strengths are its workflow, its state, and how you work with concurrency. i.e. PHP's execution model (per-request) allows for things like not having to worry about restarting the server when you're developing the files. The complete lack of shared state between requests means you don't get complex footguns.


Please do not. I wouldn't like the next version of php to become hip and force me to learn kubernetes and a myriad more technologies just to run my app from 12 years ago. Keep php unsexy.


The things you mentioned in your second paragraph are precisely why. Because there is no shortage of "devs" who took a month-long training course and think they know everything there is to know about PHP, who will get the thing you're paying them to do mostly working in reasonable time. More importantly, they'll accept crap pay to do it.


> They care nothing about elegance and have but a dim conception of larger CS/SE principles.

Elegance and CS/SE principles don't usually have a business case.

Given a choice between PHP and Python for a web-service, there's no practical real-world difference between the two, except that it's slightly cheaper and faster to get your PHP service up.


Because producing tools with php is VERY fast, and it runs almost as fast as a scripting language could. It's simple, and efficient. One of the language that requires the least amount of code to produce a given result. Plus the longevity of the project.

The question is why would anyone NOT want to use php in 2021 for non desktop developments?

I also prefer pure php, with no frameworks. I think it's best to build your own tool that suits you.


To answer the question. It evolved a lot over the last years, it has a thriving community, you will always find answers to your questions, there are a lot of developers and I personally think the community around the core is quite competent at what they're doing with the language.

We started one of our biggest projects on PHP 5.6 and Symfony 2.x years ago. The maintenance process and the upgrades were absolutely painless. If you're disciplined, you can probably do this with most of the languages, but we constantly were able to upgrade, so that we are running on PHP 8 now and the latest Symfony version. Of course we had to pull certain parts that started to be too big out of the app, some are now node, some are Symfony, some Java, but the core is running on the latest versions and the evolution of the language and the performance improvements that we had with the upgrades over 9 years are incredible.


You're right that PHP has historically had its fair share of "development by copy-and-paste from StackOverflow" developers. However, I've noticed that in recent years a lot of those people moved to the JavaScript ecosystem. It's the latest shiny and the learning curve and time-to-deploy curve is low like in PHP (though, many in the JS community are trying their best to complicate that part for reasons I can't fathom)

Does that leave a PHP community comprised of only people who adhere to solid CS/SE principles? No, but that doesn't diminish the fact that PHP still has a lot going for it. It's easy to get started. You can adhere to solid CS/SE principles with little effort if you have the discipline to do so. It's trivially easy to deploy a PHP application. The documentation is still fantastic.


I use php for my startup and all new things are made in php for these reasons.

the ecosystem is very much complete. There is nothing that has not been done and tested in php.

Plenty of developers know php and if you have done C#/Java/C++ etc its super easy to learn.

Its easy to setup and well documented and the LAMP/LEMP stack is battle tested and people know it well.

There is great Editor/IDE support with plenty of options to choose from.

You can run it on any kind of developer-os and do you development there then just deploy it to a linux server. Altho docker solves this now with any lang its still nice if you dont want to use solutions like this. I have devs developing on windows, linux and mac with no issues getting the whole development stack running and then deploy the app on linux with no issue. This has been a challange in ruby on rails last time i tired it (back in 2010).

The laravel framework is great.


I started my career in 2006 with PHP and was using it a few years before in private. I used it until 2012.

After that I switched to JavaScript and never went back. First, I did frontend development, then backend with Node.js, then Mobile with React-Native. In between games and now serverless.

PHP isn't bad, it became quite nice these days. But it simply isn't as flexible as JavaScript.

Everything new technology that comes out has JavaScript support right from the bat.

If I need static typing, I drop in TypeScript.

The performance is also crazy good for a "mere scripting language". If you need more perfomance than JS has to offer, there is only C, C++, and Rust left.

Back in the days I used PHP for those exact reasons. It was simple, fast enough, and supported everywhere. Sadly, that isn't the case anymore.


> But it simply isn't as flexible as JavaScript

I guess it depends how you define "flexible". The language itself is clunkier, particularly anything involving closures (although that's getting better), but it does so, so much stuff out of the box (even if the APIs are often a bit footgun-y).


> I used it until 2012.

That means that you've missed the train of modern PHP and frameworks completely. It's not fair to compare old school PHP with modern lang like TypeScript


> Is there anything that it does better than any other language/ecosystem?

It has the lowest barrier to entry, both as a developer, and a user - as far as I can tell no other language has even tried to compete in this area :(


"My question is: why would anyone want to start something new with PHP in 2021?"

Because that is how people get things done.

Example. With Elixir/Phoenix/LiveView I will give you a simple task. Provision a phone number on Twilio. Please see this image:

https://imgur.com/a/iACVPvU

What would you end up doing? I would bet wasting a ton of time or hacking something up with curl. With PHP/python/ruby I would be done in 10 minutes.


https://github.com/postmates/ex_twilio

Probably the code would not be that much different, or at least not more complicated to write.

You would also not use curl anyway with Elixir, it has http clients like other languages you know, for example Httpoison.


"They care nothing about elegance and have but a dim conception of larger CS/SE principles." / "I really see no reason to not choose a better tool in this day and age."

Every time there is a PHP news update these kind of posts come out. They claim some vague experience in PHP and then go on to list all these other wonderful languages you could be using instead and that insinuate you must be a bit of a shit developer to be using PHP.

Unfortunately this troll has been well fed.


Even worse, your parent comment blatantly tries to shame people who focus on the product instead of the tool.

Because yeah, I'm using a programming language to CREATE something ... not to, you know ... use a programming language.

Moreover, it's also obvious from these kinds of posts that their authors have never thought about the business context at all, otherwise they would have realized that hiring PHP devs is hard enough ... but hiring [insert fancy new language] or even [python/ruby] is next to impossible without spending way, way too much money.


Just spoke with someone who has a (very good) php dev on staff, and has someone else on staff with some node experience, and is partnering with someone else who does rails. They decided on a new project being done in rails because the rails guy said "it's easier to hire rails devs than PHP devs".

That is so far off my experience, and I don't mean "php=wordpress therefore you can find loads of devs". I mean that finding good people who can hit the ground running and not be a net drag on a project - in any tech - is, imo, very hard these days, and has been for probably the last 2-3 years at least. Basing mostly on regional network and chatter in user groups, but it definitely seems to have gotten worse recently.

"easier to hire good devs in X" doesn't seem like the best metric decide on (but maybe it is?)


Reminds me of the meme/video about mongodb: "It's webscale".

https://www.youtube.com/watch?v=b2F-DItXtZs


Wordpress. I haven’t been paying attention for a few years, but last I looked wordpress powered over half of public websites. Wordpress was forced upon my team at my last job because non technical users have been exposed to it and training costs were a big deal for my organization. It wasn’t something I would have preferred for technical reasons but it just sort of makes sense in a lot of contexts where a content management system is required.


Dont forget about content websites. PHP has pretty big dominance in usage and quality of CMSes. And i dont mean just wordpress and drupal (which are pretty meh). Its things like Craft CMS or Kirby CMS. Also open source ecommerce - prestashop/opencart/woocommerce.

So if you are devshop doing lot of CMS development and start doing webapps/apis then something like Laravel makes lot of sense.


I don't think you're a troll, but I think you know your community well-enough to trick it into a clever karma-hoarding move ;)


The ecosystem is what makes the huge difference, especially thanks to Laravel.

So much documentation everywhere. So many helpful resources.

I've tried to learn Rails back in the days (ie 7 years ago) and was shocked by how poor the entire documentation is. I subscribed to Railscast but it hasn't been maintained for years.

The PHP ecosystem, however, is incredibly alive.


Most ISP support it, and is the cheapest way to get someone on the web without surprises in running costs.


I feel like yelling “die” each time I see “php”, but on the other hand - man, those were simpler times when we were pushing a feature after feature instead of talking about overly engineered architectures and nuances of super complicated runtimes of the current pls


Maybe that is the experience with Laravel, but I had the opposite experience with Symfony.


It's easy to learn, fast and many people understand the code. And it just work.


Reasons why to use PHP:

- You know how to use it (syntax, what it can do etc.) - You've learned its ecosystem, package management, standards - You can achieve results using PHP and complete projects while adhering to deadlines

Ruby doesn't offer anything substantial that would justify the switch. I'm all for developers honing their skills, but business does not exist to cater to developer's whims. Business exists to provide value to clients and put food on employee's table. Being nitpicky about the language and doing language swap is very expensive, especially when you swap language A with language B and gain literally nothing. For smaller businesses or one man shows, it's trivial to start a new project and use a different language.

I've seen fair share of superficial analysis and loud comments made by people who are not engineers, judging by their behavior. Like any language, PHP can be misused; and often is misused. It became a rite of passage to belittle PHP. Reading or hearing comments that attack certain technology without objective reasons merely means the person doing it is toxic and should be avoided in general. I dislike plenty of things in PHP / Python / Golang, but I would never dream of whining about it; instead, I try to reach out to maintainers and make suggestions to help make improvements.

Having written a few things, here's why you PHP is still appealing (this does not mean other languages cannot do this):

- it's sufficiently fast for CRUD-y applications. Bottleneck is usually I/O, but scaling horizontally is not an issue anymore, therefore performance doesn't have to be an issue. - it's feature rich, type system received massive improvements and continues to improve - it has more than 1 framework to choose from (Symfony, Laravel, CodeIgniter, Phalcon, Aphiria, Yii, Zend Framework and the list goes on) - there's an async framework available, called swoole. It's an extension to PHP written in C++ and it brings async capabilities to the play. It's sufficiently quick and allows for building different types of applications: like web socket server or communication-oriented servers. - new Foreign Functions Interface allows for experienced / polyglot developers to extend their apps in an easier manner opposed to writing extensions in C

With technologies like containerization, it became trivial to distribute PHP applications and avoid long setup times and reading the manuals on how to make something work. Not everyone use those technologies, but it's what's available and end result can be that you distribute a container image, which for all intents and purposes, means that you deal with a single "file" (thought I want to get across is that app distribution can be made extremely simple).

Question that poses itself is this: what reason is there to move away from PHP? Personal preference - I understand it, and this is what pushed me to try other languages and technologies out.

If you've got substantial performance, mature ecosystem, plenty of libraries, plenty of frameworks to choose from, great language features, async capabilities and ability to use the language for things other than CRUD-y applications - why use a different language that will ultimately merely let you do the same?


What if your focus is not on elegance of the code but the product? What if you don't want to spend any time on boilerplate and starter project setup but spend all your time on your idea? What if programming is just the means? What if this is not you: https://twitter.com/cassidoo/status/1216871876192088065

PHP used to be light years ahead in this since it is internet native language. With anything else you have a lot of moving parts that need to be aligned in a specific way to make it work, in PHP the default state is ready to go.

How do you deploy your new code to your LAMP server? You put it in a folder. No need for package managers, no need for any other kind of tooling. You even don't need any frameworks beyond your original product requirements.

If it's local server, you drag and drop the file you just typed in the code using your file manager. If it's a remote server you use your favourite FTP app.

If your idea turns out to be worth its salt you can pay an army of engineers to re-implement it in an elegant way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: