I wouldn't pay too much attention to what "the webdev industry is doing". That's how we ended up with MBs worth of javascript to display a simple website, not to mention the cpu required to render single page apps that won't even let you open a separate tab and constantly break.

Most people in this industry are either junior devs that have no idea what they're doing, mid level devs that fall for the hype and don't like "boring" tech (battle tested, reliable) and end up using stuff that's not even production ready, and senior devs that overengineer and optimize prematurely.

Just keep on your path and don't pay attention to the dummies. PHP is great and will never die.

Definitely agree with this. And I'll blatantly add that sometimes it even appears as some sort of elitism/not-fashionable thing.

As if suggesting something that doesn't need 12 build steps, 2 transpiler passes, and 4 discombobulator demagnetizations before you finally serve your 2mb of javascript, that will then spend another 5 seconds of your crappy cpu cycles to render something that will inevitably break your back button is some sort of bad thing.

PHP is great and will never die.

agreed, for some projects it might make sense - but i've seen plenty of them completely ruined by switching over to node

Three major reasons.

React, Typescript, and isomorphic/universal JS.

The reasons for React's dominance is a separate topic, but if you're working with react, node becomes a natural fit for the backed because you can render the same components on the server or the client.

Again, the reason for TypeScript's success is a separate topic, but node is the go-to backed if you intend to build with typescript. All things being equal in the interpreted scripting language world, typescript's type system sets it far ahead of php/python/ruby.

Being able to build with one language for both front-end and back-end is a nice perk, but being able to reuse business logic in both environments is massive. e.g. sharing object structure types and interfaces between environments ensures API ingress and egress remain consistent, the same code used to validate form inputs on the front-end can also be leveraged to produce API validations on the backend and many other use-cases.

One runner-up reason: npm. Yes, npm has had a reputational hit due to some excesses of the ecosystem in years passed, but at the time when node was picking up steam, the php composer experience was terrible, whereas npm set the standard for stupid easy package management... yes, it came at the cost of a 2gb node_modules dir but this is (mostly) a developer vanity problem rather than an actual problem (unlike resolving composer dependency quagmires)

> But another reason I don't use Node is simply because JS sucks, even when compared to PHP < 7. It's a poorly designed language that requires multiple layers of tooling just to make it acceptable for use in larger projects

Any specifics? The reality is that PHP and JS are both wart-filled messes, I certainly don't see any substantive justification for the idea that node is worse than PHP.

> Again, the reason for TypeScript's success is a separate topic, but node is the go-to backed if you intend to build with typescript. All things being equal in the interpreted scripting language world, typescript's type system sets it far ahead of php/python/ruby.

Absolutely. The sad thing for PHP is that they had the opportunity to pioneer static typing in web development that TypeScript has made so popular, and finally break from all the quirkyness and crappyness of the language in the early 2010's when Facebook released Hack and XHP (https://docs.hhvm.com/hack/). At the time I worked as a PHP dev and desperately wanted to use XHP (there was a regular PHP extension for it) but couldn't get employer buy-in as they didn't see the point in it.

XHP was basically what React/JSX is now to JavaScript, except for PHP. And Hack is what Typescript is to JavaScript, except for PHP, a sensible, and partial superset of PHP with static type checking. But for years, Hack and XHP languished to get any PHP-dev attention. Why? Ten years ago I couldn't figure it out at the time, but now in hindsight, I believe it's because no one in regular PHP-land at the time recognised the genuine engineering improvements Facebook had just ushered in, because most PHP devs don't approach their work with an engineering mind-set. Could be wrong but that was my experience - a lot of PHP code is just crappy, even in a post-PHP 7+ world, and the only explanation seems to be crappy devs.

> but at the time when node was picking up steam, the php composer experience was terrible, whereas npm set the standard for stupid easy package management

Yes, this is an understatement. Running composer on a Laravel project once, it regularly hit 1.5GB memory usage. This was in the mid-2010's, at a time when Macbooks had like 4GB of RAM. Though granted, npm had the same problem, but with disk space, not RAM.

