6 ms·

I finally had a chance to write some PHP that (a) wasn't WordPress and (b) actually did something useful a few weeks ago at $DAYJOB. Going from zero to functio

I finally had a chance to write some PHP that (a) wasn't WordPress and (b) actually did something useful a few weeks ago at $DAYJOB. Going from zero to functional web backend in less than 3 hours for a language I'm almost totally unfamiliar with made me understand just why this got so gosh darn popular. I thought building out a Flask application was fast, but PHP's initial experimentation loop is just on another level, criticisms be what they may.

kingofthehill98 3y ago
It's such a perfect match for the HTTP protocol. You drop a file on a server and you're good to go. My toy VPS is full of useful scripts that I use on a daily basis. Most of them are literally one big file with all of the code, no external dependencies. Caddy proxy the request into PHP-FPM and send back the response, no bullshit. Of course this is not what we see at production-grade software, but I really enjoy the fact that the language was designed with the HTTP protocol in mind. It's really unique in this sense.
- tsukurimashou 3y ago
  yes, and the fact that you can just put inline HTML outside of PHP tags is so useful and convenient
  - zer00eyz 3y ago
    LOL The fact that I can't tell if this comment is sarcasm or snark or serious says a lot. PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
    - mschuster91 3y ago
      > PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. So what, JSPs are just the same. In the end what matters is the speed to Get Things Done, and there's utterly nothing competing with PHP, closely followed by Tomcat+JSP as you can use the insane amount of interfaces with just about everything that the Java world has.
    - FriedrichN 3y ago
      Why is it a "bad idea"? I'm genuinely curious. It works great, it's fast and you don't have to learn a new templating language or dialect every 2-3 years. Or try to figure out how to do trivial things like loops in loops. I don't quite get the use of templating engines in PHP because PHP is a templating engine itself.
      - zer00eyz 3y ago
        A few reasons: 1. It's a loaded foot gun. PHP was notorious for 1000 line files with HTML and SQL all mixed together. (I speak from personal experiences on this) 2. Templating languages are "portable" (In theory). Have a mixed env of PHP and Java... there were templating languages that would work for both teams, it took a step out of scalability.... XML and XSLT were the promise land on this one, but we fucked all that up. Portability is a big deal. We're still slinging CSV files for a good reason.
        FriedrichN 3y ago
        1. I've seen enough terrible things in my time, but you can make a mess in any language using any number of frameworks. And it's been a hot minute since I've seen one of those 1000+ line PHP+SQL+HTML+JS+CSS monstrosities in any serious environment. Improper use of templating engines or trying to use templating engines that aren't up to the task can give you headaches just as well. Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, in the end we're craftsmen who need to learn how to use our tools. 2. This could be a valid use case, but a rather rare one. XML+XSLT is something that sounds fantastic on paper, but as anyone who actually worked with it knows it ranges from a big disappointment to an absolute nightmare.
        rezonant 3y ago
        > Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, It's not a matter of whether the code is bad or not, but how bad. The entire point of frameworks is to add guard rails to help you stay disciplined and avoid cutting corners on separation of concerns. Using PHP as a template language tempts developers to violate SOC every day.
    - bemusedthrow75 3y ago
      > Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but... Indeed.
    - pintxo 3y ago
      It did make total sense at the time. Consider we are talking a time where you had static html. It is obviously good to be able to automate generating web pages based on say the state of a database. As this gives you up-to-date pages without someone having to manually build them. And if that - automatically build web-pages from a database - is your goal and your current state of the art is static pages, then creating a language you can interject into your static pages, to build the page dynamically is a no brainer.
      - rezonant 3y ago
        In defense of the PHP community, things like Symfony attempt to create some sanity when it comes to separation of concerns. Unfortunately, when people talk about PHP they inevitably talk about raw, framework less PHP and act like it's as sensible as something structured and disciplined like Ruby on Rails or ASP.NET MVC.
    - rezonant 3y ago
      > Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but... Hey don't drag Node into this, you aren't forced to do any of that. React to me feels like SPA developers discovering the idea of PHP and thinking they invented it. This shouldn't be surprising, since React came from Facebook, and Facebook historically is a PHP shop. Mixing your business logic and presentation is a bad idea, but it's very attractive when you don't have the informative scars You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail. PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
      - zer00eyz 3y ago
        > You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail. This is accurate, and I never thought of it that way. > PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment. I did laugh out loud because I did not know WHAT to make of the comment. As someone who buttered my bread on PHP when everyone hated it, it was a sign of how times have changed!
    - mrkeen 3y ago
      > PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. PHP receives its share of criticism, and HTML lives on relatively unscathed. So if mixing PHP/HTML is a problem, you'd probably throw out the PHP and keep the HTML. Also, isn't this use case PHP's origin? A dev wanted some programmable HTML?
    - flir 3y ago
      You're getting downvotes, but that genuinely puzzled me the first time I saw JSX. ("This looks a lot like 'include("form.php")' in old-school PHP. What am I missing?") Turns out I wasn't missing much. I've mentally pegged it as an example of "the pendulum swings" - thin client vs thick client, centre vs edge, tight coupling vs loose coupling, etc.
      - rezonant 3y ago
        Discerning developers avoid PHP for the reasons you mention, and yet it powers a frightening percentage of the Web. React is popular for the same reason as PHP. I can only hope the industry corrects for this soon, because I challenge you to find a startup building raw PHP in 2024, yet nearly all of them build with React.
    - Shish2k 3y ago
      > react doing this very thing and calling it JSX In PHP, “HTML" is string concatenation; in React, “HTML" is an HTML-flavoured bit of syntax sugar over HTML-generating functions (and you are still welcome to call the functions yourself, if you want your HTML-generation code to avoid looking like HTML). Aside from looking kind-of similar if you squint, I’d say the differences and pros and cons are fairly significant (For example the IMO worst thing about the PHP approach, the ease of shooting yourself in the foot with XSS holes, is a non-issue in JSX).
      - withinboredom 3y ago
        I built the Swytch Framework to exactly hit these spots. As far as I know, it’s the only templating system out there with contextual escaping (you write html, it parses the html using a streaming parser, escapes output, then writes it out). I use it exactly for rapid dev of stupid ideas. I’m not sure if I’d use it in a production environment because it is quite slow.
    - foul 3y ago
      > PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. If you think of PHP as prototype-only, mixing tags and HTML is very convenient, like it is with the other thousand templating tools. And obviously it's more a problem of XSS through badly sanitized inputs more than the mix in itself, blah blah blah It's PHP in production a bad practice that got out of hand.
    - crabmusket 3y ago
      > Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but... Because it's not "this very thing". HTML around PHP is output directly to stdout. JSX is just syntax for literals.
