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.

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.

Every Oracle Pro*C application that I could find, I have rewritten as #/bin/php -f. Good riddance to bad rubbish.

I also just trashed an extremely repugnant PDF template processor, first with fpdf.org, then with tcpdf.org - far from perfect, but improvement a thousand fold.

Exaggerate, you say? Can I interest you in COBOL on my VAX (I'm not kidding)? Or perhaps (is this is too new-fangled) assembler under EXEC-8 on OS2200?

I do like the PHP solutions very much, and yes, I work in a museum.

It also launched many information security careers :)

Injecting strings from user input into generated HTML? Sure, to hell with checking if it contains script tags and/or onclick= attributes, or perform any kind of escaping alltogether for that matter.

Worse, automatically adding request variables to the global namespace, in an order that if input validation is implemented but naively/buggily there can be easy ways to bypass it.

this is the programmer's fault and responsibility

Unfortunately the low barrier for entry meant that many programmers hit the ground "running" with no knowledge of such issues, so ended up creating much insecure code simply by never knowing any better.

Not for a programming language calling itself portable Hypertext processor, no. In fact, it's bordering on criminally negligent.

PHP have htmlspecialchars() and parameterized queries since 2000.

1. XSS != SQL injection

2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in production in the presence of superior solutions.

In fact, I'd go so far as to say if you're selling PHP solutions/consulting in this century for apps managing ecommerce or any other kind of PII, you should demand your customer signs a liability waiver. If you can even disclaim liability for gross negligence in your jurisdiction, that is.

What should php do then? What's the alternative language that handles this better?

For traditional PHP apps wishing to continue SSR and server-side templating, integrate HTML-aware templating (PHP has always been half there considering embedded PHP is using SGML processing instructions; it "just" needs to offer additional, more sophisticated, injection-free SGML entity-based mechanisms).

For highly dynamical apps, consider porting to JavaScript on the client side, and use PHP only as a service backend language. That's what I understand newer PHP frameworks are doing; but this will only be attractive for migrating legacy PHP apps rather than bring new users.

I don't see the upside to the effort of porting to js. You still have all of the same pittfalls. Yes, you can build a DOM with 20x the code and 1/20th the performance ... or you can just call htmlspeciachars() in php. Yup, security is tedious and you need to stay on your toes.

When I developed in PHP, the first line of my code was usually renaming "htmlspecialchars" to "h". This significantly reduced the length of code and increased its legibility.

If someone proposed a conspiracy theory for why the rapid application development tools of the middle 1990s became extinct in reaction to plotting by corporate interests in perpetuating the value of consulting services and the high salaries of CS graduates, I would buy the hardback edition immediately. VB, Visual Age, Delhi, Genera on Tru64, RDB and RMS and DEC TM giving you schema less (noSQL to taste) wan -clustered ACID time series transactions programmable in BASIC, COBOL, FORTRAN C and DCL on any two of three architectures (VAX, Alpha and Itanium - currently available for running unchanged on x64 VMs) and the OS/2 subsystem bundled (plus the first free beer transaction manager NT provided working with CICS, a feature that I truly believed was capable of giving Microsoft the corporate game by itself) which provided a VBA front end to legacy systems alongside local OS/2 tools running atop the kernel thru W2K.. the day I in place upgraded my overloaded think pad in a hotel room in Köln, and I realised when Slashdot loaded in Netscape 7 that Microsoft couldn't get any respect for anything even as impressive as W2K truly was –

Edit : large part cut for brevity

I really should have composed what I just said, much better than I have done -/so I have cut the bulk from my first too enthusiastic version / I mean to describe how much you can get running with just BASIC language skills and, at least atop of VMS, and buying the right licenses, that answer is "anything almost anything that you can imagine from a power station to a stock exchange ". Stack Overflow and POF running tiny amounts of hardware under Windows Server aren't rare cases of the potential for leveraging commercial tools. If VMS is more palatable than Windows (and certainly I will not compare the two for TCO) and the Intel architecture pricing for RDB holds up I totally believe that SAAS on VMS can be a viable alternative platform capable of making a minor industry of positions for the experienced programming talent for whom ageing has become a invisible barrier to retirement or even employment and if that's possible, then there's right there the environment wherein a generation of younger engineering minds can both take respite from rat race technology change and learn from direct experience to write the reliable systems for replacing what I fear is a current batch of the most fragile infrastructure building in modern history.

edit : incidentally, I think the entry level salaries the FAANG group is paying is a coincidentally perfect match for the price for a consultant from IBM or whoever and I don't think this is a accident by any means, only it didn't seem to work out how the old big firms would have wanted things..

