I've used Express (a little), and as far as I know, in Express you don't define routes by adding files to a directory, which then get implicitly run; you define routes by running code which calls methods on the app object, like app.get, to register routes. To run that route-registering code, you need to either insert it into your main program, or you need to require() the file it's in from your main program. If anything in this route-registering glob of code has a parse error or tries to require() something that doesn't exist, your server won't start.

There's an enormous difference between claiming that "you can also just drop files on your server" and have a running application, which is what you said in https://news.ycombinator.com/item?id=31246963, and claiming that "[some] people don't need nor want" to just drop files on their server and have a running application, which is what you're saying now.

Now you're bringing up "drag and drop functionality", which is a GUI gesture, totally irrelevant to the things PHP's deployment model enables, which you are correct are things that some people don't want. Here are some examples:

1. You can unzip a zipfile of PHP on your server and have a running app. This is super helpful when you're a novice who doesn't know much about processes and sockets.

2. You can add a new URL by sshing into the server and typing "cp homepage.php homepagenew.php", even using a slow or low-bandwidth connection. Then you can incrementally change the new URL's behavior by editing that new file, while the main site hums along unaffected—at least until you hose the production database. If you want to change the old version, you can type "mv homepagenew.php homepage.php".

3. If you have two PHP apps, like MediaWiki and WordPress, you can unzip them in two different directories on your server and have two apps running on the same server. If one of them is broken, even contains parse errors, it doesn't affect the other one. You can add links in one of them that link to the other.

4. You can temporarily disable a page by typing "chmod 0 upload.php", without breaking any other pages and without slowing down the server.

5. You can host apps belonging to hundreds of mutually untrusting users in the same Apache process, running on different virtual hosts, without the different users being able to screw up each other's "sites".

6. You can break into somebody's website by uploading a file to it with a .php extension in a directory that the webserver is (mis)configured to execute PHP files in.

7. You can make a usable backup of an old version of a page by typing "cp homepage.php homepage.old.4.php". Which you can later restore in a similar way, without affecting other pages, by doing the reverse. Without learning how to use Git.

8. You can load a page in your browser and not have to think about whether possibly the running server has an old version of the page in its memory and that's why your attempted fix has no effect.

Now, PHP has never been my tool of choice; it's optimized by, and written by, people who don't know how to program, and I'd already been making web pages for years when it came out. It has its share of embarrassing bonehead design errors that can now never be fixed, though it did fix a lot of them. I like getting error messages instead of wrong results when I try to run broken code; it's one of the major reasons I switched from Perl to Python for soft stuff, near the turn of the millennium. I already know how to use version control systems, so I don't find it reassuring to have a directory full of "homepage.old.4.php". I want to be able to run the whole site on my laptop, not using the production database, and I want to be able to use a staging server. I don't want to have to worry about whether someone else has edited the files in production and that's why this page, that never should have worked, has always worked, until today. And I especially don't want my site getting popped because the uploads directory treated .php files as plain text but .php4 files as executable PHP. (Oops!)

But the fact is that PHP's deployment model enables beginning programmers to manage a website by putting files in directories, copying files around, making backup copies of files, and so on, without ever taking their entire site down with a parse error at startup, and, as far as I know, there is nothing even vaguely similar for node.js. Nodemon isn't it. Express isn't either.