11 ms·

It’s hard to explain just how much easier PHP made creating a dynamic web site back in the 90s / early 00s. You drop a file in your public web server folder an

It’s hard to explain just how much easier PHP made creating a dynamic web site back in the 90s / early 00s. You drop a file in your public web server folder and you’re done. Prior was CGI Perl scripts that hacked together how to access session and rest data. Or you had to develop in C. PHP had native support for the web. It also eliminate the need for an app server. I’m still not certain even today, if anything exists that is faster to get a dynamic site up and running than PHP.

nly 5y ago
I'm currently working on a Django project and have to restart uwsgi after each git pull. It's a pain
- edgyquant 5y ago
  Can you not setup hot reloading? I work with flask but it’s as simple as FLASK_ENV=development python run.py To get hot reloading working under flask, and it’s a lot less complex than django.
- tomnipotent 5y ago
  Use py-autoreload in your uwsgi config.
Seattle3503 5y ago
> I’m still not certain even today, if anything exists that is faster to get a dynamic site up and running than PHP. With PHP you can just start typing in your file and produce output. Even with lightweight frameworks like Flask there is boilerplate.
- dimitrios1 5y ago
  This ignores the monstrous complexity of setting up PHP (and php-fpm) on a host machine. I prefer fully contained targeted binaries these days.
  - osrec 5y ago
    PHP has to be one of the easiest set ups. Even more so nowadays if you're just grabbing a docker image...
  - innocenat 5y ago
    `apt install apache2 php libapache2-mod-php` will perfectly set up Apache with PHP all Debian-based distros. What's complex about that? And if you really need php-fpm (which you should, anyway), at least in Ubuntu (never set up on other distro), the boilerplate nginx config is there.
    - forgotpwd16 5y ago
      How bad will be running the built-in web server on public network?
      - innocenat 5y ago
        You meant PHP built-in server (php -S)? It doesn't even support concurrent connection. Neither mod_php nor php-fpm is related to the built-in server though. Both are designed for production.
        tored 5y ago
        Built-in web server has experimental concurrent support since PHP 7.4 > Set the PHP_CLI_SERVER_WORKERS environment variable to the number of desired workers before starting the server https://www.php.net/manual/en/features.commandline.webserver.php https://www.php.net/manual/en/features.commandline.webserver...
      - candiodari 5y ago
        This has been debugged for 20+ years now. Not bad at all.
  - robjan 5y ago
    If you're on Windows you can just install XAMPP and it "just works".
101008 5y ago
Definitely. I started with PHP when I was only 12 or 13 years old. Adding some logic inside your .html files (mostly includes, that were like magic back then[1]), renaming to .php and upload them to the server using FTP was so simple. A few years later, when I had to set up a lot of things to run Django I was surprised at how hard it was. PHP was simple to use, and to understand its logic, because it was embeded into HTML itself if you want to. No need to write views, controllers, templates, anything. And most of the shared hosting (paid and free) supported it. [1]Includes were like magic back then because if you had a heavy content website with a lot of inner pages (fansites), updating the navigation sidebar was a pain in the ass. Originally they were made with framesets, later iframes (with no borders, but if the content changed, a scrollbar appeared). When I (and my friends) started to use PHP and be able to use includes, it was awesome. (Edited to fix formatting)
- iammiles 5y ago
  This is the same story for me. Moving from PHP to Python was really difficult conceptually for me. For years fiddling with Apache configs and uploading files via FTP was web development. I sometimes find myself thinking about teenagers getting started nowadays and the accessibility of development, but I suppose there are a lot more resources now than the early 2000s for some enterprising kids to get started.
  - cronix 5y ago
    Yes, but at the same time, web development was a much simpler process back then to get into and actually start to learn. No virtual machines to have to learn, or npm, or git, or... just code in php/html in notepad and maybe some raw basic javascript until js frameworks started becoming a thing and upload it via ftp. I mean, you didn't even have css to worry about...you just threw everything into a table! (lol!) There were only a few standard screen resolutions you had to worry about, and only desktops/laptops that were always oriented in the same position (landscape). I'm not saying it wasn't crude, but it was a lot faster to go from knowing 0 to building a dynamic web page with a real visitor counter vs everything extra you have to consider using modern devices and tooling.
