7 ms·

Every time I read "PHP" in a thread I think "Here we go again with the useless hate/love comments". Can we just agree on "PHP used to suck but it was very easy

• dividedbyzero 3y ago
  I think that ship has sailed for the time being. Too many of the older cohort have been traumatized back in the day, and those that came after will only know PHP from horrible ancient codebase fossils no one wants to touch with a long stick
  • pindab0ter 3y ago
    There are also a lot of companies and people working with modern PHP frameworks. I’ve never had the displeasure to work with code bases older than a couple of years. My experience with PHP/Laravel has been that Laravel is an awesome framework on what is nowadays a ‘decent enough’ language. For comparison, at least PHP has first party type support nowadays, whereas Rails does not.
• 29athrowaway 3y ago
  The reason it got traction was that it was easy to get a Linux, MySQL, Apache and PHP installation and getting it to run. The documentation was easy to navigate as well. This is often an overlooked aspect of it. It was comparable to ASP which was also popular at the time.
  • phpisthebest 3y ago
    >easy to get a Linux, MySQL, Apache and PHP Come on now, it is Linux, Apache, MySQL, and PHP === LAMP... it was more than just easy of getting a server going, it over all ease of development, PHP was MUCH easier to work with as a developer than ASP or Perl, or any of the other early web lang's
    • 29athrowaway 3y ago
      It is the same set. Personally I used to install it in LMAP order, because Apache and PHP share configuration settings and you want to validate everything end-to-end at the end.
    • flir 3y ago
      ASP was about on a par with PHP 3 tbh. PHP probably had the edge because of the array and string handling, but an IIS/ASP web server was easier to set up, and a lot of people could write visual basic.
      • 29athrowaway 3y ago
        IIS and ASP was harder to provision programatically. It was all GUI based. At the time some saw it as an advantage, today everyone agrees that it does not scale
        • flir 3y ago
          Sure, but we're talking about the time when servers were pets, not cattle.
          • phpisthebest 3y ago
            Lots and Lots of Pets still out there.
          • 29athrowaway 3y ago
            Speak for yourself, brother
• viraptor 3y ago
  Kinda. I can agree that for example Laravel is better than what we had in the past, but it's still worse than lots of non-php alternatives we had available for years. It's still playing catch-up, and that's assuming you get to work with new frameworks rather than writing a WP plugin or something similar. And it's hard to talk about modern php when probably most of the code out therei s still written like it's year 2000.
  • codersfocus 3y ago
    What do you think it's playing catch up to? To only competitor I see is Rails. No other framework has such a rich and powerful ecosystem for web development.
    • martinald 3y ago
      asp.net core?
    • viraptor 3y ago
      Ecosystem: Django/Rails Language features and non-web usage: basically everything Handling concurrency/streaming: Phoenix Simplicity while providing batteries: Flask Backend/front-end integration: Blazor
      • pindab0ter 3y ago
        Can you give examples of how Laravel is playing catch-up in these regards? Backend/front-end integration is very well done with Livewire/Inertia. Simplicity while providing batteries is a given, but even more so with some of the starter kits. And honestly, I’ve been quite impressed with all the high quality, Laravel-specific packages out there (looking at you, Spatie). I’ll definitely give you non-web usage and most of language features (even though PHP nowadays has first class type support, which can’t be said of Rails, unfortunately). And yes, concurrency is all but absent. Apart from RoR, I haven’t used much else in the full stack framework space, so I’d love to hear!
        • 3y ago
• boredumb 3y ago
  No, it's still a terrible language.
  • juliend2 3y ago
    Why?
    • rizky05 3y ago
      [dead]
    • IshKebab 3y ago
      Like JavaScript they've never fixed any of the fundamental issues, like implicit type coercion, and the standard library is full of completely mad methods with extra "behave_in_a_sane_way = false" parameters. I mean, probably the sensible choice - backwards compatibility is very important. But it does mean that a lot of the things that made PHP awful still make it awful.
• Nullabillity 3y ago
  There's this fallacy that just because something is popular, it must have some valid niche use case. That just because it endures, it must have improved somehow over the years, rather than just been taken over by an ever-proceeding chain of fools. You can usually recognize it because people refuse to explain why something is "good" or "better now", instead just blanket-asserting that it is.
  • mgkimsal 3y ago
    Don't be so hard on React. It does have some valid niche use cases. ;)
• ulrischa 3y ago
  Yes. I agree 100. PHP has evolved more than any other language. But it can not get rid of the dirt konnte elephant's back
• toastercat 3y ago
  As someone who used to champion PHP when PHP7 was new: if you're most productive with PHP, or if there is a PHP-only tool/library that does something specific that you want, or if you're maintaining a large PHP codebase and need to modernize it while keeping breakage to a minimum, by all means use it! But otherwise, choose something else for new projects (Node/Go). EDIT: Also forgot to mention, PHP is great for cheap hosting, and still provides one of the simplest ways of building a server-side webapp (everything can live in an index.php file) so that is another benefit if you're looking for that.
  • ipaddr 3y ago
    Why use Node/Go? What would be the advantage? The go ecosystem is a ways behind and whatever you compile in Node today will break tomorrow. What would I gain by switching?
    • askmike 3y ago
      What do you mean things in node breaking? JS is extremely backwards compatible. I think everything I wrote a decade ago in node still runs fine.
      • ipaddr 3y ago
        I've always had issues with newer versions of node not running projects written with older node without upgrading the project and hoping all dependencies can be updated.
        • tracker1 3y ago
          Fortunately, a lot of the earlier struggles came down to binary libraries. At this point, a lot of externalized libraries are now using webassembly targets or built-ins. SQLite being one of the more popular exceptions. For the most part, I haven't had too much trouble the past couple years taking an existing project and running on a newer runtime. I have seen a lot of incompatible library breaks trying to update dependencies though.
