20 ms·

PHP in 2022

• jbverschoor 5y ago
  Won’t be long before php is java
  • ragnot 5y ago
    More like COBOL honestly
  • fleetfox 5y ago
    Hopefully it's closer to Kotlin or TypeScript
    • emteycz 5y ago
      It's not. It's a mess of OOP mind-castles, very much like Java used to be before streams. Nothing to do with the excellent typed functional-ish programming model of TS or Kotlin.
  • The_Colonel 5y ago
    You mean the most successful enterprise language and 2nd/3rd most used language overall? TBH, I don't think PHP is going in that direction.
    • jbverschoor 5y ago
      No, just in terms of features and syntax. Too bad you can't remove all the bad stuff from php, or any old tech. This was one of my requests to that new search engine posted here a few days ago.. Filter on minimum version of technology. Should actually just be a field in stackexchange.. packages/languages references + version. And a marker to set if the information is obsolete.
      • BeefWellington 5y ago
        > No, just in terms of features and syntax. Too bad you can't remove all the bad stuff from php, or any old tech. You can, it just takes ages and dedication and will cause a lot of friction. See: Python's changes between 2.x and 3.x, .NET's breaking changes between 1.x and 2.x+
      • The_Colonel 5y ago
        PHP and Java are indeed superficially similar (this was claimed 20 years ago, too). You can't get rid of old stuff in the name of BC, but you often simply don't have to use that old stuff. For example, people hate on JavaScript (and PHP too I believe) for the semantics of their "==" operator, but it's a moot point since these languages have had "===" since many years.
        • marcosdumay 5y ago
          If you are enough aware of the differences that you know you should use `===`, the difference becomes moot, because this is not the only unityped footgun on the language, and one of the easiest ones to deal with. The practical problem with `==` is for beginners, and the reason most people refer to it is because it showcases a very large and deep flaw of the language, not because of itself.
          • The_Colonel 5y ago
            > If you are enough aware of the differences that you know you should use `===` Every beginner knows that because all recent books literally say "don't use ==, use ===", modern IDEs will point it out for you and 1st code review feedback will point it out. What usage of this moot point showcases for me is mostly author's blind bashing without real knowledge.
            • marcosdumay 5y ago
              If you only know "don't use ==, use ===", you will just fall for the next unityped trap. If you know why you shouldn't use `==`, you know enough so that even if you don't go for `===`, using `==` safely is the least of your problems.
  • stemc43 5y ago
    use swoole/openswoole with php - async away.
• samsaga2 5y ago
  Enums with functions. WTF
  • jpgvm 5y ago
    Enums are just special classes no? Why can't they have functions defined on them?
  • TacoSteemers 5y ago
    Java enums also have functions. If they didn't we would need to write separate helper classes. Can you give a reason why we should not have them?
    • kaba0 5y ago
      Java enums are essentially an in-built singleton pattern where only the given entries can exist. They are not necessarily analogous with sum types, even though rust sort of washes the two together.
  • tempodox 5y ago
    It's not unreasonable to group functions with the type they operate on.
  • djxfade 5y ago
    Many languages has functions in Enums. They are just a specialized Class/Struct. Rust, Swift and Java among many languages has this.
• qaq 5y ago
  Cool to see it's still kicking and making major improvements