incanus77 5y ago
This is right when I started using it and it launched my career in software dev. You could build anything. Combine that with being 21-22 and the associated naivité and nothing was impossible. Prior to PHP as part of a LAMP stack, I had indeed been cobbling Perl scripts and GDBM key/pair databases to do web apps for various projects and customers. The ability to just print to the browser with PHP without explicitly having to send HTTP headers was wonderful.
- cutler 5y ago
  The Perl standard for cheap hosts was Lincoln Stein's CGI.pm (HTML::Mason required mod_perl for decent performance) but it was constantly subject to patches as the whole internet poked it to find holes. It taught me just how difficult it can be to get HTTP/CGI parsing correct and secure. I mean there were some pretty sharp people in the Perl community working on CGI.pm but you always knew another security hole was just round the corner. To some extent PHP sidestepped these issues which may be why it took off so quickly.
kbenson 5y ago
> You drop a file in your public web server folder and you’re done. The implications of what this meant for security were very important too, but in a negative way. Instead of an application with a single or few small entry points (like CGI), you could just design your PHP app with a bunch of files spread across the exposed public directory structure, and for a long time this was the reigning paradigm for PHP. This, combined with the extension controlling whether it was processed as a PHP script or a plain text file meant that anyone making a quick and dirty backup of a file they were changing that didn't consider this would often end up exposing files to the public they didn't intend (mv config.php config.php.bak). Additionally, since most people were running on shared hosting platforms and PHP was usually run as the webserver user, and many applications were designed to be dropped entirely into a public web structure, any capability for writing locally (like allowing file uploads) often consisted of setting a directory world writable to drop files in. Even ignoring how often people screwed up setting permissions and set everything of theirs world writable, even when done correct this usually ended up being security through not-so-obscurity, since common apps had default locations they used more often than not (customizing that required more user interaction and knowledge to set up, which was against the ethos of "drop in and use" PHP heavily leaned on initially). PHP's ease of use was the ease of use of Windows 95 compared to Windows NT or Windows 2000. Sure, things are easier when you don't have to care about users and permissions and security. But you need to bootstrap any success you have into fixing those problems ASAP. PHP was always a victim of it's own success in this regard. The thing that made it easy to use for people was that it did away with a lot of the security concerns that were (barely) in place at that time, and the effects of that are what made it a nightmare for those managing it, and often at one point or another those using it as they were bitten by these problems. I'm glad we've all moved on from that. PHP did a lot to make it easier for people to do stuff online, and that in itself is a good thing and a laudable achievement. I'm unsure if it was a net gain though. It's too complex for me to easily say it was one, nor that it was definitively a net loss.
- simon1ltd 5y ago
  I'm not convinced that security is actually that much higher. I agree with your examples, but the complexity of most environments now is such that you almost have to know what you're doing in order to attempt to stay secure. How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained. I went from Perl to PHP, and my productivity definitely improved, and the speed of execution also improved significantly. mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.
