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

    Isn’t Wordpress powering like 40% of the internet? PHP isn’t going anywhere anytime soon.

    For me the weirder part of that meme is Python in 2022?

  • pixxelkick@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    It’s hard to justify using anything other than JS or if you wanna be fancy, Web Assbly, for the FE.

    Any other front end language involves generating Javascript from your language, which inevitably ends up with you making a weird Frankenstein project that mixes the two.

    I’d rather just use stuff like Webpack or Vite to compile my JS front-end out of JS (or TS) from the start. It always ends up being a cleaner result.

    My backend though can be whatever the fuck I want it to be.

    But if you ever think dynamically compiling/transpiling a JS front end on the fly on demand is a good idea, instead of simply just delivering static pre-compiled/transpiled pages, you’re part of the problem for why the web is so slow and bloated.

    It’s wild how crazy of projects people will build that take 3 entire seconds to just deliver a 500kb static form that doesn’t even need angular to do anything. They turn a couple hundred kb into several mb for no useful reason, it’s wild.

    • Tekhne@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      To my understanding, you can’t really use WebAssembly for the frontend - it doesn’t support manipulating the DOM, so you still need to offload a lot of the work to JS. It’s an uncontested language when it comes to web frontend.

      • r1veRRR@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        It does support it, it’s just slower than JS. WA is faster in other aspects though, so frameworks that compile to WA (like the Rust framework Leptos) still end up being faster than a lot of JS ones.

  • thisfro@slrpnk.net
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    I’m sure there are a lot of reasons why PHP is better than Python for the backend, but I created an app wirh Symfony 5 and then an app with Django 4.

    Symfony is so weird compared to Django. With Django I can just sit down and get things done. Symfony always seems to have some quirks which are mostly due to PHP (and me not knowing how to program in PHP).

    That said, PHP hosting is so much easier and cheaper, this probably is important for smaller projects.

    • PlexSheep@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Django is pretty nice, yeah. We also have good compiled webapps, with go and rust. Gitea for example uses go.

  • lankybiker@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    PHP is amazing

    If you’re thinking of PHP version less than 8 you need to have another look

    Totally stateless. Uncached server side rendered response times in double digit milliseconds.

    Types

    Extremely battle, highly tested frameworks.

    Excellent tooling for tdd, bdd, static analysis, automated browser testing, coding standards and auto fixing. Even fully automated refactoring for things like package upgrades (Rector)

    Regular, solid, releases bringing updates and fixes

    Arguably one of the best package management systems, Composer. And only one, none of this constantly changing tooling that some other ecosystems seem to do

    Properly open source platforms to power all kinds of web projects from e-commerce, CRM, social, scraping, analytics, monitoring, API, CMS, blogging

    Basically if your target is server side web stuff then it’s really good

    Or, you can continue to demonstrate how out of touch you are by continuing with the old “PHP bad” jokes if you want!

      • FleetingTit@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        Dude was saying that 8 is good, but people still think of version 5 when talking about PHP. Not recommended to still use in 2023.

    • 342345@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Uncached server side rendered response times in double digit milliseconds.

      Thirst thought, that sounds slow. But for the use case of delivering html over the Internet it is fast enough.

        • aksdb@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          For a bit of templating? Yes! What drives response times up is typically the database or some RPC, both of which are out of control of PHP, so I assume these were not factored in (because PHP can’t win anything there in a comparison).

          • naught@sh.itjust.works
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            Anything under like 100ms load is instant to the user, especially a page load. It’s a balancing act of developer experience vs performance. To split hairs over milliseconds seems inconsequential to me. I mean, PHP requires $ before variables! That’s the real controversy :p

            • aksdb@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              1 year ago

              Anything under like 100ms load is instant to the user, especially a page load.

              True, but it accumulates. Every ms I save on templating I can “waste” on I/O, DB, upstream service calls, etc.

            • aksdb@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              1 year ago

              If you run it in old-school CGI mode, no, because each request would spawn a new process. But that’s nowhere near state-of-the-art. So typically you would still have a long-running process somewhere that could manage a connection pool. No idea if it does, though. Can’t imagine that it wouldn’t, however, since PHP would be slaughtered in benchmarks if there was no way to keep connections (or pools) open across requests.