• m4l3x 5y ago
  I was a php developer for some time two years ago, before switching to go. I was mainly solving high performance parallel processing and distributed problems. There are things like ReactPHP which are an awesome achievement, but still every lib you use needs to be developed for ReactPHP. After learning about go and goroutines I only find it painful to solve these problems in PHP, even using ReactPHP.
  • jhgb 5y ago
    So you switched from a language X not designed to do Q to a language Y designed to do Q, presumably because language Y didn't exist when you started doing Q. I imagine that happens all the time, but seldom is it a fault of X. But what I find puzzling is why PHP, of all things, was your choice for these kinds of problems before Go appeared.
    • edoceo 5y ago
      Isn't Go like 10 years old now?
      • jhgb 5y ago
        More like thirteen. Apparently I misread the comment I was responding to as "for two years some time ago". Now I'm not sure why someone would have chosen PHP for such a task two years ago.
        • m4l3x 5y ago
          Sorry for unclear phrasing. I meant I used php from 2018-2020. And honestly I don't know why to use php for the task. I started at the company 2018 and the tech stack was given. A good compensation and praising like "PHP has changed and now supports types etc." let me take the opportunity. My bad, because it took me a lot of time. I needed to do benchmarks were actually PHP turned out to have comparable performance in the scenario under test (concurrent consuming of message Queues and heavily write operations to databases), however it took more than 4 times the effort to get there with php. In the end I resigned and switched to a new opportunity doing golang solving similar issues. My point is, that there are folks out there (ab)using PHP for all and everything. And finally php has made a lot of improvements but it is just catching up with other languages. There are still a lot of libraries, that still use older versions and probably never will get updated.
• mojuba 5y ago
  Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC. Funny how PHP devs are often unaware of this. Anyway I wish the language at least evolved faster and we wouldn't wait for 8.0 to have global `const` definitions instead of the archaic `define()` for example.
  • Aeolun 5y ago
    I think that’s my biggest problem having moved from PHP to Typescript. I just expect my language to have certain features now, and while PHP is catching up, it still isn’t there yet. And even if they do, what then? It’ll just be feature parity, so there’s no need to switch back either way.
  • ehnto 5y ago
    It's still in major use across the industry so I don't think it's too little too late. Maybe late, but not too late. I think it's pragmatism is partly why it's still so popular. No need to rush to the next best thing as PHP is perfectly capable of taking you from side-project to enterprise software with millions of users.
  • dskloet 5y ago
    Slow change is good for small projects that you want to build once and use for decades without much maintenance.
    • mojuba 5y ago
      A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".
• hmottestad 5y ago
  PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works. I love to focus my energy on building a great frontend with React or Vue.
  • dskloet 5y ago
    In the past I built a few things on Google App Engine. Honestly one of my greatest regrets in life. I ported a few to PHP so I won't get screwed again when I need to change hosting provider. Still need to port some and am dreading doing it but it will be for the better.
    • cube00 5y ago
      It's a shame companies, especially large ones with strategic architecture teams who should know better, haven't identified the short term cost savings of using cloud provider specific services is not worth the long term cost of vendor lock in.
      • edoceo 5y ago
        And for startups their recently minted MBA CEOs are too willing to load up on "tech debt" on the race to revenue. And really, it's not a bad trade - financially. But it will frustrate your eng team, for a bit - especially if you don't actually get the revenue stream going.
    • thraxil 5y ago
      Huh. I deploy a lot of stuff to GAE and love it. But my approach is to just write regular Django apps, add a half dozen lines of GAE-specific stuff to the settings and that's it. No trouble at all running the same apps somewhere else with only trivial changes. That's worked really well for me for work where we're already on GCP and GAE lets us run our lower traffic services reliably for very little money.
• f311a 5y ago
  It's still a language that's mainly used for web development, right? Modern websites in big companies require pretty complex backends that require data processing queues and other background activities. Can PHP compete with languages such as Go, Python or Ruby in the future?
  • vaylian 5y ago
    Why shouldn't PHP be able to compete here? I personally prefer Python over PHP for stylistic reasons but I have no doubt that PHP is capable of doing the same things as Python, even if the syntax looks a bit more outdated.
    • f311a 5y ago
      Because it wasn't designed for long-running processes or data processing at first. It evolved a lot, but I don't see it outside of simple backends for websites.
      • The_Colonel 5y ago
        That applies to Ruby and Python as well.
        • f311a 5y ago
          Not sure about Ruby, but Python is a pretty popular choice. There are tons of open source projects that are used by big players for data processing and complex backends.
          • The_Colonel 5y ago
            Might be used for that, but Python certainly wasn't "designed for long-running processes or data processing at first" which was your original argument. These 3 languages are pretty comparable in many ways.
            • 5y ago