dspillett 5y ago
It basically did for simple web programming what visual basic did for Windows desktop toys: allowed you to throw some UI together (drag & drop components in the VB case, any old HTML with links or forms for PHP) then start stringing bit of code in haphazardly to link it together. No need to learn a more complex compiler or other build tools, worry about configuring CGI or other web server tech (unless running PHP yourself), ... Great for prototyping, or just to encourage new programmers (as they can see results almost immediately). Though PHP was essentially thrown together initially so had a massively inconsistent standard library, had some insanely unsafe defaults for a few major versions, and other issues that it is very valid to complain about. It was also closely associated with mysql which at the time played very fast and loose with data integrity (2008-02-31? - perfectly valid date to store! Foreign keys? Let the business layer worry about rules like that! Transactional integrity? Again, sort that elsewhere!) in the name of ease & claims of performance - the two shared bits of each others reputation.
- sam_lowry_ 5y ago
  >Foreign keys? Let the business layer worry about rules like that! Rails made this approach viable at the time.
  - showerst 5y ago
    > Rails made this approach viable at the time. Rails didn't get big until 2006, eight years later than this time period =).
  - waheoo 5y ago
    I still don't like using foreign keys. They just make things harder to work with for very little gain. Wait for the crows.
    - withinboredom 5y ago
      Because of sharding, we can’t use them at work. I haven’t thought of foreign keys in years…
    - 5y ago
asadlionpk 5y ago
Try nextjs.
- cutler 5y ago
  Sorry, I don't have 250Mb for node_modules with every app I want to prototype.
  - tschan 5y ago
    PNPM (https://pnpm.io https://pnpm.io) is trying to solve that particular problem (i.e. "node_modules taking up too much space").
systematical 5y ago
And today you get all that plus a lot of features you'd expect in other languages. Starting with PHP 7 the language has gotten faster and better and it continues into PHP 8. Just checkout of the RFC's https://wiki.php.net/rfc https://wiki.php.net/rfc
bouncycastle 5y ago
It was just a massive toolbox that had everything - session, templates, large bundles of familiar libraries, Apache module. By far, the most useful tool in the box was probably MySQL. Before then, you had to work with flat files. Oh, and "magic quotes" was a bad idea ;-)
VictorDucs 5y ago
Early 00s? Back to 1995! https://www.my-old-version.com/php/ https://www.my-old-version.com/php/
owenversteeg 5y ago
Not just the early 2000s - up until maybe 2010 or so (probably a bit later) PHP was the clear leader for anyone who wanted to get something done. There was Rails and ASP.net and Java (I don’t remember anything else that was super popular) but PHP was a million times faster to develop in. Anything you wanted was explained in depth in the first Google result. You want auth? A chat server? File management? You could get anything you dreamed of. The most amazing part was how it was so simple and actually worked. Nowadays you look something up, the first few examples are often videos, unnecessarily detailed blog posts, who knows. Then things don’t even work, because one of your dependencies is out of date, or something needs to be restarted, or your linting failed, or who knows what. PHP barely ages - from 1999 or 2010 or 2020, it looks similar and works fine. By comparison I can instantly tell what 4-year timespan any Javascript was written in, because ten trends and frameworks have come and gone and left their mark. A simpler language for a simpler time.
- 29athrowaway 5y ago
  If you need to cook an egg, you can serve 1 request per second with PHP and use your CPU as heat source.
  - simon1ltd 5y ago
    Only if your code is poorly written. Even on basic hardware, hundreds of requests per second are trivial -- assuming you aren't loading a bunch of files ("require") or making 800 trips to the database to load the site. I've never found PHPs performance to be a limiting factor, even when I was dealing with dynamic page loads coming in at sustained rates between 50 and 100 per second, and this was on PHP4/5, slow (400MHZ), single core, low ram system. FAMP stack. I assume Java apps are the same way -- I've never encountered (to my knowledge) a java-based website that wasn't slow. I assume anything that relies on a huge framework probably also had that framework to blame for most performance problems.
  - progforlyfe 5y ago
    I prefer python or ruby, they cook the egg faster