tRPC may be the catalyst to at least get me to launch something on node, instead of laravel, though I'm trying to figure out how it differs from livewire/liveview type html over the wire. It's definitely interesting way to manage apis.

I think it’s the culture. The code quality of almost every PHP project I’ve seen is atrocious. I’m not saying every JS project is perfect (far from it), but amazingly well-written JS projects are ubiquitous.

So when I ask myself “how much do I trust complete strangers on the internet?” the answer is “not much, but even less than that if it’s written in PHP.”

> amazingly well-written JS projects are ubiquitous

I'd genuinely love some examples.

I've always loved this project / product:

https://github.com/outline/outline

I think the guy who built it posts here. There's also pg-promise, a "Postgres interface for Node.js":

https://github.com/vitaly-t/pg-promise

Node: https://github.com/nodejs/node

React: https://github.com/facebook/react

Vimium: https://github.com/philc/vimium

If you want more, here is probably a good place to start: https://github.com/EvanLi/Github-Ranking/blob/master/Top100/...

I mean, those are popular, but what makes them well-written? What do you see in them that makes you say those are amazing projects?

I think at this point we can all roughly agree on what makes code well-written?

1. Stylistically consistent for things like format, naming, control and logic flow

2. QA: linted, unit tested, code reviewed

3. Design: Modular, scalable, future proof, secure, stable, reliable, performant etc.

4. High adoption implies testing/verification of above design attributes

5. Follows (or establishes) best established practices for interfacing with platform APIs etc.

6. Keeping complexity low enough that a junior engineers can contribute

7. Descriptive commit messages

etc. etc.

Instead of pure code try seeing it as a book. If I read a book with a lot of spelling/grammar errors, a story that goes nowhere, characters that aren't interesting to me, plots that make no sense, etc..., then I'd tend to think of it as a not well written. Same with code, if variable names are obscure, function names don't match what they actually do, needless abstractions, nonexistent documentation, no tests, etc..., then I'd tend to think of it as a not well written project. Those aren't the only things I look for, but that's a start for me.

One could also argue, "why does it matter how it's written, it's not a book and it does what I need to do so that's fine." If it works and you don't have to do anything, great. If you have to troubleshoot it because it broke, then hopefully the code is structured in a way that lends itself to debugging. Otherwise, you might end up having a bad time.

For myself I'd say the lodash repo is well written. Would you agree/disagree?

My impression from when I read a big chunk of the React codebase to confirm some suspicions about how they'd implemented hooks ("wait, if that's how these behave, does that mean they... no, surely they didn't... well, yep, that's exactly what they did") was that it had more layers of abstraction than would be ideal and was a bit under-commented, but not awful.

I've been a PHP programmer for most of my professional career and switched a few years ago. PHP has a bad name for a long time. True or not, this started weighing on me and I shared a lot of the opinions you wrote here.

People will continue to roll their eyes. Whether deserved is besides the point. I was no longer interested in being a 'PHP programmer' and have to justify my worth. PHP is by all measures on it's way out. If you are looking at other ecosystems of course you're going to find things that aren't great. PHP has those too but in the 15 years you've been doing it you've created habits that perfectly avoid those. You're not going to attain those same skills immediately elsewhere, and the things that are worse from your perspective are going to stand out more than the things that are better.

You've tied your professional identity to a programming language that people dislike. It's not a fun place to be, but trust me you'll be better off in the long run. This has NOTHING to do with language features, and everything with your feelings and bitterness. Your post is full of emotions. It's not worth feeling this way, it's just a programming language.

Appreciate the comment, but to be clear I haven't worked on a PHP project professionally in over 6 years.

I wouldn't say my professional identity is tied to PHP. I don't even consider it my strongest language anymore because I haven't used it day-in day-out for years, plus the vast majority of my professional experience came prior to PHP 7 and Laravel. I'm more of a PHP 5 + Zend guy.