• arenaninja 5y ago
  enums in PHP! I've been waiting a long time for this
  • cies 5y ago
    And now you can wait for them to be used by (std) libs. This kind of features are hard to bolt on later on.
• cletus 5y ago
  I'm a fan of PHP and have been for years for several reasons: 1. Low barrier to entry; 2. Hard to leak resources since the model is to tear down everything after a request finishes; 3. Stateless API core which means the efforts of creating an environment for a request for (2) is extremely low. Compare this to, say, the bootstrap time for Python or Java (which is why those generally don't follow the request teardown model); 4. Almost no multithreading. This makes it great for servicing HTTP requests IMHO. I need to compare it to Hack/HHVM though since I used that for years and it's still playing catch up with features Hack has had for years eg: 1. Hack has had the async-await model for years; 2. The type system is actually really good. It made me appreciate how nullability being part of the type system is incredibly useful. Plus it's had generics for years; and 3. Better inbuilt collection types with less odd coercion behaviour (ie dict, keyset, vec). I find PHP hate in 2022 to be tired. Look at something like Laravel and PHP is completely fine. The sins of the past and even the odd inconsistencies still left in the language (eg needle and haystack param ordering) don't really matter.
  • np_tedious 5y ago
    It seems that PHP (or at least the community) is taking a lot of inspiration from hack for its newer additions, and giving very little in the way of credit or comparisons. It is weird than an article like this shows nothing for ctrl+f "hack"
  • viraptor 5y ago
    > Compare this to, say, the bootstrap time for Python or Java The bootstrap time for a request exists only in a web framework, not in the language. And since you can have the extremes of pure fastcgi or uwsgi, or full Django, you need a more specific comparison.
    • moring 5y ago
      Java has a high bootstrap time for the JVM. PHP doesn't have that, but the "tear down everything" model might imply a high bootstrap time depending on the framework, because things need to be bootstrapped per request that are already there in Java.
• cntainer 5y ago
  I started my career in PHP ~15 years ago trying to do OOP in PHP 4.x. That was "fun". In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level. I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and some of the frameworks were trying too hard to copy the Java ecosystem, all while Java itself was starting to modernize. I'm curious what is the value proposition of the latest PHP version(s). Why would I choose PHP when starting a greenfield project? I know one of the easiest answers is that there's a huge amount of developers worldwide that know PHP, but apart from this obvious reason is there anything else that would make someone choose PHP ahead of other stacks?
  • kijin 5y ago
    There are definitely parts of PHP and its ecosystem that have been trying to copy Java. On the flip side, PHP is quite similar to Java when it comes to its value proposition, so I can appreciate why the devs have chosen that path. Like Java, PHP is stable and slow-moving. It takes backward compatibility seriously, and it has a huge community. PHP is to small-time "webmasters" and lifestyle businesses what Java is to governments and large corporations. If you want to build something once and get passive income out of it for the better part of a decade, PHP has your back. Pinboard is a prime example of this business model. If you're a fast-moving startup who will replace your entire codebase every six months, you might be better served by JS.
    • cies 5y ago
      Why would one pick PHP over Java except because "you already know PHP"? > If you're a fast-moving startup who will replace your entire codebase every six months, you might be better served by JS. Noooooo... :)
      • kijin 5y ago
        > Why would one pick PHP over Java except because "you already know PHP"? If it's a lifestyle business or hobby project, it usually costs less to host a PHP app somewhere than to find a place where you can get decent performance out of the JVM. Even a small droplet can be a lot of money and effort for some people in some parts of the world. I often see kids pick up PHP for this reason alone. Then they stick with what they know.