mekster 5y ago
Perl wasn't bad, in fact I like it's Unixism in it but too bad it lost momentum. Every language has more than one way to do it, so it wasn't a down side, it's just programmers needed to know what they're doing like always. mod_perl worked without running an app server but I still don't know how other languages never implement mod_$lang or $lang-fpm that reloads code on change, so you don't have to place auto restart magic on development. These days you need transpilers (but I don't blame the flourishing of higher level tools when JS, CSS kind of totally stalled from adding useful features and people never let go of old browsers), auto restart of app servers and other build procedures just to get started and that's one of the reason people stick to plain PHP/CSS/JS (loaded independently via script tag...). We do want nice pretty slick GUI that does all that for cross platform to get new people started without asking them to do console magics. I know a few good ones but doesn't seem cross platform.
chx 5y ago
I feel people completely forgot -- for the right reasons obviously -- the disaster that was IHTML. https://web.archive.org/web/20030526173831/http://www.idude.net/ihtml/codesnippets/validate_GUID.asp https://web.archive.org/web/20030526173831/http://www.idude.... run.
that_guy_iain 5y ago
I was once asked in an interview for a PHP role what was my favourite feature of PHP and my answer was deployablitiy. In my opinion it can't really be matched on how easy it is to deploy. I can deploy any other language but it is never as easy as deploying PHP. The guy who was interviewing me was sitting their shaking his head like that wasn't a valid answer.
- FriedrichN 5y ago
  > The guy who was interviewing me was sitting their shaking his head like that wasn't a valid answer. I wonder what would be the proper answer. Also if there is a proper answer, they shouldn't ask what your favourite feature is. I hate it when people ask questions where they expect some sort of exact question to see if you think in the exact same manner as they do. Just ask me what you want to know or I'll pack my shit and leave.
  - gcmrtc 5y ago
    You're right, and donwvotes are from that kind of people.
- flippinburgers 5y ago
  Golang web apps are probably the simplest to deploy.
  - johannes1234321 5y ago
    For that you need to build some little tooling around it. You have to do the service registration somit auto starts and then you need some form of a harness to restart the go daemon if something goes bad etc. Also the one deploying Go needs system permissions on the machine. For a PHP deployment this is all handled by a fully standardized Apache httpd (at least back in the days, nowadays setups became more fancy) and the PHP.user just uses (s)ftp to copy the files in and all works magically. Need to update? - Just copy the new files. This is the unbeaten simplicity. (Of course that breaks at some point, like imma high traffic site simply copying the files via sftp will lead to some request in the middle having inconsistent state etc.)
BiteCode_dev 5y ago
Yes but your forgot that you had to setup easy php to get an dev env running. I'd trade easy deployment for easy dev any day.

nly 5y ago

I'm currently working on a Django project and have to restart uwsgi after each git pull. It's a pain

edgyquant 5y ago
Can you not setup hot reloading? I work with flask but it’s as simple as FLASK_ENV=development python run.py To get hot reloading working under flask, and it’s a lot less complex than django.
tomnipotent 5y ago
Use py-autoreload in your uwsgi config.

Seattle3503 5y ago

> I’m still not certain even today, if anything exists that is faster to get a dynamic site up and running than PHP. With PHP you can just start typing in your file and produce output. Even with lightweight frameworks like Flask there is boilerplate.

dimitrios1 5y ago
This ignores the monstrous complexity of setting up PHP (and php-fpm) on a host machine. I prefer fully contained targeted binaries these days.
- osrec 5y ago
  PHP has to be one of the easiest set ups. Even more so nowadays if you're just grabbing a docker image...
- innocenat 5y ago
  `apt install apache2 php libapache2-mod-php` will perfectly set up Apache with PHP all Debian-based distros. What's complex about that? And if you really need php-fpm (which you should, anyway), at least in Ubuntu (never set up on other distro), the boilerplate nginx config is there.
  - forgotpwd16 5y ago
    How bad will be running the built-in web server on public network?
    - innocenat 5y ago
      You meant PHP built-in server (php -S)? It doesn't even support concurrent connection. Neither mod_php nor php-fpm is related to the built-in server though. Both are designed for production.
      - tored 5y ago
        Built-in web server has experimental concurrent support since PHP 7.4 > Set the PHP_CLI_SERVER_WORKERS environment variable to the number of desired workers before starting the server https://www.php.net/manual/en/features.commandline.webserver.php https://www.php.net/manual/en/features.commandline.webserver...
    - candiodari 5y ago
      This has been debugged for 20+ years now. Not bad at all.
