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