6 ms·

If you truly wanted to replicate the old PHP style of "drop a new file to handle a new route endpoint", then you would use something like Nodemon + Express. The

If you truly wanted to replicate the old PHP style of "drop a new file to handle a new route endpoint", then you would use something like Nodemon + Express. The whole drag and drop functionality is most definitely possible using a nodejs framework, and isn't that far from the popular tools being used today. It's just not common to do it this way, since people don't need it nor want it anymore

kragen 4y ago
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 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.
- pwdisswordfish9 4y ago
  > There's an enormous difference between claiming that "you can also just drop files on your server" and have a running application You're definitely right, but the entire lament seems like a lot of special catering for the convenience of an audience that is technical enough to write PHP, but isn't particularly accommodating to, like, the actual masses of people out in the world who are not and will not ever be inclined to wade through the issues inherent to setting up a shared hosting plan with a PHP provider and hashing out their craving to publish by fiddling with templating code. The author of this piece has a lot to say about SPAs and other client-side fads, which is fair. Lots of what makes up current trends in the "modern" Web is an abomination. But the PHP application/deployment model they advocate for is nothing special wrt the affordances it makes for non-technical folks, nor is it a particularly good implementation of TBL's original vision for the Web—despite the implicit ("explicit"?) claims in the article to the contrary. On both of those fronts, stuff like Zonelets <https://zonelets.net/ https://zonelets.net/> has moral superiority (despite its being basically a toy). The essence of Zonelets is also, at a fundamental level, much closer to what we see with SPAs than the "mildly dynamic websites" of yore.
  - hlandau 4y ago
    Author here. One thing that occurs to me is that it seems to me that there's a lot of "dark matter" programmers out there, which we don't often interact with. These are not professional programmers but they tinkered with it at some point, possibly out of curiosity, possibly out of necessity. These people maybe wrangled with PHP because they had to to get the website they wanted back then. These people may drift out of doing any programming as and when it becomes unnecessary. It's similar to the sentiments expressed with GeoCities, where you had web design being done by amateurs who weren't very good at it. Nowadays they probably use some kind of site generator and aren't exposed to HTML at all. Of course one can say that these these things are better left to professionals, but it's clear I'm not the only one with a clear sense that we've lost something here. Neocities, for example, is a clear reaction to that. It's similar to how home computers used to boot to a command prompt and now they don't. They essentially invited you to learn how they worked, whereas the modern desktop computing experience tries to seem as magic as possible. Many people of a certain generation probably learnt to program as kids on these old 8-bits because the machines themselves basically invited to. As a professional programmer now I'm genuinely unsure what I would recommend to a child of the same age today.

kragen 4y ago

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

pwdisswordfish9 4y ago
> There's an enormous difference between claiming that "you can also just drop files on your server" and have a running application You're definitely right, but the entire lament seems like a lot of special catering for the convenience of an audience that is technical enough to write PHP, but isn't particularly accommodating to, like, the actual masses of people out in the world who are not and will not ever be inclined to wade through the issues inherent to setting up a shared hosting plan with a PHP provider and hashing out their craving to publish by fiddling with templating code. The author of this piece has a lot to say about SPAs and other client-side fads, which is fair. Lots of what makes up current trends in the "modern" Web is an abomination. But the PHP application/deployment model they advocate for is nothing special wrt the affordances it makes for non-technical folks, nor is it a particularly good implementation of TBL's original vision for the Web—despite the implicit ("explicit"?) claims in the article to the contrary. On both of those fronts, stuff like Zonelets <https://zonelets.net/ https://zonelets.net/> has moral superiority (despite its being basically a toy). The essence of Zonelets is also, at a fundamental level, much closer to what we see with SPAs than the "mildly dynamic websites" of yore.
- hlandau 4y ago
  Author here. One thing that occurs to me is that it seems to me that there's a lot of "dark matter" programmers out there, which we don't often interact with. These are not professional programmers but they tinkered with it at some point, possibly out of curiosity, possibly out of necessity. These people maybe wrangled with PHP because they had to to get the website they wanted back then. These people may drift out of doing any programming as and when it becomes unnecessary. It's similar to the sentiments expressed with GeoCities, where you had web design being done by amateurs who weren't very good at it. Nowadays they probably use some kind of site generator and aren't exposed to HTML at all. Of course one can say that these these things are better left to professionals, but it's clear I'm not the only one with a clear sense that we've lost something here. Neocities, for example, is a clear reaction to that. It's similar to how home computers used to boot to a command prompt and now they don't. They essentially invited you to learn how they worked, whereas the modern desktop computing experience tries to seem as magic as possible. Many people of a certain generation probably learnt to program as kids on these old 8-bits because the machines themselves basically invited to. As a professional programmer now I'm genuinely unsure what I would recommend to a child of the same age today.