- robjan 5y ago
  If you're on Windows you can just install XAMPP and it "just works".

101008 5y ago

Definitely. I started with PHP when I was only 12 or 13 years old. Adding some logic inside your .html files (mostly includes, that were like magic back then[1]), renaming to .php and upload them to the server using FTP was so simple. A few years later, when I had to set up a lot of things to run Django I was surprised at how hard it was. PHP was simple to use, and to understand its logic, because it was embeded into HTML itself if you want to. No need to write views, controllers, templates, anything. And most of the shared hosting (paid and free) supported it. [1]Includes were like magic back then because if you had a heavy content website with a lot of inner pages (fansites), updating the navigation sidebar was a pain in the ass. Originally they were made with framesets, later iframes (with no borders, but if the content changed, a scrollbar appeared). When I (and my friends) started to use PHP and be able to use includes, it was awesome. (Edited to fix formatting)

iammiles 5y ago
This is the same story for me. Moving from PHP to Python was really difficult conceptually for me. For years fiddling with Apache configs and uploading files via FTP was web development. I sometimes find myself thinking about teenagers getting started nowadays and the accessibility of development, but I suppose there are a lot more resources now than the early 2000s for some enterprising kids to get started.
- cronix 5y ago
  Yes, but at the same time, web development was a much simpler process back then to get into and actually start to learn. No virtual machines to have to learn, or npm, or git, or... just code in php/html in notepad and maybe some raw basic javascript until js frameworks started becoming a thing and upload it via ftp. I mean, you didn't even have css to worry about...you just threw everything into a table! (lol!) There were only a few standard screen resolutions you had to worry about, and only desktops/laptops that were always oriented in the same position (landscape). I'm not saying it wasn't crude, but it was a lot faster to go from knowing 0 to building a dynamic web page with a real visitor counter vs everything extra you have to consider using modern devices and tooling.

incanus77 5y ago

This is right when I started using it and it launched my career in software dev. You could build anything. Combine that with being 21-22 and the associated naivité and nothing was impossible. Prior to PHP as part of a LAMP stack, I had indeed been cobbling Perl scripts and GDBM key/pair databases to do web apps for various projects and customers. The ability to just print to the browser with PHP without explicitly having to send HTTP headers was wonderful.

cutler 5y ago
The Perl standard for cheap hosts was Lincoln Stein's CGI.pm (HTML::Mason required mod_perl for decent performance) but it was constantly subject to patches as the whole internet poked it to find holes. It taught me just how difficult it can be to get HTTP/CGI parsing correct and secure. I mean there were some pretty sharp people in the Perl community working on CGI.pm but you always knew another security hole was just round the corner. To some extent PHP sidestepped these issues which may be why it took off so quickly.

kbenson 5y ago

> You drop a file in your public web server folder and you’re done. The implications of what this meant for security were very important too, but in a negative way. Instead of an application with a single or few small entry points (like CGI), you could just design your PHP app with a bunch of files spread across the exposed public directory structure, and for a long time this was the reigning paradigm for PHP. This, combined with the extension controlling whether it was processed as a PHP script or a plain text file meant that anyone making a quick and dirty backup of a file they were changing that didn't consider this would often end up exposing files to the public they didn't intend (mv config.php config.php.bak). Additionally, since most people were running on shared hosting platforms and PHP was usually run as the webserver user, and many applications were designed to be dropped entirely into a public web structure, any capability for writing locally (like allowing file uploads) often consisted of setting a directory world writable to drop files in. Even ignoring how often people screwed up setting permissions and set everything of theirs world writable, even when done correct this usually ended up being security through not-so-obscurity, since common apps had default locations they used more often than not (customizing that required more user interaction and knowledge to set up, which was against the ethos of "drop in and use" PHP heavily leaned on initially). PHP's ease of use was the ease of use of Windows 95 compared to Windows NT or Windows 2000. Sure, things are easier when you don't have to care about users and permissions and security. But you need to bootstrap any success you have into fixing those problems ASAP. PHP was always a victim of it's own success in this regard. The thing that made it easy to use for people was that it did away with a lot of the security concerns that were (barely) in place at that time, and the effects of that are what made it a nightmare for those managing it, and often at one point or another those using it as they were bitten by these problems. I'm glad we've all moved on from that. PHP did a lot to make it easier for people to do stuff online, and that in itself is a good thing and a laudable achievement. I'm unsure if it was a net gain though. It's too complex for me to easily say it was one, nor that it was definitively a net loss.