I use PHP for personal projects simply because I find I'm much more productive with it. Emotionally I love writing Java & TypeScript code because I find both to be beautifully designed languages. PHP is fine and to your point, I have grown to love it in a lot of ways. I do love working with Laravel though, but that's not because of PHP, but just because every 10 minutes I'm thinking, "holy crap, that was easy". Everything you'd want is there and works and it all works as you'd expect.

Java "beautifully designed"? Java 19 still can't parse a regex properly, ie. without having to escape metacharacters. Which other commonly-used language has such a lousy regex implementation?

I agree with this. Anacdotally I spent years fighting my way out of the perception of being a "PHP programmer". Despite having open source projects in a litany of languages, it was all interviewees wanted to talk about.

I eventually lucked into working for a consulting firm who trusted me to work on goland and python and JS projects for two years, and that job on my CV means magically my twenty years of experience is now worth much (~$100k) more on the job market and nobody asks about my PHP work anymore.

The fact that PHP stands at 78% and Javascript stands at 2% in the report is counterintuitive. This anomaly might be caused by all the Wordpress sites that are out there, if so, readers should not use this report to steer their career.

WordPress accounts for 40% which leaves 38% not WordPress, which still stomps JS's 2% into the dirt. I use both, but lets be objective here and not cherry pick.

I don't know the numbers, but I would guess that more people sit NodeJS servers behind a CDN or proxy of some kind than PHP, making it potentially harder to identify.

What about software like Nextcloud, Mediawiki etc. built with PHP? They seem to be doing well.

Once I accepted that JS might not be the worst language in existence I slowly got to the point where now JS is my go-to language for most things. Specifically with TypeScript, I feel like I have the best of both worlds. I have a typed scripting language that works for the frontend and backend, and things just flow so nicely.

Agreed. My hatred for JS arose from having worked with it in the late 90s/early 00s and it was really painful. I did everything I could to avoid it during the ensuing years, focusing mainly on back-end work.

Having circled back around to it recently due to full-stack work, I'm now also using TypeScript targetting ES2022, and things are much, much better.

I feel that ES6 was a game changer, it really brought about major improvements to the language.

Typescript is great to work with (mainly due to the tooling). Vanilla js is not.

re: js - "It's a poorly designed language that requires multiple layers of tooling just to make it acceptable for use in larger projects." - ok, isn't this the pot calling the kettle black?

On a more serious note, i've been thinking recently that the more experienced you become with programming, the more you will thirst for functional programming or something close to it. I think that we see this with the maturation of the modern JS ecosystem too - with a trend towards thinking functionally, rendering functional components, limiting side effects, top-down data flow etc. PHP is not the easiest place to do functional programming. PHP is also not a glamorous place to be. Laravel is cool, but you are still gonna want something like React or Vue if you are building a modern front-end so why not go all-in on JS? I am not arguing for this - but I can see the argument being made by the community at large so I am not surprised to see PHP devs moving into JS.

You are in like the 1% - the mythical PHP hacker who loves the language. You will live a lonely life in your mystical PHP dragon cave high upon the on the hillside of Mount Lerdorf. This is the life you must be prepared for.

I worked on a couple of large legacy PHP projects. They were terrible.

Then I saw someone come in and modernize a legacy PHP project. It was a thing of beauty. I think modern PHP is seriously underrated.

I am not sure they are.

There was a point where colleges were only teaching Node, as JS was very fashionable. I've reeived applications where the answer to languages known are: Javascript, TypeScript, React, C++.

But, anecdotally, we moved one server to Node during the hype cycle, and that taught us enough to not repeat the mistake.

Others in the industry I have contact with (admittedly somewhat of a self-reinforcing circle) feel the same way.

Unfortunately, it is harder to find a good PHP dev.

EDIT: Actually, in my experience, the pool of PHP devs is smaller, but the average quality is higher.

> EDIT: Actually, in my experience, the pool of PHP devs is smaller, but the average quality is higher.

I'd venture to guess this is because PHP devs tend to be on the more experienced side anymore. Given the sentiment in online groups about how terrible PHP is, I doubt many younger engineers are opting to learn it at all. I know people that develop in PHP, but they have all been doing it for 10+ years now.

