1. You will still need to learn JS, and now it may even be embedded in PHP depending on the type of app you are working with!
2. It still has horrible conventions, arrays being sorted maps has to be one of the worst design decisions, IMO its worse than having null and undefined as types. Mutlibyte strings are still an afterthought in the core of PHP. Inconsistent function naming. It's new typing system is plain worse than TS in every way. Async programming is still terrible. Needle Haystack swapparoos throughout the language.
3. It was built for the web as it stood 20 years ago, HTML embedded in code, single server sessions, cgi servers, and minimal latency server to server communication. It cannot feel more out of place today.
I will give it: Laravel is a robust framework that helps hide some of this, but its hard to hide most of it.
2. I much prefer using PHP arrays than JS arrays. All the other stuff you mentioned have never been a issue for me in the past 10 years. I don’t care about types (I don’t even remember when I had a real type bug).
3. The modern web is an over engineered mess, all the modern js frameworks have made the user experience objectively worse. Oh wow your shitty website that has some text and a few pictures is taking 900mbs of ram and 70% of my cpu? Wow very modern! What progress we have made!
2) They aren't even arrays? How can you say that lol. If you haven't tripped over what I have listed I just cannot imagine how you have been using PHP. I ran into a multibyte encoding issue with Mongodb and Laravel last week for example. Just a few weeks ago the lovely json_encode a map was sometimes an array vs an object. Granted these are older laravel apps... I don't think a framework can fix these issues.
3) Great straw man! I am sure all PHP apps are beautiful things and their interactivity experience with the end user are perfect :)
Also speaking of over engineered, how is having to run a standalone web server along with PHP, and then having to have an entire JS stack as well not over engineered?
It's actually pretty clarifying. Two different perspectives on one single problem domain is almost always good for your brain. Like being bilingual.
Also I would dispute that there are not, fundamentally, two different environments in the browser and Node backend even now. One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths.
> Also speaking of over engineered, how is having to run a standalone web server along with PHP, and then having to have an entire JS stack as well not over engineered?
Not sure what you mean. There are a bunch of ways to run PHP -- one is with a process manager (php-fpm, not unlike things like PM2). Another is to run Apache as a backend to something like Caddy or nginx or some other cacher; this is actually a highly robust way to do things, because Apache can be tuned in so many different ways. And yet another is to use FrankenPHP, which is Caddy with a PHP process manager.
I personally treat JS at the front end (Vue/Nuxt) as a client application development environment, and PHP as a backend development environment, as clean separate things defined by an interface. I don't believe that blurring the boundary between code running in the client and code running in the server has ever been a good idea, nor will it ever be. It just leads to edge cases where the code has to ask, and developer traps where developers don't realise they need to know.
2) I have no idea what you are doing but I have never had those issues. I don’t use Laravel or Mongodb though so maybe it’s that? json_encode should give you a string not an array or object?
3) stating a fact is not a strawman and calling it a strawman is not an argument. PHP is as good or as bad as you want it to be. It boils down to the skill of the developer. Bad developers will have a bad time, but that applies to most languages.
I’m not serving an entire JS “stack” either, I write fast, efficient tailored JS without dependencies or frameworks.
Sending html and having JS just for interactivity is surprisingly fast.
I can see applications for async work within the wider backend all over the place.
But the objective justification for the async stuff being involved in the rendering of page content is thin.
And since the other applications are for sort of "high level systems" programming -- that boundary between the app and the OS -- I personally prefer Go for all of that.
Node is a significant devOps/package management pain that belongs in as few places as possible.
I'm curious, why is that so bad? It tends to be a useful property of PHP arrays.
Also for webdevelopment, I/O is often the bottleneck. This code creates an array with 1 million items, each being 'a' and then loops over each value, changing them to 'b':
$array = array_fill(0, 1000000, 'a');
foreach ($array as $key => $value) {
$array[$key] = 'b';
}
How often do you need to create and change each element of a million item array? A roundtrip TCP/IP call to PostgreSQL is bound to be slower than that for most web servers.
It does hint that perhaps bearjaws is (lucky for them!) too young to remember the mess that incomplete implementation of array/object duality got the JS world into.
Yes, you will. But to me this is an irrelevance: JS has IMO very little business near the back end. I have absolutely no patience for the JS-everywhere thing.
(It is never necessary to directly embed JS in PHP; there are always choices. Sure, you might sometimes need to briefly template your JS, but that's true of all web environments; it's fundamental to the problem)
> 2. It still has horrible conventions
It does. But for example JavaScript is still riddled with bad conventions. Look at the mess that inconsistent array/object duality, inconsistent property enumeration, has wrought across the language for a whole generation of programmers
> 3. It was built for the web as it stood 20 years ago, HTML embedded in code, single server sessions, cgi servers, and minimal latency server to server communication.
So was JavaScript.
Laravel is, I think, the most sensibly-designed web framework that has ever existed. Every single other framework I have used has disappeared too far into the developers' own biases towards tier after tier of NIH decisions. Laravel doesn't have pretensions.
(I used to love Ruby on Rails but even I remember when the people who were the talk of the developer world with their brand new easy to use developer framework did not know that GETs should be idempotent)