To note, you'll need strict mode for type hints to be useful. https://www.php.net/manual/en/language.types.declarations.ph...

The fun part is, instead of going for a generic strict mode system we would have expected, PHP went pragmatic: as most application won't be 100% strict typed, you need to declare it file by file, the icing on the cake being that the restriction applies on the caller of the functions, not the function itself.

It makes for complicated situations, where for instance you can make an utility class that is 100% typed and follows strict typing, but if the caller of your class isn't, none of it will matter and types will be fuzzily coerced anyway.

This is not really true — those type hints can be read by static analysis tools, preventing you from many of the issues that would also be caught in strict mode at runtime.

Unfortunately, it’s taking far too long for Laravel to catch up so parts of its API are a black hole for types.

Especially things like request input, which returns a union of string and array as opposed to using a conditional return type.

You end up with assertion soup every time you touch Laravel so over time the project uses less and less of it.

A well-typed framework and set of libraries would be very nice.

Thanks!

In PHP, typing is for function signature documentation.

false.

Utterly false, I don't know where you came up with all of that nonsense. All type hints work as expected, just you can't typehint variables. Only parameters/class properties/return types.

And the `strict mode` is a failed experiment no longer recommended in new code (no side effects but no benefits either).

Totally agree about the single thread thinking is enough for most things. It of course depends on what you build. For example, I would use some language that runs on Beam for a chat platform.

Thanks in advance!

It's quite brilliant really, even for modals etc. "look ma, no javascript!". Of course it does JS for you, you just don't see it. That's my favourite kind of Javascript - someone else's problem. Livewire is a mid-way between front-end backend, it's a progressive back-end with long polling like NextJS I suppose. From your end though, it takes care of all the security of running your own API, and correctness. You basically have dynamic front-end from the backend.

If you want a full SPA or you need an application that is very responsive without network requests, I recommend VueJS - Livewire recommends AlpineJS, but of course you might be a React guy, that's fine, and use Laravel as a regular API.

You can even use GraphQL if you want to die of a young age, have some weird kinky thing going or you have something to prove... Unless you're Facebook of course you probably don't need GraphQL.

It’s kind of funny that this is the new best thing, when this is almost the same model JSF did decades ago.

If you do, please share your experience in a comment. I’d love to hear it. I architected this framework over the last decade :)

But in any case, great job with the platform!

Your copywriting gives off strong old school enterprise sales vibes with a dash cryptomania. You are not going to get much organic product led growth among the US under 40 crowd here. I suggest taking a look at https://payloadcms.com/ and study their design, execution, and copywriting.

I checked out payloadcms though, that site is pretty terrible…

That site feels like some kind of terminal from the 80s movie "Hackers"... are we "hacking the gibson"?

It features white text on a black background, overlaid on animated white text on a black background...

Then you scroll down, and it has TEXT IN A GIANT SIZE going slowly across the screen..

Then it turns to white and has a video that doesn't fit

Then it has text of all different sizes, and code examples, which is irrelevant to most customers.

I am not making this up. It's literally here: https://imgur.com/a/IMT6pgB

Are you affiliated with that site or project?

But what i meant is that with that defensive approach you have… it is going to be tough to make it better.

Also, the design (1) doesn't promote a linear flow of reading, and (2) isn't spaced out, making for a messy reading experience. Here's an example:

https://qbix.com/platform/welcome

Instead of clear text sizes and simple messaging like in https://qbix.com/communities, there are texts of at least 5 different sizes jumbled in.

Instead of contrast so you can read text — there is white text on black over white text on black.

There is also text that is gray and low contrast until you scroll it into view, but then it gets covered up by code examples. Most regular customers are scared by code examples.

Instead of one clear button or call to action per section, there are 20 on the screen, making the user unsure what to click and what the Information Architecture / hierarchy is.

And moreover, all the links are black on white or white on black — just like the text. No clear visual separation of where to click. It violates like every UX guideline I have read in the last 12 years.

