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

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.

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.

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.

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.

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.

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

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

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

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

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/

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.

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.

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.

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.

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

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

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.

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

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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

if you want a quick script 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.

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

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

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

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

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.

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.

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

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.

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

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.

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

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)

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.

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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

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.

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.

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 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 ;)

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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

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 :(

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

well, that escalated quickly

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.

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

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

Using WordPress as an example for the state of PHP is disingenuous.

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.

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

Node/JS or GoLang or React, Java?

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.

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.

> 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

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.

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

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

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.

Could it be that there are less Rails developers than PHP developers so the Rails developers get higher salaries?

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 :)

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.

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.

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.

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 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 consider the Laravel documentation to be incredibly helpful.

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.

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!

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.

That seemed to be the recommended way of starting last I touched PHP professionally (4-5 years ago)

https://laravel.com/docs/8.x/homestead

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

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

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.

PHP is server side, not frontend like React or Angular

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

Thanks, I saw it :)

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.

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.

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.

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.

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

Amazon blogged about it at https://aws.amazon.com/blogs/compute/the-serverless-lamp-sta...

  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

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.

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.

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.

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.

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.

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

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.

1. https://git.timshomepage.net/timw4mail/php-kilo 2. https://viewsourcecode.org/snaptoken/kilo/

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.

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.