PHP is dead? - eviltoast
  • Tarte@kbin.social
    link
    fedilink
    arrow-up
    29
    arrow-down
    2
    ·
    edit-2
    1 year ago

    https://w3techs.com/technologies/overview/programming_language

    On the server-side PHP is used by 76.8% of all websites (a large chunk of that being WordPress). It is not going anywhere, soon. Looking at this statistics, nothing else seems to be even in the same league from a pure usage point of view.

    I have yet to see a reason why it should change. Serious question: What is the disadvantage of using the tried and tested PHP8 compared to the alternatives, if you already know PHP?

    • simonced@lemmy.one
      link
      fedilink
      English
      arrow-up
      13
      arrow-down
      4
      ·
      1 year ago

      Serious Answer: PHP in itself is not that bad, despite some discussable decisions in function naming and arguments order to name a few. The biggest problem, is that it has a settings file describing how it works (php.ini) and that sh*t will bite you in the rear when you move apps from server to server, where all the libs are different etc… PHP never works out of the box when moving something on a new server, that is the worst part of the language.

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Maybe the issue in your example isn’t related to “how bad PHP is” but is to “how bad the code you’re referring to is”. Never had those kind of issues and yes obviously you’ve to know what extensions an application is using, but once again, modern PHP applications usually use composer as dependency manager and will gave those specified inside the project.

        • simonced@lemmy.one
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Good on you to not have to maintain legacy code (15years+). Also, as a comparison, with JAVA, I have a legacy JAVA 1.5 to maintain, as far as you have the runtime, that stuff works, and that’s it. This is how it should be.

          • TCB13@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            I do, the difference is that, unlike Ruby code bases, it happens to be supported languages that evolved and perform better today.

    • thews@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      6
      ·
      1 year ago

      Easy example. Have they fixed file upload behavior yet? Do they store the entire file in memory by default instead of chunking it and storing it as it comes in?

      If not it’s like the worst memory usage of any language possible.

      If you have to go change the php.ini to adjust file upload sizes, it’s not really moving forward and is decades behind other languages.

      • xmunk@sh.itjust.works
        link
        fedilink
        arrow-up
        7
        arrow-down
        1
        ·
        1 year ago

        File upload behavior is actually determined by your web server (unless you’re launching PHP in listening mode) so apache is probably who you want to blame here.

        • thews@lemmy.world
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          edit-2
          1 year ago

          Other languages behind reverse proxies from apache httpd or nginx do not have the same memory hit. You can still blame php. Not my fault they tied their language to the webserver in a way that uses tons of extra memory.

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        Easy example. Have they fixed file upload behavior yet? Do they store the entire file in memory by default instead of chunking it and storing it as it comes in?

        Are you in 1995? PHP dynamically decides how to manage uploaded files, it will generally store a few MB on RAM and move it to disk after that point. It also support streams so the backend can take the incoming data live and do stuff with it without storing it first as usual in the classical model. There are also plenty of higher level solutions to deal with chunked uploads, mobile clients disconnecting such as https://tus.io/ that are used by large companies like Vimeo.

    • puffy@lemmy.world
      link
      fedilink
      arrow-up
      9
      arrow-down
      11
      ·
      1 year ago

      Poor performance, execution model limitations, lack of static typing (although they seem to be working on that), and general legacy cruft.

      Don’t compare PHP to Node, Ruby or Python, they also have problems. I think Go is currently the best choice for a web backend; an objective evaluation of PHP and Go would certainly put Go ahead. If you know PHP, you can pick up Go in a day or two, so I don’t think that’s a great reason to keep using PHP either.

      Usage statistics are a highly misleading, software projects take several years to develop and a majority will fail. Looking at current usage tells you the most popular choice from 5 years ago, not today. Over 90% of video games published in the last 5-10 years use Unity or UE4, but these probably aren’t the best choices today.

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        I think Go is currently the best choice for a web backend; an objective evaluation of PHP and Go would certainly put Go ahead. If

        Yes for performance running code, for performance as in “developer time” PHP is way faster. Go is solid but developer take more time implementing stuff with it. Use PHP for everything business related except for that one or two cases where you really need the performance that Go provides and where it is worth the extra dev time.