• kijin 5y ago
  Syntax sugar is nice. It helps PHP sidestep the age-old criticism about its crappy API, although the crappy API is still there if you want to use it. What's really great about PHP these days is the development environment. Composer is a rock-solid package manager. Most frameworks and important libraries are gravitating toward shared standards defined by PSRs. Thanks to those shared standards, the APIs are stable and easy to understand. There's no colors/faker/left-pad drama. Everything just works out of the box and keeps on working. Everything is extensively documented. And somehow the runtime keeps getting faster without breaking backward compatibility.
  • mschuster91 5y ago
    > There's no colors/faker/left-pad drama. Yet. Composer packages have the same attack surface as NPM packages, the only thing that is different is that there are (outside of frameworks like Drupal and Symfony) no automated post-install scripts that get executed during a "composer install". The fundamental difference is that lots of what is popular in the NPM world isn't needed in the Composer world at all due to PHP's extensive stdlib (meaning, less people having to maintain trivialities like left-pad and thus less potential for people to get hacked/sell out/get burned out in frustration). Furthermore, most highly popular PHP projects have extensive corporate, consulting or foundational backing - Symfony, Drupal, PHPUnit, Laravel, Typo3, MediaWiki, Wordpress to name the biggest players - and each of these provides to developers what the stdlib is missing, so there are strict QA and release procedures to prevent a repeat of the current colors/faker events.
    • kijin 5y ago
      Totally agreed. Despite PHP's reputation as a beginner-oriented, haphazardly designed language, the ecosystem as a whole feels much more mature and well-organized with multiple stakeholders and strong safeguards.
• revskill 5y ago
  Javascript is what PHP should be since day 1.
  • cies 5y ago
    > Javascript is what PHP should be since day 1. ReasonML or ReScript is what JS should have been since day 1.
    • revskill 5y ago
      It's not fun sir. What's the point of those $$$ mark for variables ? Make no sense at all. Easy adoption for all levels of programmers is what make it work for enterprise applications now.
      • bnt 5y ago
        Hey, here’s someone who never saw Perl and doesn’t know how PHP evolved.
      • 9dev 5y ago
        For one thing, it makes the distinction between language keywords and variables clear - no problems in using `$switch` or `$var`, and even more important, the core devs don't have to take as much care when developing new language features. Not that I usually use variable names like these, but it quickly becomes automatic to use a dollar sign.
    • christophilus 5y ago
      Scheme is what JS should have been since day 1.
      • cestith 5y ago
        Guile in the browser would make plenty of sense had someone not shoved the mess that was early JS into the world.
      • cies 5y ago
• syshum 5y ago
  >>Packagist, now with over 3 million registered versions and more than 300.000 packages I see PHP continues to import all of the problem of npm into the PHP community, I moved away from php about the time packagist started to gain ground.
  • captn3m0 5y ago
    Packagist actually gets a lots of things right that NPM gets wrong: 1. NPM has a global namespace that was shoe-horned into an organization thing later. Packagist has been namespaced since day one. Using a namespace avoids almost all of typo-squatting issues etc. 2. NPM hosts the code at its end. This means you could review some code on GitHub and it might not match the code that you get. Packagist fetches the code from GitHub (same guarantees as Go) 3. NPM: The package version is defined _inside_ the package.json file. This causes issues, because the NPM registry is not necessarily the source of truth for this data, resulting in weird edge cases, such as this bug[0]. Composer/Packagist on the other hand just syncs tags against GitHub. 4. The whole NPM ecosystem needs a whole lot of additional tooling to actually publish packages on NPM. NPM doesn't support robot accounts (PATs are not bots), so you must provide a token with complete write access to your account to your CI system, which then must build and push a package to NPM. This process being without 2FA has led to a lot of compromises. Every release also needs chores to bump the version in package.json (which doesn't have to match the version in package-lock.json). Packagist side-steps all these issues by setting a webhook on your repo (no write access needed) that can trigger a sync on Packagist end. Ideally, this should just work with an RSS feed, but webhooks are easier to build. NPM has a lot of good ideas (ability to load multiple versions of the same package for eg), but Packagist isn't a terrible package manager - it works quite well, and you rarely see people tripping over composer like how happens with the Python ecosystem. The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally. [0]: https://github.blog/2021-11-15-githubs-commitment-to-npm-ecosystem-security/#security-issues-related-to-the-npm-registry https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...
    • fart32 5y ago
      > The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally. I think it was Laravel or Lumen? I tried that one once and was kinda amazed it pulled like 100 packages. In PHP ecosystem, I think that's considered a lot (to be fair, this is few years back). I've worked on fairly large projects (mostly Symfony + Doctrine and PHPUnit) and don't recall seeing so many dependencies. Now compare this to initialization of any common JS framework starter.