It has GIANT TEXT HORIZONTALLY SCROLLING ACROSS THE SCREEN the minute you start to scroll down. Then when you get past that, it has a GIANT VIDEO THAT DOESN’T FIT and doesnt look like a video, more like some more text in many font sizes.

I could go on… but why? Do you actually prefer this monstrosity to clean design: https://imgur.com/a/IMT6pgB

By contrast, if you land on https://Qbix.com it looks empty and clean, and asks you who you are before showing you a page: a customer, an investor, a developer, etc. Then that page is specifically tailored to what you need.

Text is text. Colors are colors. A large black menu bar is unmistakably at the top, organized neatly so you don’t get lost, not scrolling out of the way.

Unless you think apple.com is old outdated design and modern UX is the payloadcms site?

Apparently it triggers you. I don't claim that it's perfect by any means (actually I think some of what you're saying is right).

My response was simply a reaction to the scope of criticism and the claim that this is the new best practices. Because the other site was held up as an example of what I should spend days emulating and making my site look like, the sheer time investment and “well, if you think it isn’t good, then you can’t be helped” made me believe that this is some canonical example of best practices and design. So I naturally critiqued it and said exactly why I thought the latest design standard was crap. That’s why it came out like that.

If I knew the author would be reading it, I would have been a lot more tactful in my criticism. But I do stand behind what I am saying. (For what it’s worth, the developer section of Qbix also needs a lot of work, but the OTHER sections + overall design of the site I think are good — but happy to take specific and constructive criticism in the same vein I gave it.)

It's hard to get under my skin. That's actually I think what your takeaway should be here - - you can't please everyone, but you should take all feedback as valid and try and deliver something that solves for your problem the most widely.

If someone feels something, then they felt it. Including your reaction to my site, and the others' reactions to your site.

The Qbix Communities page is definitely cleaner and more linear than the Developers/Platform page, no doubt. But it still looks very basic and again doesn't give enough focus to specific features. Instead it presents two videos (which aren't necessarily a good way to get people interested, since they may not even click on them). And at the bottom, it has two dense columns of smaller text packed together, which doesn't really invite people to really think about the features. Would be better if the text points were spaced out, given larger header text sizes, and accompanied by representative icons or even screenshots.

I also watched the first video, and the example Yang 2020 app you demonstrated also looks cluttered and squeezed due to the similar text sizing and lack of spacing things out. To me it looks like it's from 10+ years ago, before flat, material design really took hold of the mainstream and became consistent across many web apps and SPA. (Pity about Yang 2020!)

Sometimes it's best to question why others are having such a contrasting response to you. It does mean something. Letting go of your own opinions and preferences can be helpful for finding greater success in a wider community. Seriously, think about getting opinions from a few UX professionals, and give them some weight when you evaluate them, even if you disagree with them.

People often point out problems in design aesthetics, and imagine that the opposite solution somehow can be realized in a consistent way that makes everyone love the result and will make the difference in platform usaage, but no. That’s not how it works at all. It’s like the people who say “your app doesn’t work” to a developer (with no details on a solution should be), and imagine that somehow this will lead to a much better app with no bugs that everyone will use.

At the end of the day, adoption matters far more. Facebook is cluttered and ugly compared to many other clean beautiful apps, but people are super used to it. Discord is totally bewildering, with tiny gifs for flair and many controls are extremely hard to discover and operate, but people are used to where things are. Craigslist is ugly but at least it’s straightforward. Many more beautiful sites fell by the wayside as they tried to take it on (remember kajiji? others?)

As for Yang 2020… your criticisms are fine but you should realize the design wasn’t ours. It was, in fact, following the design guide here since each community designs their own portal:

https://cdn.hackaday.io/files/1665227124477248/Yang%20Gang%2...

You see, when you are designing a tool can be reused in many different environments with hundreds of variations that could go either way, and still has to work, then you realize that the design decisions aren’t so simple and that these may be the least bad after having gone through exactly the process you described.

