PHP in 2021(stitcher.io)
stitcher.io
PHP in 2021
https://stitcher.io/blog/php-in-2021
308 コメント
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.")
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/
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.
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.
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.
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.
[deleted]
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).
[deleted]
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.
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
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.
Most PHP apps out there are dump easy to use. That's not the case even for Python.
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.
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 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.
Docker probably is a better way of doing things, but it’s another layer.
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.
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 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.
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.
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.
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.
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
> - 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.
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.
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.
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.
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.
>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.
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.
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
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
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.
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`
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.
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.
- 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".
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.
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.
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
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.
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.
- 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.
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.
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)
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.
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.
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.
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".
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.
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".
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.
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...)
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.
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
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.
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.
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.
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.
[deleted]
That's the answer.
It encompasses every aspect: familiarity, usability, low learning curve, low time to market, enablement, and, eventually, greater margins.
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).
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.
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.
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.
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.
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.
>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.
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.
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.
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.
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.
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 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.
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.
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 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.
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
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.
"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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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 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
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 :(
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.
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.
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.
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.
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?)
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
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.
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.
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.
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.
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.
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?
- 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.
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.
It is a great language to put food on the table.
Especially in Europe it is still the dominant backend language. If you want to have flexibility on where you work it is a good language to know.
You have the productivity of a scripting language but still great static analysis tools that help you out. It really fills a sweet spot that no other language does.
Yes, Node has Typescript but then you have a super slow compiler negating the scripting language benefits. With PHP I can change a file and see instant results. Also languages like Go make it hard to debug anything on an live server as it is all compiled.
PHP code is mostly boring. The coding style tends to be very pragmatic. Even bad beginner code runs great due to dead code elimination and the like. Shared nothing architecture makes understanding and debugging the system so much easier.
Hosting is simple and inexpensive. Beginner can just copy their files to an shared hoster and be done with it.
PHP is only a bad choice is you have really complex requirement and need a high level of reliability, which most Web projects don't. I think Haskell fills a good niche here. It is really underestimated. Also Elixir if you happen to build anything where you can play out its strength.
Especially in Europe it is still the dominant backend language. If you want to have flexibility on where you work it is a good language to know.
You have the productivity of a scripting language but still great static analysis tools that help you out. It really fills a sweet spot that no other language does.
Yes, Node has Typescript but then you have a super slow compiler negating the scripting language benefits. With PHP I can change a file and see instant results. Also languages like Go make it hard to debug anything on an live server as it is all compiled.
PHP code is mostly boring. The coding style tends to be very pragmatic. Even bad beginner code runs great due to dead code elimination and the like. Shared nothing architecture makes understanding and debugging the system so much easier.
Hosting is simple and inexpensive. Beginner can just copy their files to an shared hoster and be done with it.
PHP is only a bad choice is you have really complex requirement and need a high level of reliability, which most Web projects don't. I think Haskell fills a good niche here. It is really underestimated. Also Elixir if you happen to build anything where you can play out its strength.
The elitists who constantly hound on PHP's deficiencies as if developers haven't heard about them for the last 20 years are the same types of people who build a fancy side project that never sees the light of day because it's massively over-engineered in some obscure flavor-of-the-month language.
Your customers don't care what's under the hood beyond your ability to provide value to them. If PHP lets you ship faster and get your product in the hands of consumers, it's a good language.
Your customers don't care what's under the hood beyond your ability to provide value to them. If PHP lets you ship faster and get your product in the hands of consumers, it's a good language.
That a lot of the issues that were "not a problem" in the 5.x days are now addressed in PHP 7 and 8 is evidence that the technical criticism was valid and hardly "elitist".
There are many successful projects in many different languages. You're using one of them right now. That claim only PHP devs care about shipping useful products is extremely silly.
There are many successful projects in many different languages. You're using one of them right now. That claim only PHP devs care about shipping useful products is extremely silly.
> PHP is only a bad choice is you have really complex requirement and need a high level of reliability, which most Web projects don't. I think Haskell fills a good niche here. It is really underestimated.
Actually I find PHP projects to be more reliable to host than stuff written in Java, the lingua franca of business projects. Constant worrying about heap sizes, garbage collection, resource leaks or your entire server crashing because of some exception somewhere... you don't have anything like that in PHP (with the exception of memory_limit, which is fairly rare to hit in a decent hoster), simply because of the shared-nothing architecture of PHP.
Actually I find PHP projects to be more reliable to host than stuff written in Java, the lingua franca of business projects. Constant worrying about heap sizes, garbage collection, resource leaks or your entire server crashing because of some exception somewhere... you don't have anything like that in PHP (with the exception of memory_limit, which is fairly rare to hit in a decent hoster), simply because of the shared-nothing architecture of PHP.
> PHP ... I think Haskell fills a good niche here.
well, that escalated quickly
well, that escalated quickly
Fuck Haskell, that's kiddy stuff. Malboge or go home.
PHP has been in a pretty good place since 7, IMO. These are some great developments.
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.
It's unfortunate that the stink of old PHP is so powerful and that salaries are still lagging so far behind.
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.
It's unfortunate that the stink of old PHP is so powerful and that salaries are still lagging so far behind.
That's because the "stink of old PHP" never really went away.
For example, Wordpress install guide [0] still talks about making your code directory writtable by web user -- practically guaranteed that any minute exploit will lead to permanent web shell.
So does Nextcloud install guide [1].
I am sure there are nice, modernPHP somewhere, but a lot of time you I see old-style programs with horrible security practices.
[0] https://wordpress.org/support/article/how-to-install-wordpre...
[1] https://docs.nextcloud.com/server/latest/admin_manual/instal...
For example, Wordpress install guide [0] still talks about making your code directory writtable by web user -- practically guaranteed that any minute exploit will lead to permanent web shell.
So does Nextcloud install guide [1].
I am sure there are nice, modernPHP somewhere, but a lot of time you I see old-style programs with horrible security practices.
[0] https://wordpress.org/support/article/how-to-install-wordpre...
[1] https://docs.nextcloud.com/server/latest/admin_manual/instal...
Not just writeable by web user. The page here[1] suggests making files and folders world writeable all over the place (to be fair, followed by disclaimers.. but still).
>If you use Permalinks you should also change permissions of .htaccess to make sure that WordPress can update it when you change settings such as adding a new page, redirect, category, etc.. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.
1: https://wordpress.org/support/article/changing-file-permissi...
>If you use Permalinks you should also change permissions of .htaccess to make sure that WordPress can update it when you change settings such as adding a new page, redirect, category, etc.. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.
Go to the main directory of WordPress
Enter chmod -v 666 .htaccess
1: https://wordpress.org/support/article/changing-file-permissi...
WordPress is about as old as Netscape Navigator. Am I judging JavaScript based on the hot mess it was in these days?
Using WordPress as an example for the state of PHP is disingenuous.
Using WordPress as an example for the state of PHP is disingenuous.
1. WordPress was released in 2003, Netscape Navigator was basically dead by then.
2. It’s fair to judge a language by its dominant platform / use case. Rails (2004) and Django (2005) are barely younger than WordPress. Is it fair to judge Ruby and (one facet of) Python by examining Rails and Django respectively? Yes.
2. It’s fair to judge a language by its dominant platform / use case. Rails (2004) and Django (2005) are barely younger than WordPress. Is it fair to judge Ruby and (one facet of) Python by examining Rails and Django respectively? Yes.
According to some statistics [0], Wordpress is used on 41% websites in the world. That’s a lot of websites! Even if those numbers are inflated, It is still likely the most popular PHP app in the world. It is not disingenuous to judge a language by its most popular application.
I wonder what fraction of PHP programmers today mostly work with Wordpress.. and how many PHP jobs involve maintaining Wordpress apps.
[0] https://w3techs.com/technologies/details/cm-wordpress
I wonder what fraction of PHP programmers today mostly work with Wordpress.. and how many PHP jobs involve maintaining Wordpress apps.
[0] https://w3techs.com/technologies/details/cm-wordpress
The list goes on, I have a pet peeve with matomo (aka piwik) for example. Impossible to do immutable containers --- it's just bad software design, not a fault of the language itself. But because these softwares are old and have an user base, design errors remain throughout decades.
They're not lagging behind. Based on my experience, companies in the bay area using PHP often pay just as competitively as others. There are likely a large number of "PHP" jobs available overall though which could bring average pay down, the low-end is low because there's such a low barrier to entry for something like WordPress development.
> There are likely a large number of "PHP" jobs available overall though which could bring average pay down, the low-end is low because there's such a low barrier to entry for something like WordPress development.
I was about to write exactly that. There is a long tail of relatively unskilled developers who technically count as PHP devs. I also do not perceive PHP salaries to be lower relative to other web dev stacks.
I was about to write exactly that. There is a long tail of relatively unskilled developers who technically count as PHP devs. I also do not perceive PHP salaries to be lower relative to other web dev stacks.
I liked Symfony but becoming a “PHP guy” looks like a terrible career move still. Also not a huge fan of the one data structure being both a dictionary and an array.
Amen. And it does neither very well. Not to mention that you can get surprising results like if you insert into an "array" out of order then iterate over it, you get the results in insertion order and not index order.
What stack do you recommend?
Node/JS or GoLang or React, Java?
Node/JS or GoLang or React, Java?
I am a fan of ASP.NET MVC. But honestly if you've used one MVC framework you've kind of used them all.
> if you've used one MVC framework you've kind of used them all
Same goes for C-like languages like PHP or C#. Most of the features and syntax are the same across all in the family, so who really cares if it's Ruby, PHP or C#, they are more alike than they are different.
Same goes for C-like languages like PHP or C#. Most of the features and syntax are the same across all in the family, so who really cares if it's Ruby, PHP or C#, they are more alike than they are different.
Well that's somewhat true too, though I think mandatory type declarations are a meaningful difference.
Those are fine. PHP has just been tainted by its past and low barrier to entry. I hate to say it but my company now just filters out candidates who have PHP as the majority of their experience because the signal to noise ratio is so bad.
> I would say that Laravel is an extremely high quality framework
I strongly disagree. My experience with Laravel made me see it as a medium quality framework with many flaws. I'll point out to a few of them.
The source code quality of the framework is not very high, and locally very poor. For instance, you can't autocomplete normally with an IDE unless you load extra declarations of the magic. Sometimes functions return values of varying types. And, last but not least, there are many cases where a call to a method on on object is intercepted by the magic `__call()` and redirected to another object created on the fly.
As pointed above, the abuse of magic means browsing the Laravel API is a nightmare. You won't see methods that you may call. Overall, the official documentation is tutorial-oriented, with an abuse of videos. I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation.
Laravel is extremely slow. Speed or concurrency is not a problem for many web sites, but when your framework is 10-100 times slower than others, you hit performance problems sooner. I suspect the magic and a few design choices (e.g. not using PHP native sessions) mean that a Laravel application can't get fast.
I strongly disagree. My experience with Laravel made me see it as a medium quality framework with many flaws. I'll point out to a few of them.
The source code quality of the framework is not very high, and locally very poor. For instance, you can't autocomplete normally with an IDE unless you load extra declarations of the magic. Sometimes functions return values of varying types. And, last but not least, there are many cases where a call to a method on on object is intercepted by the magic `__call()` and redirected to another object created on the fly.
As pointed above, the abuse of magic means browsing the Laravel API is a nightmare. You won't see methods that you may call. Overall, the official documentation is tutorial-oriented, with an abuse of videos. I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation.
Laravel is extremely slow. Speed or concurrency is not a problem for many web sites, but when your framework is 10-100 times slower than others, you hit performance problems sooner. I suspect the magic and a few design choices (e.g. not using PHP native sessions) mean that a Laravel application can't get fast.
You say
> medium quality framework with many flaws
Yet you only point out
> you can't autocomplete normally with an IDE
> You won't see methods that you may call
Firstly if there are "many flaws" list them because it seems you only don't like the developer experience with the autocomplete. I noticed no problem with browsing the Laravel API [0] with my short adventure with it.
> framework is 10-100 times slower than others
citation needed.
Also you didn't mention what you tried to use it for but remember software engineers are paid to pick the right tool for the job, Laravel is not the top pick for highly-concurrent idempotent microservice on Kubernetes, it's for monolithic app replacing that old WordPress installation without changing the tech stack
[0]: https://laravel.com/api/8.x/index.html
> medium quality framework with many flaws
Yet you only point out
> you can't autocomplete normally with an IDE
> You won't see methods that you may call
Firstly if there are "many flaws" list them because it seems you only don't like the developer experience with the autocomplete. I noticed no problem with browsing the Laravel API [0] with my short adventure with it.
> framework is 10-100 times slower than others
citation needed.
Also you didn't mention what you tried to use it for but remember software engineers are paid to pick the right tool for the job, Laravel is not the top pick for highly-concurrent idempotent microservice on Kubernetes, it's for monolithic app replacing that old WordPress installation without changing the tech stack
[0]: https://laravel.com/api/8.x/index.html
> Laravel is not the top pick for highly-concurrent idempotent microservice on Kubernetes,
Taylor Otwell would like to introduce you to Larvel Octane, i.e. support for swoole/workerman with 6k+ reqs per seq on a basic desktop.
Laravel with swoole basically makes it as performant as elixir/phoenix.
Taylor Otwell would like to introduce you to Larvel Octane, i.e. support for swoole/workerman with 6k+ reqs per seq on a basic desktop.
Laravel with swoole basically makes it as performant as elixir/phoenix.
But do you have to rewrite all your code async-style? And what are the implications for using non-async PHP libraries?
Presumably, you pick/choose which would use swoole or be delivered on php-fpm maybe run both with nginx proxying swoole, then your old code would just run sync and newer could run async if required --maybe for things like chat/websockets and not for just static pages.
> framework is 10-100 times slower than others
Seriously?
This is the hill you want to die on?
With swoole (laravel octane) you can up localhost from 200 reqs/sec to 6000+ .. I've tested phoenix and only gotten about 4600.
But just going off "plain laravel"...
According to techempower it STILL beats rails and django.
https://www.techempower.com/benchmarks/#section=data-r20&hw=...
> Overall, the official documentation is tutorial-oriented, with an abuse of videos. I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation
The docs are geared more towards beginner/intermediate users most advanced users go to the API/class docs, and look at the underlying code to get an idea of how things work internally, if you haven't done that then you're definitely not going to know how everything ties together.
Also there's plenty of plugins and an ide_helper package to generate metadata/etc to make it so you get damn good autocompletion in just about any ide and especially phpstorm, but I use vscode and used to use sublime both have great completions...
Seriously?
This is the hill you want to die on?
With swoole (laravel octane) you can up localhost from 200 reqs/sec to 6000+ .. I've tested phoenix and only gotten about 4600.
But just going off "plain laravel"...
According to techempower it STILL beats rails and django.
https://www.techempower.com/benchmarks/#section=data-r20&hw=...
> Overall, the official documentation is tutorial-oriented, with an abuse of videos. I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation
The docs are geared more towards beginner/intermediate users most advanced users go to the API/class docs, and look at the underlying code to get an idea of how things work internally, if you haven't done that then you're definitely not going to know how everything ties together.
Also there's plenty of plugins and an ide_helper package to generate metadata/etc to make it so you get damn good autocompletion in just about any ide and especially phpstorm, but I use vscode and used to use sublime both have great completions...
> with an abuse of videos
Are you thinking Laracasts is the documentation or something? I don't think there is a single video in the Laravel docs.
> I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation
You can't have looked very far, because even now the docs go back to 4.2 (released 2014).
Are you thinking Laracasts is the documentation or something? I don't think there is a single video in the Laravel docs.
> I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation
You can't have looked very far, because even now the docs go back to 4.2 (released 2014).
The magic is a problem in other ways as well, it confounds static analysis (Psalm has to have a separate plugin just to be able to profile it).
I'm not saying it's a fault of Laravel (yet) because the framework predates a lot of 7/8 stuff but they show absolutely no incentive towards making it better in that area.
Frankly, just pick symfony it's a better tool for longer lived projects, better documented (insanely better), better backwards compatibility.
I'm not saying it's a fault of Laravel (yet) because the framework predates a lot of 7/8 stuff but they show absolutely no incentive towards making it better in that area.
Frankly, just pick symfony it's a better tool for longer lived projects, better documented (insanely better), better backwards compatibility.
> It's unfortunate that the stink of old PHP is so powerful and that salaries are still lagging so far behind.
Could it be that there are less Rails developers than PHP developers so the Rails developers get higher salaries?
Could it be that there are less Rails developers than PHP developers so the Rails developers get higher salaries?
Rails also got traction in SF & other high paying areas at the right time. PHP had it’s chance to make establish itself in SF in the mid to late 2000s, but Ruby on Rails worked its way in as a fast prototyping tool that made efficient use of VC capital at a time that PHP was seen as a tool used by less serious developers. A lot of startups contact me about Rails to this day.
I have wondered how much of this is also due to markets. A lot of governments and security-centric nonprofits (eg hosptials) use PHP instead of Rails, which seems much more popular in startup land. It could even be that PHP is used fairly evenly across the whole US, while Rails is used more on the coasts.
Disclaimer: I don’t have hard facts or even anecdotes, I am a functional-first developer who marvels at any language which actually has jobs on the market :)
Disclaimer: I don’t have hard facts or even anecdotes, I am a functional-first developer who marvels at any language which actually has jobs on the market :)
Laravel docs are virtually non existent. The code comments are meh.
Their upgrades are frequent but are not backwards compatible. Many times after an upgrade we spent hours finding something that broke and was not documented in the upgrade guide.
Their code quality leaves much to be desired, and it very significantly will slow down every part of the site.
It is hard to call this a "extremely high quality framework" or even a "acceptable low quality framework". It may be possible to say this is unfortunately the best we've got in PHP.
Their upgrades are frequent but are not backwards compatible. Many times after an upgrade we spent hours finding something that broke and was not documented in the upgrade guide.
Their code quality leaves much to be desired, and it very significantly will slow down every part of the site.
It is hard to call this a "extremely high quality framework" or even a "acceptable low quality framework". It may be possible to say this is unfortunately the best we've got in PHP.
Also, can you kindly tell me how to upgrade from Rails 2.8 to 6.*?
I once scrapped a project trying to upgrade from 2.8 to 3.2..I see MANY open source rails apps that never upgrade because it's too damn hard they just keep building for an older version.
I once scrapped a project trying to upgrade from 2.8 to 3.2..I see MANY open source rails apps that never upgrade because it's too damn hard they just keep building for an older version.
Have you heard of https://railslts.com/? They provide security patches for old Rails versions
laravel.com covers all features that are available and enable to know how to use the features, what documentation do you need on top of that?
We had no problems with upgrades yet, but the eco system is pretty big and there is a tool to make upgrades https://laravelshift.com. Pretty helpful.
I'm wasn't digging around in other web frameworks yet, so I'm not sure how to rate the source.
We had no problems with upgrades yet, but the eco system is pretty big and there is a tool to make upgrades https://laravelshift.com. Pretty helpful.
I'm wasn't digging around in other web frameworks yet, so I'm not sure how to rate the source.
Um... what?!
Laravel has extremely comprehensive documentation:
• General purpose docs: https://laravel.com/docs/8.x/
• API-specific docs: https://laravel.com/api/8.x/index.html
Laravel updates are released frequently (which is a good thing). Including 2 years of bug fixes, and 3 years of security fixes, for LTS releases:
• Major version upgrades are clearly documented: https://laravel.com/docs/8.x/upgrade
• Every new update has clear changelogs: https://github.com/laravel/framework/releases
• Backwards-incompatible releases are annual: https://laravel.com/docs/8.x/releases#support-policy
I would love you to point me to where Laravel's code quality leaves "much to be desired". The source code is, generally speaking, excellent.
Laravel has extremely comprehensive documentation:
• General purpose docs: https://laravel.com/docs/8.x/
• API-specific docs: https://laravel.com/api/8.x/index.html
Laravel updates are released frequently (which is a good thing). Including 2 years of bug fixes, and 3 years of security fixes, for LTS releases:
• Major version upgrades are clearly documented: https://laravel.com/docs/8.x/upgrade
• Every new update has clear changelogs: https://github.com/laravel/framework/releases
• Backwards-incompatible releases are annual: https://laravel.com/docs/8.x/releases#support-policy
I would love you to point me to where Laravel's code quality leaves "much to be desired". The source code is, generally speaking, excellent.
> Laravel docs are virtually non existent. The code comments are meh.
I consider the Laravel documentation to be incredibly helpful.
I consider the Laravel documentation to be incredibly helpful.
Upgrading literally takes 1-2 hours MAX for any codebase and I've upgrading from MANY versions... I once updated a 4.2 app to 6.* ...that did take more than a few hours and there were some hitches but those would've been smoother if there was decent unit testing.
There's also some services that will basically use static analysis to tell you how to "safely" upgrade your project, what files need edited etc...
There's also some services that will basically use static analysis to tell you how to "safely" upgrade your project, what files need edited etc...
> 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.
Never heard of Laravel. Decided to take a look. First thing the intro documentation says to do is install something called 'Docker Desktop'. I'm good, thanks.
Why do I need Docker to play around with a web framework?
Never heard of Laravel. Decided to take a look. First thing the intro documentation says to do is install something called 'Docker Desktop'. I'm good, thanks.
Why do I need Docker to play around with a web framework?
“ Never heard of Laravel. Decided to take a look. First thing the intro documentation says to do is install something called 'Docker Desktop'. I'm good, thanks.
Why do I need Docker to play around with a web framework?”
Because modern web development is complex, and Docker helps make that burden less so.
You make it sound like you took one look at the docs, and that was just too much for you to go any further.
Don’t get into front end development, because you’ll lose your mind.
Because modern web development is complex, and Docker helps make that burden less so.
You make it sound like you took one look at the docs, and that was just too much for you to go any further.
Don’t get into front end development, because you’ll lose your mind.
OP has a valid point. What's so painful about Laravel deployment that it requires Docker? And that's just for Laravel, then you need another for your database. Then if you're working from home most broadband connections will not be suitable for containers. The whole Docker/Kubernetes cult is a farce as far as solo freelancers are concerned. Making it an idiomatic default just smacks of elitism.
This feels so un-PHP. One of the reasons PHP won is because it was relatively environmentally neutral.
There was a galaxy of free and cheap PHP software whose deployment process was basically "FTP everything up and plug in database credentials." At most, you might have to confirm you had PHP5+, but basically any random cheap hosting or default-config VPS would work with default or near-default settings.
In contrast, a lot of Rails and Node stuff was much more fragile by comparison-- I can recall trying to deploy other people's RoR applications and it turns into a huge rabbit hole of version matching and dependencies that aren't there out of the box and "OMG you never should have started with $distro."
The Docker mindset feels like a snarky response to "it works on my machine"; rather than actually making things reasonably environment-neutral, just ship your machine with every install!
There was a galaxy of free and cheap PHP software whose deployment process was basically "FTP everything up and plug in database credentials." At most, you might have to confirm you had PHP5+, but basically any random cheap hosting or default-config VPS would work with default or near-default settings.
In contrast, a lot of Rails and Node stuff was much more fragile by comparison-- I can recall trying to deploy other people's RoR applications and it turns into a huge rabbit hole of version matching and dependencies that aren't there out of the box and "OMG you never should have started with $distro."
The Docker mindset feels like a snarky response to "it works on my machine"; rather than actually making things reasonably environment-neutral, just ship your machine with every install!
Unfortunately the documentation does make it look like you need docker to get started. You don’t though. A litter further down in the docs there is a section for using just Composer, if you’re still interested in checking it out: https://laravel.com/docs/8.x#installation-via-composer
Aha! Thank you.
I haven't used PHP since ~2002/2003 so I wasn't aware of Composer, but this seems more along the lines of the original Rails tutorials which used gem to install rails.
I think learning things with as few components as possible is an important part of actually learning what you're working with, rather than just turning knobs.
I haven't used PHP since ~2002/2003 so I wasn't aware of Composer, but this seems more along the lines of the original Rails tutorials which used gem to install rails.
I think learning things with as few components as possible is an important part of actually learning what you're working with, rather than just turning knobs.
What happened to Homestead?
That seemed to be the recommended way of starting last I touched PHP professionally (4-5 years ago)
That seemed to be the recommended way of starting last I touched PHP professionally (4-5 years ago)
Alive and well. And if you haven’t seen the surrounding laravel ecosystem in 4-5 years I think you will be quite impressed. The amount of 1st party integrations and side projects is amazing.
https://laravel.com/docs/8.x/homestead
https://laravel.com/docs/8.x/homestead
Because getting a modern version of PHP, postgres, and redis up and running isn’t necessarily easy for your average beginner.
Does docker make it easier or harder though?
I was testing out Apache Superset the other day and it recommends using Docker to do so. I am not strong in Docker - I prefer to run things from scratch so I know exactly what is going on under the hood - but thought I'd give it a go.
I had so many problems getting it going. Part of it was the Superset instructions were slightly obsolete, but mostly it was this same problem in this issue[1] from 2016, which was closed in 2017, which is still obviously an active issue for new Docker users.
It seems to be just a relatively simple Linux filesystem permissions issue (or at least, that is how I resolved it quickly, just to get it working), but it strikes me as bizarre that this kind of thing could not be resolved with a better installer or docs or something.
I then ran into problems with the application running under Docker not being able to access the database in the host OS. Again there are a zillion resources for resolving this, going back years, with many dead ends as it has changed so much since then.
There's this hugely upvoted solution[2] on Stack Overflow - which works for Docker, but Superset is launched through docker-compose, so straight away a new user has to figure out the differences.
In PHP on a fresh Linux box, you can be up and running and developing on Debian/Ubuntu with two or three apt-get commands, depending on whether you need a database server. Adding Docker into this mix just seems like it would unnecessarily complicate things.
All that said, I appreciate once you're over the learning curve of Docker, it's super useful. I am finding myself increasingly reaching for it as an option to container-ise some setups away from my current setup, which is basically bash-scripted install processes on fresh VMs.
I was testing out Apache Superset the other day and it recommends using Docker to do so. I am not strong in Docker - I prefer to run things from scratch so I know exactly what is going on under the hood - but thought I'd give it a go.
I had so many problems getting it going. Part of it was the Superset instructions were slightly obsolete, but mostly it was this same problem in this issue[1] from 2016, which was closed in 2017, which is still obviously an active issue for new Docker users.
It seems to be just a relatively simple Linux filesystem permissions issue (or at least, that is how I resolved it quickly, just to get it working), but it strikes me as bizarre that this kind of thing could not be resolved with a better installer or docs or something.
I then ran into problems with the application running under Docker not being able to access the database in the host OS. Again there are a zillion resources for resolving this, going back years, with many dead ends as it has changed so much since then.
There's this hugely upvoted solution[2] on Stack Overflow - which works for Docker, but Superset is launched through docker-compose, so straight away a new user has to figure out the differences.
In PHP on a fresh Linux box, you can be up and running and developing on Debian/Ubuntu with two or three apt-get commands, depending on whether you need a database server. Adding Docker into this mix just seems like it would unnecessarily complicate things.
All that said, I appreciate once you're over the learning curve of Docker, it's super useful. I am finding myself increasingly reaching for it as an option to container-ise some setups away from my current setup, which is basically bash-scripted install processes on fresh VMs.
> Does docker make it easier or harder though?
I happen to do web development and run a Docker course and I will confidently say it's a lot easier based on support questions and overall feedback that I've gotten over the years.
Because the alternative involves a ton of manual steps that every individual needs to take, for example with Python (and this applies to most languages / ecosystems with tiny changes):
- Which version of Python do I install? How do I install it on Windows 10? What about macOS? What's the instructions look like on my distro of Linux?
- How do I handle multiple versions of my programming language or install the language without the root user?
- I need to run Postgres, how do I install that on my OS?
- I need to run Redis, how do I install that on my OS?
- I need to run a specific version of Postgres / Redis for this project but a different version for another project, how to set this up?
- I need to use Webpack, how do I get Node installed and set all of that up
- How can I easily run all of my app's dependent services at once (web + worker + webpack + database + cache) without having to open multiple terminals or discover language specific tools with their own config files
- How can I use environment variables in my app that are loaded from a file?
- My app needs a library that requires a C dependency to be compiled to use it, how do I get that working on my OS?
Now imagine you're just getting into programming and want to build a web app with Flask, Django, Laravel, Rails, Phoenix or any other language / framework. You're going to need to do this for pretty much every tech stack and the learning curve for this stuff is really high when you're a beginner. There's so many unknown unknowns that lead to dead ends causing folks to get really frustrated and just say fuck it and never start.
But with Docker, you install Docker Desktop and technically you can treat it as a black box where everything is on a need to know basis. As long as you can find a reasonable base project to work off of getting started is as easy as installing Docker and running docker-compose up --build, and waiting 5-10 minutes. Now you can focus on learning the important thing (web development using the framework you've picked).
In most cases that works very well. Sure there's some installation related issues along the way but with tens of thousands of folks who have taken one of my courses using Docker, this a huge minority and it's usually something that's easily fixable (I offer support and deal with questions like this once in a while).
I happen to do web development and run a Docker course and I will confidently say it's a lot easier based on support questions and overall feedback that I've gotten over the years.
Because the alternative involves a ton of manual steps that every individual needs to take, for example with Python (and this applies to most languages / ecosystems with tiny changes):
- Which version of Python do I install? How do I install it on Windows 10? What about macOS? What's the instructions look like on my distro of Linux?
- How do I handle multiple versions of my programming language or install the language without the root user?
- I need to run Postgres, how do I install that on my OS?
- I need to run Redis, how do I install that on my OS?
- I need to run a specific version of Postgres / Redis for this project but a different version for another project, how to set this up?
- I need to use Webpack, how do I get Node installed and set all of that up
- How can I easily run all of my app's dependent services at once (web + worker + webpack + database + cache) without having to open multiple terminals or discover language specific tools with their own config files
- How can I use environment variables in my app that are loaded from a file?
- My app needs a library that requires a C dependency to be compiled to use it, how do I get that working on my OS?
Now imagine you're just getting into programming and want to build a web app with Flask, Django, Laravel, Rails, Phoenix or any other language / framework. You're going to need to do this for pretty much every tech stack and the learning curve for this stuff is really high when you're a beginner. There's so many unknown unknowns that lead to dead ends causing folks to get really frustrated and just say fuck it and never start.
But with Docker, you install Docker Desktop and technically you can treat it as a black box where everything is on a need to know basis. As long as you can find a reasonable base project to work off of getting started is as easy as installing Docker and running docker-compose up --build, and waiting 5-10 minutes. Now you can focus on learning the important thing (web development using the framework you've picked).
In most cases that works very well. Sure there's some installation related issues along the way but with tens of thousands of folks who have taken one of my courses using Docker, this a huge minority and it's usually something that's easily fixable (I offer support and deal with questions like this once in a while).
Late reply, sorry, forgot I wrote this.
All points taken! I just get frustrated because I figure if the developer is taking care of building a Dockerfile or whatever it is with all of that stuff sorted out for me, providing at least those build instructions as part of the README is enough for weird users like me.
Then I can spin up my own VPS/VM with the dependencies myself, which removes the entire black box nature of it.
I get that most people don't want to do that and indeed embrace the black box, but I've never worked anywhere where I could spin up a random application in Docker in any sort of Production or even near-Production capacity and say with a straight face I'd done due diligence in what was going on under the hood. (Maybe people don't use it for this ever though.)
I would probably be more on board if I'd ever had a single Docker experience that was just "install docker and run something" and it worked, but every single time I have run into problems.
Realised I forgot to include my references in my previous post. Again, appreciate these problems are probably old hat for regular users, but for people coming in cold they're just pains in the ass.
1. https://stackoverflow.com/questions/48957195/how-to-fix-dock...
2. https://stackoverflow.com/questions/24319662/from-inside-of-...
All points taken! I just get frustrated because I figure if the developer is taking care of building a Dockerfile or whatever it is with all of that stuff sorted out for me, providing at least those build instructions as part of the README is enough for weird users like me.
Then I can spin up my own VPS/VM with the dependencies myself, which removes the entire black box nature of it.
I get that most people don't want to do that and indeed embrace the black box, but I've never worked anywhere where I could spin up a random application in Docker in any sort of Production or even near-Production capacity and say with a straight face I'd done due diligence in what was going on under the hood. (Maybe people don't use it for this ever though.)
I would probably be more on board if I'd ever had a single Docker experience that was just "install docker and run something" and it worked, but every single time I have run into problems.
Realised I forgot to include my references in my previous post. Again, appreciate these problems are probably old hat for regular users, but for people coming in cold they're just pains in the ass.
1. https://stackoverflow.com/questions/48957195/how-to-fix-dock...
2. https://stackoverflow.com/questions/24319662/from-inside-of-...
Docker on non-Linux OS's is just a VM. You could do the same by starting a linux VM w/ the system environment you're deploying on, and save the Docker overhead.
> Docker on non-Linux OS's is just a VM. You could do the same by starting a linux VM w/ the system environment you're deploying on, and save the Docker overhead.
It's not close to the same user experience.
- If you roll a custom VM you need to first pick a hypervisor. Are you going to use vmware workstation, virtualbox or the native type-1 hypervisor on your OS such as hyper-v on Windows or hyperkit on Linux?
- Are you going to set up that VM using your hypervisor's UI or look into using something like Vagrant?
- What private network subnet are you going to choose when you set up your static IP to your VM?
- How will you get file sharing to work really well (complete with inotify support on Windows)?
- What about starting and stopping the VM for each project? What if you wanted to run a few projects at once with different exposed ports, how will you manage all of these VMs and the resources they've created?
- What if you're running native Linux and still want to isolate everything? Now go back to the first bullet point and add KVM, etc. into the mix
- Which Linux distro are you going to choose to run in the VM? If you're using Vagrant does your Vagrant box's OS support all of the guest features of your hypervisor?
- Now that you have your base Linux environment in a VM, how are you going to set up all of those bullet points I provided in my previous reply. It's back to the drawing board on having to do everything yourself but now on Linux.
A beginner developer is not going to have the same experience doing all of that instead of installing Docker Desktop and running docker-compose up --build. Docker is adding massive value from a convenience point of view and it gets much better once you go beyond your local dev environment too. Now you have a way to easily share your exact project set up process with another developer on any major OS and you can run your containers in the same way on a VPS if you deploy your app there too.
It's not close to the same user experience.
- If you roll a custom VM you need to first pick a hypervisor. Are you going to use vmware workstation, virtualbox or the native type-1 hypervisor on your OS such as hyper-v on Windows or hyperkit on Linux?
- Are you going to set up that VM using your hypervisor's UI or look into using something like Vagrant?
- What private network subnet are you going to choose when you set up your static IP to your VM?
- How will you get file sharing to work really well (complete with inotify support on Windows)?
- What about starting and stopping the VM for each project? What if you wanted to run a few projects at once with different exposed ports, how will you manage all of these VMs and the resources they've created?
- What if you're running native Linux and still want to isolate everything? Now go back to the first bullet point and add KVM, etc. into the mix
- Which Linux distro are you going to choose to run in the VM? If you're using Vagrant does your Vagrant box's OS support all of the guest features of your hypervisor?
- Now that you have your base Linux environment in a VM, how are you going to set up all of those bullet points I provided in my previous reply. It's back to the drawing board on having to do everything yourself but now on Linux.
A beginner developer is not going to have the same experience doing all of that instead of installing Docker Desktop and running docker-compose up --build. Docker is adding massive value from a convenience point of view and it gets much better once you go beyond your local dev environment too. Now you have a way to easily share your exact project set up process with another developer on any major OS and you can run your containers in the same way on a VPS if you deploy your app there too.
Redis and postgres are an apt install away. I can't imagine redis would throw you. Postgres use to require using a separate user to login through the shell.
[deleted]
You don't, that's just the quickest/easiest way to get started. If you read slightly further, you'll get to the section for people who already have the dependencies installed directly: https://laravel.com/docs/8.x#installation-via-composer
From the looks of things it's because it sets up a full project with MySQL and Redis rather than just a codebase.
> Why do I need Docker to play around with a web framework?
PHP is server side, not frontend like React or Angular
PHP is server side, not frontend like React or Angular
I think OP was referring to Laravel as the web framework, not PHP.
Maybe but I would find even that is more confusing.
[deleted]
It's nice to see PHP adding useful things like enums and async (green threads). My foray into Web development started with Perl, but quickly segued into PHP with how much simpler it felt. The ability to hop into vim on your server (or use CPanel back in the day) and edit your site live was exciting back then – but now that very thought makes me shudder with what could go wrong, haha.
While I've moved onto JVM languages and Rust professionally, I do hope PHP will continue getting future generations excited about Web development and building out their ideas quickly.
FYI: Not sure if the author will see this but some spelling mistakes in the article. [0] E.g. s/reslease/release/
0. https://stitcher.io/blog/php-in-2021#the-community
While I've moved onto JVM languages and Rust professionally, I do hope PHP will continue getting future generations excited about Web development and building out their ideas quickly.
FYI: Not sure if the author will see this but some spelling mistakes in the article. [0] E.g. s/reslease/release/
0. https://stitcher.io/blog/php-in-2021#the-community
> FYI: Not sure if the author will see this but some spelling mistakes in the article. [0] E.g. s/reslease/release/
Thanks, I saw it :)
Thanks, I saw it :)
Just yesterday I hopped into a server, attached to a running app, and did the copy/pasta thing to dynamically add some debug logging to a running app. It worked great!
What do they want async for? PHP's purpose is to run once to generate one HTTP response - they'd already forgotten this by inventing frameworks, but adding async seems to especially have forgotten this.
PHP already had curl_multi_perform which is very useful for running child tasks, but I'm not sure you need much more than that.
PHP already had curl_multi_perform which is very useful for running child tasks, but I'm not sure you need much more than that.
The usual asynchronous stuff like fetching data from two APIs to then prepare the HTML response to the user. Today, it's sequential, which is fine for DB calls to localhost, but less fine with API calls.
Well that’s one purpose of php.
My workloads involve billions of php executions daily that have nothing to do with http or Apache or serving pages. Lambda and cli based jobs mainly.
PHP can do a lot of things if you stick with it and don’t jump to the next shiny object. Async helps with this.
My workloads involve billions of php executions daily that have nothing to do with http or Apache or serving pages. Lambda and cli based jobs mainly.
PHP can do a lot of things if you stick with it and don’t jump to the next shiny object. Async helps with this.
People also use PHP to write backend scripts, without web use at all.
While the original and primary purpose may have been for personal home pages, it has evolved considerably since then. Consider an accounting/aggregate billing script for a PHP application that runs on a scheduler. That isn't dependent on the web necessarily, but it does interface with the moving parts of the overall application. Async would be great here.
While the original and primary purpose may have been for personal home pages, it has evolved considerably since then. Consider an accounting/aggregate billing script for a PHP application that runs on a scheduler. That isn't dependent on the web necessarily, but it does interface with the moving parts of the overall application. Async would be great here.
Another use of async is to build other kinds of servers like websockets, which need to hold long-term connections. ReactPHP + Ratchet works great for that in PHP. Currently it works with an event loop (multiple implementations under the hood, like libev, libuv, etc) similarly to Node. Fibers should make the internals of ReactPHP better, but it'll barely change anything in userland.
PHP has astounding longevity. In maintaining my personal websites (static pages, web toys, projects with my writing groups), I always ask myself: how will I keep this running in 20 years?
It's unrealistic to think that languages will stay static over 20 years -- servers get rebuilt, old versions languages get deprecated, frameworks disappear. So the question becomes
- will I know how to fix or rebuild this, even if I don't touch the code more than once every 5-10 years? - what is sufficiently resilient to mean that "mean time between rebuilds" is as long as possible?
Over all that time, what's lasted best are CGIs (Python/Perl) and PHP, running behind Apache.
I don't use PHP day-to-day, so changes in the language don't affect me much. But for keeping the history of the web alive, it is an unparalleled tool, and its proven commitment to longevity is why I still reach for it.
Separately: I think that longevity is a question we should ask ourselves more about the web. New ideas often come from experiencing old (even failed) ideas -- but if those old ideas just disappear, we lose some of our ability to progress.
It's unrealistic to think that languages will stay static over 20 years -- servers get rebuilt, old versions languages get deprecated, frameworks disappear. So the question becomes
- will I know how to fix or rebuild this, even if I don't touch the code more than once every 5-10 years? - what is sufficiently resilient to mean that "mean time between rebuilds" is as long as possible?
Over all that time, what's lasted best are CGIs (Python/Perl) and PHP, running behind Apache.
I don't use PHP day-to-day, so changes in the language don't affect me much. But for keeping the history of the web alive, it is an unparalleled tool, and its proven commitment to longevity is why I still reach for it.
Separately: I think that longevity is a question we should ask ourselves more about the web. New ideas often come from experiencing old (even failed) ideas -- but if those old ideas just disappear, we lose some of our ability to progress.
> It's unrealistic to think that languages will stay static over 20 years
Depends on the language really. JavaScript? Yeah, good luck even spinning up a year old project on NodeJS without any breakages. Slightly better situation in the browser but most likely you'll need to change something if you're using NPM.
On the other hand, Clojure hasn't had a breaking change in their core API in almost 14 years now, since you can change the language yourself without affecting the core API for others, so new features are usually launched as libraries instead of changing the core API.
Coming from the JS world, being able to spin up old Clojure projects without having to do any changes is really a undervalued feature of the stability of Clojure.
Depends on the language really. JavaScript? Yeah, good luck even spinning up a year old project on NodeJS without any breakages. Slightly better situation in the browser but most likely you'll need to change something if you're using NPM.
On the other hand, Clojure hasn't had a breaking change in their core API in almost 14 years now, since you can change the language yourself without affecting the core API for others, so new features are usually launched as libraries instead of changing the core API.
Coming from the JS world, being able to spin up old Clojure projects without having to do any changes is really a undervalued feature of the stability of Clojure.
> Depends on the language really. JavaScript? Yeah, good luck even spinning up a year old project on NodeJS without any breakages. Slightly better situation in the browser but most likely you'll need to change something if you're using NPM.
Is that really true? I can't think of much in terms of older nodeJS stuff that would break on modern node (and with N, you can just install an older version of node).
Is that really true? I can't think of much in terms of older nodeJS stuff that would break on modern node (and with N, you can just install an older version of node).
Over long periods of time, and assuming I chose stable 3rd party libraries in the first place, I've found that breakages are down to (a) language changes, and (b) patched security holes. And that's where the risk of a majorly changed (or disappeared) library comes in, triggering a re-write. So it's not just a matter of sticking with the old stuff, unfortunately.
Interesting! I'm not from a Clojure world but that stability is great.
> PHP has astounding longevity. In maintaining my personal websites (static pages, web toys, projects with my writing groups), I always ask myself: how will I keep this running in 20 years?
PHP originally stands for Person Home Page. really!
In a post called "PHP in 2021" we really can't omit https://bref.sh/ -- it allows running PHP apps on AWS Lambda effortlessly. With all the serverless craze, it's a very important piece of the ecosystem. After writing PHP apps for two decades, I am absolutely stunned how easy it is.
Amazon blogged about it at https://aws.amazon.com/blogs/compute/the-serverless-lamp-sta...
Amazon blogged about it at https://aws.amazon.com/blogs/compute/the-serverless-lamp-sta...
So since only a few decades I can do this:
1. create a shared hosting account for almost nothing (or literally nothing: https://www.000webhost.com/free-php-hosting)
2. write index.php
3. upload index.php
4. ???
5. profit!
1. create AWS Account
2. follow these "simple" (nothing in AWS is simple) 4 steps to create AWS keys: https://bref.sh/docs/installation/aws-keys.html
7. #npm install -g serverless
8. #serverless config credentials --provider aws --key <key> --secret <secret>
9. #composer require bref/bref
10. #vendor/bin/bref init
11. edit index.php
12. #serverless deploy
13. ???
14. no profit, because your stuff went viral and your AWS bill is killing you
I don't get it - the cheapest webhosts ($3/month) all let you run PHP - why would I need a cloud function when I have an always-on machine?
And if it's for something with high traffic, why would you want a cloud function anyway? I thought they are meant for "runs sporadically, so why have a machine that's always on?" setup.
And if it's for something with high traffic, why would you want a cloud function anyway? I thought they are meant for "runs sporadically, so why have a machine that's always on?" setup.
I am using a lambda to answer a webhook. The lambda function writes into SQS and in turns, SQS calls a queue worker automatically.
Is this possible without AWS? Certainly. I was one of the two people who wrote the queue subsystem for Drupal more than a decade ago. And yet, AWS here does away with all the scalability concerns both up and down.
Is this possible without AWS? Certainly. I was one of the two people who wrote the queue subsystem for Drupal more than a decade ago. And yet, AWS here does away with all the scalability concerns both up and down.
When load varies you'll only pay while it's in use. Web-hosts without VMs or containers often promise a lot until you find their shadows limits. And those with VMs and containers can come out more expensive for some workloads.
The landscape is changing too. So if your work is stateless or relatively low bandwidth, and has variable load then it's probably worth trying FAAS.
The landscape is changing too. So if your work is stateless or relatively low bandwidth, and has variable load then it's probably worth trying FAAS.
With your webhost, you have to setup and maintain the server, including patching/updating it, setting up SSL, etc.
I used to do that for side projects, but I've had too many servers, and maintaining them was a pain.
For something with high traffic, Lambda provides the instant scalability. Imagine servers autoscaling, but instantly. And again, without having to setup or maintain that.
I used to do that for side projects, but I've had too many servers, and maintaining them was a pain.
For something with high traffic, Lambda provides the instant scalability. Imagine servers autoscaling, but instantly. And again, without having to setup or maintain that.
> With your webhost, you have to setup and maintain the server
You're confusing a root server or a VPS with a webhost aka "shared hosting", where the hosting service takes care of Let's Encrypt certificates, and scheduled downtime for patching.
You're confusing a root server or a VPS with a webhost aka "shared hosting", where the hosting service takes care of Let's Encrypt certificates, and scheduled downtime for patching.
For what it's worth, PHP has always been kinda "serverless". You just point the PHP interpreter at a file, and it runs the script contained in the file!
That's how literally anything which is "executable" works. You just point the interpreter (kernel, ld-linux, php, python, ...) at a file, and it runs the file.
Exactly, and PHP brings this simple intuitive behavior to the web. You just point your browser at a .php file, and the server runs the file for you.
Sure, once you've set up the web server, and PHP itself, and installed (usually through a not-easily-wget'able link) the program you want, and configured it, and set up its permissions properly...
FWIW Bref is cool, but it's AWS-only and still has a couple of orders of magnitude fewer daily installations than Laravel: https://packagist.org/packages/bref/bref/stats vs https://packagist.org/packages/laravel/framework/stats.
> Still no support for generics, unfortunately
Huh? PHP is a dynamic language, you already have them in principle.
Usually you can just have no type and use instanceof, but also requiring the parameter to be an interface does the job in most cases if you need more clarity.
Edit: There's also method_exists! Also a whole heap of other tools in the toolbox https://www.php.net/manual/en/ref.classobj.php
Huh? PHP is a dynamic language, you already have them in principle.
Usually you can just have no type and use instanceof, but also requiring the parameter to be an interface does the job in most cases if you need more clarity.
Edit: There's also method_exists! Also a whole heap of other tools in the toolbox https://www.php.net/manual/en/ref.classobj.php
You have them in theory — you can use generic concepts to model operations — but that dynamism also allows you to break any generic model that might exist.
For example I might say that a function takes a parameter of type "Traversable<string>", but there's nothing stopping me manipulating that object and turning it into a "Traversable<int>" because of that same dynamism.
It might be possible in the future to introduce reified generics which could be guaranteed by the engine, though that may end up being too difficult to add and maintain. In the meantime static analysis tools (like Psalm, which I created) are able to model operations using generics described in docblocks, which works pretty well.
For example I might say that a function takes a parameter of type "Traversable<string>", but there's nothing stopping me manipulating that object and turning it into a "Traversable<int>" because of that same dynamism.
It might be possible in the future to introduce reified generics which could be guaranteed by the engine, though that may end up being too difficult to add and maintain. In the meantime static analysis tools (like Psalm, which I created) are able to model operations using generics described in docblocks, which works pretty well.
Traits!!
When 7.4 was released, with FFI now available, I had the crazy idea to make a cli text editor in PHP[1] (based on kilo[2], and since 8 has come out, with the addition of the PHPToken class, highlighting PHP with PHP has gotten easier.
1. https://git.timshomepage.net/timw4mail/php-kilo 2. https://viewsourcecode.org/snaptoken/kilo/
1. https://git.timshomepage.net/timw4mail/php-kilo 2. https://viewsourcecode.org/snaptoken/kilo/
As someone who works with Rails and Laravel, one of the huge benefits I find working with PHP/Laravel are the speed and consistency of releases. PHP seems to release versions more frequently, and Laravel tags every week. It means there's much less lead time to work with new features/functionality as it becomes available (when it's stable, rather than running on edge).
I once came back to a Laravel project after just one year of working on other projects and had to go through several upgrade guides just to stay up to date. Most changes were quite trivial (yet annoying to make), like namespace changes and other things that should probably have been weeded out before ever making it into a release... It’s why I prefer Symfony if I absolutely had to work with PHP nowadays.
Laravel did release major versions every 6 months in the past. The changes have not been much and https://laravelshift.com is able to it automatically.
They‘ve now changed to yearly major releases because not everyone is able to upgrade every 6 months.
My beef with PHP is not so much the language itself, but the weird community that surrounds it.
The FIG standard that forbids TAB for indentation (which is perfectly legal in PHP), the notion that classes should be either abstract or final, the micro-optimizations (thou must use single quotes, things like that).
I don't think anyone can tell anyone how to write PHP, because nobody knows how to get it right (myself included). Yet in my many years of coding in PHP, there's been more and more tooling and so-called "standards" that do exactly this.
The FIG standard that forbids TAB for indentation (which is perfectly legal in PHP), the notion that classes should be either abstract or final, the micro-optimizations (thou must use single quotes, things like that).
I don't think anyone can tell anyone how to write PHP, because nobody knows how to get it right (myself included). Yet in my many years of coding in PHP, there's been more and more tooling and so-called "standards" that do exactly this.
FIG stands for Framework Interop Group. At its peak, it was a place for representatives of the major PHP frameworks and libraries to hash out ways for their projects to cooperate more effectively, and some of the standards - such as PSRs 3, 4, and 7, have been extremely useful.
If you're not writing a framework or library for others to use, nothing the FIG says is necessarily relevant to you.
And in fact, even if you are, Doctrine, Guzzle, Laravel, and Symfony have all left the FIG, so it has even less relevance now.
So...it's a group that used to make standards for a very specific audience, and now mostly doesn't, in part because all of the most important members of that audience got fed up and left.
That's your biggest beef with PHP? Just adopt whatever standards you like.
If you're not writing a framework or library for others to use, nothing the FIG says is necessarily relevant to you.
And in fact, even if you are, Doctrine, Guzzle, Laravel, and Symfony have all left the FIG, so it has even less relevance now.
So...it's a group that used to make standards for a very specific audience, and now mostly doesn't, in part because all of the most important members of that audience got fed up and left.
That's your biggest beef with PHP? Just adopt whatever standards you like.
If you look at a language like Go, it's rare to find a project not using the standard gofmt. PSR-12 states that "the benefit of this guide is not in the rules themselves but the sharing of those rules". The guidelines to use single quotes and tabs vs spaces exist for the sake of consistency, to remove that subjective argument from the conversation.
I'm a fan of PHP in general, but I've never liked the FIG coding standards. Common interfaces for logging, caching, and the like are useful, though, so I don't think the PSRs are all useless.
After using more languages with a distinction between strings and characters, a string in single quotes starts to look weird.
Although there are several questionable "best practices" in general, I have found that stricter typing in PHP has generally been a plus.
After using more languages with a distinction between strings and characters, a string in single quotes starts to look weird.
Although there are several questionable "best practices" in general, I have found that stricter typing in PHP has generally been a plus.
PHP's chaotic developer community, as well as the "there are 1000 ways to do the same thing" philosophy that it inherited from Perl, is fertile ground for those who wish to say that they know better than others. This occurs in every level, from which quote character to use, all the way to how to arrange your namespaces.
The PSR's also reflect this tendency. They're a mix of extremely useful standardization (e.g. PSR-4) and hardcode nitpicking about whitespace (e.g. PSR-12). Take what you need, focus on maintainability and interoperability, and ignore the noise.
The PSR's also reflect this tendency. They're a mix of extremely useful standardization (e.g. PSR-4) and hardcode nitpicking about whitespace (e.g. PSR-12). Take what you need, focus on maintainability and interoperability, and ignore the noise.
Thank you so much, this is good advice and it's what I'm doing right now. Much like how a carpenter carefully picks the right tools to work with.
Writing code isn't an exact science and much like in probably any other profession, this requires us to twist and bend or even break the rules in order to create something beautiful. As a programmer, it's desirable to adhere to SOLID principles but without freedom of expression this is pretty much impossible.
A good mix of constraints and creativity can take years to develop and should probably keep developing over time as one exercises the art.
Writing code isn't an exact science and much like in probably any other profession, this requires us to twist and bend or even break the rules in order to create something beautiful. As a programmer, it's desirable to adhere to SOLID principles but without freedom of expression this is pretty much impossible.
A good mix of constraints and creativity can take years to develop and should probably keep developing over time as one exercises the art.
FIG standards are explicitly interoperability standards. They make it easy for anyone to jump into a new company or open source project with minimal friction and minimal bikeshedding.
If you or your team don't care about that and want to do something different, there's nothing stopping you. Even the Symfony team, who contributed to these standards and largely follow them, have gone their own way when they thought it was worth the trade-off.
If you or your team don't care about that and want to do something different, there's nothing stopping you. Even the Symfony team, who contributed to these standards and largely follow them, have gone their own way when they thought it was worth the trade-off.
I never heard of the abstract/final thing, except maybe from one or two coworkers that don't produce much but talk about the language all day and will berate you about protected/private or ordering your "use" alphabetically.
It's true that the PHP community has a bit of an inferiority complex which result sometimes in abuse of patterns, like suddenly someday everyone wanted to do refactor everything with DDD/CQRS/etc for no good reason.
It's true that the PHP community has a bit of an inferiority complex which result sometimes in abuse of patterns, like suddenly someday everyone wanted to do refactor everything with DDD/CQRS/etc for no good reason.
FWIW, I think the rule about classes being either abstract (like interfaces) or final makes sense. Inheritance is the biggest OOP anti-pattern, producing most headache and bugs. It cannot be completely removed from an OO language like PHP, but can be nicely replaced with composition using interfaces / abstract classes and traits.
It's just a linting standard. You're free to use it or not and some linters support the entire specification as-is but with tabs instead.
[deleted]
I wish there was a nodejs equivalent to Laravel
This is very surprising to me honestly. Yeah, folks have pointed out some of the big players, but none of them have really risen above the competition.
You would think NodeJS would have a clear cut dominant, monolithic web framework by now but there isn’t. Everyone seems to be happy to throw together hodge-podge Express apps.
You would think NodeJS would have a clear cut dominant, monolithic web framework by now but there isn’t. Everyone seems to be happy to throw together hodge-podge Express apps.
I'm not sure whether it's due to the language or community, but it's the same with Go: there's a preference for libraries and very light frameworks over full-stack like Django/Rails/Laravel.
That is because everyone is writing SPAs with node and thus only needs an api like express for the backend stuff.
Even for writing APIs a monolithic web framework can be useful.
We're building a Django + React web app, and Django brings many things to the table, for example the admin panel, an opinionated structure, and many other goodies. Much better dev experience than just Express for a small team, IMO.
We're building a Django + React web app, and Django brings many things to the table, for example the admin panel, an opinionated structure, and many other goodies. Much better dev experience than just Express for a small team, IMO.
True but there is alternatives like NestJS for example. So there is some stuff a bit like Django for node as well but I'll admit that they are less common.
I don't know why, maybe it's the culture of node/npm that you just pick stuff from a basket instead of getting handed a big finished thing whatever you like it or not.
I don't know why, maybe it's the culture of node/npm that you just pick stuff from a basket instead of getting handed a big finished thing whatever you like it or not.
Why not Django REST Framework if you're feeding an SPA?
I would say next.js comes closest for a ‘nodejs server framework’ for me. It’s really great to only use one language for frontend, backend and templating.
But to really come close to laravel I would add something like blitzjs.com or redwoodjs.com. Blitz is built on top of next and adds ORM (Prisma), code generators, even authentication out of the box, so it's really close to Laravel. Redwood is its own thing AFAIK, but also aims to be closer to a full stack framework.
Adonis.js is the closest one imo
There are multiple projects like this in beta now. It seems like the javascript community has become open for the idea of monoliths, so it will be interesting to see how it plays out.
Look into Sails.js -- it's not the same but it's something
I'd take a look at Nest.
Nest.js is more like Angular
I think you're thinking of Next/Nuxt. I'm a laravel dev but have tried every framework under the sun cause I get bored.
Next/Nuxt are basically react/vue SSR / Server Side Rendering or SPA frameworks... which seems more like Angular..no?
Nest.js is a fullstack backend framework more like fastify or express and has guides on connecting databases, graphql, etc....
Personally, if I were going to go with node, I'd choose nest.js or feathers or express as they have the best ecosystems ... but none seem as mature as laravel, rails, or django.
Next/Nuxt are basically react/vue SSR / Server Side Rendering or SPA frameworks... which seems more like Angular..no?
Nest.js is a fullstack backend framework more like fastify or express and has guides on connecting databases, graphql, etc....
Personally, if I were going to go with node, I'd choose nest.js or feathers or express as they have the best ecosystems ... but none seem as mature as laravel, rails, or django.
The last sentence in their philosophy section reads "
The architecture is heavily inspired by Angular." https://docs.nestjs.com/#philosophy
Maybe they were inspired by the way it was built/laid out, but angular is more in the vein of react/vue.
Nest.js is more like feathers, actix for rust, flask, lumen, etc... it's not as opinionated iirc last time I played with it... so there's not a specific way everything is organized like a rails or laravel project... if I were doing node it'd probably be nest, but w/ swoole/octane and knowing laravel inside/out I'm gonna lose time/productivity switching to anything else, so I stick w/ what I know.
Nest.js is more like feathers, actix for rust, flask, lumen, etc... it's not as opinionated iirc last time I played with it... so there's not a specific way everything is organized like a rails or laravel project... if I were doing node it'd probably be nest, but w/ swoole/octane and knowing laravel inside/out I'm gonna lose time/productivity switching to anything else, so I stick w/ what I know.
Adonis.js is is basically a Laravel clone for Node
I like PHP but dislike the PHP frameworks.
Why?
Most languages have great DX. It seems like the majority of PHP frameworks have very bad DX. I would consider using Laravel or Symfony.
I used to work both with Go and PHP.
At first when I started digging into Go I thought that eventually I'll replace platform for all my future PHP projects. But it never happened.
Every time I should implement business logic and info exchange with database I immediately became frustrated with so much boilerplate code of Golang. In comparison, writing such code in PHP is real breathe.
But suddenly I've got used to Go speed and want to get the same benefits for my PHP APIs. So I've implemented my own framework with low latency and hight throughput in mind. It beats many Go frameworks on TechEmpower Benchmarks! Now I feel like I found epiphany finally :)
https://github.com/gotzmann/comet
At first when I started digging into Go I thought that eventually I'll replace platform for all my future PHP projects. But it never happened.
Every time I should implement business logic and info exchange with database I immediately became frustrated with so much boilerplate code of Golang. In comparison, writing such code in PHP is real breathe.
But suddenly I've got used to Go speed and want to get the same benefits for my PHP APIs. So I've implemented my own framework with low latency and hight throughput in mind. It beats many Go frameworks on TechEmpower Benchmarks! Now I feel like I found epiphany finally :)
https://github.com/gotzmann/comet
I am not a programmer, and I have hired developers to build websites for me for close to 15 years now.
I love PHP. Two reasons. One, because this was the language I learned to code when I started off. So, it's easy for me to understand stuff my developers tell me.
More importantly, the language is so mainstream that the developers I work with are quite cheap to hire. The more sophisticated a language is, the fewer the programmers available for hire, which shoots up the costs with no visible changes to me on the front-end.
I'm currently building a simple search-engine like project - all on PHP. We have been testing it right now, and it's fast and usable - and I am not regretting my decision to use PHP for this; yet.
I love PHP. Two reasons. One, because this was the language I learned to code when I started off. So, it's easy for me to understand stuff my developers tell me.
More importantly, the language is so mainstream that the developers I work with are quite cheap to hire. The more sophisticated a language is, the fewer the programmers available for hire, which shoots up the costs with no visible changes to me on the front-end.
I'm currently building a simple search-engine like project - all on PHP. We have been testing it right now, and it's fast and usable - and I am not regretting my decision to use PHP for this; yet.
I’m primarily a javascript dev who had to dive into php and wordpress this past year for a client.[0] The php docs often drive me nuts with their range of what info and examples are available per feature, and the language’s naming can be funny at times with a lack of consistency...
But I really like it. Php writes and reads like javascript. And working with dates has actually been pretty fun - I like the natural language manipulation layer it provides, ie: `last Sunday`, etc. And the built in url parsing.
I’m happy to have added it to my tool belt!
[0] https://www.zionbaltimore.org
But I really like it. Php writes and reads like javascript. And working with dates has actually been pretty fun - I like the natural language manipulation layer it provides, ie: `last Sunday`, etc. And the built in url parsing.
I’m happy to have added it to my tool belt!
[0] https://www.zionbaltimore.org
I no longer use PHP, but I have to say, I truly appreciate the regular articles on the state of PHP by @brendt_gd. I think they're absolutely awesome, and I wish I could get the same kind of regular rundowns for Python, for example. :)
So basically PHP is still catching up to Hack and but not quite there yet?
Hack might be better from a language design point of view, but most people outside of Facebook seem to have lost interest in it once PHP 7 caught up to it performance-wise.
With Hack's extensive static type checking and even contexts / coeffects, it's much more than just performance. The bigger your system grows, the more pain it removes.
You still can mix it with plain PHP, much like you can mix TypeScript with plain JavaScript.
I wish high-profile PHP projects, like Nextcloud, migrated to Hack eventually; it can be done piecemeal.
You still can mix it with plain PHP, much like you can mix TypeScript with plain JavaScript.
I wish high-profile PHP projects, like Nextcloud, migrated to Hack eventually; it can be done piecemeal.
> With Hack's extensive static type checking and even contexts / coeffects
Have you used contexts/coeffects?
My understanding is that it's still yet to be fully rolled out to WWW, and nobody outside FB has yet played around with it. IMO it still has some DX issues (https://github.com/facebook/hhvm/issues/8828) and the examples given in documentation don't actually work in real life (https://github.com/hhvm/user-documentation/issues/1016).
Have you used contexts/coeffects?
My understanding is that it's still yet to be fully rolled out to WWW, and nobody outside FB has yet played around with it. IMO it still has some DX issues (https://github.com/facebook/hhvm/issues/8828) and the examples given in documentation don't actually work in real life (https://github.com/hhvm/user-documentation/issues/1016).
Not extensively; rather, I had to pay attention to the limitations that a particular context enforces.
It's definitely a fresh feature, iirc rolled out last winter.
It's definitely a fresh feature, iirc rolled out last winter.
Ironically, Nextcloud is moving to Golang.
https://github.com/nextcloud/server/issues/16726
https://github.com/nextcloud/server/issues/16726
In fact, if you read the discussion, you'll find there are no plans of moving from PHP at all. Nextcloud is not moving to Go.
Oops, you are right, I confused it with ownCloud
Hacks language is better, nobody will deny it. But outside of facebook there is barely no community, not many big open source projects. And as the language is now incompatible you even may not be able to use php libraries.
That sounds right, but probably at considerably lower cost.
Daily reminder that by Lindy effects, for each additional year of php still alive the probability of staying alive increase. We will probably die before PHP
> All of that to say: PHP is alive and doing very well.
Oh. I was hoping for good news. :-(
Oh. I was hoping for good news. :-(
I know PHP is really great (and always has been).
But sh*t, there is soooo much bad, no, really really bad PHP code that lives out there.
Isn't it?
But sh*t, there is soooo much bad, no, really really bad PHP code that lives out there.
Isn't it?
Yeah, same experience for me. Lots of fragile and bloated code bases. And I don't tell you about maintainability nightmare. Javascript in the server is another example.
So this is not the fact that PHP people can write useful things with it or that PHP can help them to put food on the table, etc.
Here some questions not only for PHP enthusiasts: Are you using the right tool for the job? If so, Are you do it well? Are those programs that you write easy to maintain over the time? Is the language providing you the necessary mechanisms to help you to do so?
So this is not the fact that PHP people can write useful things with it or that PHP can help them to put food on the table, etc.
Here some questions not only for PHP enthusiasts: Are you using the right tool for the job? If so, Are you do it well? Are those programs that you write easy to maintain over the time? Is the language providing you the necessary mechanisms to help you to do so?
With a background in Java, both have bad codebases that is impossible to understand and maintain. That's because both have bad developers.
Simple, but expensive solution: Rewrite.
PHP is not perfect, but it works, and gets better every year. So should the developers who use it, because it's a good choice usually.
Simple, but expensive solution: Rewrite.
PHP is not perfect, but it works, and gets better every year. So should the developers who use it, because it's a good choice usually.
Yeah in my whole career, the worst codebases I’ve worked on are far and away PHP
HAve you never worked with jQuery / Javascript in <script> tags and no real state management other than Local Storage or maybe some cookies? BEFORE webpack/etc so every plugin/package... is linked from the page you're working on?
PHP is bad, but my god some of the javascript nightmares and if you fuck up javascript with some recursion you can crash the entire browser.
PHP is bad, but my god some of the javascript nightmares and if you fuck up javascript with some recursion you can crash the entire browser.
[deleted]
Yeah, also some incredible literature and worthless spam. Practically infinite expression will inevitably lead to poor results in one corner or another.
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. :-)