7 ms·

> PHP has the world's simplest deployment model for web applications: copy some files to a directory And set up a webserver. Perhaps compile mod_php for Apache

> PHP has the world's simplest deployment model for web applications: copy some files to a directory And set up a webserver. Perhaps compile mod_php for Apache and configure it, taking care to do it securely. Then configure php too, again taking care to do it securely. Only then you can drop a bunch of files in a docroot and have PHP process them. And put some .htaccess files in so that things that aren't supposed to be directly executed can't be. I think it all just appeared simple, but it wasn't. It was dumb luck and lowest common denominator configurations on shared hosting that made it appear easy.

krapp 4y ago
Yes, if you have to set up and configure a webserver from scratch, and compile things, deployment in any language is difficult. But for the most common use cases, PHP is still easier.
- woojoo666 4y ago
  That assumes you have PHP already installed on the server right? I mean if you already have nodejs on the server, you can also just drop files in
  - jonwinstanley 4y ago
    All the really cheap hosts have PHP installed for you. Not saying they are good, but someone starting out wouldn’t ever start installing things like that.
  - teh_klev 4y ago
    Shared web hosting is still a big thing outside of our developer bubble. PHP is 99.9% guaranteed to be installed in these types of offerings, or it's a one click install on your control panel page.
  - kragen 4y ago
    In my experience, node.js won't run random files it finds in the current directory, and normally it won't reload them if they change after it starts either. And you have to configure your URL space separately from copying files around; it's not as simple as copying homepage.php to homepagenew.php, hacking on it until it works, and then renaming homepagenew.php to homepage.php.
    - woojoo666 4y ago
      You can use nodemon for that. PHP Apache similarly requires a process running in the background to handle requests right? My point is, the infrastructure needed to be able to simply drag and drop PHP files onto a PHP server, can be replicated with NodeJS too. There's nothing inherent to PHP about this process, it's just about how you set up you server. Now it's far more likely to find a hosting provider that already has PHP set up over NodeJS, but as the main article observed, those are in decline. That seems to me as simply a lack of demand. If people want static sites, theres no need for PHP. If people want even a bit of dynamicism, then it's not hard to use a framework, and you get far more scalability. The barrier to entry for these frameworks is so low that it's not worth using barebones PHP and then having to rewrite everything if you start wanting more.
      - kragen 4y ago
        Well, I suppose it's true that you can write command-line programs in the PHP language rather than run them as web pages, but PHP isn't just a language; it's also the software that implements this deployment model on various web servers, with built-in support for things like MySQL. node.js also implements a deployment model, but it's a different one. (node.js rather than JS is maybe a closer analogue to PHP.) nodemon gets you partway to the PHP model (by restarting your server when something changes) but not all the way; it doesn't start running random files it finds lying around. And people never run it in production. So, in summary, it is comprehensively not true that if you're already running node.js on the server, you can just drop files in. If you just drop files in, node.js will ignore them.
        4y ago
- kragen 4y ago
  The first time I set up and configured a webserver from scratch, in 01994 with EIT's Webmaster Starter Kit (wsk.eit.com), I think it took me about 20 minutes; I just had to fill out an HTML form with some configuration data. I didn't have to compile anything. Later, I would spend many hours getting intimate with the Apache manual, but Apache didn't exist yet. WSK didn't support PHP, of course. Nowadays it's not that difficult; you can just run nginx or Apache with Docker, and a few command-line options later you have a server running. If you have IPv6 or can reconfigure your home firewall (and aren't afflicted with CGNAT), it's a globally accessible server. Hosted options are a little trickier but not much.
  - chasd00 4y ago
    Plus with package managers you just say “install apache”. There’s now apache helpers that come with that will setup mods and all that stuff. Last time I did this I think you only had to create some symlinks in the config folder to enable a site. It is work but I mean you’re writing a website then knowing these things is a prerequisite and the docs are good and there’s tutorial after tutorial all over the place.
  - cutler 4y ago
    I was just thinking how long before somebody mentions Docker. Why leave Kubernetes out? Point of article missed completely.
    - kragen 4y ago
      By you, maybe. But I'm contributing things like https://news.ycombinator.com/item?id=31263708 https://news.ycombinator.com/item?id=31263708 to the discussion while all you're contributing is smug dismissals.
- chasd00 4y ago
  Remember, setting up a web server is done once. Deployment is done more than once. The deployment is still just as simple as scp’ing files to a folder.