For all the love Node/JS gets for having wonderful and well-designed projects, junior programmers still do laughable things with it.

I moved from Swift to TypeScript last year. Best decision ever, TypeScript is super productive if you treat it just as a fancy linter, and it gives me access to a vast ecosystem that runs everywhere. Obviously then, Node is the choice for the backend.

To be honest, I find it hard to justify using anything BUT TypeScript these days.

> Can someone explain why I'm wrong about this because when ever I tell any of my Java / Node colleagues that I love PHP they tend to roll their eyes.

You're not wrong so much as out of fashion.

It's very important to recognize how much industry trends are driven by fashion. But being fashionable also makes an ecosystem good. Well, at least makes it better. For certain definitions of better. Lots of development attention that means there's probably a highly visible project building exactly the bells and whistles that will garner praise and more attention for the ecosystem.

You can make your slow, measured, careful decisions about tech to use. But webdev is full of YOLO projects too. Churn and fashion are always going to be at your door.

I was talking to a colleague recently and he said PHP died when senior devs were no longer able to say, "we're building it in PHP" and be taken seriously. I think there's truth in that.

I also think it's interesting how many TS advocates seem to have popped up in this thread. I find Java to be a lovely language and I think it's fair to say generally most developers agree Java is a well designed language with a mature ecosystem backing it, but I've never met a passionate Java developer. But I hear there was a time many years ago when Java was the hot new technology in town and naming your crappy new language, "Java"Script was considered a good marketing strategy.

I used to use PHP in the long-long ago.

Full stack typescript for me is SO much nicer. Occasionally there's code-reuse but more often it's interface reuse for type-safety and autocompletions. This yields a lot of correctness/safety in a large project.

No context or tooling switching.

> It's a poorly designed language that requires multiple layers of tooling just to make it acceptable for use in larger projects.

The thing is, most of this tooling isn’t even related to the language itself. In NodeJS, you need basically none of your the tooling. Here are reasons why tooling is used:

- Webpack. Files need to be minified because code is downloaded nearly every time you access a website. (Not a language problem.) This also leads to a whole other class of optimizations like dead code elimination.

- Babel. Can’t guarantee client-side runtime layer, so need to make sure new syntax is transpiled. Not a language problem.

- Eslint. Ideally you’d use a linter in any server-side project, like PHPCS for PHP.

- Typescript. This is a language problem. :p At least PHP has some types now!

On Node, you don’t need webpack or babel or any similar set of tools, because Node can resolve imports and you know which Node version you support. Other tooling, like dependency management and linting, would be normal in other languages too.

On the client, you need a huge set of tools just to deal with the fact that your software is literally downloaded over the internet as part of the startup process. That comes with a huge set of performance optimizations related to bundle size that other languages simply don’t need to care about. That’s why there’s so much extra tooling in the JS ecosystem.

It's a fair point. TypeScript + Node is mostly fine.

My main issue with using TypeScript is that you're building in the JavaScript ecosystem. For most things you'll need to use JavaScript packages which typically only have a few years of maturity to back them up.

There's also no standardised way of building things in TypeScript and this was a similar problem PHP had when I first started working with PHP. Back then it was common for developers to copy and paste bits of code from all over the internet into their projects. Every project would be structured differently. The tooling wasn't standardised. Etc..

But today PHP feels surprisingly mature. TypeScript is like trying to build something in Ruby without Rails, or Java without Spring. And now PHP has Laravel which is used almost universally in new PHP projects.

Is Babel even needed anymore? Only for the more experimental features like decorators etc.

Now IE is dead most people are using Chrome/WebKit based browsers like Edge/Google Chrome/Opera/Safari or other standards-compliant browsers like Firefox.

Javascript indeed sucks, but Typescript whips

