It was a scripting engine with a such a thin layer of C that it could easily and quickly incorporate the huge number of open source C libraries that existed at the time.
Perhaps I was quite late to the party though - I only started programming in 1999 (got a computer for my 11th birthday!) - so I'm not sure what it was like before then.
CGI just would run any type of script. Originally that was typically Perl but PHP surpassed Perl for a variety of reasons. PHP could be run either through CGI or through mod_php in Apache. There was also a mod_perl I believe and a few others but php is what web hosts typically installed in the early 2000s.
From https://perl.apache.org/about/history.html
> "PHP was also around already, and was an embarrassing witness to Perl's greatest weakness for server-side programming: that embedding Perl was a pain. Although the hooks were there for embedding Perl, they were both undocumented and buggy.
My other take on it is that PHP is like TypeScript, in that the path to adopting PHP from HTML is simple enough—just rename your HTML files with a .php suffix and you can add dynamic elements—or not. Just like how you can rename your JavaScript code with a .ts suffix and add types—or not.
Personally, I remember writing a few Perl CGI scripts. But I ended up using PHP for any quick-and-dirty dynamic stuff.
This is the competition that PHP was so much better than.
PHP was only free beer with a clunky language and 3rd class DB support.
MySQL couldn't hold a candle to real RDMS back then, versus what was available with ODBC connectors.
Perhaps that is your definition, but the dictionary disagrees.
https://dictionary.cambridge.org/dictionary/english/superior
I don't see definitions about being cheaper as sign of quality, quite the opposite.
Maybe you would like to share your dictionary as well?
Getting access to a Windows box was never a problem in countries with more flexibility towards piracy.
80 and 90's Portuguese students could get whatever they wanted from shaddy shops that used to copy books and software.
Booklets with 200+ items on them.
I started doing ASP development before my web host suggested it was cheaper and easier to do PHP. They had both Linux and Windows shared hosting at the time.
http://www.apache-asp.org/faq.html
I was only wrong regarding the language, it made use of Perl instead.
The cheapest of them all was PHP with files being dumped via FTP upload.
The only competition in those early years was Perl iirc.
I'm not entirely sure if PHP was fast at acquiring new features.
PHP didn't have classes until version 4 iirc. Namespace in 5.4? And 5.x is around NodeJS early days where RoR and Python Django/Pylon/Pyramid was around.
I think how easy it is to pick up the language to do things contributed to its success. The template is built-in and 1000 functions in the global namespace.
You really have turn back the clock; languages didn't have package management back then. They didn't have packages. The only exception, at the time, was Perl (which had CPAN). PHP acquiring features was not just about language features but also how quickly it's standard library grew to accomplish anything you needed on the web.
> PHP didn't have classes until version 4 iirc. Namespace in 5.4? And 5.x is around NodeJS early days where RoR and Python Django/Pylon/Pyramid was around.
I'm actually talking about the PHP3 era; by the time we're talking about PHP5 then there was already plenty of competition and the "early days" were already long over.
Namespaces in 5.3
Javascript namespace/module handling is a nightmare, they should have copied PHP's.
To this day, cloud functions still deal with "cold starts", where this was already a solved problem with PHP shared hosting.
All PHP needed to be was good enough. It was how it served pages that made it as popular as it was.
Large disclaimer, I know a PHP shared host was not actually scalable like AWS Lambda. Just the idea that any small business could plop down a few servers and start selling shared PHP hosting was huge back then.
If it's just me writing and deploying I use TypeScript but otherwise I tend to use PHP.
That is not what I remember. CGI existed before PHP (1994), and was used extensively for web apps (ebay still appears to use it to this day). Also, mod_perl and Java Servlets were introduced around the same time, circa 1996, so I don't think it's correct to say PHP had a monopoly on web apps "for a long while".
Java required specialised or dedicated hosting ($$$). CGI was slow as hell. Mod_perl often was not available in shared hosting, for whatever reason.
PHP was cheap, fast, ubiquitous, and Good Enough™, for about a decade. Then VPS happened and the market changed.
While CGI was slow-ish, alternatives like fastcgi were already around (and in fact running PHP via fastcgi was also quite common for a while.
By the time PHP became ubiquitous, most people had moved away from plain CGI regardless of language.
Mind clarifying how this is different from the current hotness (from what I can tell, due to a decade-old shortcoming that no longer exists in mod_php/Apache MPM options) where folks are running PHP via the Fastcgi Process Manager?
That is only in relative terms in its time. For the past few years I keep thinking how the hell did Web Development went from Perl and CGI, arguably troublesome but understandable, to PHP which is ugly but easy to set up and running, to present days of... depending on which timeline you are, vagrant, VM, docker, k8s, Node.js... I would argue even Heroku with Ruby Rails isn't anywhere as easy as they were than the old days.
PHP only became viable with version 3, around 1998, and having most ISP only offering a choice between CGI (usually C or Perl) and PHP, naturally drove most cost oriented devs to PHPs.
Those willing to shell out more, could use one of the above options.
I could probably compete with python if I used guile's lower level C-procedures, but I sort of lost interest after that :)
You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation where programmers can't move fast enough in adding it to their stack. Data exfiltration is no longer a flaw but a feature.
It is very very easy to write sloppy PHP, definitely easier than in many other languages and default frameworks.
> You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. P
I'm very aware of them, basically none have (had) as many high-impact vulns as PHP-based stuff does.
> Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written.
You're not acknowledging the orders of magnitudes difference between the impact of an usual PHP vuln and those you listed.
> You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation
The flaws in others are a very poor excuse for flaws in a thing itself.
Where's your proof? Modern PHP frameworks are secure by default.
Symfony Laravel CodeIgniter CakePHP Yii Zend Slim
All of these can (and recommend) using either PDO with named parameters, or a full ORM for SQL work. Most came packaged with a PDO (Doctrine, mostly) by default but have always supported whatever you wanted to use.
Write shit code, win shit prizes.
I disagree, mostly on the grounds that string concatenation isn't very convenient, so it tends to be easier to do things "the right way" instead of hacking things together. Yes, you can do string concatenation using something like `format!(...)`, but at that point it's really similar to the correct solution that it's not really what you'd reach for by default.
And yeah, the community here is a huge part of it, and IMO languages can and should be judged by their communities. If a language's community promotes insecure solutions, that's a language that I don't want to use at my company because I don't want my employees following that example.
While there are some web-focussed languages (vs frameworks) that deliberately make it hard for you to write that sort of code, barely anyone uses them.
Not trying call you out on this point, more it made me laugh. Our lead developer strips out characters that break his XML importer (lets just say they are standard common characters, heck, he changes chr(13) to a string so he can switch it back later because he doesn't know how to handle multiple lines in an XML value). People who don't know how to escape inputs / actually handle data properly are in every language. We cringe on a daily basis.
- it is not "input" must be treated, but, so to say - output. It's the destination that matters, not the source. By the time you get the input, you have no idea how and where it will be used. You can tell it right before the output (or, rather, better to call it "use") only. Say, you've got some input that didn't pass the verification and you will have to display it back in the HTML form. And if you already "escaped" it for SQL, it will be malformed. And vice-versa. Moreover, any data must be formatted properly before use, not just something that you tagged as "input".
- the word treated above is for a reason. Because the term "escaping" suggests some certain routine in PHP, which is the actual reason for numerous SQL injections.
I'm working on comprehensive taint analysis for PHP[0], and I'm spending a bunch of time thinking about how to automatically detect those dirty strings.
[0] https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis
I personally believe it's ubiquity is well-deserved, and I actually like it as a language despite all its quirks (which exist in almost every language I've come across)!