• aarondf 3y ago
  I've been working with PHP since the early 2000s, and it has undergone massive changes. I made a video recently called "PHP doesn't suck (anymore)"[0] to try to cover some of the changes from 2012 to now. If you read through the comments you see a lot of people surprised at how much the language has evolved. And a lot of people saying "PHP sucks lol," but it is YouTube afterall. [0] https://youtu.be/ZRV3pBuPxEQ https://youtu.be/ZRV3pBuPxEQ
  • dinkleberg 3y ago
    Nice video! I was genuinely surprised to see how far PHP has come since I last touched it.
• asddubs 3y ago
  but pachico, your comment is one of those comments
  • pachico 3y ago
    This is true. On my defense, I hoped I could, somehow, settle some of the dust with it.
• ompogUe 3y ago
  Been working with PHP since the late '90s, still do with some legacy Zend Framework clients. Lot's of people people who hate on PHP's "design" (not the code bases created from it), didn't understand what was going on. PHP allows taking any C program and writing a wrapper around it, and they would often just use the C program's API, which would then become part of the PHP API for that extension . There was amazing inconsistency there, yes, when looking through a formal lens. But it was not "designed" so much as "grown" - it was an organic thing made for delivering. It was quickly able to have huge amounts of functionality added that didn't happen as fast with ASP or Cold Fusion, and I didn't find it nearly as gnarly as Perl.
  • tracker1 3y ago
    I understood that a lot of API inconsistencies come from the underlying C libraries. For me, the biggest annoyance was in that the language itself was inconsistent with itself (not talking about libraries), array usage in particular was iirc really weird in terms of the usage functions. From what I understand it's better today and Laravel and other options can make it nice to work with. I was rather partial to Classic ASP with JScript myself... Although the biggest issue in that whole space was a lot of the addons were commercial and expensive COM libraries. VB6 added a lot of value and made it more useful. It was a much different time in the mid-late 90's though. These days, I'm still more inclined to fave JS environments such as Deno or node, that have vast and rich options for everything. Though the language itself still has a lot of detractors, even for TS. I've also been enjoying the bit I've played with Rust.
• JodieBenitez 3y ago
  More like "PHP used to suck but it was installed in very cheap hosting, reason why it got traction. Things got better over the years and while those that use modern versions see how much it has changed, those that only saw the early years don't even care because they all use better tools".
• ramesh31 3y ago
  > "PHP used to suck but it was very easy to work with, reason why it got traction. Things got better over the years and those that only saw the early years, rightfully only remember how much it sucked, while those that use modern versions see how much it has changed"? +1 I fall into the latter and will always defend it. PHP had a very similar development arc to JS.
• littlestymaar 3y ago
  Counterpoint: PHP used to be a very simple tool, the best for simple projects and to learn stuff about the how to build a website. But now it grew into one of the biggest language ever in terms of different features and syntaxes, and people have been building monstrous framework to try a build “serious” stuff with it. PHP of the past didn't “suck”, but people who grew PHP in it current state, because they wanted a “professional” language definitely made it suck. RIP PHP.
  • vbgamer45 3y ago
    Agreed basically the OOP people who took it too far.
• saghm 3y ago
  > Can we just agree on "PHP used to suck but it was very easy to work with, reason why it got traction. Things got better over the years and those that only saw the early years, rightfully only remember how much it sucked, while those that use modern versions see how much it has changed"? This comment is super interesting to me, not because it contains anything I haven't heard before, but because the phrasing managed to break through my "bubble" of being the type of PHP naysayer you're talking about by making me realize just how similar this trend is to some other tech products that I'm not nearly as down on (I use btrfs on my personal machines, and I worked for several years at MongoDB, both of which seem to suffer from similar views of "fool me once and I'll refuse to ever give you another chance, no matter how much changes"). I still probably won't end up using PHP myself, given that I don't really do much web development anymore, but you've at least gotten one person to reconsider their opinion on PHP, so thank you for that!
  • johnny22 3y ago
    ok, maybe i'm falling into what you're talking about here, but i saw those as 2 separate things. BTRFS had bugs that could be fixed, so when they're fixed you can use it. While with mongo, it's still fundamentally a schemaless datastore. If you have a fundamental problem with that, then there's no bugs that can be fixed to make it ok. I think in these cases you need to separate out the core criticism over simply temporary issues.
    • saghm 3y ago
      The criticism of mongodb that I'm referring to is from the early days when there were some questionable defaults (e.g. writes not being required to be fully written to the database before returning success to the user, which can lead to data loss if something happens that prevents the write from completing afterwards). I agree that's a separate concern than not having the schema enforced by the database. It's possible that my experience is skewed by being more involved when I worked there, but I used to hear and see a lot more criticism of mongodb around things like data durability and ACID compliance than about the lack of an enforced schema. Maybe things have moved on enough that this isn't a common complaint anymore, which would be a pleasant surprise, and hopefully we can get to that point on PHP too.
• deleted 3y ago
  [deleted]