edit, again, mea - my conspiracy being IBM et.al killed the good development tools in hope for being able to bill for consultation only they didn't count on the ability for big tech competitors to dismantle entirely other industries to feed paying salaries at the level of consulting rates and monopolizing the talent in that way.

> why the rapid application development tools of the middle 1990s became extinct

RAD tools were focused on Desktop application development and web suddenly took over everything.

Yes, but the web was noticeably inferior as an application platform until html5, jQuery, Node and modern JS frameworks were being leveraged. But the web didn't require expensive licensing, and everyone by the late 90s had a web browser.

> web was noticeably inferior as an application platform

Nope. The web was both cross platform and insanely easy to use at the same time. It also cost an order of magnitude less because developers didn't have to implement an entire ui, printing and a bunch of code to make little things like the clipboard and resize window actually work. The web was vastly superior to the 1998 4gl scene and it was crystal clear in 98 that it was the future. So sure you could make a order entry crud app with your favorite 4gl and your order entry team could use it. With the web, I could make an order entry system and the whole world could use it...

I think one thing that killed the RAD market was it became viable to stick together a web application, especially since for a while no one cared if you included a barebones web server in your delivery

>Foreign keys? Let the business layer worry about rules like that!

Rails made this approach viable at the time.

> Rails made this approach viable at the time.

Rails didn't get big until 2006, eight years later than this time period =).

Because of sharding, we can’t use them at work. I haven’t thought of foreign keys in years…

Care to elaborate? It felt like the best thing ever when switching to InnoDB.

Elaborate on what? They're an opinion that data integrity is dependent on foreign keys containing pointers at existing data.

In systems where actual row deletion doesn't actually happen its kind of a pointless kick to the nuts.

Now I have to create things in a specific order for no reason other than foreign keys say so. When you're using uuids for reference keys you're not beholden to what order you insert you can have these things span databases or have separate systems do the insert.

For a naive example, maybe I have an order A, and two orderliness A1, A2, why do I have to create A before I create A1 and A2. Why can't I loadbalance those three operations to different systems that insert at different timings.

Eventually they all line up, and my system is resilient enough to be ok with that.

With foreign keys you're just beholden to some feigned idea about data integrity but it's mostly bullshit.

The other common situation is when you need to backup tables and restore them elsewhere in whatever order you want, foreign keys just get in the way.

I see your point for decentralised systems, "eventual consistency" is an unavoidable evil in many cases there at least if you don't want a performance hole caused by distributed transaction requirements.

But otherwise, I disagree strongly.

> feigned idea about data integrity but it's mostly bullshit

I call BS on your call of BS.

> The other common situation is...

If that is common in your production environments, then I never want to work with your production environments.

> foreign keys just get in the way.

Disable them, do the jiggery-pokery, and then replace them. Again, but not in production systems.

If FKs are an inconvenience day-to-day then you have something seriously wrong somewhere. They are protection against bugs and other unpredictables causing corruption of data that other code later relied upon being correct.

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.

> PHP was the clear leader for anyone who wanted to get something done.

Isn't that still the case?

At least here in Europe the word Backend Developer is basically synonymous with PHP Developer.

Every other language for backend development is pretty niche. Sure there is Java (and C#) for the enterprise but that was already there back then. Ruby had a good run but modern PHP with frameworks like Laravel could reclaim most productivity benefits so not that fierce of a competition. JS with node, sure but I mostly hear it in the context of micro services which is the opposite of wanting to get something done.

> PHP barely ages - from 1999 or 2010 or 2020, it looks similar and works fine.

Yes but no. PHP takes stability and backwards compatibility quite seriously but the language and culture around it has changed tremendously. The wild west days are long gone, it has gotten much more professional and mature while adding many modern language features.

> At least here in Europe the word Backend Developer is basically synonymous with PHP Developer.

Pretty much, I've seen PHP powering traditional companies with revenue in the hundreds of millions (approach billions).

Yeah my "niche" right now is consulting for companies that are high revenue but built out their platforms during lean times where they were focused on growth over stability, reliability, or security. "Legacy code" I guess though it's a little more varied than that might imply.

Basically the only two technologies I touch these days are rails and php. I'm not filtering out other tech stacks, these two are just absolutely dominant for this type of company.

Sometimes not just "lean startup" type companies.

The place I'm thinking off that I know uses PHP for everything is a bricks and mortar retailer/manufacturer, I think last time I looked their revenue was ~£500m a year.

Their software was however awful in the worst ways :).

> Isn't that still the case?