• hparadiz 5y ago
  I'm just leaving my current role, a fast growing start up with a completely custom framework. Currently at half a million active accounts but there's really no bottleneck with the PHP. Can easily keep throwing more boxes and hardware at it and I feel pretty comfy that it will be fine at 20 million active accounts. Also background jobs processing which is sort of async cause it lives on top of SQS and fires a sub process for every new message. My iteration cycle is very fast. No need to sit there and wait for compiles. PHP is C-like and written in C so the hate is funny to me. Our code is unit tested, documented, and extremely well organized. I even connect to our database on my dev box through an SSH tunnel managed by a tool I made for us in.... PHP which uses AWS IAM to authorize a private key for 60 seconds and then auto connect. That's how I connect to our EC2 instances too. I'm now jumping to another successful start up with a small team running Laravel. Again super organized and well documented.
  • simias 5y ago
    I congratulate you on your successful projects but I don't understand what you mean by "PHP is C-like and written in C so the hate is funny to me". The language of the runtime is not particularly relevant unless you want to write custom extensions (which I remember being an absolutely atrocious experience back when I had to do in in ~2007, hopefully it improved since then) and the language itself is only very superficially C-like. In fact the most C-like thing I remember about it is that many standard library functions where extremely thin wrappers around the libc, so thin in fact that you could get a segfault if you weren't careful.
    • hparadiz 5y ago
      Was implying it's efficient and fast. It's extremely unlikely you will ever need to write an extension.
  • egeozcan 5y ago
    > PHP is C-like and written in C so the hate is funny to me. You didn't realize how many people hate C? (Like any other popular language, yes)
• stemc43 5y ago
  if you are working on PHP projects - dont forget to look into swoole/openswoole. all major PHP frameworks are adopting it now. this way you can do async and build websocket servers and such and build http applications with event loop and without apache/nginx and such. etc etc
• vdo 5y ago
  I learned to use php when I was like 14. I’m 27 now and still derive such joy when making my own little projects that will never see the light of day. I try to be humble as far as just being a php trash coder, but I don’t feel too ashamed honestly, as it is the most mainstream thing really. I will always be grateful to php for being accessible and yeah, I guess easy. I don’t know why php is the only one I really stuck with exactly, but it is weirdly dear to me. Nearly half my life I’ve never gone too far past being a lowly php coder, and not a great one at that, but I still like what I can make at the end of the day. It’s a side creative thing for me. Laravel was a revelation for me over the last few years, it just makes some things make sense that never did for me as a self-taught hobbyist.
  • fvavsc 5y ago
    PHP was my first love. It still is. Professionally I have moved on to other languages. But whenever I have an urge to create something for personal use, PHP is always the most productive way to get it done. With Laravel, I can even make it look polished and put it on the web. PHP is such a joy that I am really thinking about switching back to it for my day job.
  • hparadiz 5y ago
    I started at 16 and I'm 34. Went from working on gaming websites to running giant ERP backends for mobile apps, web apps, and api users in high throughput environments. All I need to get to work is VSCode and some linux VM or container. PHP has an obnoxious amount of depth. You can become an expert on just ORMs or just SSO or just Collections or just routing and still be learning something new everyday. I am actually "self tought". Whatever that means.
    • irrational 5y ago
      > I am actually "self tought". Whatever that means. What does that mean? I know what taught means, but tought? No idea.
      • I_complete_me 5y ago