To call Javascript "poorly designed" when having a discussion about PHP is… a bit jarring… Both PHP 7/8 and Typescript are huge improvements over their forbearers, but it seems indisputable to me that fundamental Javascript is at least a better-designed language than fundamental PHP (circa v3), and contemporary Typescript is better-designed than modern PHP.

(creds: I've been writing PHP and Javascript since around 1997)

Okay, so let's talk about TypeScript.

Let's say I want to create a simple app. Nothing complex, it just needs to connect to a database to support some some basic user auth and CRUD stuff.

TypeScript is probably my strongest language, and everyone says it's great so I'll use it for my backend.

Cool. So first thing we need to do is create a user API for signups. I'm going to need a framework for the API stuff. Express is good, let's go with that...

Okay, now we need to talk to the database. Let's install mysql2, seems popular and well maintained, should be okay.. Do I need a @types package? Nope. Great.

Now I need to create some environment config for connecting to MySQL. Going to need another library for that, I guess. dotenv is popular, should be safe enough...

Hm, actually I probably want to set up some logging too just in case there are SQL/DB errors. Going to need a library that. Looks like log4js would probably work. Is it well maintained / safe? Eh. Should be fine, just need to build this thing...

Right, finally connecting to the DB. How do I do DB migrations? Is there a library for that? Hm, let's check Google... Okay, typeorm seems like it might work. Seems quite popular. Let's try that.

Okay, our tables have been defined and we're connecting to the DB. Great!

Now we can finally create the signup code. Hm, actually, going need to validate email addresses. Do I write an email validator? No, don't be silly, this is the JS ecosystem! There's probably a library for that. validator seems popular, I'll go with that. It's probably safe...

Okay, signup done. That wasn't so hard was it? Just need to connect to the SMTP server to send the email verification email now... Erm, wait... How do I do that in TypeScript exactly? Guess I'll need a library for that.

I won't go on but this is the developer experience of just trying to do something extremely simple in TypeScript. But it gets worse because in two weeks when you come back to the project you'll find several of your libraries have been deprecated so you'll need to spend a few hours refactoring and the docs for the 50 libraries you needed are distributed across 22 websites (2 of which are 404ing) and 28 Github readmes.

In comparison all of this would probably take me about 15 minutes max in Laravel and I wouldn't need to install any 3rd party packages. And if I'm honest I could probably do this in Spring Boot faster too without having to worry about installing malicious, poorly maintained packages along the way.

Like, I swear I must be missing something here because while I acknowledge TypeScript itself is great, the JS ecosystem it's built on is awful. So yeah, sure, TS is better designed that modern PHP, but why anyone developer would choose to use TS for their backend isn't clear to me. Unless you absolutely need TS for writing isomorphic code or something then why bother with the headache?

You're question seems more on the side of "Why use a micro framework when you can use a mature full-fledged one?". I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge. I feel there is still so much momentum in the JS/TS community. Would you genuinely pick PHP for anything else besides Laravel?

I would also question you're mentioned frequency to update packages tbh. Just pin a stable version with a lock file, track the required node engine and use an OCI image to provide just enough reproducibility. I never had to do anything more than cd-ing into a directory and run npm ci after coming back to a project for a few years now.

> I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge

I'm not talking about staying on the edge though, I'm talking about connecting to databases and logging - stuff that would be considered basic when working with other languages.

You're right though... If there existed a fully-fledged framework for the backend (with dev tools) which had been around for a few years and fairly stable, I'd consider it. Frontend JS frameworks like Next.js are pretty great. They still feel a bit immature and prone to large changes, but they're on the right track and get a lot of things right.

Also, yes, I would probably still use PHP even without Laravel. I have PHP projects which are over a decade old which use a very minimalist framework I created for simple projects. It still works fine and I haven't changed the framework in over a decade. You're right that you can just pick some stable packages, but what happens when you're running Node 12 and you want to upgrade to 14 or 16? Do you upgrade and risk breaking packages or just continue running an out-dated unsupported version of Node? I've had this specific issue several times now.

I think some people here think I'm saying Node is unusably bad, but I'm not. I'm just saying I don't get why people / projects who would have used PHP a few years back are now moving to Node when Node is still so immature and PHP has improved so much. I guess I'm not sure why my view of PHP has improved so much, while the industry as a whole seems to be dismissing it for the JS ecosystem which in my opinion has a lot of problems.

PHP's big advantage over Node is that it comes with batteries included. Ok, those batteries could have been namespaced better but JS and Node suck more than any language because you have to import literally everything to get anything done.

Well, part of it is that PHP was initially one of only a few options, and since then new languages and technologies like Node have appeared and slowly eroded that market share by the simple fact that they are competition. Node became popular for the many good qualities it has: isomorphism, simplicity, etc., and I don't think php devs in particular moved to node as much as devs in general gravitated toward it.

If you look at PHP vs Node in Google Trends, you can see the PHP decline was well on its way before Node.js came on the scene in 2009.

I used to love PHP, but these days JS is good enough that I don't feel the need to look back. My personal JS projects still look PHP-ish in the sense that they're very simplistic, often lacking a build step and often even lacking a framework. I do like having more control over the server logic than what I remember having with PHP (granted this was the days of WAMP and LAMP, and I hear with docker and nginx things are nicer now). I also like the fact that I can go to a single place (npmjs) for both my browser-side and server-side libs because sometimes I haven't decided yet where it'll reside.

> developer community broadly seems to be migrating more towards Node?

How did you came to this conclusion? I work with PHP teams daily and they don't think about moving, but even if they did I wouldn't expect them to seriously consider node. Overall I would say that in the last few years there was increase in number of competent PHP developers.

People end up with such conclusions because of developer-bubbles and 'hip/visible' organizations using 'better' technologies. They have no awareness of the enterprises that use PHP directly or through frameworks, WordPress and other apps. These organizations don't tend to do high-profile PRs or hire in hip places. They silently recruit developers and keep them on board for ages. Merely WP itself is a gigantic space, leave aside Laravel etc.

https://www.isitwp.com/popular-big-name-brands-using-wordpre...

So basically people get such misconceptions due to the perception-distorting bubbles that they are in. And not only related to PHP - it applies to any language, stack, technology even the Internet itself...

PHP's popularity's gonna have to decline a long time before it's no longer relevant though. Old languages have an insane amount of momentum.

You wouldn't be able to tell from what's being discussed in programming circuits, but PHP is actually significantly bigger than Rust.

> But another reason I don't use Node is simply because JS sucks, even when compared to PHP < 7. It's a poorly designed language that requires multiple layers of tooling just to make it acceptable for use in larger projects. And again, when the ecosystem is changing so often any tooling you're using needs to be updated constantly.

TypeScript, ignoring about half the language features many of which are "oh my god please never actually use this" (e.g. all the distinctive features of prototypal OO), and finally being able to concisely tell the language to please let you treat async calls the way everyone's always wanted to be able to treat them 90% of the time for the entire existence of JavaScript and Node (async/await) has made the language downright tolerable.

The culture and ecosystem still blows, though, you're not wrong there.

I think your issue is having to use a language/runtime you're not productive/happy in. I switched from PHP to Node.js of my own choosing and loved TypeScript everywhere and a Java like runtime vs a state less execution model. I found the npm ecosysteem much richer and accessible than Packagist / Composer. However if I was forced to write in Python, I would have similar complaints.

I'll bite: you are OK with PHP and JS, but would complain if you had to use Python? JS is known for its speed of change (not in a good way) and PHP is legendary for inconsistency in system library. Python is not without its warts, but still... What did it do to rank lower than those two in your eyes?

I think it's mostly personal preference. I don't like significant whitespace, the type system, overall language ergonomics. It just doesn't fit my mental model. My point was more, if you have to use a language you don't like, you will end up with complaints as given by the OP, eg: "JS sucks".

Fair enough. :)