deleted 4y ago
[deleted]
nicoburns 4y ago
> And set up a webserver. Perhaps compile mod_php for Apache and configure it, taking care to do it securely. You don't need to do any of this if you use a hosted service, which most people did. In that case you just needed to setup an FTP client. Of course these days hosted services for other stacks like Heroku are about as simple. Just push to a git repository and you're done.
- Macha 4y ago
  However, presumably you wanted to test locally before deploying, so you needed a local install. Tools like XAMPP to simplify this were as relatively bloated as the modern create-react-app or whatever. And then you find the software doesn't work because it relied on imagemagick to resize avatars to display the index page and your web host skimped out on the imagemagick module in their PHP deployment to minify resource use or it was just too much effort for them to deploy because it was the 2000s and they were using Slackware on their production servers. Oh and the web host disabled .htaccess support so you need to turn off the pretty URL support in the config files. Oh and their default config (which you can't override - see .htaccess) is insecure as it means people can execute PHP files from the upload directory. So then you got owned because of that. Oh and the MySQL configuration or old version used had some weird ideas about character encoding, so good luck with those € signs. And then you wanted to install a plugin for phpbb or something and the instructions were basically a diff in textual form on a forum post.
  - nicoburns 4y ago
    > However, presumably you wanted to test locally before deploying, so you needed a local install I wouldn't necessarily presume that. I mean I would want that now. But for my first forays into web development, I didn't have that. Precisely because it was hard to setup. I would just FTP stuff onto the "live" server (it wasn't exactly a critical site anyway, so if it broke for a while then that didn't matter so much). There were editors which could edit files directly on an FTP which made the dev workflow pretty seamless. Stuff like imagemagick could indeed be a pain. But you could at least get started without that. In general there were lots of problems, but the on-ramp to some dynamic behaviour was really minimal.