- jdpedrie 3y ago
  On the other hand, vanilla PHP effectively "hides" HTTP from the programmer. I taught myself PHP in middle school and high school as my first programming experience, and had no concept of a thing called "HTTP" for a very very long time. I knew the pieces of it that PHP gave me. I knew what $_POST, $_GET, $_SERVER, $_HEADER, set/getcookie(), were and how to manipulate them, and I knew the rules (setting a header after "echo" made it complain), but I didn't understand how that all hung together as a thing outside PHP called HTTP. When I did learn about HTTP, it was very easy, since I already knew it without knowing I knew it, so maybe that's in favor of your point, but there's much to be said for the actual understanding that I didn't have at first. When I started interviewing people for PHP entry-level jobs, asking about HTTP was one of the ways I gauged how well applicants understood their work at a conceptual level.
  - fideloper 3y ago
    This mirrors my experience exactly - it took me an embarrassingly long time to learn about http and what it means to be stateless. It also took learning other languages to understand how PHP is so unique in how tied to HTTP it is (rebuilding its entire universe every request). (these learnings happened when moving beyond the PHP-based CMS style of development - agency style work on my case - to make more custom software).
    - jimbokun 3y ago
      I imagine it took you awhile to understand what “stateless“ meant, because you weren’t exposed to the default state-fullness of most other languages, so didn’t realize stateless wasn’t the default.
      - fideloper 3y ago
        Yeah, that's for sure true.