Based on the trends in "scripting" language programming over the past 30 years including Perl , Python, PHP & Node, i've noticed it's not the "best" language that wins . There needs to be an intersection of ease of use, a broad component library , adequate toolchain, quick iteration and a vibrant community.

Perl & PHP were two examples of languages that were particularly bad fits for their use cases – poor performance, buggy syntax that led to lots of runtime bugs – both were very successful for a time.

To answer your question: Node meets the above qualities reasonably well. It also is ambiguous enough to allow lots of navel-gazing over academic tangential topics so people can avoid actually getting work done and waste a lot of wall & CPU time doing so.

When Perl was popular (late 90s/early 2000s) it had the best performance of any interpreted language especially with regular expressions and mod_perl. If you're comparing Perl with Java or C++ that's apples to oranges.

Might want to double check the "poor performance" thing when it comes to PHP. In practice, it's kinda hard to beat without dropping scripting languages for something compiled.

[EDIT]

> To answer your question: Node meets the above qualities reasonably well. It also is ambiguous enough to allow lots of navel-gazing over academic tangential topics so people can avoid actually getting work done and waste a lot of wall & CPU time doing so.

OMG, this is spot on, though. Perfect way to put it.

We recently moved all our projects to Node. Few thoughts -

1. The TypeScript tooling with Node has improved tremendously. Frameworks like Nest make it simple to work with it.