Look, if Payload’s GIANT SCROLLING TEXT and white text in black over white text on black was the unavoidable result of hundreds of iterations, then I’d accept it. I personally think there are good reasons for what we have done, having tried tons of other variations. But I don’t think the GIANT SCROLLING TEXT, or making all links look exactly like the text, is necessary or the inevitable result of iterating. We HAVE been listening to criticism and THIS is the result.

https://i.imgur.com/RYEo7Gv.png

On the one end of the scale you've got the PHP Laravel monolith, and on the other you've got the completely serverless bits of JS over lambdas, with 12 different technologies, buckets up the wazoo, to store 300mb worth of data.

Then you're told 'yeah, but this is distributed'! Okay cool, so you save 50ms of latency. Super... How long does your javascript takes to start returning content? Right, much longer. What the hell is even a cold start? How is that a thing in 2023?

PHP is unsexy. And people don't like unsexy. I, on the other hand, I like my vacations uninterrupted.

But yeah, before you jump through the whole ecosystem of JS and require 3 different third party services, only to make a website, that does not work with JS turned off and cannot be build and run any longer 3 month later, due to dependency fup, you are much better off with unsexy PHP.

I do understand hiring someone who has that tradesman programming ethic and is comfortable with Linux, but that’s more requiring certain positive traits.

That's a state of the art WebApp. You old PHP developer!

Though to be fair, devs lose employability when they don't get to use (in their work) technologies that are gaining wide popularity. It's a balance to be struck by the CTO/architect (assuming the devs want or are able to demand that skills development in the first place).

However, I'm not yet sure a complicated edge deployment would actually fix the 10% problem.

So PHP was and might still be a shitty language.

And PHP was my first language I'm fine with scripting with it but it was ugly as hell to write big code

Sure, it's perfectly possible to grow numb to those pains and some will even pat themselves on the back, claiming pragmatism over principles, but wow, if you're not used to that level of make-believe in computer languages you'll be paralyzed by disbelief. An endless series of "this can't be true!"

Depends on the reasons. One good reason for preferring another language is .NET/Java business app developers can earn a lot more here than PHP developers ;)