> At least here in Europe the word Backend Developer is basically synonymous with PHP Developer.

Here in Norway backend mostly means JVM or dotNet it seems. Last I touched a PHP installation that wasn't a prototype or a blog or something was in the spring of 2009.

That said: In my opinion PHP has been massively underrated in HN circles.

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.

Performance is the last thing one can blame php for. Its quite fast for a non compiled dynamic language and most bottlenecks are usually I/O and db access

+1, once you get the right indices in place, MySQL 4.x would scale just fine to millions of rows per table. Innodb and Percona were even better. Maatkit was amazing for tuning, as was xdebug.

When you just had expensive queries that were already optimized, you’d use IPVS, haproxy, apache, or RR DNS to help. This was before nginx existed. Static caching pages using Perl scripts to crawl the site and write out everything static as html files worked well too. Varnish was a real game-changer when that came out.

Edit: forgot about Gearman for distributing work as well. Now people probably build the same types of things using SQS and functions.

PHP was never the bottleneck, and the web could definitely “feel” faster back then on hardware an order of magnitude or two slower than we have today with these >10MiB index pages, CDNs and parallel downloads be damned.

Exactly, if there is one thing that is to blame for cooking CPU's it's an ORM, and those aren't very typical to see in PHP at all.

It's funny you say that. I was toying with PHP not long ago and managed to squeze 50k requests per second on an old server using a pure php server library called Workerman.

And by squeze I mean copy 30 lines or so from their hello world tutorial and run: php start.php

I reimplemented the speedtest.net backend for fun a number of years ago, right around when it was transitioning from Flash to HTML5 and offered both.

I used a PHP process running in the background using stream_socket_server().

IIRC my computer had a 5Gbps connection to localhost using HTML5, and fractionally less using Flash :>

...which meant that PHP was writing to the web browser at 5Gbps.

I prefer python or ruby, they cook the egg faster

How does perl compare?

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)

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.

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.

Nearly 20 years ago I wrote a dynamic listing page in PHP that renders an html table from data in MySQL.

Today it still works.

It is important to point out that this simplicity was by design. There was a ton of complex UI frameworks in the 90s, but Tim Berners Lee decided to get away with that complexity. Of course, developers being who they are, decided that simple is not what they wanted, and created probably one of the most complicated development stacks the world has ever seen on the top of the web browser.

I mean, the exact same things work now, a beginner don’t have to use docker, don’t have to care about responsive layouts, etc.

Similarly to how one can start writing python scripts without having to know OOP, maintainability, or even functions. It will suck, but it is a valuable learning step.

Starting with PHP and Visual Basic got me on the way to making cool stuff really fast, but I think they both made the leap to "real" programing languages later. With web development, I didn't really move on from PHP's "HTML with extra stuff" until I came across Ruby on Rails, and I'm not sure I ever really got past VB for high level GUI desktop stuff, but I was able to get into some lower level C in high school, but I've never really done desktop GUI programming since other than a little bit of Cocoa/Objective-C with earlier version of Mac OS X.

I learned PHP / MYSQL back in the 2000 because I had a website with ~100 pages. The only reason I had back then was to not have to update ~100 files whenever I changed the navigation.

Pretty much the same for me. A migration from using MS Access and FP extensions to PHP/MySQL.

I used SSI to include things like footers, but pho was great if you were into front end stuff

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

This ignores the monstrous complexity of setting up PHP (and php-fpm) on a host machine. I prefer fully contained targeted binaries these days.

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

How bad will be running the built-in web server on public network?

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.

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

This has been debugged for 20+ years now. Not bad at all.

I have set up PHP on Apache (both php-fpm and mod_php) and Nginx countless times on different Linux distros and never ran into problems. It might have to do with the fact that I have so much experience with web servers but it takes me only a few minutes to set it up on any Ubuntu/Debian based system (download time of the packages excluded).

PHP has to be one of the easiest set ups. Even more so nowadays if you're just grabbing a docker image...

If you're on Windows you can just install XAMPP and it "just works".

Monstrous? It couldn't be any more simple, if you even have to go through the process of setting up PHP. Hosting options that support PHP are two a penny, probably literally.

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

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.

> 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 think the fact that it's another layer and not essential for anything is a pretty good reason why it's not necessarily the same.

What I'm talking about is the default or minimal install complexity and how that affected what was to come. I'm not sure anyone considers S3 a default or minimal config for a website or code execution on the web.

I do agree it's much easier to add complexity these days though, and there are plenty of resources that probably encourage it.

> mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.