rjh29 4y ago
The other easy part was the markup. Just take your existing HTML page, add some for loops around bits of it and insert placeholders. 14 year old me found it very easy to turn my static HTML (which I was copying and pasting and changing for each article) into a dynamic page. Of course it had tons of issues (GET and POST variables turning into globals, SQL injection etc.) but the barrier to entry was very low.
open-source-ux 4y ago
PHP is probably the only language that makes it relatively easy for non-technical users to self-install a web application. It is not a quality inherent to PHP but is a consequence of the widespread adoption of PHP among shared hosting providers (no web server setup required). This is a quote from Jeff Atwood (founder of Stackflow) about PHP (he's not a fan): Despite the serious problems with PHP, I was forced to consider it. If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. [1] When did Atwood say this? 2012. A decade has passed and hardly anything has changed. Server installation remains needlessly complicated. Current solutions like Docker, Sandstorm, Cloudron, command line scripts etc. are "easy" for developers but not for ordinary users. What is easy for ordinary users? Installing a web app by uploading files to a folder on a server using a GUI FTP app is one example for PHP. (And for some non-technical users, even that might be too complicated). [1] https://blog.codinghorror.com/the-php-singularity/ https://blog.codinghorror.com/the-php-singularity/
- pwdisswordfish9 4y ago
  Agreed with the Atwood quote (not a fan of PHP myself; not a fan of Atwood, either). But I think you overestimate the approachability of PHP for non-technical users. > Current solutions like Docker, Sandstorm, Cloudron, command line scripts etc. are "easy" for developers but not for ordinary users. It sucks that Sandstorm didn't "win". But the implication here is that PHP is easy for "ordinary users". It's not, though. It's easy for a slice of the somewhat technical population at the low end of the technical spectrum. Ordinary people are still left out—and not to mention: susceptible/vulnerable to being lured by the false promises about the "easiness" of the PHP model. Unpatched installs of shoddily written PHP apps (or plugin-laden installs of WordPress) are an undeniable vector for potential security compromises of personal data, spam, and nodes use to coordinate the spread/execution of malware.
  - open-source-ux 4y ago
    But the implication here is that PHP is easy for "ordinary users". It's not, though. I agree. I've often wondered: why can't web server apps be installed with the same ease-of-use as desktop apps? Simply click through simple screens and installation is complete. All desktop users know how to install desktop apps. Unfortunately, Sandstorm and Cloudron - trying to provide easy app installs - are not widely supported by hosting providers.
chasd00 4y ago
Yes, if you’re going to build a web application you’re going to have to do the things to build a web application. Even the newest framer knows how to swing a hammer at a nail.
adamrezich 4y ago
when teaching myself web development in high school it was very straightforward to use the "PortableApps Launcher" from my iPod's hard drive over USB to get me Portable XAMPP, Portable Notepad++, and Portable Firefox to develop locally with, and Portable FileZilla (but also the Notepad++ SFTP plugin) to deploy to my paid host. couldn't have been easier.

krapp 4y ago

Yes, if you have to set up and configure a webserver from scratch, and compile things, deployment in any language is difficult. But for the most common use cases, PHP is still easier.

woojoo666 4y ago
That assumes you have PHP already installed on the server right? I mean if you already have nodejs on the server, you can also just drop files in
- jonwinstanley 4y ago
  All the really cheap hosts have PHP installed for you. Not saying they are good, but someone starting out wouldn’t ever start installing things like that.
- teh_klev 4y ago
  Shared web hosting is still a big thing outside of our developer bubble. PHP is 99.9% guaranteed to be installed in these types of offerings, or it's a one click install on your control panel page.
- kragen 4y ago
  In my experience, node.js won't run random files it finds in the current directory, and normally it won't reload them if they change after it starts either. And you have to configure your URL space separately from copying files around; it's not as simple as copying homepage.php to homepagenew.php, hacking on it until it works, and then renaming homepagenew.php to homepage.php.
  - woojoo666 4y ago
    You can use nodemon for that. PHP Apache similarly requires a process running in the background to handle requests right? My point is, the infrastructure needed to be able to simply drag and drop PHP files onto a PHP server, can be replicated with NodeJS too. There's nothing inherent to PHP about this process, it's just about how you set up you server. Now it's far more likely to find a hosting provider that already has PHP set up over NodeJS, but as the main article observed, those are in decline. That seems to me as simply a lack of demand. If people want static sites, theres no need for PHP. If people want even a bit of dynamicism, then it's not hard to use a framework, and you get far more scalability. The barrier to entry for these frameworks is so low that it's not worth using barebones PHP and then having to rewrite everything if you start wanting more.
    - kragen 4y ago
      Well, I suppose it's true that you can write command-line programs in the PHP language rather than run them as web pages, but PHP isn't just a language; it's also the software that implements this deployment model on various web servers, with built-in support for things like MySQL. node.js also implements a deployment model, but it's a different one. (node.js rather than JS is maybe a closer analogue to PHP.) nodemon gets you partway to the PHP model (by restarting your server when something changes) but not all the way; it doesn't start running random files it finds lying around. And people never run it in production. So, in summary, it is comprehensively not true that if you're already running node.js on the server, you can just drop files in. If you just drop files in, node.js will ignore them.
      - 4y ago
kragen 4y ago
The first time I set up and configured a webserver from scratch, in 01994 with EIT's Webmaster Starter Kit (wsk.eit.com), I think it took me about 20 minutes; I just had to fill out an HTML form with some configuration data. I didn't have to compile anything. Later, I would spend many hours getting intimate with the Apache manual, but Apache didn't exist yet. WSK didn't support PHP, of course. Nowadays it's not that difficult; you can just run nginx or Apache with Docker, and a few command-line options later you have a server running. If you have IPv6 or can reconfigure your home firewall (and aren't afflicted with CGNAT), it's a globally accessible server. Hosted options are a little trickier but not much.
- chasd00 4y ago
  Plus with package managers you just say “install apache”. There’s now apache helpers that come with that will setup mods and all that stuff. Last time I did this I think you only had to create some symlinks in the config folder to enable a site. It is work but I mean you’re writing a website then knowing these things is a prerequisite and the docs are good and there’s tutorial after tutorial all over the place.
- cutler 4y ago
  I was just thinking how long before somebody mentions Docker. Why leave Kubernetes out? Point of article missed completely.
  - kragen 4y ago
    By you, maybe. But I'm contributing things like https://news.ycombinator.com/item?id=31263708 https://news.ycombinator.com/item?id=31263708 to the discussion while all you're contributing is smug dismissals.
chasd00 4y ago
Remember, setting up a web server is done once. Deployment is done more than once. The deployment is still just as simple as scp’ing files to a folder.

deleted 4y ago

[deleted]

nicoburns 4y ago

> And set up a webserver. Perhaps compile mod_php for Apache and configure it, taking care to do it securely. You don't need to do any of this if you use a hosted service, which most people did. In that case you just needed to setup an FTP client. Of course these days hosted services for other stacks like Heroku are about as simple. Just push to a git repository and you're done.

