Is PHP still relevant in 2021?(saasstarterkit.app)
saasstarterkit.app
Is PHP still relevant in 2021?
https://saasstarterkit.app/blog/is-php-still-relevant-2021
2 comments
> I have the same fast feedback cycle, in other words, that I would have had with PHP fifteen years ago.
What astonishing progress! It's almost as fast of a feedback cycle that you would have had working in Lisp at a REPL 30 years ago!
Javascript is popular, but in most ways it's actually a much worse language than PHP, especially for new learners. The package ecosystem is a pigsty. It only exists because of legacy. I would hate to send some shiny new university grad down the route of learning that stack in depth when eventually, inevitably, it will be pushed out by something that sucks less. As soon as WASM matures to the point where in-browser UI that is NOT javascript/DOM powered is feasible on most devices, we're going to see a spate of new frameworks, new / repurposed languages on the client, etc. and the big advantage of "JS on both frontend and backend" will go away.
Can't come soon enough.
What astonishing progress! It's almost as fast of a feedback cycle that you would have had working in Lisp at a REPL 30 years ago!
Javascript is popular, but in most ways it's actually a much worse language than PHP, especially for new learners. The package ecosystem is a pigsty. It only exists because of legacy. I would hate to send some shiny new university grad down the route of learning that stack in depth when eventually, inevitably, it will be pushed out by something that sucks less. As soon as WASM matures to the point where in-browser UI that is NOT javascript/DOM powered is feasible on most devices, we're going to see a spate of new frameworks, new / repurposed languages on the client, etc. and the big advantage of "JS on both frontend and backend" will go away.
Can't come soon enough.
> What astonishing progress! It's almost as fast of a feedback cycle that you would have had working in Lisp at a REPL 30 years ago!
Indeed - I chose the word REPL for a reason.
> Javascript is popular, but in most ways it's actually a much worse language than PHP, especially for new learners. The package ecosystem is a pigsty. It only exists because of legacy.
Agreed.
> I would hate to send some shiny new university grad down the route of learning that stack in depth when eventually, inevitably, it will be pushed out by something that sucks less. As soon as WASM matures to the point where in-browser UI that is NOT javascript/DOM powered is feasible on most devices, we're going to see a spate of new frameworks, new / repurposed languages on the client, etc. and the big advantage of "JS on both frontend and backend" will go away.
Hard to say. JS has a powerful incumbent factor, and a lot of the difficulties in browser dev are less down to JS-the-language than asynchronous programming in an actively hostile runtime (web browsers). I think there will be a trough of disappointment when the e.g. Java devs realise that crossing the gulf between systems and UI dev is much bigger than just the programming language.
Right now the big movement for WASM is to do high performance frontend work in it. I have had some experience in this domain - e.g. zero GC webVR apps - and it's probably the area where WASM will initially bring the greatest benefits. That means that initially the best supported WASM toolchains will likely be for systems languages like C++ and Rust.
So I think it's likely that JS will be killed by a WASM targeting language, but that this language will be selected for its near term benefits on the web. And right now the momentum seems heaviest behind Rust.
Indeed - I chose the word REPL for a reason.
> Javascript is popular, but in most ways it's actually a much worse language than PHP, especially for new learners. The package ecosystem is a pigsty. It only exists because of legacy.
Agreed.
> I would hate to send some shiny new university grad down the route of learning that stack in depth when eventually, inevitably, it will be pushed out by something that sucks less. As soon as WASM matures to the point where in-browser UI that is NOT javascript/DOM powered is feasible on most devices, we're going to see a spate of new frameworks, new / repurposed languages on the client, etc. and the big advantage of "JS on both frontend and backend" will go away.
Hard to say. JS has a powerful incumbent factor, and a lot of the difficulties in browser dev are less down to JS-the-language than asynchronous programming in an actively hostile runtime (web browsers). I think there will be a trough of disappointment when the e.g. Java devs realise that crossing the gulf between systems and UI dev is much bigger than just the programming language.
Right now the big movement for WASM is to do high performance frontend work in it. I have had some experience in this domain - e.g. zero GC webVR apps - and it's probably the area where WASM will initially bring the greatest benefits. That means that initially the best supported WASM toolchains will likely be for systems languages like C++ and Rust.
So I think it's likely that JS will be killed by a WASM targeting language, but that this language will be selected for its near term benefits on the web. And right now the momentum seems heaviest behind Rust.
> And right now the momentum seems heaviest behind Rust.
Maybe for the low-level mechanism that directly targets WASM, but what the average developer actually wants to work with day-to-day has to be more forgiving and more expressive. Something closer to Ruby is probably more appropriate: so if Rust is to be in the mix, use it to implement a really good interpreted language, like how PHP is written in C but with twenty years of learned-lessons mixed in.
Maybe for the low-level mechanism that directly targets WASM, but what the average developer actually wants to work with day-to-day has to be more forgiving and more expressive. Something closer to Ruby is probably more appropriate: so if Rust is to be in the mix, use it to implement a really good interpreted language, like how PHP is written in C but with twenty years of learned-lessons mixed in.
Reminds me of this: https://pbs.twimg.com/media/DDfKMx-XgAAWoCT.jpg
Is PHP still a language in use, should I support it if I build tools or platforms for programmers? Sure. It's in use in many places.
Is PHP still a language worth learning if I intend to do agency style web development? Probably yeah. It still has a high showing in that domain.
Is PHP relevant for someone writing brand new distributed systems? Probably not. It has poor ergonomics and a bad concurrency story, and there are better languages for any criteria you care about.
Is PHP relevant outside of backend web services? No, and it never has been.
Is PHP relevant for PL research? Absolutely not. PHP's language design is almost wholly parasitic. It has few ideas of its own.
But... that's not really what we're writing about, when we're writing about relevance. Relevance here is a value judgement. But it's not PHP's quality as a language that makes it so ubiquitous. PHP is largely widespread because for a long time it had by far and away the best deployment story. You could get a LAMP server provisioned and be up within minutes.
I think the really interesting question is, "based on what made PHP so ubiquitous, what's the next PHP?". And I think the answer is JavaScript.
JS is quickly becoming the platform of least resistance. I can write a script and have it served on AWS Lambda within seconds. I can go into my function code and add logging on the fly. I have the same fast feedback cycle, in other words, that I would have had with PHP fifteen years ago.
I'm becoming more and more convinced that the most powerful tool a language can provide is a REPL. The faster I can turn abstract ideas concrete, the better. And the next generation of programming languages will live or die on their "playability".