simon1ltd 5y ago
I'm not convinced that security is actually that much higher. I agree with your examples, but the complexity of most environments now is such that you almost have to know what you're doing in order to attempt to stay secure. How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained. I went from Perl to PHP, and my productivity definitely improved, and the speed of execution also improved significantly. mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.

dspillett 5y ago

It basically did for simple web programming what visual basic did for Windows desktop toys: allowed you to throw some UI together (drag & drop components in the VB case, any old HTML with links or forms for PHP) then start stringing bit of code in haphazardly to link it together. No need to learn a more complex compiler or other build tools, worry about configuring CGI or other web server tech (unless running PHP yourself), ... Great for prototyping, or just to encourage new programmers (as they can see results almost immediately). Though PHP was essentially thrown together initially so had a massively inconsistent standard library, had some insanely unsafe defaults for a few major versions, and other issues that it is very valid to complain about. It was also closely associated with mysql which at the time played very fast and loose with data integrity (2008-02-31? - perfectly valid date to store! Foreign keys? Let the business layer worry about rules like that! Transactional integrity? Again, sort that elsewhere!) in the name of ease & claims of performance - the two shared bits of each others reputation.

sam_lowry_ 5y ago
>Foreign keys? Let the business layer worry about rules like that! Rails made this approach viable at the time.
- showerst 5y ago
  > Rails made this approach viable at the time. Rails didn't get big until 2006, eight years later than this time period =).
- waheoo 5y ago
  I still don't like using foreign keys. They just make things harder to work with for very little gain. Wait for the crows.
  - withinboredom 5y ago
    Because of sharding, we can’t use them at work. I haven’t thought of foreign keys in years…
  - 5y ago

asadlionpk 5y ago

Try nextjs.

cutler 5y ago
Sorry, I don't have 250Mb for node_modules with every app I want to prototype.
- tschan 5y ago
  PNPM (https://pnpm.io https://pnpm.io) is trying to solve that particular problem (i.e. "node_modules taking up too much space").

systematical 5y ago

And today you get all that plus a lot of features you'd expect in other languages. Starting with PHP 7 the language has gotten faster and better and it continues into PHP 8. Just checkout of the RFC's https://wiki.php.net/rfc https://wiki.php.net/rfc

bouncycastle 5y ago

It was just a massive toolbox that had everything - session, templates, large bundles of familiar libraries, Apache module. By far, the most useful tool in the box was probably MySQL. Before then, you had to work with flat files. Oh, and "magic quotes" was a bad idea ;-)

VictorDucs 5y ago

Early 00s? Back to 1995! https://www.my-old-version.com/php/ https://www.my-old-version.com/php/

owenversteeg 5y ago

Not just the early 2000s - up until maybe 2010 or so (probably a bit later) PHP was the clear leader for anyone who wanted to get something done. There was Rails and ASP.net and Java (I don’t remember anything else that was super popular) but PHP was a million times faster to develop in. Anything you wanted was explained in depth in the first Google result. You want auth? A chat server? File management? You could get anything you dreamed of. The most amazing part was how it was so simple and actually worked. Nowadays you look something up, the first few examples are often videos, unnecessarily detailed blog posts, who knows. Then things don’t even work, because one of your dependencies is out of date, or something needs to be restarted, or your linting failed, or who knows what. PHP barely ages - from 1999 or 2010 or 2020, it looks similar and works fine. By comparison I can instantly tell what 4-year timespan any Javascript was written in, because ten trends and frameworks have come and gone and left their mark. A simpler language for a simpler time.