You didn't miss much. While mod_perl was first released within a year or two of the first version of PHP, it works in a fundamentally different way, as wasn't really suitable for shared hosting, so it was never going to have the same popularity. mod_perl keeps a perl interpreter persistent per Apache thread, but it doesn't (can't) really completely separate one request from the next, and given's the prevalence of globals that Perl lets you tweak that affect how many built-ins function (and the ability to redefine portions of the symbol table), it wasn't really suitable for shared environments, just for applications which were mostly the sole purpose of the webserver.

In fact, the way it works is sort of to just take any file set to be handled by it, and eval the content of it in a sub (to deal with some scoping issues), and display the output. As you might imagine, this required special care to not accidentally create closures and pollute subsequent request handling with data in variables from prior requests.

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.

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

You're right, and donwvotes are from that kind of people.

Golang web apps are probably the simplest to deploy.

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

Need ssh access. Can't deploy via ftp. A non-techincal person can deploy a WordPress site they will not be able to deploy a golang binary.

If the binary fails for whatever reason the application is either down or you have to have something ensuring it stays running. With PHP if it breaks, it'll be ok for the next run.

I am not familiar with tooling designed to allow non-programmers to deploy. For a programmer, a single binary is trivial stuff. My point being you can drop a golang in any linux environment and it will just run. It doesn't get simpler than that.

I understand what your point is, it is just your point is invalid.

You say you just drop a golang binary into any linux enviroment and it'll just run. Except it won't. If I just upload the file it won't just run. I need to run the binary. Literally, you need to do more than just upload the binary to the enviroment. Where as with PHP with many hosters you do just need to upload the files and it is deploy. As you said you can't get simplier than just uploading the files.

Secondary, if you have to make exclusions to proof your point of simplicity then it is not as simple as you state.

Thirdly, your deployment would be unstable. If an error occurs someone would manually have to restart it. For any production deployment you would need supervisior. And if you were going to deploy a new version you would have to stop supervisor, stop your process, upload and then restart supervisor. Quite simply your trival deployment is not production ready and would not be how someone would deploy it.

I get it you like golang, I like it to, but PHP has it beat on deployablity. It's got years on it when it comes to improving the ecosystem around it.

> Systemd

Doesn't restarted failed processes last time I checked. Maybe I'm wrong but I am pretty sure there is a reason every sys admin I know uses supervisord to manage long running processes.

> Whatever you think it is that is simple about php, I am certain there is plenty happening behind the covers that you are unaware of. An environment built around supporting php is required.

You are as wrong about that as you are as wrong about golang being as simple to deploy. You're just consisently wrong.

> A compiled golang binary only needs a linux system. That is it. Very, very simple.

Golang binary requires the deployer to have linux system knowledge. Uploading files does not require that it requires FTP client knowledge at most or in some cases the ability to use a web based file manager.

Requring knowledge core operating system functionality do deployments is not simple. Just because a techincal person can do it, does not mean it is simple. If you can not teach your grandma to do the deployment it is not simple.

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.

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

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 ;-)

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.

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.

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

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

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.

Use py-autoreload in your uwsgi config.

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.

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

Try nextjs.

Sorry, I don't have 250Mb for node_modules with every app I want to prototype.

PNPM (https://pnpm.io) is trying to solve that particular problem (i.e. "node_modules taking up too much space").

I feel certain that an entire generation of careers started from Rasmus Lerdorf's little hobby project. Despite the fact that things like Perl Mason, Tcl web apps, and your bog standard CGI scripts already existed, nothing compared to PHP's wild grab bag of a standard library, and above all, the documentation with user-contributed notes and examples (not to mention that there was nothing similar/free in Windows-land).

In some ways, that incredible ease of use of PHP for backend mirrored the ease of use of Macromedia Flash for animators and front-end/UX designers, which also led to a generation of middle schoolers and high schoolers tinkering and learning from each other and accidentally falling into a real career path.

Thank you Rasmus and PHP team... despite all the warts PHP gets often-deserved flack for, you have undoubtedly changed the lives of, quite possibly, hundreds of thousands of people who would never have become professional developers without the easy on-ramp that your creation provided.

It def started mine. The biggest for me was the excellent documentation and comments as you said. The comments were like an early version of stackoverflow

Yes! I don't think people who started in the modern age can even relate to how amazing this was, to have a documentation site with a built-in user comment system collecting errata, tips, pointers and snippets (even as erroneous as they sometimes were)...

This was before the embarrassment of riches that we have now...

- before proliferation of open source examples on GitHub,

- before StackOverflow,

- before jsfiddles,

- before snippets on gist or pastebin

- before very common web forums (many of which were eventually written in PHP in fact)...

- before fantastic search results of google...

Best you could hope for when you got stuck? Someone's personal web page, or usenet and mailing lists...

The search engines weren't great -- I think I had the best luck with Altavista. It's almost impossible to convey how different the 'web was back then. Searching mailing list or usenet archives was the only way to track down examples most of the time.

PHP 3 is what started the careers and it comes from Andi Gutmans and Zeev Suraski. I'm sure Rasmus Ledorf has pulled his weight throughout the entire thing but without the Zend Engine PHP would have never became what it is today.

"PHP: Hypertext Preprocessor was chosen as the official meaning of the PHP acronym with 53% of the votes."

For anyone curious I tallied the votes from the linked page:

    57 PHP HTML Preprocessor
    29 PHP Hypermedia Preprocessor
    98 PHP Hypertext Preprocessor

i guess "Personal Home Page" didnt sound sophisticated enough.

Professional Home Page instead

That breaks the fourth wall though.

I haven’t used PHP in years, but Laravel was such a fun and productive framework to work in. It really has a way of making you feel like a “code artisan”, something I typically only hear coming from Rails developers. In contrast, every Node app I’ve worked on has felt somewhat amateur, even if the code was high quality.

I've developed very large apps in PHP (Cake), Rails, Django, and Node.js (Express). If I had to rank my preference for how easy/nice/productive I was in each of them:

1) Django

