• @jagoan@lemmy.world
    link
    fedilink
    1517 months 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?

    • Zeppo
      link
      fedilink
      English
      60
      edit-2
      7 months ago

      12 years after we learned Flask. 19 years after Django, which also was apparently hot 2 years before it was released.

    • @EnderMB@lemmy.world
      link
      fedilink
      14
      edit-2
      7 months ago

      IMO, Ruby is a better Python than Python. It’s simpler, has a cleaner syntax, and if you want to do funky stuff metaprogramming can allow you to do cool, and sometimes unspeakable things. Python has great library support, and slowness and Rails did make Ruby unpopular for a bit, but I would love to see a Ruby resurgence that wasn’t to do with Rails, because it is truly a lovely language to use.

      Hell, I would say that in 2023, it’s easier/faster to get something set up and working in Rails than it is with frameworks like Symfony, Express, ASP.NET, etc.

        • @nilloc@discuss.tchncs.de
          link
          fedilink
          English
          77 months ago

          There are literally dozens of us.

          Ruby feels a lot like writing poetry. Especially with microframeworks like Sinatra.

          Python feels more like writing JS/ECMAScript without any punctuation.

          Then again I cut my teeth on Actionscript (1 ugh, 2 ooo, and 3 nice—oh the iPhone doesn’t support it…), so my opinion is probably pretty worthless.

          • folkrav
            link
            fedilink
            37 months ago

            Python feels more like writing JS/ECMAScript without any punctuation.

            I don’t know Ruby enough to judge, but I’ll have to say, hard disagree on this particular statement for me. JS to me feels like a bastardized C with some functional-inspired syntax tacked on top, while Python feels like writing English.

        • @EnderMB@lemmy.world
          link
          fedilink
          27 months ago

          I’d wager that most people haven’t used Ruby in anger, so don’t really have the comparison. Those that have used it have probably only used it in a Rails context, which IMO is a fairly limited environment to really play with Ruby.

          I definitely love the language, but the ecosystem, library support, and some of the companies that jumped on the initial Rails bandwagon can be extremely backwards and resistant to change in tech.

    • @Kerandir@lemmy.world
      link
      fedilink
      27 months ago

      Can you elaborate on the python part? I’m not a programmer ( I don’t work in the field but I studied programming in high school) but I see python mentioned everywhere, is the language obsolete?

      • @jagoan@lemmy.world
        link
        fedilink
        67 months ago

        It’s not obsolete, it’s very good, still is. Just that Flask and Django both built on top of Python. So if it’s like late 90s or early 00s. Definitely before either Django / Flask. Python isn’t the new and thing of 2022.

      • 520
        link
        fedilink
        6
        edit-2
        7 months ago

        Python based web frameworks like Flask are a lot newer

    • Raltoid
      link
      fedilink
      17 months ago

      In 2020 it was used at least in part on over 80% of websites according to w3techs.

  • mrbubblesort
    link
    fedilink
    1147 months ago

    People who say PHP is shit haven’t really used it and are just repeating the memes. It’s a perfectly fine language and there are a number of excellent tools and frameworks for it. It’s reputation is a result of it’s easy entry and widespread use. A whole lot of people who knew just enough to be dangerous made a whole lot of stuff, and it ended up causing a whole lot of problems. But for some reason devs shit on the language instead of shitting on the devs who put them in a mess.

    • @frezik@midwest.social
      link
      fedilink
      417 months ago

      Nah, it’s historically been a special kind of shit. It started life as a Perl templating engine, then grew out to its own language where it repeated all of Perl’s mistakes while adding more of its own. Its community was single-handedly responsible for keeping SQL injection attacks in the OWASP Top 10 list for years. Notice that it’s now bundled with “injection attacks” as a generic label for a wider range of similar issues–SQL injection alone would no longer warrant being there. Its conflation of arrays and hash maps meant it took years to wrestle with algorithmic complexity attacks. Perl kept the two separate, and was able to get a patch out for algorithmic complexity almost immediately (though it turned out to have a few bugs of its own, and a true fix came in a few years later; still faster than PHP solved it).

      The web from 1998 through 2010 or so was absolutely riddled with bad PHP programs. “But that’s not the language’s fault”, you say? Doesn’t matter. Community is an important and underappreciated feature of a language, and PHP had a special kind of shit community. It almost seemed designed to suck away the dross from all other communities.

      Consider the plugin system for phpBB:

      • Its architecture doesn’t have any kind of hook system for plugins; they’re added by patching the code in place
      • This naturally leads to different plugins interfering with each other
      • Having done that, you might choose one of the patch formats already out there, but phpBB decide to create their own
      • There are, at first, no tools available to automatically patch in plugins, so administrators (often not developers themselves) need to hand edit the source files and modify the database (the plugin format specifies both together)
      • Tools start to emerge over the years to handle it automatically, but they’re buggy and unusable for a long time

      Is it PHP’s fault that one major application was implemented so poorly? YES! Its community is a feature, and its community is what brought us to this.

      You want to claim that the language has done better since PHP7? Alright, that’s fine. I still don’t care. There are so many better options available, and I don’t have time to keep up with all of them. I’m happy relegating PHP to being a long-tail language where it trails off slowly over the years like COBOL.

      • @araozu
        link
        97 months ago

        I’d say that PHP allows you to write very bad code (and makes that the default). It’s a language feature.

        For example Java has a lot of NullPointerException because it was designed with null and without mechanisms to detect & prevent these errors. Any method can return null and cause a NPE. It’s just easy to ignore them. Modern languages like Go, Rust or Zig force you to handle null errors, and make it easy to do so. NPEs are a lasguage feature in Java.

        In the same way PHP allows you to write any ugly code you want. There are no checks, no safety. People can write bad code, people can be lazy, people can be stupid. PHP allows it and empowers them.

      • @catacomb@beehaw.org
        link
        fedilink
        English
        17 months ago

        Exactly. I used PHP for years, I haven’t “not used it.” It was the first programming language I seriously learned. Writing good code was tedious if not impossible and that became even more obvious as I expanded to C#, Java, Python and C++; none of which tolerated any of the bad and unconventional practices I’d inevitably picked up. Keep in mind, I was actively trying to avoid bad practices and pay close attention to types but still got kicked to the curb hard when I tried other languages. I haven’t had that since.

        I appreciate it’s changed since, I’m happy to see it’s not the same dumpster fire it once was, I also don’t care. I don’t actively trash it, I just think there’s usually a better option.

    • @Bigworsh@discuss.tchncs.de
      link
      fedilink
      277 months ago

      I used PHP for the past year. And honestly I still think it is not a good language. Just of the top of my head.

      1. By far the biggest culprit. Arrays. This monstrosity is basically everything. Yes, it is fast but it only teaches bad habits. It is a weird combination of Arrays/Lists/(Dictionary/Hashmap) and you can’t know which one it currently is because there are 0 compile time safety checks. Also when used as a parameter it is passing a full copy instead. But the copy of course is only shallow. I have seen so many problems with that. And even worse when someone thinks the way to fix it, is to just json encode/decode the whole thing in order to get a deep copy before passing it.

      2. Generics. I still don’t get why this is such a huge issue. Like I would rather have a half-baked optional compile time implementation then none at all. The worst part is that IDE tools support generics so you end up inplementing them on the comment level. I shouldn’t be forced to use generics through comments.

      3. $ for variables. I know that this is just based on how the language grew. But god do I hate having to type it. It is not an easy to reach letter and just breaks my typing flow the whole time. You get used to it but still.

      4 . The default functions. Yes. You will mostly use framework provided functions or your own stuff. But you still end up in contact with them and the naming schemes are still all over the place, so it is fast to just google it then hope you accidentally stumble upon it through the IDE. And some things are still straight up missing. Like the best way to deep copy an array is json_encode into json_decode. When I saw this the first time I was sure that must be wrong. But no. That is legit the way to do it.

      Also I am stuck with PHP7 so some of my other complains seemed to be fixed in later versions. Also please don’t recommend DS for my first issue. I tried to push for it but it got vetoed because “it is too complicated for new devs”.

      • @gornius@lemmy.world
        link
        fedilink
        107 months ago

        The language itself is not that bad. Especially the newest releases are really great, thought out DX improvements. What stinks are its legacy parts and how it needs to be run.

        My biggest pain is that for it to actually behave like it should it requires some sort of an actual web server like apache or nginx.

        Also, servers written in are actually request handlers - every time a request comes, the whole app is reinitialized, because it just can’t hold its state in memory. In many apps every request means reinitializing connection with database. If you want to keep some state, you have to use some caching mechanism like redis or memcached.

        Also had one time when Symfony app was crashing, because someone forgot to close class braces, and everything was “working” until some part of code didn’t like it and was just dying without any error.

        And one time when someone put two endlines after php closing tag at the end of the file, confusing the entire php interpreter into skipping some lines of code - also without warning, and only in specific php version.

        • @frezik@midwest.social
          link
          fedilink
          6
          edit-2
          7 months ago

          Back in the day, the way it integrated with Apache was an evolutionary advantage to PHP. It found a strategy that worked in its environment and it thrived. That environment no longer exists, but PHP holds on vestigially.

          We didn’t have AWS or other cheap, virtualized hosting way back when. It was all shared plans where you had a directory of your stuff, and it was there with a hundred other people on the same server and Apache instance. You could run whatever you wanted as a CGI, but that was even worse; it forks off a whole interpreter for the language, parses the code, and then used STDIN/STDOUT to communicate. Even if you implemented it in compiled C code (which had all the other problems you would expect), that fork is still expensive.

          Projects like mod_perl and mod_python built an interpreter directly into Apache, but there was a problem with how it worked: it was too sophisticated. They could hook into the entire Apache API. That meant that there was no way to separate your stuff from every other thing on the same shared hosting plan. Any one instance would be able to fool around in all other accounts. That’s untenable, so your choices for those languages were to either get a dedicated plan at well over $100/month, or stick with a $5/month shared plan and put up with it being unscalable.

          Enter mod_php. It builds the interpreter into Apache, but that’s all it does. Still have a parsing step, but it doesn’t have to fork. Doesn’t try do anything else. Its fast, and it can be hosted on cheap shared plans.

          If you’re a startup at this time, operating on frozen pizza and office chairs from a thrift store, then you could get a cheap plan, develop it under CGI, and hope that you can refactor it later when you can afford a dedicated plan. Oh, and keep in mind that CGI doesn’t lend itself to converting easily to the Apache API or whatever else you’re going to use in the future. Alternatively, you could build it in PHP and it will be fast now and acceptable later.

          It’s no great mystery why PHP was chosen at the time. There were limited options, and it was the cheap, get it done now option.

      • @moriquende@lemmy.world
        link
        fedilink
        97 months ago

        Not sure why you focus on arrays for deep copying. Deep copying objects is a problem in many languages and brings some challenges with itself that make it almost always necessary to delegate it to a library.

        • @Bigworsh@discuss.tchncs.de
          link
          fedilink
          57 months ago

          Simply because it was an issue that I ran into at work. And the reason I focus on arrays is because of the previously mentioned default behaviour of arrays being cloned when passed as an argument for a function. The issue here was someone unexperienced wrote a bunch of code and used only arrays (deep ugly arrays) and it ended up being a huge mess of some references staying the same while others changed. So the only solution was to deep copy at one place. That way later operations on these arrays didn’t affect the original structure. Not pretty but refactoring would have been too much effort.

      • @glimse@lemmy.world
        link
        fedilink
        57 months ago

        $ for variables. I know that this is just based on how the language grew. But god do I hate having to type it. It is not an easy to reach letter and just breaks my typing flow the whole time. You get used to it but still.

        I’m assuming you’re not using an English keyboard…? Shift+4 is an extremely key combination for me lol

      • @GombeenSysadmin@feddit.uk
        link
        fedilink
        37 months ago

        The answer for the deep copy would seem to be a combination of a static recursive function to copy the array while cloning the objects inside, with setting the __clone() magic function in your objects to break the references, no? Granted it’s not a built in function, but not difficult to implement.

        • @Bigworsh@discuss.tchncs.de
          link
          fedilink
          27 months ago

          Sorry for being lazy so no sources for now. But based on my research back then. Using clone (on arrays) is actually slower then json_encode/json_decode.

          So there are some cool optimization tricks going on in the background. But that doesn’t make it any more intuitive for me.

        • @derpgon@programming.dev
          link
          fedilink
          2
          edit-2
          7 months ago

          Arrays are passed by copy by default. Every scalar or array value is copied by value. Every other thing (objects basically) is copied by reference.

          Passing array by reference passes everything it used to copy by reference.

          Attempting to clone an array will result in an error.

          Reassignment of a variable containing an array will do the same as if passed to a function by value.

          Reassignment of a variable containing an array using the reference operator will do the same as if passed to a function by reference.

          So, in order to deep copy an array, just reassign and recursively traverse the array calling clone on each object. Of course, this would break (or not, depending on the intended use) when the same object is referenced multiple times under different keys.

    • @ahto@feddit.de
      link
      fedilink
      147 months ago

      It has also improved a lot in the last years. PHP5 and especially versions older than that weren’t very good and deserved a lot of the criticism. PHP7 and onward are much better languages and don’t deserve the hate.

      • @BeigeAgenda@lemmy.ca
        link
        fedilink
        57 months ago

        I worked a lot with PHP3 and 4, they work by the “Here is a flat C style API and here’s all the functions to use.” principle, and a lot of the work was finding the needed function, and how to use it.

        I know PHP5 did a lot of redesign especially with classes, but have never used it, hope PHP5+ feels more like Pythons toolbox.

        If I should write a web application today, I would start looking at Python based frameworks: Django (I have used it before)/Flask/Etc. as I am not sure I would like to work with JavaScript, or have to re-learn PHP.

        • pingveno
          link
          fedilink
          37 months ago

          A fun story about the origin of some of PHP’s first function names. The hash function in the table for function names in the interpreter was strlen(), so names were chosen to have a wide distribution of lengths.

          (source)

        • pingveno
          link
          fedilink
          17 months ago

          A fun story about the origin of some of PHP’s first function names. The hash function in the table for function names in the interpreter was strlen(), so names were chosen to have a wide distribution of lengths.

          (source)

    • @TrickDacy@lemmy.world
      link
      fedilink
      147 months ago

      There are a lot of people who think that if a language or framework doesn’t completely disallow bad practices (and of course the authors have to agree with their very specific subjective ideas of what bad practices are) then it sucks. I’ve always found that weird. Like why are you mad at a tool for being “too flexible”? Why not be okay with learning what not to do?

      • @frezik@midwest.social
        link
        fedilink
        6
        edit-2
        7 months ago

        If you’re going to do that, then you also have to have a community that stresses best practices.

        In 1999, Perl was leading the world with a tutorial for DBI (its primary database driver interface then and now) that uses placeholders in its very first code example. The community made that the standard, and it was the first hit on “Perl SQL tutorial” on Google for a long time. Perl applications with SQL injection attacks are out there, but have been relatively uncommon.

        Notice that the API doesn’t force you to use placeholders. It’s simply strongly encouraged by the community.

        Also in 1999, PHP was leading the world in not having a database driver interface through a common API, but rather a thin wrapper over whatever C libraries were used for individual databases. If that database supported placeholders at all (MySQL didn’t, and guess which database was most popular with PHP?), then it often had a different syntax* for every one. (Note that Perl’s DBI uses a translation interface that can implement “?” as a placeholder for you if the underlying DB doesn’t do anything else or uses weird syntax). You could always use a filtering function, and PHP devs would routinely try to write their own rather than use the one that came with the database API that’s already vetted. Either way, there was no widespread community pressure to use safe practices, and PHP led the world in SQL injection vulnerabilities for well over a decade.

        *As a side note, I was recently accused by another dev of having a Python app riddled with SQL injection vulnerabilities. In fact, it was well protected, but it was using the psycopg interface to PostgreSQL, and it has a weird placeholder syntax that the other developer wasn’t familiar with. Thanks, psycopg!

        • @xmunk@sh.itjust.works
          link
          fedilink
          27 months ago

          An interesting thing you may have missed is that the PHP community actually aggressively removed posts from stack overflow suggesting the old broken autoquoter approach. I’d say that PHP actually has an incredibly security minded community at this point.

          • @frezik@midwest.social
            link
            fedilink
            57 months ago

            I don’t doubt the language has improved. I just don’t see a point when there’s a million other options. In the 90s/early 2000s, you had Perl, Python, Java, and PHP. Ruby was playing around the fringes. There had been some attempts at server side JavaScript, but they weren’t well developed or integrated with the frontend the way it is today.

            We’re now spoiled for choice, and I see no reason to give PHP any of my time over Elixir, Rust, Go, or TypeScript.

    • @araozu
      link
      147 months ago

      I used to think that php was a bad language until recently (used php5 when i was just learning to program, cooked some delicious spaghetti). But after 5 years I had to use PHP at work. The language has improved a lot, but I think a lot of the bad parts are still there.

      Like, why does stdclass exist? Why not just use associative arrays? Why are there warning, error, fatal errors, exceptions? Some functions throw exceptions, other raise errors, others return false, other fail silently and you have to call another function to check if there was an error (last_json_error). Why do find functions return false instead of -1? Like every other language? Why can’t I use strings with numeric values as maps keys? (I can’t have ["001" => value], it gets casted to ["1" => value].

      There are no generics, you have to use mixed everywhere. The stdlib is an inconsistent mess, some_snake_case, someCamelCase, verb_noun, noun_verb, functions are not namespaced, everything is global. A lot of duplicates: die vs exit, print vs echo, etc. You are forced to use PSR & autoload to be able to use namespaces in a tolerable way, not including_once everywhere. No UTF-8 support, only ascii. You have to manually use mb_ functions. Variable scoping is weird. Variable variables? Why?

      And all that is just comparing it to the average language. If compared to a modern language like Rust, Zig, Swift, php is light years behind.

      It’s not hot garbage, but I wouldn’t call it “good”. There’s laravel, but not much more. PHP still makes you shoot yourself in the foot by default, unless you spend a lot of time learning its edge cases. Just like javascript.

    • @Blackmist@feddit.uk
      link
      fedilink
      English
      87 months ago

      I think the worst thing about PHP is all the ancient tutorials that litter the web like landmines. SQL injections everywhere.

      And there’s way too many low-budget wannabe web developers who know just enough to blow their own feet off. Or more likely whoever paid for its feet, because that web dev will be nowhere to be seen a week after handing it over.

    • @xmunk@sh.itjust.works
      link
      fedilink
      67 months ago

      Honestly, php is actually pretty fucking sweet for functional programming and metaprogramming… other languages wish they had __invoke and __get.

      I also think it has the “right” balance of library functions built in, you can do pretty much anything common and trivial with built-ins but the function list is short enough that you can comprehend most of it.

      • @araozu
        link
        47 months ago

        __invoke is just for making a class Callable. Java has those with functional interfaces. __get is just dynamic property resolution synax sugar. Instead of something like obj.get("property") you do obj->property.

        Instead, I would like to see ADTs, generics, pattern matching, immutability, expressions everywhere and a better stdlib. Then one could call PHP functional.

        It’s like how people say Javascript is functional. Sure, it has lambdas, anonymous functions, closures, const. But those alone don’t make it functional.

        Functional programming is very different (and at times hard). If you have the time you can check out F#, OCaml, Elixir, Erlang, Rust or Haskell (in order of difficulty imo). Those are more “pure” functional, rather than imperative/OOP with a touch of functional.

        See how things work, what features they have and don’t have. How problems are solved in these languages. I think learning about one of them can give you a different perspective on what functional means. I discovered F# one day, got curious and discovered a whole different paradigm, a new perspective on programming. And learning about functional programming really made me a better programmer, even on procedural/OOP.

    • @ursakhiin@beehaw.org
      link
      fedilink
      5
      edit-2
      7 months ago

      My issue with PHP isn’t the language, it’s the developers. PHP developer culture is much like C# and Java culture.

      I could bring a million reasons I don’t want to program in PHP and every time we talk about it, the PHP developer tells me I should be using it for everything. If I suggest that it may not be the best tool for a particular task at hand, the PHP developer tells me it’s the only language they know so they will use PHP.

      The issue is that this type of culture closes doors mentally. In any craft, we should try to use the best tool available for the task at hand. In carpentry you’d use a hammer with nails and a screwdriver with screws. In programming, there are times using PHP makes sense and times it doesn’t.

      In container based services, I tend to lean toward a compiled binary because it reduces the size of the container at run time and most modern languages don’t require tons of heavy duty frameworks to scale well there.

      In a monolith, a fully interpreted language with an MVC framework could make sense.

      • @EthicalAI@beehaw.org
        link
        fedilink
        37 months ago

        I’ll never understand devs that go “I don’t know that language”. PHP is one of the only languages used in production I don’t know. I have read examples and it looks like you bastardized a Java/c# clone with bash or a string templating language, which isn’t very appealing. But like, if I had to learn it, I’d do so in a month, functionally writing it in a week tops. Learning languages is part of the job, and they all add something to your understanding of paradigms.

      • I think we need to keep in mind that a programming language isn’t learned in a day whereas the use of most tools can be learnt within minutes, albeit not perfected of course.

        The hurdle to learn a new language is higher and also there is only so many langauges you can be fluent in at the same time, until you start mixing stuff up and causing more problems for yourself than being proficient in just a few languages.

        • @ursakhiin@beehaw.org
          link
          fedilink
          27 months ago

          It’s fine to not know every language. I’m not saying you must know every language. I’m saying that only knowing one and refusing to use another is a problem I’ve seen from PHP, Java, and C# cultures almost exclusively.

          The only exception I’d say that makes sense is people who are using coding for a small part of their overall job. But full time software engineers should have at least a few options in their belt for backend that they understand and can use in different scenarios.

    • Fushuan [he/him]
      link
      English
      47 months ago

      It’s also funny how they mention languages and frameworks, but php is just php. No symphony or whatever people use now, php. And somehow people whlent from using frameworks in python to not using them? It makes little sense.

    • @Pipoca@lemmy.world
      link
      fedilink
      37 months ago

      I’ve never actually used PHP.

      Does it still have random Hebrew in error messages like ‘unexpected T_PAAMAYIM_NEKUDOTAYIM’?

    • z3bra
      link
      fedilink
      17 months ago

      One could argue that people who say PHP is fine only suffer Stockholm syndrome !

    • jungle
      link
      fedilink
      -147 months ago

      I think PHP is shit because I used it about 14 years ago (+/- 1/2 years), where it was crystal clear that the language was written by a complete amateur. I’ve example off the top of my head: you couldn’t reference an element of an array returned by a function in the same line, you had to first assign the function’s output to a variable and only then were you able to reference an element of the array in the variable. Like, WTF!!!???

      It may have improved over time, I just don’t care enough to find out. It doesn’t deserve my attention.

      • @xmunk@sh.itjust.works
        link
        fedilink
        67 months ago

        Yea, I used Rust 14 years ago and it didn’t even have a compiler, what a fucking clown car of a language!

        (Also, they fixed that with a really smooth syntax… and 14 years ago, you actually could do it with list())

        • jungle
          link
          fedilink
          -27 months ago

          I’ve designed languages from the ground up, and written interpreters and compilers, so maybe I’m a bit of a snob regarding that kind of thing.

          With all the levels of abstraction nowadays it’s impossible for anyone to understand the whole stack, so I don’t blame you for not caring how things are implemented under the hood.

          But that issue with PHP (one of many) made me want to find the person who wrote that abomination and slap them with a baseball bat.

  • @vsis@feddit.cl
    link
    fedilink
    English
    837 months ago

    There are two kind of programming languages:

    1. The ones everyone complaints about
    2. The ones nobody uses.
  • @pixxelkick@lemmy.world
    link
    fedilink
    667 months 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.

      • @pixxelkick@lemmy.world
        link
        fedilink
        177 months ago

        I prefer html personally :x

        But yeah, I mostly blame the project managers that encourage this behavior, it’s wild how much overengineering goes into basic stuff like making mostly static websites.

        • @derpgon@programming.dev
          link
          fedilink
          77 months ago

          Same, plain old HTML, and if I need some reactivity then Stimulus. And if need even more reactivity, then VueJS / Alpine. If the form can’t be submitted via a regular submit button, it infuriates me.

    • Tekhne
      link
      fedilink
      77 months 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
        127 months 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.

    • @araozu
      link
      37 months ago

      I find that the only reason for SSR existence is to be able to just move a JS frontend to the backend for SEO/client performonce reasons with almost no effort. If the frontend really needs to be highly interactive then yeah, a FE framework makes things easier. But then you are locking yourself to using JS in the backend. Voluntarily locking yourself to use an objectively bad language.

      Then there are the react/angular/other people, who build everything in these frontends.

      I really hope tools like htmx gain traction, since it looks like a model able to solve the current JS madness.

      • @pixxelkick@lemmy.world
        link
        fedilink
        27 months ago

        I’m not liking htmx, I checked it out, it seemed promising, but it has giant gaping security holes in it so I can’t endorse it.

        I have been sticking to using Ejs with html-bundler-webpack

        The combo is lightning fast and gives me a solid usability of html partials so I can modularize my front end in re-useable chunks.

        It compiles to the static site fast for iterative development, it has everything I need baked in for common needs (minification, bundling, transpiling, cache busting, integrity, crossorigin, tree shaking, etc etx)

        I like how it let’s me just focus on actually writing the html + js + css and not have to muck around with thirty boilerplate steps to just make the app run.

        If I need a lot of reactivity I’ll use vue or angular but I so so rarely need that.

        And now with the template element, half the time reactivity can just be done with those.

        Only time I actually need react/vue is when I have to frequently mutate/delete in the DOM.

        But if I purely am additive, adding things to the DOM, template elements are plenty.

        • @araozu
          link
          37 months ago

          Could you elaborate on the htmx security holes? I only know about xss attacks, and for those it’s trivial to sanitize in the backend.

          I too gravitate towards just templating for static or simple interactivity, but for pages that need SEO and interactivity I’m still wondering what’s a good solution that doesn’t involve SSR and a js framework. For a recent project I had I generated the html in php and sent a lot of pure js for dom manipulation

          • @pixxelkick@lemmy.world
            link
            fedilink
            97 months ago

            Htmx has a bunch of logic that basically completely bypasses Content Security Policy stuff, as it has its own pseudo baked in “execute inline js” logic that executes arbitrary javascript via attributes on html elements.

            Since this gets executed by the HTMX logic you load in from their library, it effectively allows an attacker to arbitrarily execute js via manipulating the DOM, and Content Security Policy won’t pick it up because HTMX parses the attribute and executes on behalf of it (and you have already whitelisted HTMX in your CSP for it to function)

            Result: It punctures a giant hole in your CSP, rendering it useless.

            There’s technically a flag you can flip to disable this functionality, but its via the dom so… not reliable imo. If I could pre-compile HTMX ahead of time with that functionality completely disabled to the degree it doesnt even get compiled into the output .js at all, then I would trust it.

            But the fact all the logic is still technically there in the library I have loaded and I am purely relying on “this flag in the dom should block this from working, probably”, I don’t see that as very secure.

            So until that gets fixed and I can compile htmx with webpack or vite in order to completely treeshake that functionality right the hell out of my output, I aint gonna recommend anyone use it if they want an iota of security on their site. It’s got literally baked in security bypasses, don’t use it.

            Hell Id even just be happy if they released a “htmx-lite” package I could use, that just doesnt have that functionality baked in, thatd be enough to make me consider it.

  • @lankybiker@lemmy.world
    link
    fedilink
    667 months 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!

    • @342345@feddit.de
      link
      fedilink
      207 months 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
          47 months 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
            47 months 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
              47 months 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
              07 months 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.

    • nicman24
      link
      fedilink
      37 months ago

      not only that but you just install it with the lamp stack setting in ubuntu tasksel with apache and mariadb. the beating that these can take (except maybe the sql) and survive is great. you also have access to the whole of linux to do more advanced stuff, while other languages/ stacks shy away from exec

        • amio
          link
          fedilink
          117 months ago

          Turns out arbitrary code execution is actually great(!)

            • @Slotos@feddit.nl
              link
              fedilink
              27 months ago

              Problem is, you’re mixing a number of different concepts into a nonsensical claim.

              Exec as an “execute a string as a language instructions” is nothing new nor unique to PHP. Ruby on Rails, for example, uses it in a controlled manner to generate methods on ActiveRecord models.

              Exec as an “replace this process with another process” is old news again. It’s not even language specific.

              Popen/spawn family (which seems to be what you alluded to) is, once again, nothing new and is used everywhere.

              • nicman24
                link
                fedilink
                -17 months ago

                i just meant that python’s and node’s implementation is shit

      • @TheBeege@lemmy.world
        link
        fedilink
        3
        edit-2
        7 months ago

        All of that can be the same as other stacks except the Apache bit. You can stand up a Go application on Ubuntu hitting MariaDB as its persistence layer. Or Python. Or Node. Or Java. Or even Ruby. Shit, Haskell can do it.

        Also, exec is a code smell. Arbitrary code execution is a massive security risk, and the effort to mitigate that risk is often less than explicitly building out the required functionality.

        I think you need to explore more technologies, my friend. And read up on some security things

        Edit: I now realize you mean exec as in calling out to a shell. All languages have this. Still, the overhead of spawning and managing a new process is often more than just implementing the logic in your application itself.

    • @gkd@lemmy.ml
      link
      fedilink
      17 months ago

      On the note of testing, Pest is still one of the best testing options I’ve seen across a variety of langs.

  • @breakfastburrito@sh.itjust.works
    link
    fedilink
    44
    edit-2
    7 months ago

    This was nearly a decade ago. I worked at a small app company (5-10 developers) for a bit that used Ruby on Rails for our product. The product was in active development, but was available to customers so it was “done”. We were hiring a senior level dev to oversee the team and we interviewed this guy (maybe in his 40s?, a but older than most people in tech) and he said his first order of business if hired would be to refactor the entire code base to php. I don’t think he was joking. I’m not sure why he interviewed.

    • @TCB13@lemmy.world
      link
      fedilink
      English
      77 months ago

      Is there anything serious still running on a Ruby codebase nowadays? In PHP however…

        • Samuel C
          link
          fedilink
          57 months ago

          Github too or a least when you look at the github enterprises source code

          • @TCB13@lemmy.world
            link
            fedilink
            English
            27 months ago

            What can they do tho?

            Since the beginning, GitHub.com has been a Ruby on Rails monolith. Today, the application is nearly two million lines of code and more than 1,000 engineers collaborate on it daily

      • @darkpanda@lemmy.ca
        link
        fedilink
        77 months ago
        • GitHub
        • Gitlab
        • Airbnb
        • Shopify
        • Hulu
        • Zendesk
        • Basecamp, obviously

        I know of a bunch of less famous ones, but those are a few of the bigger ones that I’m aware of.

      • @kroy@lemmy.world
        link
        fedilink
        English
        57 months ago

        Only people supporting legacy regret.

        Ruby was never good. It just got memed enough to make it way into some medium business

  • Arthur Besse
    link
    fedilink
    43
    edit-2
    7 months ago

    This is an irritating meme.

    Were people saying PHP was dead in 1995, the year it was released? I guess maybe?

    But who was suggesting abandoning PHP for Django in 2003, two years before the latter was publicly released? I suppose the person who made this must’ve read that Django development started in 2003 and gone with that; most of these years correspond with when the respective project started.

    So, the reason Perl (which remained more popular for web development than PHP or any of these things into the early 2000s) isn’t on the list must be because it actually predates PHP.

    But then what is up with Python in 2022?

    • @paholg
      link
      English
      297 months ago

      I also appreciate that you’re supposed to learn Django 19 years before you learn Python.

    • @catacomb@beehaw.org
      link
      fedilink
      English
      17 months ago

      Yeah, plus PHP was very popular circa 2011-2016 and laravel was loved by many around that time and beyond. It’s always been a useful language.

  • @thisfro@slrpnk.net
    link
    fedilink
    367 months 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.

    • SokathHisEyesOpen
      link
      fedilink
      English
      127 months ago

      You don’t need a framework for PHP. That’s the beauty of it, you don’t need anything. You cannot build a website with Python without a framework.

    • @PlexSheep@feddit.de
      link
      fedilink
      107 months ago

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

    • @locuester@lemmy.zip
      link
      fedilink
      English
      47 months ago

      Isn’t all hosting containerized at this point? Is hosted, language specific servers still a thing?

      I’ve been out of the market for a while now and just run everything as containers on aws and gcp

      • @thisfro@slrpnk.net
        link
        fedilink
        17 months ago

        Many older projects don’t get migrated to containerized infrastructure and smaller businesses don’t want the overhead it creates to run a single app/webpage. Plain LAMP with FTP access is still the most common way to host I think (and thus the cheapest if you consider the amount of work that would need to be invested to containerize).

        • @locuester@lemmy.zip
          link
          fedilink
          English
          17 months ago

          Interesting. I never really realized how it was more my path changing than the entire industry.

          • @thisfro@slrpnk.net
            link
            fedilink
            27 months ago

            The industry is surely changing, but “the industry” is mostly geared towards enterprise, because it’s where the money is. But the large amount of webpages are not enterprise pages but personal blogs, small businesses etc.

    • @TCB13@lemmy.world
      link
      fedilink
      English
      -37 months ago

      Lets just say that Python was a language that was never supposed to be used for anything production related. PHP’s memory management and multi threading capabilities are WAY more solid and less prone to leaks than Python 's.

      • @kroy@lemmy.world
        link
        fedilink
        English
        37 months ago

        As someone that used PHP professionally for literal decades, the PHP hate is so meme-y.

        Its biggest problem is that it allows you to do some truly cursed things. The same can be said about other languages, but PHP really doesn’t do much to set you up for success, especially as a new-intermediate coder.

        With opcache, it became fast enough for basically most web backends, and as a language overall it does seem to be evolving and shedding off some of the crap that used to make it truly horrible in the hands of a new person. At least the type-juggling stupiderrors

        Now I mainly use go and python (only because I have to on this one), and I would put Python and PHP on a similar level of “fuck this language” moments

    • @zeppo@lemmy.world
      link
      fedilink
      English
      -117 months ago

      For the backend? Why? I could see PHP being better for the front end considering it’s basically a templating language already, and setting up Python on a webserver is much more complex, last I tried.

      • SokathHisEyesOpen
        link
        fedilink
        English
        167 months ago

        PHP is a server-side language, how do you plan to use it for the front-end? Good luck with that!

        • @zeppo@lemmy.world
          link
          fedilink
          English
          -3
          edit-2
          7 months ago

          Oh, I see what you mean. I thought you meant output HTML and templating vs server side logic, but yes, obviously I know the difference as the only front-end language is JavaScript and derivatives.

          I’m more used to the terms ‘server-side’ and ‘client-side’ btw. Obviously PHP is server-side. But not all server-side is backend in my view. I consider backend to be application logic and things like database access. Templating can be done on the server or the client, and that’s front-end.

  • @effward@lemmy.world
    link
    fedilink
    English
    357 months ago

    I like how 3 of them, across almost 20 years, boil down to “learn Python”. When’s that dude gonna die??

  • Tarte
    link
    fedilink
    27
    edit-2
    7 months 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
      97 months 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
        17 months 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
          17 months 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
            27 months ago

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

    • @puffy@lemmy.world
      link
      fedilink
      -27 months 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
        17 months 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.

    • @thews@lemmy.world
      link
      fedilink
      -27 months 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
        67 months 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
          3
          edit-2
          7 months 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
        27 months 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.

  • Einar
    link
    21
    edit-2
    7 months ago

    Symfony, Laravel & other PHP based frameworks are going strong. PHP isn’t going away anytime soon.