Re:A look at modern PHP
by vertex-four on Tuesday May 05, 2020 @11:28AM
(#23081061)
I can, on my local server, change the code, hit it again, and have my changes reflected in what happens. Doing that with Python, Node.JS, Ruby, or Java requires extra configuration. That's the point.
Re:A look at modern PHP
by erik_seaberg on Tuesday May 05, 2020 @05:29PM
(#23085300)
Rewriting a bunch of text files isn't atomic, so you need to take a planned outage or atomically rename the source dir so you don't serve 5xx errors from parsing half-written source. At that point you might as well have a deploy process, which can be as simple as "rsync && mv" into each host.
Re:A look at modern PHP
by vertex-four on Tuesday May 05, 2020 @06:19PM
(#23085796)
Indeed, but again, I don’t care about that while I’m developing locally.
Not sure if you even understand what you're talking about.
As for node.js, I set up pm2 to watch for file changes and restart ts-node process and this takes a few seconds, which is slower than I can hit alt-tab back to the browser, which is annoying to see 'Bad Gateway' error page quite often, not to mention embarrassing to explain and help set it up to someone new to other languages than PHP.
PHP is instant and I'd like to know if there's a solution in node.js that can do the same.
most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild.
yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability.
there is really very little difference if you ignore the fact that it gets hard with the codesize and the environment in which the service is deployed in. the language is almost always the smallest challenge.
and fwiw, i'm definitely not "against" php in any way. i think ssr script languages are wonderful for easy development - especially if you combine them with something like intercoolerJS for interactivity. extremely easy to get started and you're even able to make ssr-"components" by just fetching each segment separately, which isn't really any overhead with HTTP2 nowadays.