2) Rails

3) Cake

... BIG GAP ...

4) Node.js (Express)

PHP is proof how little the core web technologies change over the years, even though so many new technologies have come after it.

Looking at this page I beleive I can still make a pretty decent website backend using vanilla php (including authentication) and a nice front end using plain old html and javascript from so many years ago.

PHP has changed quite a lot over the years, though. Not so much the core language (although it has) but the ecosystem has matured a lot.

Same as most other parts of the web.

20-25 years ago, everyone used tables for layout and random snippets of JS were scattered everywhere. HTML today has a much more expressive vocabulary as well as a whole suite of well-established best practices. Meanwhile, JS has evolved from a bunch of cute onmouseover handlers to an entire ecosystem in its own right.

The language changed a hell of a lot between 3 and 5 and between 5 and 8.

It has improved markedly and while it still has it's warts modern PHP8 code is very different.

However the ecosystem has absolutely matured alongside it as well, Symfony and Laravel are excellent general purpose frameworks, composer is an excellent package manager etc.

It's what I write for my day job and while it'll never be my favourite language, it's a pleasant enough productive language and it pays the bills.

Another fun piece of PHP history: The old leaked source code for Facebook's index.php and search.php circa 2007: https://gist.github.com/nikcub/3833406

    // Holy shit, is this the cleanest fucking frontend file you've ever seen?!
    ubersearch($_GET, $embedded = false, $template = true);

lol

A good bit of my work is in php codebases from that era and uh... yeah kinda.

Generally at that time (and for a few years after) you still see a huge influence from C programming constraints in php.