• dncornholio 5y ago
  Hating on PHP almost feels like racism. All the arguments are biased or false. I always get sad after clicking on PHP articles on HN.
  • deleted 5y ago
    [deleted]
  • awestroke 5y ago
    I feel it's the opposite. Always a lot of people defending PHP in these threads, no criticism allowed. Gives a very misleading picture of the industry - in reality, PHP is not a loved language, it's below Powershell and just over C in the latest ranking[0] with 40% love / 60% dread. [0]: https://insights.stackoverflow.com/survey/2021#technology-most-loved-dreaded-and-wanted https://insights.stackoverflow.com/survey/2021#technology-mo...
    • dncornholio 5y ago
      This only adds fuel to my argument. Yeah let's post a results on how people FEEL about a language. How is that objective? I could argue 100% of the 40% of the people actually uses PHP and 100% of the 60% people don't even use it.
      • awestroke 5y ago
        I've worked in PHP for years. It still makes me nauseous. I would never recommend anybody to learn PHP, it's simply a shitty language all around.
      • amarshall 5y ago
        You can argue that, but it's not what the question was about. The survey question is: > Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year? (If you both worked with the language and want to continue to do so, please check both boxes in that row.) Of course nothing requires survey participants to be honest or to actually totally read and comprehend the question.
• peterhil 5y ago
  Wow, Php almost catches up with majority of programming languages!
  • peterhil 5y ago
    Can't wait for: - Pattern matching in switch statements (done horribly wrong) - If, while, and switch expressions - Inferred type system - Consistent array method argument order - Actually usable higher order functions and reflection Big reminder: Php is a fractal of bad design, and I intensely hated using it at work for many years. The only good thing in Php is Symfony2 framework. https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
    • TheCapeGreek 5y ago
      Big reminder: Read beyond decade old articles. This is precisely the tired parroted line people in this post are talking about when they say they don't understand the modern hate.
      • xigoi 5y ago
        Does modern PHP have any of: - Pattern matching in switch statements - If, while, and switch expressions - Inferred type system - Consistent array method argument order - Actually usable higher order functions and reflection ?
    • Zababa 5y ago
      Sum types, too, since the enums are C enums.
    • fraktl 5y ago
      You could have googled and hated better. Why bother trolling if you won't even give it 40 seconds of using search engines?
• dreadnip 5y ago
  I'm glad the community around modern PHP is thriving, but filler articles like these are getting on my nerves. Reiterating a bunch of content that has already been covered extensively on the web in the past months (and in 10+ previous posts on your own blog), slapping a misleading title on it and filling it up with call-to-action's for your own personal video/newsletter/courses isn't good content. The author had some really good articles in the past, but this reads like fluff just to fill up his blog. Quality over quantity.
  • dotancohen 5y ago
    You're not wrong, but Brent's articles are just about the cream de la cream for PHP. I'm glad to see him on the HN front page. I've been coding in PHP since 1999, so I've seen the language evolve from not-Perl to what we have today. For maybe two or three years now I've relied on to Brent to bring me up to the newest state of the art without having to parse changelogs and release notes (which I usually get to around March or April, a few months after the yearly December release). For those of us in the PHP industry, I feel that the most concise way to stay up to date is with Brent's commentary and the Jetbrains PhpStorm blog.
    • dreadnip 5y ago
      He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it. Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/ https://www.ncameron.org/blog/rust-in-2022-2/), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year. Maybe he should've called it PHP in 2021? Oh wait, he already did that (https://stitcher.io/blog/php-in-2021 https://stitcher.io/blog/php-in-2021) and it's eerily similar to this article. If there is nothing new to write about, why write? I'm glad you bring up the PHP Annotated Monthly blog, it's a great resource and definitely one of the blogs to follow to keep up to date with PHP.
      • dotancohen 5y ago
• snov 5y ago
  PHP was a pretty cool language back in the days. Bizarre (yet fast) stdlib and ugly syntax, but super quick to write web stuff, supported by every shared hosting. Nowadays, it seems to mimic Java, while having inferior libraries, I'm not sure what's the advantage.
• AdrianB1 5y ago
  Maybe I am just too old and tired, but current PHP has nothing to do with original PHP, version by version it changed direction and the last versions are just yak shaving. I strongly believe that a programming language should be stable over a longer period of time while bug fixes and behind the scene improvements are fine, but for the developer it should not be a moving target, the manual should not triple in size and developers that know very well version x-1 should have zero problems with version x. There is a huge cost of change and if some people don't care, real life does.