2. There are some really good frameworks that, over the years, have remained simple and just work. Example - Express, Sequelize, etc.

3. Same developer can make changes on both the frontend and backend since the language on both sides is TypeScript now. That simplifies building features as less coordination is required for full feature development.

4. Deploying Node apps is overall simpler. Be it VMs, containers, or serverless. Horizontal scaling is cheap, and most applications don't need much processing optimizations there.

For me, the reasons are:

- PHP's capability is limited in a sense that its main use case is akin to a template engine rather than a full fletched executable. This puts a lot of limit in PHP

- TS steps up JS' game. Like what other have said, TS brings the hassle of maintaining complex codebase down quite a lot.

- NodeJS is a stepping stone for many frontend developers to learn backend because of the same language used.

- JS' syntax and capabilities, while having inherent unavoidable footguns, allow expressive code (I might be partial on this, the last time I used php is a long time ago)

Edit: formatting

I want so much to get off laravel, because it feels bloated, but I can't for the life of me find a decently structured way to do so in node, rust, golang, etc. The best I can do is maybe sprinkle in vue/react + inertia on frontend, and filamentphp on the backend, honestly I was close to switching until filament came out, I hated doing admin dashboards, and now I don't have to do as much.

Years back at ZendCon (maybe 2011 or 2012?) one of the keynotes mentioned they liked ZendFramework over something from Java* because they can hire developers cheaper than for other languages. That was my sign to move to another language.

* The memory is fuzzy what the comparator was, the point stands

Same, I've always liked PHP pretty well (outside shitshow frameworks/platforms like Wordpress, anyway) but actively avoid looking for jobs in it because of the pay and the stigma (which could affect ability to transition back out of it again—thank god I got out the first time before it'd fallen as far in common regard as it has now).

Last time I applied to a PHP shop I killed in the interview, was in the wrap-up where it was totally obvious I was at least a front-runner if not a shoe-in, then watched everyone's faces go white when I named a comp figure. They quickly and politely ushered me out with some "we'll get back to you" niceties. I wasn't trying to be a dick, but after I left I realized I'd probably given a number higher than anyone in that room was making except maybe the owner, and I was not pushing the boundaries of normal comp for a senior dev (what they claimed they wanted in the job listing) in my area. Whoops. Never should have even applied, mea culpa.

[EDIT] Incidentally, this is one reason why it'd be nice if places put comp ranges in listings, and it's why I make sure our notions are at least in the same ballpark up-front, now—I'm never again putting more than a couple minutes into an interview process before making sure we're not irreconcilably far apart on that, since it's a waste of everyone's time if we are.

When using React, Vue, Svelte, etc. for large SPAs, so much of the logic has to be duplicated from the backend to the frontend. That's why it's tempting to ditch PHP and use a JS meta framework to be able to reuse code (types, utils, etc.).