Arguably, this is the model of CGI, which is about a decade older. Every time you hit a page on a CGI-powered service, it starts up a new process that runs your script. So you just edit a shell/Perl/PHP/Python/etc. file in place (or edit it locally, and FTP/SCP/etc. it to the remote host) and immediately on the next page load you see the impact of your change.
It was kind of the original "serverless" - you'd often host it on a shared (multitenant) server with other users, with someone operating the web server for you and providing you with storage space. And it was a great development experience for small sites, especially for people new to web programming, and I miss it a lot.
For performance reasons people built "FastCGI" where you have a long-running process that handles multiple requests, and for software engineering scaling reasons people moved away from the model of one file on disk per URL (and URLs mostly mapping to file paths on disk), and then eventually we got the setup we have now.
Comments
Arguably, this is the model of CGI, which is about a decade older. Every time you hit a page on a CGI-powered service, it starts up a new process that runs your script. So you just edit a shell/Perl/PHP/Python/etc. file in place (or edit it locally, and FTP/SCP/etc. it to the remote host) and immediately on the next page load you see the impact of your change.
It was kind of the original "serverless" - you'd often host it on a shared (multitenant) server with other users, with someone operating the web server for you and providing you with storage space. And it was a great development experience for small sites, especially for people new to web programming, and I miss it a lot.
For performance reasons people built "FastCGI" where you have a long-running process that handles multiple requests, and for software engineering scaling reasons people moved away from the model of one file on disk per URL (and URLs mostly mapping to file paths on disk), and then eventually we got the setup we have now.