• ChrisMarshallNY 5y ago
  I use PHP for my backend work. I don't claim to be an expert, but I have been writing in it for over 20 years. I probably started by rewriting PHP-Nuke to emit actually valid XHTML (what a chore -never again). I've written a couple of CMSes in it, and many plugins. I've done some fairly big stuff, in PHP. Works a treat. Fast, solid, secure. Widely-supported, great way to have a high "bus factor," because so many people can understand it. All that said, I never did really like the language. It has always been a necessary evil, for me.
• dainiusse 5y ago
  I havent used pho for 10+ years now, but the point is - the tools mostly don't matter. What matters is the result.
• aarondf 5y ago
  A lot of people here have mentioned Laravel. I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel team have paid products, but they are all 100% focused on the Laravel ecosystem and developer experience! Some of the things that the Laravel ecosystem has as first party packages / services: Paid: • Vapor - Serverless Platform. Run your vanilla Laravel apps on Lambda. • Forge - Server Management. Builds Laravel ready servers on any cloud. • Envoyer - Zero Downtime Deployment. Deploy your apps with push-to-deploy. • Nova - Administration Panel. Completely code-driven admin panels. • Spark - SaaS App Scaffolding. Basically a SaaS starter kit. Free: • Horizon - Queue Monitoring. Like Sidekiq • Jetstream - App Scaffolding. SaaS starter kit with teams, invitations, api, etc. • Echo - Realtime Events. Think Pusher, Socket.io, etc. • Sail - Local Docker environment. • Valet - Dev Environment for Macs. • Mix - Webpack Asset Compilation. A sane wrapper around webpack. • Cashier - Subscription Billing Integration. Stripe + Paddle. • Dusk - Browser Testing and Automation. First party browser automation for tests. • Sanctum - API / Mobile Authentication. • Laravel Scout - Full-Text Search. Wrapper around Algolia, Melisearch, or full-text database searching • Socialite - OAuth Authentication. Log in with GitHub, Google, etc. Dozens of community packages as well. • Telescope - Debug Assistant. That's all first party. It's unbelievable to me how many batteries are included. Then you start looking at the surrounding ecosystem beyond that and it gets even crazier. Laravel as a community is an extremely welcoming place, and I have found that most people care deeply about their code and architecture, but don't pick each other to death on details that don't matter. I think all in all it's a pretty pragmatic group. If you haven't checked out PHP lately because you think we're writing a file-per-page and FTPing them up somewhere, you should give Laravel a look.
  • jgilias 5y ago
    Yeah, curiously, I think Laravel is just getting started in a way. Taylor seems to have a superb vision about what it is that he wants to achieve with it and in what way, and I don't think the 'rest of us' have fully grasped the 'end-game', and what the implications will be. I mean, he took the most popular, but somewhat 'not cool anymore' backend programming language with a huge pool of developers, and proceeded to build _the_ way to build server applications with it. If that's not strategic brilliance, I don't know what is. EDIT: For context. My exposure to Laravel is jumping into some projects and becoming productive in a day without prior exposure to PHP. Largely due to superb documentation and the batteries included approach.
• synergy20 5y ago
  As long as wordpress still holds 40% of the sites PHP will be a major language. In my opinion, all the modern 'script' languages are now adding static-typing one way or another, to make they much robust(python's mypy, typescript,PHP, etc). I will pick PHP for backend website development, I just want to avoid the async-node-js as much as I can as it's much worse than other options I feel.
  • Loeffelmann 5y ago
    What's wrong with async node js? I think the async API is pretty good.
• tored 5y ago
  PHP in 2022 has much going for it, the only dark clouds on the horizon is the increasing framework oligarchy within the PHP community, which may reduce innovation and foster a "one size fits all" culture.
• thakobyan 5y ago
  I have worked with many programming languages and what attracts me to PHP the most is the simplicity of its tooling.