Macha 4y ago
However, presumably you wanted to test locally before deploying, so you needed a local install. Tools like XAMPP to simplify this were as relatively bloated as the modern create-react-app or whatever. And then you find the software doesn't work because it relied on imagemagick to resize avatars to display the index page and your web host skimped out on the imagemagick module in their PHP deployment to minify resource use or it was just too much effort for them to deploy because it was the 2000s and they were using Slackware on their production servers. Oh and the web host disabled .htaccess support so you need to turn off the pretty URL support in the config files. Oh and their default config (which you can't override - see .htaccess) is insecure as it means people can execute PHP files from the upload directory. So then you got owned because of that. Oh and the MySQL configuration or old version used had some weird ideas about character encoding, so good luck with those € signs. And then you wanted to install a plugin for phpbb or something and the instructions were basically a diff in textual form on a forum post.
- nicoburns 4y ago
  > However, presumably you wanted to test locally before deploying, so you needed a local install I wouldn't necessarily presume that. I mean I would want that now. But for my first forays into web development, I didn't have that. Precisely because it was hard to setup. I would just FTP stuff onto the "live" server (it wasn't exactly a critical site anyway, so if it broke for a while then that didn't matter so much). There were editors which could edit files directly on an FTP which made the dev workflow pretty seamless. Stuff like imagemagick could indeed be a pain. But you could at least get started without that. In general there were lots of problems, but the on-ramp to some dynamic behaviour was really minimal.

rjh29 4y ago

The other easy part was the markup. Just take your existing HTML page, add some for loops around bits of it and insert placeholders. 14 year old me found it very easy to turn my static HTML (which I was copying and pasting and changing for each article) into a dynamic page. Of course it had tons of issues (GET and POST variables turning into globals, SQL injection etc.) but the barrier to entry was very low.

open-source-ux 4y ago

PHP is probably the only language that makes it relatively easy for non-technical users to self-install a web application. It is not a quality inherent to PHP but is a consequence of the widespread adoption of PHP among shared hosting providers (no web server setup required). This is a quote from Jeff Atwood (founder of Stackflow) about PHP (he's not a fan): Despite the serious problems with PHP, I was forced to consider it. If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. [1] When did Atwood say this? 2012. A decade has passed and hardly anything has changed. Server installation remains needlessly complicated. Current solutions like Docker, Sandstorm, Cloudron, command line scripts etc. are "easy" for developers but not for ordinary users. What is easy for ordinary users? Installing a web app by uploading files to a folder on a server using a GUI FTP app is one example for PHP. (And for some non-technical users, even that might be too complicated). [1] https://blog.codinghorror.com/the-php-singularity/ https://blog.codinghorror.com/the-php-singularity/

pwdisswordfish9 4y ago
Agreed with the Atwood quote (not a fan of PHP myself; not a fan of Atwood, either). But I think you overestimate the approachability of PHP for non-technical users. > Current solutions like Docker, Sandstorm, Cloudron, command line scripts etc. are "easy" for developers but not for ordinary users. It sucks that Sandstorm didn't "win". But the implication here is that PHP is easy for "ordinary users". It's not, though. It's easy for a slice of the somewhat technical population at the low end of the technical spectrum. Ordinary people are still left out—and not to mention: susceptible/vulnerable to being lured by the false promises about the "easiness" of the PHP model. Unpatched installs of shoddily written PHP apps (or plugin-laden installs of WordPress) are an undeniable vector for potential security compromises of personal data, spam, and nodes use to coordinate the spread/execution of malware.
- open-source-ux 4y ago
  But the implication here is that PHP is easy for "ordinary users". It's not, though. I agree. I've often wondered: why can't web server apps be installed with the same ease-of-use as desktop apps? Simply click through simple screens and installation is complete. All desktop users know how to install desktop apps. Unfortunately, Sandstorm and Cloudron - trying to provide easy app installs - are not widely supported by hosting providers.

chasd00 4y ago

Yes, if you’re going to build a web application you’re going to have to do the things to build a web application. Even the newest framer knows how to swing a hammer at a nail.

adamrezich 4y ago

when teaching myself web development in high school it was very straightforward to use the "PortableApps Launcher" from my iPod's hard drive over USB to get me Portable XAMPP, Portable Notepad++, and Portable Firefox to develop locally with, and Portable FileZilla (but also the Notepad++ SFTP plugin) to deploy to my paid host. couldn't have been easier.