rizky05 3y ago
It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego. Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way.
dijit 3y ago
I upvoted you and vouched u/rizky05 because I think they raised an important point. > It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego. > Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way. “Elegance” is something that gives people warm fuzzies, I think this is why there are so many Rust advocates (I am one), when pieces fit together nice or can be refactored cleanly and tests are first-party it is nice. However there have always been “hacky” and “proper” languages, because doing something hacky that works also feels great. Python is a hacky language, it’s easy to go to 0-100 very quickly. C++ however requires time and precision to make things proper, so people avoid it and few things are made comparatively in C++ unless it's infrastructure software that people spent a lot of time writing. Maintainability be damned, sometimes you really just need to throw something together. The curse of things that work is that they will be expanded upon and kept around for too long. Unfortunately: PHP works, and is an excellent hack-language for the web. Which means there’s a lot of code that becomes “production grade” that should really have never been intended to live forever in the first place.
- smarkov 3y ago
  > when pieces fit together nice or can be refactored cleanly This is a trade-off that makes sense to embrace in some contexts, and I do believe that web is one of them. The more nicely your pieces fit together the harder it'll be to break them apart. You can only refactor cleanly once you are aware of all the requirements, but those requirements are usually constantly changing in the context of web and so your pieces fitting together a little too nicely means that you now have to refactor a lot more code.
- thinkindie 3y ago
  PHP can be super hacky and super structured, within the same file, and it's your choice. You can have tests, static analysis, etc etc, or not. Or you can start without and then adding it as the project mature, without having to necessarily switch to another language. I'm working on my own startup that started as a side project and it was super hacky at the beginning, but by sticking to PHP (and thanks to PHP continuous improvements) I was able to refactor little by little and make the codebase way more structured and easier to maintain.
penteract 3y ago
This matches my experience of PHP. The questions/advice on stackoverflow and blog posts are also geared towards people who just want to get something done, which helps a lot if that's your goal. Go is the only other programming language I've had this experience with - picking it up with a goal in mind and succeeding in doing something more quickly than I might have with a familiar language.
- hiAndrewQuinn 3y ago
  I remember someone on SO saying "Go isn't a programming language, it's a DSL for writing networked services", and, well, if we can squint and call Go that, we can definitely call PHP a DSL for dynamic webpages.
  - nucleardog 3y ago
    You don’t even really need to squint that hard. That’s what it started as. It’s entire process model (instantiating the world for each request then tearing it all back down, not having any shared state) is fairly unlike most other general purpose languages. PHP inverts the usual assumption that “this code file is primarily code” on its head—it assumes any file it’s given contains other data until it finds the special open/close tags signifying a section that contains code. (Allowing you to embed it within HTML easily.) The runtime handles things like GET/POST variables natively and has a special way to expose them. Ditto for file uploads. The standard library isn’t extensive but contains a ton of functionality that revolves around managing web requests. (Managing HTTP headers, setting and reading cookies, ...) Etc, etc.
    - hiccuphippo 3y ago
      I'd say any sufficiently elaborated template language becomes Php.
      - Steven420 3y ago
        Damn that would be a pretty elaborate template language
