4 ms·

1) Okay, but in terms of getting shit done how is it helpful to people to learn two languages? 2) They aren't even arrays? How can you say that lol. If you hav

1) Okay, but in terms of getting shit done how is it helpful to people to learn two languages? 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?

ecjhdnc2025 2y ago
> 1) Okay, but in terms of getting shit done (one of your points) how is it helpful to people to learn two languages? 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.
- throwitaway1123 2y ago
  > 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. Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes: input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output. If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX > Not sure what you mean. There are a bunch of ways to run PHP Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-httpserver https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...
  - ecjhdnc2025 2y ago
    > Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term. PHP also has a built-in webserver, which you shouldn't use. FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.
    - throwitaway1123 2y ago
      The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-in web server is production ready, so you can safely cut out the reverse proxy middleman. I don't actually have any major qualms about the FrankenPHP stack, I was just trying to intuit what the original commenter meant when they said "standalone server". [1] https://www.php.net/manual/en/features.commandline.webserver.php https://www.php.net/manual/en/features.commandline.webserver...
archerx 2y ago
1) learning two languages is not hard or a problem. The fundamentals are the same. 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.

ecjhdnc2025 2y ago

> 1) Okay, but in terms of getting shit done (one of your points) how is it helpful to people to learn two languages? 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.

throwitaway1123 2y ago
> 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. Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes: input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output. If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX > Not sure what you mean. There are a bunch of ways to run PHP Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-httpserver https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...
- ecjhdnc2025 2y ago
  > Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term. PHP also has a built-in webserver, which you shouldn't use. FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.
  - throwitaway1123 2y ago
    The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-in web server is production ready, so you can safely cut out the reverse proxy middleman. I don't actually have any major qualms about the FrankenPHP stack, I was just trying to intuit what the original commenter meant when they said "standalone server". [1] https://www.php.net/manual/en/features.commandline.webserver.php https://www.php.net/manual/en/features.commandline.webserver...

archerx 2y ago

1) learning two languages is not hard or a problem. The fundamentals are the same. 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.