4 ms·

> is a nobrainer. Out of curiosity, why?

meiraleal 2y ago
JS is everywhere, nodejs is much more performant and scalable than anything PHP and the amount of HIGH QUALITY libs in npm is unparalleled.
- indianmouse 2y ago
  I have heard dreaded comments from *JS ecosystem users that the packages go to unmaintained state and there is just too much noise in the ecosystem. Very few packages thrive and live for longer periods... and eventually results in a lot of rewrites for newer engine support. Also, does it add to a non-maintainable code (or result in a complete rewrite) in a period of six months to one year? I don't code much of web apps as I'm a system's guy who still code in C where the created programs are running fine across OS versions without dependencies and many have crossed decades of use without resulting in any security issues. Most of them are for security and system's utility purposes and does some complex work on media and security pipelines. Also, many hours have gone into making them secure from the general RUST / GoLang fortification offering perspective as I am against using RUST or GoLang as I have got some experiences with them on the long term maintainability and support. Some of the created programs run fine with OSes older since the early day's of SUSE to the modern rolling versions of Linux (and almost all versions of Windows since Windows NT till date) without any modifications. It cannot be guaranteed with RUST or GoLang or with any other stack other than C... Sorry for the deviation though!
  - rafark 2y ago
    > I have heard dreaded comments from *JS ecosystem users that the packages go to unmaintained state and there is just too much noise in the ecosystem. Very few packages thrive and live for longer periods... and eventually results in a lot of rewrites for newer engine support. I would say most packages are somewhat maintained. But there are definitely a lot that don’t. Just last week I tried to install a few web worker packages and I couldn’t make any of them work.
- phatskat 2y ago
  I get these arguments, and I still wouldn’t say it’s a “no brainer”. (_Node-brainer?_ :V) Having mostly worked in PHP, I’m certainly biased, and also I’ve been heavily working in Node for the past year. Node does seem to have better performance - I’d be curious to see some comparisons with some of the newer (PHP 8 I think) performance enhancements that probably aren’t used in benchmarks, like JIT. That said, in my experience, both perform well enough for the majority of what you’re going to do on a day-to-day basis. If you really need to crunch lots of concurrent connections and heavy data loads, maybe you’d go with Node? Although there’s probably something better than either of those for that job. PHP’s package ecosystem is certainly high quality, again from my anecdotal experience. Composer et al have done a lot of really good things where PEAR fell far short. I also know that this is mostly a “me” issue with not being a Node backend person from the start, but my goodness there’s a lot to do to dive into an imported method and actually figure out what’s happening. Having to sift through bundled JS to trace back to the root of something is a lot more difficult than just seeing the raw PHP of a Composer package. To each their own, and the right tool for the job - to say one tech is always better or preferred over another seems a little narrow for my personal taste.

JS is everywhere, nodejs is much more performant and scalable than anything PHP and the amount of HIGH QUALITY libs in npm is unparalleled.

indianmouse 2y ago
I have heard dreaded comments from *JS ecosystem users that the packages go to unmaintained state and there is just too much noise in the ecosystem. Very few packages thrive and live for longer periods... and eventually results in a lot of rewrites for newer engine support. Also, does it add to a non-maintainable code (or result in a complete rewrite) in a period of six months to one year? I don't code much of web apps as I'm a system's guy who still code in C where the created programs are running fine across OS versions without dependencies and many have crossed decades of use without resulting in any security issues. Most of them are for security and system's utility purposes and does some complex work on media and security pipelines. Also, many hours have gone into making them secure from the general RUST / GoLang fortification offering perspective as I am against using RUST or GoLang as I have got some experiences with them on the long term maintainability and support. Some of the created programs run fine with OSes older since the early day's of SUSE to the modern rolling versions of Linux (and almost all versions of Windows since Windows NT till date) without any modifications. It cannot be guaranteed with RUST or GoLang or with any other stack other than C... Sorry for the deviation though!
- rafark 2y ago
  > I have heard dreaded comments from *JS ecosystem users that the packages go to unmaintained state and there is just too much noise in the ecosystem. Very few packages thrive and live for longer periods... and eventually results in a lot of rewrites for newer engine support. I would say most packages are somewhat maintained. But there are definitely a lot that don’t. Just last week I tried to install a few web worker packages and I couldn’t make any of them work.
phatskat 2y ago
I get these arguments, and I still wouldn’t say it’s a “no brainer”. (_Node-brainer?_ :V) Having mostly worked in PHP, I’m certainly biased, and also I’ve been heavily working in Node for the past year. Node does seem to have better performance - I’d be curious to see some comparisons with some of the newer (PHP 8 I think) performance enhancements that probably aren’t used in benchmarks, like JIT. That said, in my experience, both perform well enough for the majority of what you’re going to do on a day-to-day basis. If you really need to crunch lots of concurrent connections and heavy data loads, maybe you’d go with Node? Although there’s probably something better than either of those for that job. PHP’s package ecosystem is certainly high quality, again from my anecdotal experience. Composer et al have done a lot of really good things where PEAR fell far short. I also know that this is mostly a “me” issue with not being a Node backend person from the start, but my goodness there’s a lot to do to dive into an imported method and actually figure out what’s happening. Having to sift through bundled JS to trace back to the root of something is a lot more difficult than just seeing the raw PHP of a Composer package. To each their own, and the right tool for the job - to say one tech is always better or preferred over another seems a little narrow for my personal taste.