There are good reasons to avoid/switch-away-from PHP... Like weak compile time quality guarantees, messy std lib, low quality of available libraries, many security issues; all WHILE great alternatives exist for free! (e.g. Kotlin, Rust, C#, Java)

This just sounds like PHP Stockholm syndrome with extra steps.

It's fine to be excited about programming but those that build their whole identity around it are just super obnoxious and not fun to work with.

I personally never liked PHP, so I haven't kept up with how it has developed and I don't expect to start, to be honest. Of course, if you've got an otherwise interesting project that happens to be PHP and want to pay me to help you with at it, I'll be professional about it, but there are too many alternatives that appeal to me more than PHP for anything where I have a say.

I found the (Laravel) community to be more about object-level discussions ("how to do x feature the best way possible") rather than meta-level discussions.

Python is no more "proper" than PHP as a language.

In fact, they're both identical as far as footguns go.

> Note: In the years since releasing Lumen, PHP has made a variety of wonderful performance improvements. For this reason, along with the availability of Laravel Octane, we no longer recommend that you begin new projects with Lumen. Instead, we recommend always beginning new projects with Laravel.

Serious question, what does that argument consist of ?

Bottom line is that the language being so flexible, unassuming, and swamped by needless features almost everything can be debated the point of exhaustion.

Python, being more straight to the point and not overkilling oop allows for more focus on doing what matters: business logic.

This also reflects in their salaries.

And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed?

If so I want to learn how they did it. That's some heavy duty language evolution work.

If that was a metric for language quality, then Javascript would be undeniably the most perfect language ever designed by any intelligent species in the universe, judging by the number of frameworks.

> to an almost decent language

And now I would like to hear a good reason why I should use an "almost decent language", when I can use a decent one instead.

> It can be used properly if you know what you are doing

It doesn't matter what I do, the language still insists of having multiple modes of error handling, a massive amount of builtins all of which sit in my global namespace, it's configuration is still seperated between compiler flags, a system wide ini, and local config. The base deployment mode is still "dump files into folder and let CGI do the rest".

What i am saying is that the offering of tools has matured in php - instead of a basic template engine like smarty you now have “advanced” templating engines, packages and so on. Python has less packages but that can also he because python packages work better and there is no need for an overwhelming number of packages.

Regarding error handling that’s precisely one of the many issues with php. There are so many ways of doing the same thing that it becomes exhausting. And what many php devs do is they work around these issues either by endless hair splitting debates or a dubious amount of made up design patterns.

You shouldn't use php, i am totally against it. I think it’s as bad as it can affect your mental health. Just saying that by comparison to it’s previous versions it has come a long way.

However it does handle character encoding quite well and you can scale as much as you want to literally. Probably because thats too complex for the average php developer and it was left to core language developers which are pretty competent and experienced.

This is why so many basic php we hosts continue to offer older php versions because the old code will not work and why paid projects like cloudlinux hardened php still exists. Just in the last 2 years they finally ended security support for php4 on the hardened php project.

So to explain how it worked, it wasn’t as sudden as python, but the problem areas have been depreciated and removed as php has evolved.

Everything? No.

Much of it? Absolutely (and the more widely a particular point is agreed upon, the more likely it's fixed). The article is eleven years old.

What's that George W Bush line, Fool me once, shame on...shame on you. Fool me—you can't get fooled again. But we're not talking about getting fooled just once, or twice, we're talking about eight times.

No one got “fooled”. The got a useful tool that got better over time.

This is a language built by people who didn't really know any better, so I don't blame them, but it's ludicrous to pretend that it's a "red flag" to have noticed that this keeps happening and learned from that experience.

I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance.

There are developers who don't like PHP because of outdated reasons and possibly because they are snobs. Sure, that's a red flag.

But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore. Even though PHP has evolved (with regular breaking changes...) and tries its best to put something useful on top of a shaky foundation: The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.

However I would say there are three very good reasons why you should use or at least consider the language:

- You want to quickly hack together something useful with minimal fuss, AKA its original purpose.

- Buy-in of the OO, code generation, IoC/DI, magic framework stuff that Laravel/Symphony provide.

- You have to.

The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.

This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described.

Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design.

Again: Trade off.

That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.

If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier.

Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.

Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all.

I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go.

I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money.

As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity.

This happens a lot more frequently than you think.

We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.

debug_backtrace() has always been my friend in situations like this

Have you actually used Symfony?

It's an absolute pleasure in its domain and includes rich debugging abilities through its dev toolbar.

Apparently there's now something called annotation routes. Which appear to be inferring functionality from comments.

You made me look though. I suppose I had it coming.

[0] https://www.php.net/manual/en/language.attributes.overview.p...

Unknown attributes are also ignored silently, which isn't really a good sign.

It may technically be forwards compatible syntactically (`#[foo]` will, as you say, just be ignored by PHP 7), but that's an anti-feature (assuming that the attribute isn't a no-op, it'll presumably break something else).

> `#[foo` used to be legal PHP 7, but is illegal in PHP 8).

So it is not a comment in PHP8 then.

I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.

It is the magic part that is the problem, regardless if it is the framework or your own code that it is doing it.

One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that.

Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.

Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.

> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore.

I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? No because they are "outdated reasons" as you say

> The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.

Do you have an example of this?

Yes. And I say that as someone who has been developing "modern" Typescript web apps full-stack for the last few years.

My issue with JavaScript are fundamental to language design decisions that can't be removed due to major breaking changes. Things like having to deal with `undefined` AND `null`. `==` vs `===` (more specifically, type coercion), prototypal inheritance in addition to ES classes in addition to TypeScript classes. Array.push causing mutations. Having `for of` in addition to `Array.forEach` etc. etc. etc.

And then you have the fact that it is neither OOP nor Functional. So you get people from both backgrounds, and ideologues from both backgrounds, trying to squeeze JavaScript into their preferred paradigm, within the same code-base ... and JavaScript obliges. Because it is neither.

Every single JavaScript application looks radically different from each other and, worse, in a large organization with many teams working on a common code-base, consistency becomes damned near impossible to enforce.

And so you start adding lint rule after lint rule after lint rule until you have an entire team dedicated to maintain your custom linting bullshit.

JavaScript is a complete shit show to this day even if it does have nice features and even if you can get up and running with it quickly.

If it weren't so popular, and if it weren't the "language of the browser", I wouldn't recommend it for anything other than small teams who can decide on which "version" of a JavaScript adventure they want to strictly adhere to.

It is not only bad for the developer, but for the users, too. The overall confusion and frustrations are abundant.

I’m also very loyal and pragmatic. I really tried.

I don’t want to start a language war here either. What I said above was a counterattack on the idea avoiding tech that doesn’t agree with you is somehow a red flag.

My general point is: consider that there are people who have earned their opinion the hard way. Even if you disagree.

This applies to absolutely every language or stack. You switch to Ruby because the grass is greener, and 5 years down the road you feel the same. Then you switch to Kotlin or Erlang or JavaScript and you'll end up hating it anyways if that's how you roll.

But when a dev says X is objectively bad, that is not a good sign. Languages are tools, not a way of life.

Hard disagree. Sorry, I don't have a computer science degree, why does their documentation make that assumption. I find their docs very hard to grok.

PHP.net docs are no-frills no-fuss, straight to the point. Other frameworks are documented very well too, CakePHP comes to mind (at least, when I was using it last in v2 and v3).

I can't say I've read the absolute latest version of their v10 docs, but when I was neck deep in 5.8 I found I had to switch to older versions of the documentation to read up on some of the most basic of Laravel features. eg. What's the syntax of using Form in Blade templates? I had to go back to v4.x docs to read up on it, Blade templating hardly got a mention in v5.x documentation, despite it being critical component in a Laravel application.

If there was a bug in a project and I had management breathing a fire down at me because it's breaking the site / losing sales / stopping monthly reports from going out, I shouldn't need to decode computer science terms, or look through previous versions of documentation to find the solution.

This is why, in my opinion, Laravel documentation sucks hard.

All that being said, my overall experience of working with PHP / Laravel is quite pleasant, probably more so than other technologies I've worked with in recent years. Everything has its issues I suppose.

[1]: https://laravel.com/api/10.x/Illuminate/Database/Eloquent/Mo...

Ah yes, the Ansible approach. I've used it for a decade, and I routinely get lost in its utterly terrible by-example documentation.

They are the golden standard on how not to write documentation.

God, I hate the Ansible docs so much, they are the reason I burned 30% of my Kagi search quota this month.

- tutorials;

- how-to guides;

- technical reference and;

- explanation.

1: https://diataxis.fr

It doesn't get more clear than that.

https://docs.ansible.com/ansible/latest/playbook_guide/playb...

On this page there is no quick index of all the functions available, their argument and a short summary of how they work. You need to synthesize this information yourself by reading through ALL the examples, and hoping your niche use case is listed.

There are more than one type of documentation, with different use cases. There's the tutorial/list of examples, which Ansible excels at, and is ideal for a first timer reading the docs from cover to cover. Then there's the API reference with quick index, for intermediate to advanced users, where they know roughly what they need, they just need to find it. In this, Ansible's docs fail dramatically.

The authoritative answer to what filters are currently available in your distribution is by running `ansible-doc -t filter --list` which does include a summary line, although for some of them it's "geez, thanks" just like any open source collection of disparate modules glued together

I used to actually build the ansible docs locally with singlehtml because I despised that chopped-up view, but now that they're all "galaxy all the things" it's practically useless again (although I will also say that building it locally and eliding all their tracking bullshit makes the pages load like a bazillion times faster, so ... still valuable in that way)

eg. https://laravel.com/docs/5.8/contracts – talks a lot about how Contracts are powerful additions (like all the other features of Laravel, the docs are good at telling you they're powerful) and the examples show just some barebones code that doesn't really do much without a lot more work. The examples in the documentation seem to be more on the side of being some code snippets that don't convey much context.

Additionally, there's lots of "congratulatory" text in the documentation ("Laravel has a powerful feature called <x>", "in Laravel adding <feature y> is actually really simple", "some developers enjoy using <feature z>". You simply don't see this in PHP.net's docs, it just tells you what the function / feature is, gives you examples that work straight out of the box, lets you know of any pitfalls or differences in PHP versions to watch out for, and there's a whole list of comments contributed by other PHP devs spanning years, that are up/downvoted.

Another example of powerful documentation was that I learnt what MPTT is, and how to implement it effectively, purely from CakePHP docs back in the day (I'm talking v2 here). I can't see how anything as remotely useful would be able to be taught from Laravel docs alone; for someone who doesn't have a computer science degree, there would be a LOT of tabs open, full of rabbit holes that need to be explored. This is not effective documentation in my eyes.

The difference between these sets of documentation is like night and day to me. The Laravel docs needs to stop patting itself on the back, and be more like other software projects' documentation.

Don't get me wrong, I love working with Laravel, it is powerful. My issue is with the documentation, which leaves a lot to be desired.

I agree with the documentation sentiment. The documentation is enough to get one started, but not nearly enough to get the job done well. The community is overran with beginners, and you are left to your own devices once you really want to get your hands dirty.

Guess that is why selling Laravel tutorials seems to be a fruitful business.

I’m sure that plenty of us used PHP in the day, have been doing something else for a while, and see these HN posts from the people that stuck by PHP singing its praises. Let’s not forget that there’s probably been a steady stream of newbies coming through the system the entire time - which makes the language, and by extension Laravel, a prime target for bottom feeding ‘one step ahead of the audience’ “educational” content producing scum.

Thanks to Laravel (along with Livewire and Alpine.js), and an ecosystem of libraries enabled by Composer, PHP is a great choice for web development. I'd not use it for, say, coding machine learning stuff though!

Most mature programming languages are nice to work with these days though. At least in my opinion. About the only one I dislike is C#, and that is mostly because whenever I need to use C# I need to use it with a combination of libraries (Odata, Entity Framework, Asp.versioning) as an example which simply don’t work together unless you overwrite/extend half of them. Because for most use cases C# is as excellent as all the rest.

But PHP was essentially build for the modern use case of everything being web-based and it’s weird to see the reputation it still has. Then again, django is also an excellent tool for most modern work that doesn’t see the adoption it should. I’m so sick and tired of having to deal with things like umbraco failing at things that have been a fundamental part of django for longer than some of the people reading this post have been alive. :p

But I guess its all those things that keep me well paid. So maybe I shouldn’t be too angry about it.

Thanks to JVM you have really good out of the box debugging features including hot code replacement and profiling.

You can use kotlin which is a really really good language in comparison to PHP.

There is no need in my opinion to write real applications with PHP.

IME, Laravel's "easy deployment" story is heavily linked to the paid service Forge, and installing dependencies during deployment is a bit slow plus takes a /lot/ of memory (we're using old Composer and Laravel versions though). What's your take?

Personally, I do like the way the standard library is - almost all cases of where people whine about it being inconsistent, it is a consequence of the PHP standard library and many of its extensions being extremely thin wrappers around libc and C/C++ libraries in general.

That, in turn, makes it often possible to just take straight C library example code, copy it into a PHP file, add a $ in front of all variables, and have it magically work.

(IMHO, it's no surprise that the whiners tend to be younger programmers who have grown up with Java in their university education - us older "neckbeards" are so used to the C world that its conventions are second nature for us)

* head explodes awesome

I know what I'm doing this afternoon!

Obviously Go and PHP are two very different languages but they bring me peace in ways JS never did. Especially when reopening older projects.

That said, PHP does have complexity to running like node does with pm2, Apache or Nginx in front. Is it as bad, depends on the person, but it does suck IMO.

You could make it single threaded. But the standard is multi threaded, and if you have more then 100 users will be have to deal with locks.

That said, locks/threads are still easier to manage then async code.

Unless you’re getting shared hosting, then it’s true for most things now. You don’t need a specific OS or cloud provider for .NET, Java, Go, Rust… etc

> When I consider the solutions of flask and microservices I've left behind, the many node processes running with pm2, the complexity of .NET solutions... PHP just works, and it's easy to make reliable... And if it's slow, it's because I'm doing dumb stuff, not because of dark corner edge case I happened to be tripping into.

.NET isn’t anymore complex than a PHP app. Unless you write many layers of abstractions. And nothing stops you from doing the same thing in PHP.

Fast, the most overrated feature that we developers endlessly look for. How fast? How much are you winning, milliseconds, nanoseconds, picoseconds? It's extremely likely that if something is slow is because you're doing something wrong regardless the language and/or framework.

It's reliable PHP? Well, so are Python, Ruby, Go and other friends, right?

> Laravel is pretty darn rock solid.

Again, so are: Rails, Flask, Django and many other matured frameworks out there that have been baked for years now. Unless you pick some toy framework project written in a weekend I'd say there are plenty of rock solid options out there.

> Just ignore the fugly standard library inconsistencies of (old) PHP...

I'll just prefer to pick a language that narrows/discards that dark side as much as possible. Very long time ago I couldn't finish reading a page whose author painstakingly detailed every single inconsistent feature of PHP (literally it could have taken a whole day to read). After that horrifying testament I said myself to ever get my feet wet with PHP. Now in a team with PHP you will need to agree which "inconsistencies" should be left out either by adding some tool to automatically watch for that or educating onboarding members of your team.

> Oh and it's free. All of it. PHP, Laravel.

Aren't the other friends out there also free? All of them?

> When I consider the solutions of flask and microservices...

Flask AND microservices are two completely different things. You can have a full fledged monolithic Flask application or go with the microservices rabbit hole with ANY technology and/or programming language that you want.

So PHP, well... Nah. At least not for me. There are plenty of interesting languages and technologies out there to be learnt and PHP for me is definitely not one of them.

One question aside out of ignorance. How do people debug in PHP? Many many many years ago I worked for an extremely short time for a company that were heavily using Laravel. I didn't know how to debug a PHP program at a time. People told me to simply do "prints" to the rendered template. If I remember correctly I also tried to find some tutorial or howto on debugging with PHP only to be unsuccessful. I'd be interested to know because with Python is just a joke to do that. Install ipython and ipdb. Then set `import ipdb;ipdb.set_trace()` and you are done, you get the full fledged mighty console where you can see everything you need to track down an issue. Up today I haven't got the opportunity to testify someone using a similar capability with PHP but hey I might be wrong and something of the like is out there.

Mostly xdebug. There is also ZRay on IBM if you use Zend, but I've never used it.

I use as much of one thing as I can. Because the browser speaks Javascript, that's what I use, client and server-side, wherever I can.

How should I interpret this? The language is cool? Can perform cool tricks?

PHP makes simple stuff easy and difficult stuff possible. (But you're not going to win the Tour de France on a BMX bike.)

Nowadays, a lot of other things also do this, but PHP was the first to really "get" this. I understand it's not for everybody, and for certain things, other languages are certainly better. But there's precious little that you can't do with PHP, since it's been around for so long and has been growing with the Web from pretty much the very beginning.

Sorry, could not resist! lol :-D

Would you mind sharing your insights into why one should go with modern PHP+Laravel instead of NodeJS+Express+Typescript? what does the PHP equivalent of pm2 load-balancing look like and how does it compare?

API Platform is really good for scaling CRUD endpoints too (its a Symfony project, or at least tightly Symfony adjacent)

Of course, this is my experience (albeit over many years) however I wanted to just throw out a worthy alternative people really should look at.

But for web, I personally prefer Typescript frontend and backend combos. It's amazing to be able to write everything in one language. I largely tune out the arguments and new flashy frameworks, but I get why people call the JS ecosystem a hellhole. There are a lot of options out there. That being said, when your team is competent and balances functionality with new shiny stuff, it can be a real treat to have access to npm for frontend and backend.