Lot of extremely terse abbreviated variables and explicit looping. And for some fucking reason the pervasive believe that variable names need to be at most either 3 or 6 characters long. (Yes I know the reason it's still bad)

So yeah painful as it is to admit that is well above average expressiveness and readability for php of its era.

That was probably the last time the Facebook code was ever sane and readable.

> This may sound a little foreign to all you folks coming from a non-Unix background, but PHP doesn't cost anything. You can use it for commercial and/or non-commercial use all you want. You can give it to your friends, print it out and hang it on your wall or eat it for lunch. Welcome to the world of Open Source software! Smile, be happy, the world is good. For the full legalese, see the official license.

What a nice, whimsical message.

I guess you are lacking some context.

Back in the day, you could:

* Be bold enough to use Linux or FreeBSD and use CGI or Perl as the only free version

* Use ASP but pay license fees for Windows NT, ISS and SQL Server

* Use ColdFusion which was kind of trendy but was pretty expensive.

When PHP arrived it was so refreshing. I used to make my stuff in Apache+PHP, MySQL and Linux and it was magical what you could do with very few lines of code.

The worse part was to manually get the sources of the dependencies one by one, hit ./configure and make, so you can compile a php module for Apache

In those days Microsoft was pretty strong, everything used to be closed source and payed and that's why for people who understand what it was back then, this does not sound like the splashy announcements of today.

That's why every time you see Linus, Stallman or any person that was active in the open source movement, you should pay a beer to them. The world of technology owe a lot to them, specially the underdogs.

I remember my employer was paying Indian consultants a fortune to build a web app in ASP that didn't work. I told them I could do it in PHP in a week, but they didn't trust some "free program."

I've saved a startup once from going bankrupt more or less like this.

They were paying a lot for ASP and a shitty product(cant remember the name..it was something like WebObjects) that was taking too long to load, the newly born company i was hired for would cease to exist, so even thought i was hired as a sysadmin to manage the network, linux and databases, i've used my low skills as a programmer, without nobody asking me, and designed the thing in secret, in about two or three weeks with PHP, Linux and MySql instead.

The (news based, with a lot of personalization page) loaded in about 400 milliseconds instead of what once was a 10 seconds load.

My bosses were a little skeptic at first, because the ASP folks was a team formed with university professors and skilled pros, and i was a teen that was not even hired as a coder. Also it was so much faster that they thought i could only be cheating somehow (like static instead of personalized with data from a backend db)..

Linux and open source was also faced with skepticism, specially when confronted with Microsoft stuff that everybody was used to back then.

The LAMP stack was a wonder back in those days, and it helped a lot to popularize Linux, MySQL, Apache and PHP. I know today PHP doesn't look so cool giving all the other players, but in the context it was launched it was so much better than all the status quo of the nineties where the options were quite limited.

Ha, I can relate to that. Met a potential in the mid-2000s who lived down the road running a travel agency which was falling over due to bugs in its web app. He knew nothing about technology other than that his app needed to parse "an XML" to work properly. "Can you get the XMLs working?". As soon as he showed me a couple of files I realised it was a Classic ASP site written in VBScript running on some overpriced Windows host so I offered to rewrite it in PHP. No chance - in his mind "the XMLs" were glued to the original code.

I didn't even remember this, OMG.. VBScript that used to ship with IE and could be used instead of Javascript.

We are so lucky that Bill Gates missed how important internet would turn out to be..

Some poor lost souls are still using ColdFusion. Pity me.

Ha. I am currently consulting on a project that is moving from ColdFusion to PHP.

It’s funny. For all the hate php gets these days, it was a pretty big part of the web getting to where it’s at today. I was super pleased when php 7 came out, this project isn’t going anywhere just yet.

PHP deliberately has a low barrier to entry, and as a result there is a lot of poor quality code out there, written by beginners. People like to use this fact to suggest that the entire language is bad, which it most certainly is not.

I've seen lots great, well structured and performant PHP code - the quality depends on the programmer, as it does for any other language.

As somebody who loves PHP, some PHP mockery is deserved. The standard function naming and argument ordering is inconsistent and stupid. It throws errors written in Hebrew. There were fundamental decisions made that harmed web security for years. Unicode wasn’t in PHP for a long time. Getting decent performance and/or scaling was/is a major challenge. The comparison tables are questionable at best. Etc.

The language is bad, but... you can still write great code in a bad language. And you don’t need a good language, or even good code to build a great website. Facebook has made more money with questionable PHP code than any site built with elegant pearl webscripts that I know of. Wikipedia is PHP. So was Digg (RIP). Your users don’t give a darn how good your language or code is so long as it usually works.

So tl;dr, PHP sucks, but I love PHP.

I started my career as a PHP dev in 2003 (mysql/smarty/adodb ftw) and I became a Rails dev around 06. Since then I have, for various reasons, switched back and forth between PHP and Ruby. The interesting thing that I've noticed in that time is that Ruby is, for the most part, the same language (and ecosystem!!) it was 15+ years ago and that is a good thing. PHP has tried hard to not be the language and ecosystem that it was 15-20 years ago and because of that it feels pulled in a lot of different directions. You encounter code that mixes 15/20 year old functions with more enterprisey OO conventions that came out of the post PHP5 era. It can feel weird to switch to that from a language like Ruby that more or less has had coherent approach since 2003.

I'm sure it's nostalgia but I think the PHP 4 -> 5 transition was the best era of PHP. Codebases at that time mixed OO and C-ish function based programming in pragmatic and easy to understand ways. That weird shitshow of objects, functions that accept pass by reference or pass by value, request scoped global state, etc was fun and anarchic and, for whatever reason, totally made sense to a self-taught programmer like me at the time.

> The standard function naming and argument ordering is inconsistent and stupid

This is quite hard to fix, as it would break almost everything. So you'd end up with a Python 3 situation. However, as of PHP 8, it's less of an issue. If you can't remember the order for arguments, you can use named arguments <https://3v4l.org/cY1PB> like so:

    strpos(needle: "foo", haystack: "foobar")

> It throws errors written in Hebrew

If you're referring to T_PAAMAYIM_NEKUDOTAYIM, this is no longer true as of PHP 8: https://3v4l.org/2T8qQ -- the error is just this:

    Parse error: syntax error, unexpected token "::", expecting end of file

Internally, the token is still called T_PAAMAYIM_NEKUDOTAYIM, but you can also refer to it by T_DOUBLE_COLON: <https://www.php.net/manual/en/tokens.php> and I suspect eventually they'll phase out the Hebrew spelling.

oh man, named arguments are great. I should have read the release notes sooner, i had no idea this change came out. Thanks for mentioning it!

You should watch this video: https://youtu.be/wCZ5TJCBWMg

It's a talk by the creator of PHP about how PHP grew to what it is today. The entire thing is really interesting.

There is actually a reason for things like 'inconsistent' argument ordering. They're ordered based on the C API, rather than being consistent in user land ;).

I think the C roots are also why PHP arrays double as hash maps.

Re Facebook, you can say that again. In August 2007 the source code of Facebook's index.php was exposed revealing a long list of global variables and not a single function definition in the whole 439 lines. Facebook engineer Steven Grimm commented 3 years later that similar, if not the same, code was still part of the codebase. So much for enterprise architecture.

> Facebook has made more money with questionable PHP code than any site built with elegant pearl webscripts that I know of.

Wasn't Amazon originally written in Perl?

AKAIK Amazon was a hodgepodge, with the front end being mostly C with a custom templating engine that could (eventually) run a subset of pearl for scripting. More C/C++/Java/Pearl was using for backend and internal tooling. So kinda sorta, but definitely not in a way that seems elegant to me :)