29athrowaway 5y ago
If you need to cook an egg, you can serve 1 request per second with PHP and use your CPU as heat source.
- simon1ltd 5y ago
  Only if your code is poorly written. Even on basic hardware, hundreds of requests per second are trivial -- assuming you aren't loading a bunch of files ("require") or making 800 trips to the database to load the site. I've never found PHPs performance to be a limiting factor, even when I was dealing with dynamic page loads coming in at sustained rates between 50 and 100 per second, and this was on PHP4/5, slow (400MHZ), single core, low ram system. FAMP stack. I assume Java apps are the same way -- I've never encountered (to my knowledge) a java-based website that wasn't slow. I assume anything that relies on a huge framework probably also had that framework to blame for most performance problems.
- progforlyfe 5y ago
  I prefer python or ruby, they cook the egg faster

mekster 5y ago

Perl wasn't bad, in fact I like it's Unixism in it but too bad it lost momentum. Every language has more than one way to do it, so it wasn't a down side, it's just programmers needed to know what they're doing like always. mod_perl worked without running an app server but I still don't know how other languages never implement mod_$lang or $lang-fpm that reloads code on change, so you don't have to place auto restart magic on development. These days you need transpilers (but I don't blame the flourishing of higher level tools when JS, CSS kind of totally stalled from adding useful features and people never let go of old browsers), auto restart of app servers and other build procedures just to get started and that's one of the reason people stick to plain PHP/CSS/JS (loaded independently via script tag...). We do want nice pretty slick GUI that does all that for cross platform to get new people started without asking them to do console magics. I know a few good ones but doesn't seem cross platform.

chx 5y ago

I feel people completely forgot -- for the right reasons obviously -- the disaster that was IHTML. https://web.archive.org/web/20030526173831/http://www.idude.net/ihtml/codesnippets/validate_GUID.asp https://web.archive.org/web/20030526173831/http://www.idude.... run.

that_guy_iain 5y ago

I was once asked in an interview for a PHP role what was my favourite feature of PHP and my answer was deployablitiy. In my opinion it can't really be matched on how easy it is to deploy. I can deploy any other language but it is never as easy as deploying PHP. The guy who was interviewing me was sitting their shaking his head like that wasn't a valid answer.

FriedrichN 5y ago
> The guy who was interviewing me was sitting their shaking his head like that wasn't a valid answer. I wonder what would be the proper answer. Also if there is a proper answer, they shouldn't ask what your favourite feature is. I hate it when people ask questions where they expect some sort of exact question to see if you think in the exact same manner as they do. Just ask me what you want to know or I'll pack my shit and leave.
- gcmrtc 5y ago
  You're right, and donwvotes are from that kind of people.
flippinburgers 5y ago
Golang web apps are probably the simplest to deploy.
- johannes1234321 5y ago
  For that you need to build some little tooling around it. You have to do the service registration somit auto starts and then you need some form of a harness to restart the go daemon if something goes bad etc. Also the one deploying Go needs system permissions on the machine. For a PHP deployment this is all handled by a fully standardized Apache httpd (at least back in the days, nowadays setups became more fancy) and the PHP.user just uses (s)ftp to copy the files in and all works magically. Need to update? - Just copy the new files. This is the unbeaten simplicity. (Of course that breaks at some point, like imma high traffic site simply copying the files via sftp will lead to some request in the middle having inconsistent state etc.)

BiteCode_dev 5y ago

Yes but your forgot that you had to setup easy php to get an dev env running. I'd trade easy deployment for easy dev any day.