ChrisMarshallNY 3y ago
I've been writing PHP for a quarter century, but I've never become a "whiz" at it. But I regularly write fast, robust, secure backends, in a day or less (less, if possible. I don't actually like working in PHP). Despite the torrents of hate from this community, it is still pretty much the backend king. Here's the "Fishtank Graph."[0] It kind of puts things in perspective. [0] https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...
- netule 3y ago
  I agree that it still owns a massive chunk of the backend market. 20-something years in, and it's still difficult to shake. However, I would take the numbers on the site you linked with a big grain of salt. Detecting which backend technology powers a site without direct evidence is nearly impossible. PHP may be high up the list since it and its associated stack leak the most metadata.
  - deleted 3y ago
    [deleted]
  - stevarino 3y ago
    I've totally copied php http headers into non-php backends just to see what happens. It costs nothing and gets a trifle more security. (Not really but it makes me giggle at least)
- KronisLV 3y ago
  I've always found those statistics to be a bit odd, given how popular other languages are, especially the likes of Python. Not only that, but since .NET Core and the new versions of .NET running just fine on Linux distros, I'd expect their usage to go up, not down. Curious. Actually, their disclaimer page seems to suggest that setups with a decoupled SPA/API might not be detected correctly: https://w3techs.com/disclaimer https://w3techs.com/disclaimer
  - throwaway84862 3y ago
evantbyrne 3y ago
In a lot of ways, PHP represents developer productivity maximalism. It's neither pretty nor safe, but there is a lot that other communities could learn by studying popular PHP libraries.
indigodaddy 3y ago
Any online resources you used to get yourself on the right track or as a starting point to get running?
- hiAndrewQuinn 3y ago
  Try running through https://bootcamp.laravel.com/blade/installation https://bootcamp.laravel.com/blade/installation if you've never worked with PHP at all before, and want to see what modern PHP feels like.
  - indigodaddy 3y ago
    Thanks!

kingofthehill98 3y ago

It's such a perfect match for the HTTP protocol. You drop a file on a server and you're good to go. My toy VPS is full of useful scripts that I use on a daily basis. Most of them are literally one big file with all of the code, no external dependencies. Caddy proxy the request into PHP-FPM and send back the response, no bullshit. Of course this is not what we see at production-grade software, but I really enjoy the fact that the language was designed with the HTTP protocol in mind. It's really unique in this sense.

tsukurimashou 3y ago
yes, and the fact that you can just put inline HTML outside of PHP tags is so useful and convenient
- zer00eyz 3y ago
  LOL The fact that I can't tell if this comment is sarcasm or snark or serious says a lot. PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
  - mschuster91 3y ago
    > PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. So what, JSPs are just the same. In the end what matters is the speed to Get Things Done, and there's utterly nothing competing with PHP, closely followed by Tomcat+JSP as you can use the insane amount of interfaces with just about everything that the Java world has.
  - FriedrichN 3y ago
    Why is it a "bad idea"? I'm genuinely curious. It works great, it's fast and you don't have to learn a new templating language or dialect every 2-3 years. Or try to figure out how to do trivial things like loops in loops. I don't quite get the use of templating engines in PHP because PHP is a templating engine itself.
    - zer00eyz 3y ago
      A few reasons: 1. It's a loaded foot gun. PHP was notorious for 1000 line files with HTML and SQL all mixed together. (I speak from personal experiences on this) 2. Templating languages are "portable" (In theory). Have a mixed env of PHP and Java... there were templating languages that would work for both teams, it took a step out of scalability.... XML and XSLT were the promise land on this one, but we fucked all that up. Portability is a big deal. We're still slinging CSV files for a good reason.
      - FriedrichN 3y ago
        1. I've seen enough terrible things in my time, but you can make a mess in any language using any number of frameworks. And it's been a hot minute since I've seen one of those 1000+ line PHP+SQL+HTML+JS+CSS monstrosities in any serious environment. Improper use of templating engines or trying to use templating engines that aren't up to the task can give you headaches just as well. Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, in the end we're craftsmen who need to learn how to use our tools. 2. This could be a valid use case, but a rather rare one. XML+XSLT is something that sounds fantastic on paper, but as anyone who actually worked with it knows it ranges from a big disappointment to an absolute nightmare.
        rezonant 3y ago
        > Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, It's not a matter of whether the code is bad or not, but how bad. The entire point of frameworks is to add guard rails to help you stay disciplined and avoid cutting corners on separation of concerns. Using PHP as a template language tempts developers to violate SOC every day.
  - bemusedthrow75 3y ago
    > Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but... Indeed.
  - pintxo 3y ago
    It did make total sense at the time. Consider we are talking a time where you had static html. It is obviously good to be able to automate generating web pages based on say the state of a database. As this gives you up-to-date pages without someone having to manually build them. And if that - automatically build web-pages from a database - is your goal and your current state of the art is static pages, then creating a language you can interject into your static pages, to build the page dynamically is a no brainer.
    - rezonant 3y ago
      In defense of the PHP community, things like Symfony attempt to create some sanity when it comes to separation of concerns. Unfortunately, when people talk about PHP they inevitably talk about raw, framework less PHP and act like it's as sensible as something structured and disciplined like Ruby on Rails or ASP.NET MVC.
  - rezonant 3y ago
    > Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but... Hey don't drag Node into this, you aren't forced to do any of that. React to me feels like SPA developers discovering the idea of PHP and thinking they invented it. This shouldn't be surprising, since React came from Facebook, and Facebook historically is a PHP shop. Mixing your business logic and presentation is a bad idea, but it's very attractive when you don't have the informative scars You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail. PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
    - zer00eyz 3y ago
      > You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail. This is accurate, and I never thought of it that way. > PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment. I did laugh out loud because I did not know WHAT to make of the comment. As someone who buttered my bread on PHP when everyone hated it, it was a sign of how times have changed!
  - mrkeen 3y ago
    > PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. PHP receives its share of criticism, and HTML lives on relatively unscathed. So if mixing PHP/HTML is a problem, you'd probably throw out the PHP and keep the HTML. Also, isn't this use case PHP's origin? A dev wanted some programmable HTML?
  - flir 3y ago
    You're getting downvotes, but that genuinely puzzled me the first time I saw JSX. ("This looks a lot like 'include("form.php")' in old-school PHP. What am I missing?") Turns out I wasn't missing much. I've mentally pegged it as an example of "the pendulum swings" - thin client vs thick client, centre vs edge, tight coupling vs loose coupling, etc.
    - rezonant 3y ago
      Discerning developers avoid PHP for the reasons you mention, and yet it powers a frightening percentage of the Web. React is popular for the same reason as PHP. I can only hope the industry corrects for this soon, because I challenge you to find a startup building raw PHP in 2024, yet nearly all of them build with React.
  - Shish2k 3y ago
    > react doing this very thing and calling it JSX In PHP, “HTML" is string concatenation; in React, “HTML" is an HTML-flavoured bit of syntax sugar over HTML-generating functions (and you are still welcome to call the functions yourself, if you want your HTML-generation code to avoid looking like HTML). Aside from looking kind-of similar if you squint, I’d say the differences and pros and cons are fairly significant (For example the IMO worst thing about the PHP approach, the ease of shooting yourself in the foot with XSS holes, is a non-issue in JSX).
    - withinboredom 3y ago
      I built the Swytch Framework to exactly hit these spots. As far as I know, it’s the only templating system out there with contextual escaping (you write html, it parses the html using a streaming parser, escapes output, then writes it out). I use it exactly for rapid dev of stupid ideas. I’m not sure if I’d use it in a production environment because it is quite slow.
  - foul 3y ago
    > PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand. If you think of PHP as prototype-only, mixing tags and HTML is very convenient, like it is with the other thousand templating tools. And obviously it's more a problem of XSS through badly sanitized inputs more than the mix in itself, blah blah blah It's PHP in production a bad practice that got out of hand.
  - crabmusket 3y ago
    > Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but... Because it's not "this very thing". HTML around PHP is output directly to stdout. JSX is just syntax for literals.
jdpedrie 3y ago
On the other hand, vanilla PHP effectively "hides" HTTP from the programmer. I taught myself PHP in middle school and high school as my first programming experience, and had no concept of a thing called "HTTP" for a very very long time. I knew the pieces of it that PHP gave me. I knew what $_POST, $_GET, $_SERVER, $_HEADER, set/getcookie(), were and how to manipulate them, and I knew the rules (setting a header after "echo" made it complain), but I didn't understand how that all hung together as a thing outside PHP called HTTP. When I did learn about HTTP, it was very easy, since I already knew it without knowing I knew it, so maybe that's in favor of your point, but there's much to be said for the actual understanding that I didn't have at first. When I started interviewing people for PHP entry-level jobs, asking about HTTP was one of the ways I gauged how well applicants understood their work at a conceptual level.
- fideloper 3y ago
  This mirrors my experience exactly - it took me an embarrassingly long time to learn about http and what it means to be stateless. It also took learning other languages to understand how PHP is so unique in how tied to HTTP it is (rebuilding its entire universe every request). (these learnings happened when moving beyond the PHP-based CMS style of development - agency style work on my case - to make more custom software).
  - jimbokun 3y ago
    I imagine it took you awhile to understand what “stateless“ meant, because you weren’t exposed to the default state-fullness of most other languages, so didn’t realize stateless wasn’t the default.
    - fideloper 3y ago
      Yeah, that's for sure true.

rizky05 3y ago

It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego. Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way.

dijit 3y ago

I upvoted you and vouched u/rizky05 because I think they raised an important point. > It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego. > Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way. “Elegance” is something that gives people warm fuzzies, I think this is why there are so many Rust advocates (I am one), when pieces fit together nice or can be refactored cleanly and tests are first-party it is nice. However there have always been “hacky” and “proper” languages, because doing something hacky that works also feels great. Python is a hacky language, it’s easy to go to 0-100 very quickly. C++ however requires time and precision to make things proper, so people avoid it and few things are made comparatively in C++ unless it's infrastructure software that people spent a lot of time writing. Maintainability be damned, sometimes you really just need to throw something together. The curse of things that work is that they will be expanded upon and kept around for too long. Unfortunately: PHP works, and is an excellent hack-language for the web. Which means there’s a lot of code that becomes “production grade” that should really have never been intended to live forever in the first place.

smarkov 3y ago
> when pieces fit together nice or can be refactored cleanly This is a trade-off that makes sense to embrace in some contexts, and I do believe that web is one of them. The more nicely your pieces fit together the harder it'll be to break them apart. You can only refactor cleanly once you are aware of all the requirements, but those requirements are usually constantly changing in the context of web and so your pieces fitting together a little too nicely means that you now have to refactor a lot more code.
thinkindie 3y ago
PHP can be super hacky and super structured, within the same file, and it's your choice. You can have tests, static analysis, etc etc, or not. Or you can start without and then adding it as the project mature, without having to necessarily switch to another language. I'm working on my own startup that started as a side project and it was super hacky at the beginning, but by sticking to PHP (and thanks to PHP continuous improvements) I was able to refactor little by little and make the codebase way more structured and easier to maintain.

penteract 3y ago

This matches my experience of PHP. The questions/advice on stackoverflow and blog posts are also geared towards people who just want to get something done, which helps a lot if that's your goal. Go is the only other programming language I've had this experience with - picking it up with a goal in mind and succeeding in doing something more quickly than I might have with a familiar language.

hiAndrewQuinn 3y ago
I remember someone on SO saying "Go isn't a programming language, it's a DSL for writing networked services", and, well, if we can squint and call Go that, we can definitely call PHP a DSL for dynamic webpages.
- nucleardog 3y ago
  You don’t even really need to squint that hard. That’s what it started as. It’s entire process model (instantiating the world for each request then tearing it all back down, not having any shared state) is fairly unlike most other general purpose languages. PHP inverts the usual assumption that “this code file is primarily code” on its head—it assumes any file it’s given contains other data until it finds the special open/close tags signifying a section that contains code. (Allowing you to embed it within HTML easily.) The runtime handles things like GET/POST variables natively and has a special way to expose them. Ditto for file uploads. The standard library isn’t extensive but contains a ton of functionality that revolves around managing web requests. (Managing HTTP headers, setting and reading cookies, ...) Etc, etc.
  - hiccuphippo 3y ago
    I'd say any sufficiently elaborated template language becomes Php.
    - Steven420 3y ago
      Damn that would be a pretty elaborate template language

ChrisMarshallNY 3y ago

I've been writing PHP for a quarter century, but I've never become a "whiz" at it. But I regularly write fast, robust, secure backends, in a day or less (less, if possible. I don't actually like working in PHP). Despite the torrents of hate from this community, it is still pretty much the backend king. Here's the "Fishtank Graph."[0] It kind of puts things in perspective. [0] https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...

netule 3y ago
I agree that it still owns a massive chunk of the backend market. 20-something years in, and it's still difficult to shake. However, I would take the numbers on the site you linked with a big grain of salt. Detecting which backend technology powers a site without direct evidence is nearly impossible. PHP may be high up the list since it and its associated stack leak the most metadata.
- deleted 3y ago
  [deleted]
- stevarino 3y ago
  I've totally copied php http headers into non-php backends just to see what happens. It costs nothing and gets a trifle more security. (Not really but it makes me giggle at least)
KronisLV 3y ago
I've always found those statistics to be a bit odd, given how popular other languages are, especially the likes of Python. Not only that, but since .NET Core and the new versions of .NET running just fine on Linux distros, I'd expect their usage to go up, not down. Curious. Actually, their disclaimer page seems to suggest that setups with a decoupled SPA/API might not be detected correctly: https://w3techs.com/disclaimer https://w3techs.com/disclaimer
- throwaway84862 3y ago

evantbyrne 3y ago

In a lot of ways, PHP represents developer productivity maximalism. It's neither pretty nor safe, but there is a lot that other communities could learn by studying popular PHP libraries.

indigodaddy 3y ago

Any online resources you used to get yourself on the right track or as a starting point to get running?

hiAndrewQuinn 3y ago
Try running through https://bootcamp.laravel.com/blade/installation https://bootcamp.laravel.com/blade/installation if you've never worked with PHP at all before, and want to see what modern PHP feels like.
- indigodaddy 3y ago
  Thanks!