> Getting decent performance and/or scaling was/is a major challenge.

The rest of what you say I agree with, but the language was never a performance bottleneck over other scripting languages.

It certainly scaled better than ruby or perl or python apps with the same logic.

The fact that each request was fundamentally stateless and ephemeral helped this if you needed to distribute your app and made development faster as well.

Back to V5 it outperformed its competition in benchmarks

Paradoxically, PHP's stateless architecture is also what makes it dog-slow with large frameworks such as Laravel. Now you have to load the whole framework with every request.

> the whole framework

Files are autoloaded lazily, meaning only classes that are touched are loaded on any given request. If the code is split into well sized, purposeful modules, it becomes a non issue.

Sort of, but you don't need to parse it. Anyone using PHP in serious prod uses something like memcached/opcache to skip parsing, which speeds up TTFB typically by about 200x.

Even a bog standard LAMP setup has opcache enabled nowadays.

It outperformed them in benchmarks but not in practice due to having to reload all libraries on every request.

Back in the days it had terrible defaults that made it very difficult not to write insecure code and it was lacking so much it was really hard to write good, structured code.

Back in the day perhaps, but not today. PHP has come a really long way.

It's not the wand, it's the wizard.

If you recall the cartoon of programming languages as weapons, PHP was a sword without a hilt, which was quite fitting. Despite the low barrier to entry, there were "features" that were / are distinctly dangerous, and should not have been exposed to beginners (the comments section in the official documentation os a perfect example of this).

I never say this, but this resonates with me.

My company sent (or tried to send) money to Rasmus back in '95 to have him implement a feature we needed. I think he ended up adding our ask to PHP for free. Anyway, good times.

Do you remember what the feature was?

Someone from my dads office gave my some printed pages about ASP from MS. Until that time I was doing all my web dev in Perl (it was basically either that or c) with print "<HTML><BLINK>hello... et. After reading about ASP, I concocted my own miserable php-like thing in perl where you could put perl code in between <% %> to add logic. I tried to find the code (I have it somewhere in dropbox, I'm sure), but I remember I failed at doing it reliably with regexes, so I made a while(1) loop finding all open <% and close %>, escaping the html before and after, printing it and adding the code in between. It was only a handful of lines and worked really well; I wrote a lot of cgi for my clients with it.

But it was slow (even after adding cache) and it need quite a bit of setup and libraries (CPAN with my own layers to make it easier to use), so I was very happy when I discovered PHP 3 (I did not know it existed before that).

Good memories; deploying a site cheaply by scp/rsync the files.

> Good memories; deploying a site cheaply by scp/rsync the files.

Well. I have a minio instance running for static small sites, every time I wanted to create a new bucket I had to re-read my own notes and fiddle around for half an hour with s3cmd and mc before getting something live. Today I threw the things out and started using scp again. It's much easier, it's not in the way.

Have you tried IaaC Tools like terraform?

No, I don't have yet a use-case for it. It'd be a bit overkill for what I need.

I originally set up minio because I wanted to test out some backup solutions relying on S3 but I didn't want to use amazon (can't remember why). Turns out minio is great but not a 1:1 S3 clone and not every app can swap out amz for minio anyway.

I was thinking reading about ansible soon though.

But how is that easier than just uploading your files though? And it is more expensive, more overhead, more setup etc. Depends on the use case but for some things (like a personal or small company site), why would you over engineer it?

That brings back fond memories. I used to package up a PHP installer (and a MySQL one) for macOS for many years, back when OS X was still new and it was a bit of work to build various UNIX open source projects from source.

My day job was Solaris/Linux work so I was used to it and I wanted PHP on my Mac, so I built the installer for myself and also put it on my website, where more and more people downloaded it from over the years.

I haven't used PHP in more than ten years and only recently started dabbling with web development again for fun. I am very happy with TypeScript + React on the client side and Python or Swift on the server side.

Nostalgia. I started with PHP/FI 2.x. Was a great relief from writing web server apps in C.

Around this time, I tried to create stuff with the old Java J2EE. I found it too slow to compile and the language was too inflexible.

So, without a framework, I built my project in PHP and finished it in a week.

Bah! All I need is some perl and a CGI script to sail her by. Kidding, with the current web development churn I sometimes miss the simplicity of php.

I remember when I was at school in ~2000, I bought a paper book about PHP4.

I remember that as a warm feeling...

PHP 7.x and Laravel really gave the language its big boy pants. Really fun to develop in and looks nothing like the PHP 3.x and 5.x grime.

Sadly along with Laravel and Symfony came PSR culture where idiomatic PHP, with its fanfold docblock comments and double-spaced lines of code means you're lucky if you can see a dozen lines of code on a typical screen. I don't call that productive at all.

I agree, thats some bad practice and people think its good. I am part of the Uncle Bob clean code fan club. If you need comments and a doc bloc then there is something wrong with your code.

Double spaced lines of code? What do you mean?

FWIW, I no longer use DocBlocks because PHP's own type system is usually expressive enough.

> PHP's own type system is usually expressive enough.

I'd say it's one of the worst type systems. Expressive enough not to need docblocks, ok. Expressive as a type system: hell no.

I meant expressive enough that you don't need DocBlocks as often. We're nowhere near being done, PHP still lacks proper Generics and Algebraic Data Types. Recently we got Union Types (8.0) and will soon have Enums (8.1).

If you really needed generics today, you can do it with DocBlocks and static analyzers like PHPStan: <https://phpstan.org/blog/generics-in-php-using-phpdocs>. I'm hopeful that in the future, you won't need a DocBlock for that.

As for ADTs, there's some on going discussions here: <https://wiki.php.net/rfc/adts> which would build upon the existing support for Enums (8.1). I'm really looking forward to being able to have something resembling Optional/Maybe.

I'm by no means saying what PHP has is enough today, just that it's less limited than it was a few years ago. It'll be even less limited in the future.

You just said exactly what I said in my comment you reply on. More words, and more promo for future versions of PHP.

Seriously, try build something trivial with a strongly typed lang like Haskell or Elm (Elm is quite easy to get started with), and we can talk type systems after :)

Blank line above and below each line of code made even worse with opening brackets at column 1 of yet another new line. WTF!?

PHP was a godsend, saving me from Perl. I switched to the Dark Side and prefer C# these days, but I still keep an eye on it just because there was some fun stuff I built with it.

Looking at that archived page brings back memories. Since I'd started with PHP/FI and I think I went on until 4.x, I'm pretty sure I saw that announcement when it actually came out.

Once upon a time I used PHP as a scripting language. Then I got with the times and switched to Perl.

Look at those gifs enabling the rounded corners.

And also remember how slow connections was back then so the progressive enhancement from square to round wasnt just a blink.

So many memories

It's because it's not 'cool' like the young backends on the block. HNer's like to be 'in' with the cool crowd, so collectively dump on stuff like PHP for no reason whatsoever.

I see the same with modern VB.NET. It's my go-to 'utility' language because I can knock up tools in it without having to think or look up code fragments. However it still has the stink of old BASIC on it for some reason and as such draws the distain of 'real' coders. I just don't get it.

PHP is still the dominant backend language world wide and lot's of new projects are started with it. Might just be your bubble.

I think it’s still used a lot. The startup I worked with that used php (5 years ago) just got bought.

I think it’s pretty stable and so doesn’t get a lot of mindshare. It not what the cool startups are using but it’s still used. With a framework like Laravel or symfony I enjoy working with it.

I had this thought before I entered my job one year ago. There I experienced how fast php can be. Since php7 and the opcache things make fun again