Go with PHP | Hacker News Reader

Go with PHP

gowithphp.com

549 pointseiiot516 comments

As a fullstack developer who has worked many, many years in the javascript hellhole, I mean ecosystem, as well as the python ecosystem and .NET; coming back to PHP the last 2 years, working essentially in Laravel and the like - I couldn't approve more of this message.

Seriously, PHP is the grand father that will drive you to class and you'll never be late, the car will never smell and everything will always just be fine.

It's fast, it's typed (now), it's reliable.

Laravel is pretty darn rock solid. I've used a LOT of frameworks. Most of them fall on their ass in either the documentation or performance scope. Laravel is beasty, reasonably well documented, handles hundreds of thousands of users without a scratch. Plays well with Redis and MariaDB or anything really.

Just ignore the fugly standard library inconsistencies of (old) PHP, every language has their toilet corner...

Oh and it's free. All of it. PHP, Laravel. And its hosting has always been the cheapest. You don't need a particular OS or certain cloud providers.

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.

It's single threaded first, queue jobs for anything slower. That simple facts make it so much easier to reason about things, and keeps the fullstack linear, transactional and easy to reason about, 2 years into it.

PHP is not the best language in the world. I prefer Swift and even Go for many reasons, but it's an easy, simple, straightforward language. It's the BMX of the languages.

For a framework that is radically different but also PHP-native (since PHP 5), would you like to spend an hour playing with https://github.com/Qbix/Platform ?

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

Very interesting. I am shocked that this is the first time I am hearing of your framework. Any chance you can make the app setup work using composure instead of cloning from the git repo? It may increase visibility to your project.

But in any case, great job with the platform!

Will look into it. You likely meant composer?

The way your landing page is laid out isn't doing you any favors. If you are going to build a rapid application development platform, look at Retool for inspiration in terms of designs and copywriting. Cut the token stuff, otherwise you will lose customers or self select for crypto bros. The license you chose will turn off most professional development shops and the ones using the platform would be based in places like eastern Europe where the license will be ignored entirely. Your landing page design is fifteen years out of date, this is the sort of design used to bamboozle small trades shops and non tech companies in places like the midwest and the US south, you will have a hard time attracting the sort of web engineers that will help make it go viral. Again, it depends what sort of customers you are trying to sell to, but if you intend to make a profit, the usually advice would be to offer a cloud offering like WordPress. Selling web frameworks rarely work out unless your product is a specialized database.

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.

You seem to know what you’re talking about.

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

I am afraid that if you think that then there is no help.

Umm... are you serious? I could believe you perhaps with your criticism but then you say this is the future of web design?

The site you held up as the example I should emulate 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, I would invite anyone to look at these images and tell me whether this is unironically what I should make the Qbix site look like: https://imgur.com/a/IMT6pgB

Are you affiliated with that site or project?

You cant take this stuff personally. I think people just try to help. I dont think payloadCMS site is some kind of incredible achievment but its very well done site in line what developers are used to. Qbix website in my opinio has so many issues it is hard to point out which one to fix and how. Sorry but i think is simply a mess. There is too much information crammed together, to many various elements that dont really fit together and it makes is for anyone that visits the site really harder than it needs to be.

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

I mean no disrespect, but imo you need to get a modern UX designer involved in rethinking and redesigning your site. Message-wise, your site has too many angles, sells too many use cases, and has too many general marketing statements and not enough concrete examples. This only confuses readers.

In terms of design, the site design (1) doesn't promote a linear flow of reading, (2) doesn't space out information with enough padding, (3) doesn't make good use of text sizing to create an information hierarchy, (4) has too many disparate and messy screenshots, and (5) has distracting cursor animations and alignment shifts when hovering over the top navbar. Overall, it makes for a messy, cluttered reading experience and imo likely turns many people away. Here's the page I'm talking about:

https://qbix.com/platform/welcome

The important thing is to present a very clear "how this is used" right away, targeted at a narrow set of use cases, in an easy-to-follow, nice design. Not too many examples; one key feature at a time. For the audience of devs, they need to see how the platform is used at the most basic level (the code and UI screenshots on that Payload CMS site are good examples). If you find that Payload site's layout confusing, you're probably out of sync with modern design. In any case, I hope this feedback helps.

Please see the sister comment. If this is what “modern design” looks like — no wonder things are so bad.

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?

Hi, I made the Payload 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).

Sorry if my criticism sounded harsh. I was not triggered by it, but simply going into depth why I do not think I should spend time making my site look like that.

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.)

Don't worry, I've been a designer for 15 years and I know intimately that I can't please everyone.

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.

While some of what you say is correct (e.g. about the scrolling text and the messiness in parts of the Payload site), overall your criticisms show that your view of what's easy to follow is pretty out of sync with developers here. What you perceive as "bad" isn't really taken as bad by most others here, and I'd guess they're more likely to have positive impressions of Payload than Qbix.

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.

I do question it. I am happy to have substantive conversations, and improve things. You may not realize it but the current site(s) other than the Development page are the result of years and hundreds of iterations with people who expressed criticism just like yours. Including professionals. And thus what you say at this point is one data point — but you can’t please everyone.

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.

Could do with some improvements, a template, maybe a CSS framework if you're not using one yet

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

I agree about the developer portal. Have you seen the other sections of the site? Start at the welcome page

Quick scan.. I'm going to be 100% honest. Screenshots looks like it's a hobby project. While scanning the code I came across folders named "files", "classes", "includes" and "scripts" are big warning signs.

There's javascript in the back. And there's javascript in the front. Curious what you use for application development on the frontend and if you have some recommendations for that?

Thanks in advance!

Most of the stuff we do now we do with "Laravel Livewire".

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 a progressive back-end with long polling like NextJS I suppose

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

It just had so many other issues with its ergonomics that this nice innovation was lost in the weeds a bit.

That I agree with, though I found that for internal admin pages with many forms, there was nothing more productive.

I actually used a product that built on top of it, so my experience is probably worse than yours!

For those who are not familiar with the PHP ecosystem, any currently maintained framework is also fine. I myself use F3 for small personal projects.

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.

> it's typed (now)

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.

> To note, you'll need strict mode for type hints to be useful

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.

You’re right. Psalm has been a god send on the project I’m working on.

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.

> Psalm has been a god send on the project I’m working on.

Thanks!

The type system isn’t expressive enough for these tools to catch anything but the most basic errors.

In PHP, typing is for function signature documentation.

> you'll need strict mode for type hints to be useful.

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).

This 100%. It's actually a bit of a red flag to me these days if a developer turns up their nose at PHP. The language has matured a lot and building stuff with it is simple, cheap, straightforward and fast. If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for their own amusement vs. what the business needed, etc. etc. Red flag. I've had these guys like this on my team and guess what, they built fancy over-engineered solutions to problems that no one had and then job hopped and left it for us to deal with. I can't speak for anyone else but I go into work every day for one purpose, and it's to ship shit which users use. I don't have room on my team for people who have other priorities. The amount of stuff you can get done with basically just PHP and Linux is amazing.

I love PHP, but a red flag?! If they’re busy in the Ruby/Java/C#/Go worlds (all get-it-done environments) then I’d just assume they don’t read many Hacker News praises for PHP. It’s easy to have not encountered it since the bad old days unless you work on a team that uses Laravel for some things.

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

Exactly how I feel reading this thread, I had no idea PHP has changed so much.

Yeah, that's fair. Now that you mention it, 90% of these guys where I get that red flag instinct I described are Javascript devs or wannabe Javascript devs. It's as if the JS ecosystem has driven an entire generation of developers insane

I'm in complete agreement there; I've seen a number of those. I like to ask simple questions about what they like about programming to catch some of those issues and look for a certain amount of self-understanding.

I think it's a case that unfortunately many people don't understand how simple a solution can be. They've been fed the typical books and articles and firmly believe that if it's just PHP it just can't be good. Right? I mean going through all this pain and requiring that many developers, means that this solution has to be much better? Right?

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.

One does not need PHP for that. Most well known traditional web framework with server side template rendering will do.

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.

Don't you dare to tell me that my isomorphic Node trpc graphql with redux and sagas on top of next.js with SSG and SSR and parts in server components with my home grown validation and ORM framework and still no translations because they don't work together with everything else and deployed on serverless docker lambdas to a kubernetes cluster is over engineering a landing page with a contact form. So fast!

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

This made me giggle because I've heard stuff like this in serious situations.

Of course, it's based of my personal experience too. I'm not claiming I invented this at all.

You described the marketing website of my previous employer.

And the marketing website of many others. It’s not a joke. Pure real life.

You're not using Temporal workflows? So outdated!

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).

Yeh, JS-land is wild. In a way, it's amazing that this ecosystem is so lively and fertile, but my gosh it's draining.

Don’t forget to deploy all that code to the edge. Your $5 VPS in NY running both nginx and MySQL is going to be a huge bottle neck when somebody in Texas tries to view your simple website and it takes .10 seconds longer to load. You’re going to want that contact form code on at least 1,000 servers worldwide for maximum benefits and conversions.

Also, now that you are on the edge and your form submissions are web scale you likely need to model eventually consistency for the processing so you will need a highly available queue running somewhere.

10 seconds? Slight exaggeration, surely.

0.10 seconds

Joking aside, as someone who runs their entire saas off a single bare metal server in Las Vegas, I have been toying with the idea of pushing some stuff to the edge. The reason being, sometimes those average load times are not giving you the real picture. If my average load time is 560ms per request because 90% of requests are 400ms and 10% are 2 full seconds, that might be a problem. Fixing those 10% requests and bringing them down in line with the rest would equate to an average speed up of only around 100ms.

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

I like the idea of a "Progressively Enhanced Monolith". Start by building the core of the application in something like Laravel that can do anything and be developed quickly, then stick it behind a proxy/CDN like Cloudflare. Then if you find endpoints or pages that are accessed frequently and would be better as their own microservice then use a small serverless worker to either respond directly from the edge or forward the request onto a microservice.

I'm jumping on the conversation , actually my portfolio website is on cloudflare pages with astrojs , it costs me nothing to host it , has a quick way to develop . I higly recomend it

Wait you're not using islands architecture!? Hahahaha how quaint! Get a load of this site, it's not using islands!!

Just 6 years ago you still were writing type hints in comments as suse annotations which was not PHP standard.

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

And don't get me started with all the points where the syntax pretends to consume an expression but it's actually just the parser looking for a very specific pattern that will be read as if it was an expression, but other forms won't be accepted.

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!"

> It's actually a bit of a red flag to me these days if a developer turns up their nose at PHP.

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 ;)

Oppositely: not being able to articulate the problems with PHP/Laravel compared to a stack of say Kotlin/Ktor or C#/MVC or Java/SpringBoot is a red flag too in my book.

Have worked at a few places where PHP was dumped on because “it doesn’t have threads”. The dumper-folks were also noted to be for spending most of their time trying to fix threading issues (Java, usually). Saw this in person twice, have heard similarly from other colleagues over the years.

I agree “it doesn’t have threads” is a bullshit reason. Especially since it took JS's threadlessness to make evented (aka async, aka promise-based, aka callback-based, aka eventloop-based) mainstream, and for good reasons! It allows many to maximize the compute resources better than possible with the threaded approach.

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)

To be blunt, you are a terrible hiring manager if your red flag is “they haven’t got an up-to-date opinion about the shitty-history language that I’m personally into”.

This just sounds like PHP Stockholm syndrome with extra steps.

I guess it depends on how it's communicated. If someone tells me he doesn't like PHP because of this and that reason, that's fine. Getting wound up about some specific programming language (feature) or any tech still raises a red flag for me. But then I might be terrible as well :)

I can be pretty confident that if a language is not from the ML family I’m not going to like it for all of the reasons it’s not a ML language.

Whatever happened to passionate programmers?

One of the reasons why I love working on PHP jobs is that I get to avoid "passionate" programmers.

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.

Thousands at Railsconf or Clojure Conj would disagree, I'm sure but these languages are kinda special.

I am totally passionate about removing complexity from apps and stacks.

There's plenty of stacks that I'd say qualify as "simple, cheap, straightforward, and fast" (modern Java, for instance - huge red flag to me if people still turn up their nose at Java), including some that you'd probably consider exotic (honourable mention: Elixir+Phoenix).

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 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.

PHP has matured and has been a nice language for a decade now. But PHP developers havent. Cargo culting “good practice” and lack of creativity plagues the community. Frameworks have become so heavy that you spend more time configuring them than actually adding value. Oh and some still argue over setters and getters.

That hasn't been my experience at all. Although, I do spend more time interacting with the Laravel community (a subset of the PHP community) than the PHP community itself.

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.

But that’s kinda their point… you spend time configuring the framework instead of reimplementing from scratch and doing the plumbing yourself.

The issue is that there is so much configuration that it’s basically coding. PHP frameworks are all bloat. It would have been much better to abstract things in a way that you actually spend time on features not thousands of configs.

Then use lumen, it comes with laravel.

Nah, I’ll use python or other proper languages, thanks.

> Nah, I’ll use python or other proper languages, thanks.

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

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

https://lumen.laravel.com/docs/10.x

> 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.

> Oh and some still argue over setters and getters.

Serious question, what does that argument consist of ?

Whether to use them or not. Petty endless debates over their benefits and drawbacks. Literarily for as long as i worked with php devs in all teams there was someone debating this pattern. As php is not strongly typed these can help with data type validation, can perform some logic when setting values, while others say it’s inefficient as thats an unnecessary method call, or that no logic should be performed in them. Some prefer to use magic functions instead of setters and getters others are against it because it makes the code difficult to maintain, some say they should only be used for data entities, others want to use them for every property, some prefer them because you can rename properties while maintaining external accessors, others against then because of consistency, some argue over what naming convention is best, some want to persist data in some type of storage when making updates, some attach observers to them and so on.

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.

class variables can be typed now though, so the data type validation argument doesn't hold at least for basic type system validation

My experience is that if I join a team of PHP developers, there is a 40% chance of the team being professionals and writing good maintainable code. With Java, .NET and Python I would say 80%. C and C++ around 90%.

This also reflects in their salaries.

That is my experience as well. A competent PHP developer can earn as much as developers for the languages you listed, but they are less frequent.

> PHP has matured and has been a nice language for a decade now.

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.

Encodings are a non issue in PHP and the availability of web tools is much wider in php than for python. PHP matured in the sense that it from a wordpress type of hacky language to an almost decent language. It can be used properly if you know what you are doing (ie can scale really well for the web, can be secure, allows for good oop design, can be fast _for the web_, and has a wide range of supported packages, separation of concerns and so on).

> and the availability of web tools is much wider in php than for python.

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".

I am not saying that’s a metric of the language’s quality, nor am i saying that python is worse than php.

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.

There are breaking changes from 4->5->7->(less so)8

This is why so many basic php web 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 described in it has been fixed?

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.

PHP8. You think it's a red flag when people don't believe that PHP8 finally got their shit together.

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.

First off, this comment reveals some ignorance about the language. PHP 6 never existed. Trying to infer anything off version numbers like this is goofy; in a much shorter time period Node is up to v20. Does 20 versus 8 mean anything? No.

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

Anybody who believes that this time PHP isn't awful can expect the same disappointment as the last few times. I'm an old man, I remember all the pain of upgrading to PHP3 and for my sins my current work includes trying to cajole somebody's PHP7.x code into running even though it appears their employer disowned the project we know if we don't make it work the "replacement" will never actually materialise.

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.

> If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for their own amusement vs. what the business needed, etc. etc. Red flag.

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.

> magic framework stuff that Laravel/Symphony provide

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.

I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits.

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.

I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.

It's like that with every framework: Laravel, Rails, Django, you name it.

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.

"...Once you try to build something that does not fit the confines of the framework..."

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.

Out of curiosity, what foundation would you consider solid currently?

> 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.

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

Indeed so. But there's value in an ability to find out such things without running the code, just by looking at it.

> The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation.

Have you actually used Symfony?

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

I have, though I admit it's been about 10 years since and my memory may be mixing in (pun intended) things from version 1.

You're really doing a disservice to others with opinions that are so out of date.

https://symfony.com/doc/current/page_creation.html

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.

They are not comments they are php8 attributes

PHP8 attributes are comments with a special format.

They are not. Attributes are metadata that can reflected/accessed at runtime: https://php.watch/versions/8.0/attributes

Comments can also be accessed at runtime :)

And a program can generally read its source code and make fancy adhoc interpretation, sure. That’s nowhere close to specified facilities that you are guarantied to be able to use with a fair amount of trust in the resulting outcome with the regular toolbox.

# is a PHP comment syntax. #[foo] is as much of a comment as #foo is.

Not since PHP8 it's not [0], it's a real part of the language that you can read and view using reflection

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

It's still using a subset of the comment syntax, and will still be ignored as comments rather than hard-fail in earlier versions.

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

This is one of the reasons I like PHP, in newer PHP versions it is an attribute but in older versions it is just a comment. Clever and backwards compatible.

It isn't backwards compatible (`#[foo` used to be legal PHP 7, but is illegal in PHP 8).

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).

Okay, forward compatible. It makes it easier for framework and library maintainers to support multiple versions of PHP, which is nice.

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

So it is not a comment in PHP8 then.

What ruined PHP's reputation is people believing the language itself was a sufficient framework and unsafe SQL and escaping practices being the norm, due to naive developers (which PHP has plenty of) thinking the simplest solution (eg concatenating strings and variables into SQL queries vs prepared statements) is always the most correct.

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.

I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses

Sure, but it does exist frameworks that uses minimal amount of magic.

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

There are really different topics here.

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.

OOP, codegen, vendorlock, and bloat-magic...

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.

This comes across exactly what the previous poster was saying as someone who turns their nose up to PHP. Especially the "you have to" gibe.

> 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?

> 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?

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.

Same experience. JS is shitshow and dumpster fire. I’m picking up Vue 3 and every time I have a new question I need to ignore Vue 2 documentation written 1-2 years ago because the paradigm has shifted away from the “option” API to “composition”. The same jarring change experienced in the React community when it shifted to hooks. It is no wonder I can find a cascade of defects in just about every modern website made written within the last 3 years.

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

I don’t turn up my nose though. I don’t judge anyone for choosing tech, especially if they have good reasons.

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.

> 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

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.

These “as a super important hiring manager” brags are quite boring to read

Ditto for any language. I think it is a good sign for someone to recognize the trade-offs a language makes, or even accept that they can complain about it while acknowledging they don’t understand the trade-offs.

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

What about people who get their stuff done with mature, well established, and high performant Java and C# frameworks? The benefits of static languages is already established, particularly for longer maintained and larger code bases where multiple people work on them.

> Laravel is [...] reasonably well documented

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.

The documentation reads like a tutorial, which is fine the first time you read it, and really annoying the next 99 times when you're just trying to find something. My biggest gripe though is that the majority of classes / methods aren't locally documented with comments, or only minimally. If I don't understand how a certain parameter behaves (or even what a function does), I have to go online and search for examples, or look through the docs hoping that it's explained. And don't get me started on Facades, which are a code discovery dead end...

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.

Yep, the tutorials/guides are really good, but as you say, the details aren't really covered. There are so many examples like "relationsToArray(): Get the model's relationships in array form."[1] Just an expanded version of the method name with no context or detail.

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

The good ol' "you thought docs, but actually generated no information gain and no docs, ha tricked you! but look at how fancy our docs website looks" kind of documentation style.

> The documentation reads like a tutorial, which is fine the first time you read it, and really annoying the next 99 times when you're just trying to find something.

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.

I think more documentation teams need to know of the concept of Diataxis [1] so they can invest in the 4 different kinds of documentation developers turn to for help when picking up a new technology:

- tutorials;

- how-to guides;

- technical reference and;

- explanation.

1: https://diataxis.fr

This looks very nice and is something I have been searching for but didn't know existed. Thank you!

See also the C4 model "for visualising software architecture". https://c4model.com/

Thanks for this. This is something I kind of knew but would have been hard pressed to articulate, especially on the spot. Seeing it laid out like this is very useful.

For stuff like Ansible (and other lacking software) docs i find that ChatGPT can provide the missing pieces.

What is wrong with the Ansible documentation?! Almost all Ansible module documentation pages follow the same structure: a one-sentence synopsis, a list of OS packages needed to be present on the machine where Ansible runs and on the target machine, a table of parameters including aliases, default values and other hints, a list of attributes exported, some notes, and real-world examples.

It doesn't get more clear than that.

Outside of modules documentation, the rest of Ansible docs are examples. For instance, there is no page where all ways of accessing inventory variables are listed. Or supported jinja filters. They are all scattered in a myriad of examples, which you have to read, carefully, to find what you need.

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.

I am certainly not one to defend the new ansible docs, but part of the woes that you're describing are due to the fact they just doubled down on `ansible-galaxy install` based setups, meaning there isn't "an answer" to what filters are available in ansible

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)

What "computer science terms" did you encounter, that you did not understand? I also do not have a CS degree, but every term that I've encountered in the Laravel docs I found easy to search for. Just don't rely on Wikipedia for explanations, for CS (and mathematics) subjects Wikipedia seems to be useful only to those already versed in the field.

I struggled with sorting out Contracts vs Facades vs Traits. I graduated from university 20 years ago with a software engineering degree, where it was drummed into me that simpler often is better, and much more robust. Reading the Laravel docs however, leaves more questions than I started off with.

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.

The project is in a constant state of flux. So for example the Contracts you cited are in version 5.8 but they are no longer in the current versions.

EDIT: I just noticed that Contracts are still in the current version just got moved in the docs, so I your point still stands.

Right, but this is a discussion about their documentation, not whether Feature X in a version of Laravel is still around in the latest version. I'm not attacking the framework, as I said I love using Laravel. I just have criticism about their documentation.

The 5.8 docs are like from like 7 or 8 years ago. I’d say the 10.x docs have improved a lot, but I do share some of your opinions on the docs in general. Anyone can contribute to them, though. https://laravel.com/docs/10.x/contracts

Laravel focus a lot on branding & communication to create a hype by overselling their functionality, you are a "Web artisan" when using it, the ORM is not like other ORMs, it is an Eloquent ORM etc.

A facade cuts out the boilerplate to achieve the same ends as a contract, which is to provide a dependency of some kind.

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.

The documentation for Laravel is still unreadable.

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

But why? I‘m working with it daily and what I learned is to read the docs properly. Usually it‘s me not reading correctly. There is some advanced stuff that‘s not covered in the docs, but not necessary to build an app.

That's exactly the point: a documentation should be comprehensive, i.e. it for each class and each method it should describe exactly what the method does, including all parameters etc. The Laravel "documentation" is a tutorial, i.e. it describes what you should do for the most common use cases in a style designed to be read from beginning to end. Which has its uses too, but as documentation, it's pretty lacking...

Laravel tutorials are a fruitful business because PHP still quite rightfully carries its legacy of being the noob language.

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.

The documentation for Laravel is readable, in the sense that if you read it from beginning to end, like a book or tutorial, you will get a pretty good understanding of what Laravel does. But [supreme being of your choice] help you if you just want to find out what the possible values for a specific parameter of a specific method can be...

Nah. It's pretty bad. They only document like 5% of the features. What they do document is good but other than that you have to read the source on GitHub or Google for code snippets and I say this as an expert that studied the docs for help in documenting my own orm. They just straight up don't document most of Eloquent's features and class methods in the docs at all and it's super frustrating to me.

What are the “computer science terms”? I went looking in the docs briefly but didn’t find anything like that. Maybe the v10 docs do better? https://laravel.com/docs/10.x/blade

there are many documentations tells you the detail in their code.... even with the most basic usage

Really? I don't have a comp sci degree either, and yet I find the Laravel docs incredibly easy to grok. Do you have any specific examples of things you've struggled to understand?

Agree. Last time I tried Laravel the documentation was lacking a bit. E.g. there are lot of "automagic" things that aren't explained. And then you are left wondering with things like "Must the names of those 2 things really match for it to work?".

I've used maybe a couple of dozen programming languages over the years (yes, I'm that old). I see programming languages as tools—you want to pick the right tool for the right purpose. Whether a tool is right depends not just on the language itself, but also the ecosystem of libraries.

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!

Absolutely. The developer experience with PHP is so far ahead of the Javascript "ecosystem" that it is ridiculous!

I've always told my coworkers and friends that the programming language doesn't matter at all (despite I don't think there's anything wrong or worse than alternatives in modern PHP). What matters is the frameworks, libraries, ecosystem, editor support, available talent, culture around it, etc. And PHP (and the Laravel ecosystem) is rock solid in that area, the best by far. I'm a frontend dev at a pretty big company, but before this I worked on a Laravel + TurboLaravel (Hotwire, etc) and it's just incredible how easy and quick it was to build and maintain things.

Agree, though I would put Java in the same category as well (and actually prefer that). Great ecosystem, great frameworks for every conceivable business case, excellent performance, tooling.

PHP has been a great language for a while, essentially since the world of enterprise became web based instead of application based. I suspect it’s not seeing too much adoption because it wasn’t always great, partly because a lot of enterprise is married to Java (which is frankly also in a decent state) and because JavaScript (with types) and Python lets your teams do a single language while also doing a react client or a lot of BI/ML.

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.

Have a look at quarkus.

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.

In my experience Laravel teams are WAY more productive than Quarkus teams though.

Is C#/.NET overly complex? I'm used to Laravel and have been exploring C#/.NET, which while a bit complicated is nice for the static typing. I've been hearing that for web apps the Laravel ecosystem is still simpler and more batteries-included than the equivalent ASP.NET.

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?

PHP has types now??

Yes. Since 2015.

> Just ignore the fugly standard library inconsistencies of (old) PHP, every language has their toilet corner...

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)

>> 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.

* head explodes awesome

I know what I'm doing this afternoon!

Writing PHP bindings is pretty easy as well (once you manage to sort out build tooling, but that's a mess anywhere in C). Have fun :)

The NPM/JS/TS hellhole is real. Moved on from it a couple of years ago, and today I switch between Go and PHP (WP custom stuff).

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

It's goofy to me how many devs think the art of writing software necessitates continually updating dependencies to have things not break. You're running in place! You could be working on something new that generates value, or adding features to what you have in that time.

To me, dependency management is a part of software maintenance and it's not always just 'running in place'. Updates bring security patches (sometimes not publicly explained or disclosed), performance improvements, and new features that could enhance the value generated by the said software.

you only point out positives, but the negatives are usually felt a lot more intensively

I agree that PHP is a fine language these days, if using modern features and techniques. I've seen plenty of recently written PHP that looks like it was written in 1997.

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.

> It's single threaded

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.

> Oh and it's free. All of it. PHP, Laravel. And its hosting has always been the cheapest. You don't need a particular OS or certain cloud providers.

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.

> It's fast, it's typed (now), it's reliable.

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.

> How do people debug in PHP?

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

The main reason I don't use PHP is because the browser doesn't.

Sooner or later I end up having to write Javascript and lots* of it. Therefore I use it across the board.

*where "lots" = logic that needs to exist on both client and server side

All those arguments would apply to Python and Django in my opinion.

> It's the BMX of the languages.

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

If you want to ride a bike, you can ride the bike. If you want to do tricks, you can do 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.

And...the language can be taken to a high school prom - like any BMX bike can be: https://www.youtube.com/watch?v=VPVJzi7Ta9w

Sorry, could not resist! lol :-D

Most things wrong with PHP that I really care about are currently being resolved in Psalm which undoubtedly will eventually (might be 10-15 years who knows) be rolled into the language.

I know NodeJS well but have never used PHP, but I can attest that using PM2 is a pain and node_modules deps issues can be a hair-pulling event. But the package.json scripts provide a simple and built-in way to run basic build tasks. There's always an ~~app~~package for that, no matter what "that" is. There are also tons of tutorials, examples, and snippets for everything you want to do to get up and running quickly. TBH I really enjoy working with Typescript, it really brings sanity to JS (as long as you are consistent with it) and Express is dead simple and just makes sense.

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?

Symfony is better for scaling apps, I have found. I know Laravel is built on top of Symfony, but Symfony scales out of the box much better, Laravel is still the framework of bespoke one off projects in my experience (used it for years). It does not excel at maintainability of large apps.

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.

I hold a center position on this. I think PHP is great for a lot of things (especially these days). I even agree about Swift. Love that lang.

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.

I'm in the group described halfway down: was on the Internet during PHP 5, lost interest in it, and moved on [to Go]. I haven't written anything in PHP newer than version 5. Even transitioning from 4 to 5 was quite a big deal, I definitely noticed improvements.

But it wasn't enough.

I couldn't fit the data set in memory with PHP. But I could do it with Go.

I couldn't do parallel computations in PHP in order to respond to an HTTP request quickly enough. But I could do it with Go.

I couldn't reliably and easily deploy to different systems with PHP. But I could do it with Go.

Eventually, I couldn't write a web server with PHP. But I could do it with Go.

A lot of my early websites were written in PHP and I was able to build them quickly and routinely. I didn't really have a problem with PHP as a paradigm, or even its security and consistency posture. I'm glad they've since made an actual language spec and fixed a lot of issues with it. And I don't judge or look down on PHP programmers. I just don't think it was the right tool for my jobs.

When are these ever issues? In a real life scenario

In almost any scenario?

>I couldn't fit the data set in memory with PHP. But I could do it with Go.

I guess this on is self-explanatory.

>I couldn't do parallel computations in PHP in order to respond to an HTTP request quickly enough. But I could do it with Go.

Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results.

>I couldn't reliably and easily deploy to different systems with PHP. But I could do it with Go.

I haven't been using PHP since 5 but I assume it's still much easier to just push you Go binary to a destination.

Though with Docker and company deploying PHP code is not a big issue these days I assume.

> >I couldn't fit the data set in memory with PHP. But I could do it with Go.

when would you ever have a website serve a request, and have to use gigabytes of memory to do so?

> Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results.

Again, why would you ever have an HTTP server do so much work in order to serve a request?

>when would you ever have a website serve a request, and have to use gigabytes of memory to do so?

I'm pretty sure that PHP is not only used for web sites otherwise comparing to Go is simply meaningless. There is little to no point in using Go to build something with a relatevely low load.

>Again, why would you ever have an HTTP server do so much work in order to serve a request?

http server != website. You can have two services somewhere down infrastructer that communicate via http(s).

> I'm pretty sure that PHP is not only used for web sites

PHP is explicitly designed to serve web content. It's usage may vary, but it is unfair to expect it to optimize towards anything but as a web backend.

> you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results.

This definitely sounds like a typical situation for handling the job in a queue (plus with an async library like spatie/async to retrieve data in parallel), though I see the advantages and convenience of using a natively-async language here.

An example (not the best one maybe but I'm not the right guy to come up with good examples immediately) from a year ago:

We have to integrate company M and W (one is a marketplace the other one is a big store, think Walmart or something).

Company W mostly uses software similar to SAP-whatever and have a small team resposible for building 'helper' services in place where SAP can't do the job.

Company W can't communicate with M in any other way except through your generic http API they provide.

So every now and then M has to send a request to W and W has to prepare a pretty large XML response. (obviously the data is split in some way and we are not talking about tens of GBs but even so W has has to fetch the data from more than one data source, process it and send it)

In some cases you can simply have a cache\a view\whatever for this (so you only have to fetch prepared data) but in some cases you can not.

PS: this is if we are talking about HTTP communication. Or maybe some real-time communication where you can't really respond with "hey, we are getting your data prepared so just wait for a bit and re-request it with this nice jobID at a later time"

Well, for that use case, it would be typical in my industry for party A to send a callback URL to party B, so that B can POST the required information back to A after doing the multi-step processing. It's not really a done thing to make a synchronous HTTP request and wait say a minute or more for the response. Maybe that's just different expectations in different industries, though.

I agree, the main problem with PHP in my experience so far has been that it's very memory-hungry and slow (even PHP7/8), especially when coupled with frameworks/ORM magic.

I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because that would take like a gig of RAM (which would compete with other PHP processes on the server) and considerable amount of time. You have to use a lot of hacks to make it all fit in memory and be fast.

Our Symfony framework also initializes in like 300 ms on each request, while in Go it's below 10 ms. As every PHP process dies after serving a request, you have to reinitialize the whole dependency container on each request from scratch, and in large enterprise applications, that's a lot of dependencies.

What you are describing only happens in dev environment

The Symfony container does not rebuild in production and requests should easily be served within 5-10ms as well so you might want to check your deployment pipeline and that you correctly composer dump-env prod

If symphony takes 300ms in prod. Then you have a serious problem!

Probably a configuration missing.

That 300ms initialization time sounds like a cache-free execution (aka dev mode). I have symfony projects light on ORM usage (I dislike Doctrine from the bottom of my hearth, but what can you do it's the blessed symfony ORM) and after a cache warmup it handles requests under 100ms.

Yes, the frameworks have obscene (java-like) class dependencies that build up during initialization (I'd prefer if there'd be a lighter function based framework nowadays), however for someone that knows how to manage PHP on the server there are OPCache tweaks, preloading facilities which help improve the request initialization performane (these steps are also expanded on in the symfony docs).

The share-nothing arhitecture of each request is either a benefit or a downside, depending who you ask.

It does run with caches enabled, my memory is murky but I remember Go processing requests on an order of magnitude faster (10x). Maybe it's about dependencies reconnecting on each request, or the large amount of classes in the monolith? I remember marking dependencies as "lazy load" helps.

>there are OPCache tweaks, preloading facilities which help improve the request initialization performance

I remember we disabled some of the settings for preload because we hit a bug which manifested as a segfault due to PHP's shared memory space for preload getting corrupted under a high load.

In any case, everything is fast and usually doesn't require a lot of tuning in Go out of the box.

However, I do love PHP's shared nothing architecture for the reasons of memory isolation: we have thousands of B2B tenants and with PHP, I'm confident we won't accidentally spill one company's data into another company's account. Things like when ChatGPT exposed your conversations to random people because a bug in the Redis connection pool inside Python's shared memory space returned a connection for a different user, due to a race condition.

Well, that's the problem with all PHP frameworks: they're written in PHP! Yes, PHP has gotten faster thanks to OPCache and other tricks, but still, the less time your application spends executing PHP code, the faster it will be. And frameworks like Laravel just pile on additional PHP code to execute like there's no tomorrow. I mean, just look at the callstack when an exception happens...

I was running tens of thousands of jobs an hour with an asynchronous AWS SQS job dispatcher written in php that would launch php sub processes on the CLI. Super fast. Was able to get by with a very modest ec2 instance ($20/month) handling jobs for 300k users. Was auto scaling too.

PHP 8.x has a ton of performance improvements that make what you're saying sort of not relevant anymore. I prefer PHP over Python these days on the Linux CLI. The code is cleaner.

You're doing something terribly wrong. Sounds like caching isn't setup and your http -> php handler is cold booting the interpreter for every single request.

Check these Go vs. PHP benchmarks. PHP is quite fast and stands up nicely to the performance you get out of Go.

https://www.techempower.com/benchmarks/#section=data-r21&l=z...

Isn't that synthetic benchmarks for toy projects? The amount of code which is run on every request grows with the size of the project in PHP/Symfony (which can take quite some time in a huge monolith), while in Go, everything is usually initialized once at startup.

All i see is that the php fpm based frameworks (e.g. laravel) are 100x - 300x slower. And this is the best case scenario. When projects grow, php-fpm gets slower and slower. Which is not the case for go. Im not a go-fanboy, my entire carreer has been in PHP. Im just saying, PHP is one of the most terrible languages for web servers. And it's all php-fpm's fault. On top of that, the PHP community seems to promote OOP and SOLID which are the last design patterns you want to combine with php-fpm. There's a reason why facebook created their own PHP transpiler.

This benchmark means nothing.

I’ve written PHP apps that process millions of entities without issue at my old job. We didn’t use an ORM or anything magic. At my current job, using an ORM, my code has twice as much memory yet I can only load a few thousand entities before OOMing.

If you’re willing to give up magic, it’s worth it.

FWIW: There are a bunch of ways to "do" php execution, and a lot of them are wrong. That's not exactly PHP's fault, just that there's been a lot of blind-leading-the-blind.

Assuming that you're not spinning up and tearing down a container for every request, you want to be sure you're running php with a php-fpm configuration (preferably talking over a unix socket) -- this is the fastcgi process manager, which maintains a pool of "hot" php interpreters for you that are immediately ready to execute code for an inbound request. This is usually good enough for most applications without going into the weeds on things like opcode caching, but that's all available as options too.

I'd be happy to help troubleshoot this with you if you're interested. I've also got a fully automated build script that works pretty well. You can find my contact info via the link in my profile. I promise it doesn't have to take anywhere near 300ms for php to reply to a request.

My experience is that Symfony, in its fat, batteries-included form, does take quite long time to initialize on cold caches. The first request can take hundreds of milliseconds but usually the very next request is in the normal 10ms range. This is especially noticeable on (cheap) shared hosting which has always been a common place to run PHP.

I've never found it to be a problem on a VPS but if you're developing on something slow like a Raspberry Pi I can see this happening regularly. If you're used to deploying stuff in containers and constantly throw out the cache the initialisation problem can happen very easily as well.

IIRC back in symfony 1 part of it was becasue symfony used the first request to write optimized versions of the code into a folder that I cannot remember the name of.

I think there was a way to do this up front in Symfony 1 and there might be some way to do this as part of a build and deploy step. Of course on applications with less traffic and less strict requirements just hooking something up to run a request immediately after deploy might work just as well, but if it runs across n small pods it might be a much better idea to do it on a beefy build machine instead of on n resource constrained pods causing slow loading for n customers.

PHPs language peers are things like Python and Ruby, both of which are slower.

The way developers are encouraged to structure PHP projects (mainly due to autoloader semantics) always felt more like Java or .NET to me than it did like python. The resource consumption comparison between a Symfony web app vs the same thing written in ASP.NET or Spring Boot has a pretty clear winner, and it's not PHP.

Well that depends. There are like a dozen python interpreters and JIT compilers. PyPy is fast, albiet memory hungry.

We do a lot of work with large datasets. PHP 7&8 are so much better than 5 in terms of memory usage for large datasets.

Its not magic though, and I'm not surprised a compiled executable is many times faster, especially for math heavy stuff. Slow is often "good enough" though and deploying is quite straight forward.

I agree with every checkmark except for Go.

PHP was the right tool at the time especially when everything on the web was somewhat Wordpress first. PHP felt like a blast with WAMP/LAMP.

Since then I have moved on and honestly it never occurred to me, that PHP still could be an option in my tech stacks, neither one of my devs recommended it.

No one hates or disliked PHP, there are simply other options.

Looking back, recommending PHP today feels like "You can do this with jQuery, too" in the Frontend domain. Yes, you can, but maybe you shouldn't or only if you have the right people. And PHP is a rare skill now.

I’m not defending PHP necessarily, but yes, obviously a language that’s more performance oriented will be better at performance-oriented tasks.

In terms of parallelization and reinterpreting every request, there is Swoole (implemented in Laravel as Optane) that fixes both of those issues. Most Laravel projects can handle 2x as many requests with a simple modification.

I'd say PHP is great to get started, Go is for when you need more control, more mechanical sympathy.

I did write a REST/JSON API in PHP 5.2 (two years ago, I'm aware there's newer versions out there but they aren't easily available in RHEL 6/7 used at our customers at the time - it was a slow moving industry); it's doable, and using best practices learned from other languages makes it look maintainable at least.

Did run into some issue with large datasets though, but that was an implementation problem; the original author would read a CSV, convert it to XML using concatenation, then parse the XML to convert it into JSON because at some point a decade ago he found out that the X in XHR was no longer (and never was) the norm, all in memory. That broke when there were more than a few thousand rows in the CSV.

Developer advocacy is such a weird thing, do it right and people will line up for you to mentor them and pay you for it, do it wrong and you will people scratching their heads asking "so you can do with this thing what you could do with Perl + CGI 15-20 years ago and still not get more performance out of it?".

Sadly this article is the latter.

I'm working on both sides of the fence -- dynamic strongly typed language (Elixir) and static strongly typed languages (Golang, Rust) -- so I am already sold on the advantages of dynamic languages. That page is doing a poor job selling PHP to me though, f.ex. it's not clear when you do `$request->user->orders`, does that automatically go to the DB? Does it first fetch the user and then all their orders, or does it do it in one go? Is the whole thing prone to N+1 queries like Rails is (was? no clue about it nowadays)?

Posting cute little coding snippets is skipping 99% of the story. The code must remain small and simple and understandable and easy to dissect / troubleshoot, long-term, and allow for adding metrics / telemetry, analytics and such.

So OK, we get it, you're so hyped about PHP that you made a website about it. Alright. Now do a cookbook. Next show us a 5-year old project and tell us how long does it take to add a feature or fix a bug exactly. Tell us of the issue that took you the longest to troubleshoot -- and why did it take so long.

Before that this is basically a surface-level marketing page that says almost nothing and is not even accentuating the strong sides of your loved technology because what I am seeing here I can clearly remember 5 other languages I've done it successfully with: JS, Golang, Elixir, Rust and Ruby.

> Is the whole thing prone to N+1 queries like Rails is (was? no clue about it nowadays)?

Rails has had the ‘include’ method which solves n+1 since version 3.0 around 2010. Before that it also had preload which worked similar.

Planet php has a strange and probably unique geography. It has its large continent of modern generic web frameworks but it also has these countless small but thriving islands of specialized platforms that solved specific problems.

But islanders and continentals dont talk or help each other.

You can obviously build from scratch a blog, a wiki, lms, forum, analytics, e-commerce, survey etc. etc. site in Laravel. The funny thing is that it is quite likely that the leading open source solution for what you want to do is already in php (wordpress, mediawiki, etc) yet you cannot benefit much from it. You definitely cannot import it, but you cant even learn easily from it unless you dig deep into a complicated codebase.

Because php is so old and so adapted to web development people went on and built wonderful things with it, capturing complex domains with all their peculiarities. But that valuable knowledge base remains fragmented and locked within each one of these monoliths.

Going forward there is ever more intense competition between open source language ecosystems. A lot of improvement efforts look inward (making languages faster, safer).

The php community might also be able to draw unique advantage looking more "externally", taping the enormous domain knowledge of all these projects. How that could be done in practice is an open question, but it could become the USP for php, the way data science has become for Python.

Why do most PHP related posts on HN read like repentance ? If you want to promote the language -to the point of buying a domain and making a webpage-, please show interesting stuff, not something that is equally trivial to solve in gazillions of web frameworks written in gazillions of languages.

I don’t get that feeling. And I like that people are doing their best to try to improve the reputation of the language. The reality is that modern php is very decent, but a lot of people that have never used it or have used a very old version mock or look down upon it for no apparent reason.

It’s important to try to improve the reputation so that it gets new developers interested in it in order for the language to keep being relevant.

If you want a concrete reason why I think php is great and has many things that are very useful compared to its competition:

Extensive native support for classes and types.

Php does class-based OO better than its competition (JavaScript, python).

Designing a traditional object oriented system using classes and interfaces is better in PHP than in JavaScript and python, if we limit ourselves to the native features of the language.

For example, you cannot define a native interface or an abstract class in python or JavaScript. JavaScript classes, since they’re just syntactic sugar, have a lot of unexpected behavior.

In python you have to accept the this/self object in every method definition.

Here are a couple of links about php classes, interfaces and types for anyone interested:

https://www.php.net/manual/en/language.oop5.variance.php

https://www.php.net/manual/en/language.oop5.interfaces.php

You just prove my point... you start your post with something that reads like "it's decent now, please look at PHP again". But:

    - you make bold claims about PHP OO
    - you make downright false points about other languages
    - you nitpick things that are non-issues in other languages

All in all, nothing in your post really seals the deal about PHP. It's not about mocking or looking down on PHP for no apparent reason. I'm pretty sure most of us on HN have used it already and most of us have followed its development. I sure did. And every time a new version comes out, I welcome the improvements although it's just mostly catching up with the competition. So what compelling reason do I have to use it again in 2023 for greenfield projects ? None. It used to be "the web specialist", but now all platforms have great web frameworks along their distinctive features.

Because there is a lot of negative propaganda against PHP out there, especially within academia.

You can meet people fresh out of university telling you that PHP is bad even though they have never written a line of PHP. They just know.

This is quite bad for the industry as a whole, because it plays right into large companies that is pushing their technology in an effort to subvert web.

PHP sucks though.

I wouldn't say it sucks, or rather at this point it has its warts like any other platform. It's definitely not a pretty thing, and it was never meant to be. It's something that borrows from the competition rather than innovate.

Name something better to build web sites.

HTML

Yes, I agree. But if you want to do some form of dynamic rendering and not static rendering HTML only is not an option. PHP matches HTML pretty well.

I've been using PHP for about 19 years and what I can tell is that both the language and its community have evolved the right way. Writing modern PHP is a joy, IDE support is great and we have tools for everything.

Modern PHP is about community standards, not about any particular framework and exposing Laravel as the best way to get started with PHP is questionable. I wouldn't recommend it to anyone wanting to learn (real) PHP.

The article praises PHP but it is sad that doesn't link to any other resource or project which ditches the value of PHP community.

Laravel is great for RAD which is attractive for small projects. The kind of stuff "business with 500K orders runs on a $6 VPS" thing. For clients wanting a robust software system you can use a better tool.

Yeah, I think phptherightway.com does a much better job introducing people to modern PHP.

So Laravel is not robust?

Honestly asking. Haven't written PHP in over 20 years.

Laravel only seems to be for small stuff like - the backends of Apples Webapps - spiegel.de, the biggest German news site - the New York Times website - backend services at Disney - About You (large online retailer)

Seriously, though, I myself work for an enterprise that runs big parts of the European energy grid and we use Laravel for all sorts of stuff. At a previous job Laravel powered a whole ISP.

Notice when people say Laravel is good for small stuff and early prototypes, they never explain why.

The only bad part of the PHP community is the people that have never done anything else other than WordPress. The shittiest more careless horrible and bad practices riddled codebases I’ve seen in my life come from WordPress developers. It has nothing to do with the language though, it’s just that part of the ecosystem which I think is what drives all the negativity and looking down towards PHP.

> Your website is automatically protected against XSS, session hijacking, CSRF, SQL injection, host header attacks, and other vulnerabilities.

That's quite misleading however

Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.

The code snippet is very Laravel, and it does a lot to stop all those attacks with that API.

I worked for a company and we used the PHP ORM Propel. So in theory no SQL injections you would think, WRONG.

We used a function like findOne() (I don't recall exactly). It looked like this:

$resetTokens->findOne($GET['password-reset-token']);

The issue was that findOne would accept wildcards, so one could use ?password-reset-token=% in the URL and reset the password of any random users.

... why would you pass $GET through to a logical layer with access to a data store write without sanitizing it?

This seems like a pretty basic thing to fix, but then I only have your snippet to go by.

That’s a parametrized API that’s supposed to be safe against injection, at least to anyone who’s ever used parametrized APIs and hasn’t read the documentation of this particular library in detail. That it supports wildcard makes as much sense as log4j executing code in textual messages.

If an ORM/builder casually puts =/IS and LIKE in the same method, don’t touch it.

I think the webpage is talking specifically about Laravel. It ambiguously doesn't mention Laravel till later, but the code snippet looks like Laravel code. Laravel's ORM does sanitise strings.

The snippet also validates request inputs, so clearly it doesn't assume that inputs are safe.

I totally agree with everyone before me here on the issue of security.

If an app stands the stress test against say for example this comprehensive list(1), it can consider itself somewhat safe or at least benchmarked. Otherwise, only vague and unsubstantiated claims, which does not help PHP nor any other programming language or framework.

[1] https://github.com/payloadbox/xss-payload-list

In both Symfony and Laravel these days they have their own request objects to help you get information on the request. You shouldn’t be reaching into the get or post variables directly like that.

i.e. $request->query(‘password-reset-token’);

Rails does a pretty good job.

PHP has come a long way and I have since changed my mind about Laravel but I love Ruby, and Rails does an awesome job. Laravel actually seems to try to mimick Rails in PHP

I've tried Laravel, it's a beautiful framework. But I see no reason to switch from Rails, it's a beast.

Hi!

I'm looking for advice on how Rails vs Laravel compare (as I'll have to pick one of them soon for a project). Assuming the same knowledge and familiarity on both of them, why would you prefer Rails over Laravel? Thanks!

The reason why I stuck with Rails is because I am already a Ruby user. I like PHP and all but I am way more comfortable with Ruby.

I don’t think there is anything Rails can do that Laravel cannot and wise versa.

It’s about taste.

I think Rails + hotwire hit the sweetspot for me!

Thanks!

In general I think there’s something to be said for sticking with languages that match your model of approaching a problem. DHH gave a good, albeit a bit rambly, keynote on this topic once. He compared some of the tools selection conversations to the equivalent of people comparing gaming consoles purely by specs when in reality, picking a console mostly boiled down to what you subjectively enjoyed more. I like that idea as a rule of thumb and encourage people to start there and go with what feels right for them before making deeper choices. (Lots of nuance here, don’t want to delve too deep so please view from that context :) )

Ruby is a beautifully-designed, concise language. PHP is the opposite. If you like Java-style verbosity you may like PHP. I don't.

Yea, I think what makes me enjoy Ruby a lot is the ability to meta-program a lot. I can mold the language to what I want to express.

Of course, this can be a double edged sword if you aren't comfortable in the language yet.

I want to second this. The top StackOverflow comment for protecting against XSS in PHP still recommends htmlspecialchars() https://stackoverflow.com/questions/1996122/how-to-prevent-x... which is a terrible and ancient approach (context-aware templates are the modern approach).

I also Googled to check CSRF protection and all the sites I can find just discuss rolling it yourself; the example uses some CSPRNG that can potentially return not cryptographically secure numbers without erroring. https://www.section.io/engineering-education/csrf-protection...

That's one thing that really drove me away from PHP. It presents an extremely simple seeming universe, in which web apps are very easy to write – but has really naïve bones, requiring a lot of extra scaffolding to be safe.

You don't get XSS protection out the box from any language's standard library, nor CSRF.

Well, of course not from any lang that treats HTML as a string, but there are langs, which treat HTML as structured data, in their standard libraries. Take a look at SXML libraries for example. Whatever script you stored as a username for example, it would still get treated as text, not tag, when put into lets say a span or p. SXML is aware of the boundary between tags, their attributes and their content.

I googled SXML and it appears to be have implementation libraries in lots of languages. This is not the core language's standard library.

What do you put as the distinguishing feature between "core language standard library" and "comes with the language at installation"?

Some example: https://www.gnu.org/software/guile/manual/html_node/Reading-... (no installation of anything third party required)

Alright, let's go with widely-used programming languages for now - I've been programming for over 20 years and never heard of Guile.

I am not against the idea of having native protections built into stdlib, we can agree there, but it's disingenuous to suggest that this problem is unique to PHP as the parent comment suggested. It's the same in all of the major programming languages used to spit out HTML as far as I can tell.

Oh, very much so. I don't doubt it. Most of them are doing it wrong, fiddling with strings, instead of structured data, which HTML would lend itself really nicely to. Especially PHP, with its "output HTML" in-built mentality should have gotten it right, but did not. Many others did not do any better.

You do get XSS protection out of the box in most templating languages, though, and PHP is also a templating language.

Take this template:

  <h1>{{ title }}</h1>

In most templating languages, for a title of "<script>alert();</script>", the result will end up being:

  <h1>&lt;script&gt;alert();&lt;/script&gt;</h1>

In PHP, which is a templating language, the equivalent seems to be:

  <h1><?php echo $title; ?></h1>

But this will print the title unescaped, which is a security vulnerability, and incorrect. In reality, the equivalent is:

  <h1><?php echo htmlspecialchars($title); ?></h1>

Now, you could say, don't use PHP as a templating language! But if you're not supposed to use PHP as a templating language, why does it behave as one? This is one of PHP's footguns to be avoided. Personally, I recommend a linter like PHPCS to catch issues like this one.

Templating languages are abstractions on top of other technologies. I don't see how PHP is a templating language. I could write that exact same code above in NodeJS and I'd need to use mustache to escape the output. So you can make the same mistakes in Node, Python.

Nobody writes PHP mixing HTML and PHP anymore, and if you do you should run. Shit code is not unique to PHP and I've seen more than my life's share in JS and Python codebases.

> I don't see how PHP is a templating language [...] Nobody writes PHP mixing HTML and PHP anymore

PHP is designed to be a template language, but it's a terrible template language, so nobody (it is claimed) uses it as it was originally designed to be used anymore.

So "use PHP" is not good advice if what you mean is "use a web framework and a separate third-party template language", which works just as well in any language and doesn't give PHP any particular advantage.

Tangential, but I've always found Mustache's tagline "logic-less templates" confusing - what they mean is that the template language doesn't have control flow. Logic is not a synonym of control flow in my mind.

I think the easier way to do things is mostly always the secure way in Laravel, so unless you go out of your way to do something weird, you're mostly safe from those attacks once you know how it works under the hood (to some extent) and what Laravel does and does not do for you.

> There is no need to compile anything.

But I really like compilers, they catch a whole class of bugs, before I run things.

And static typing, and linting, and code analysis, and security checks, and .. these pipelines are long nowadays

Oh and the garantiert that no one can modify it post the compile step.

While you don't have a proper compilation step, you can run some very good static analysis on PHP.

I can't imagine not having Psalm or PHPStan in our build pipelines.

Unit testing

Unit testing is a poor mans compiler. Our medium size rails app has 40,000 unit tests and constantly we have issues where an updated library changed the name or parameters of a method without warning causing breakages.

Yikes. Is there a static analysis tool for Ruby (along the lines of MyPy or PHP Stan) that could have caught this?

Also, out of curiosity, are all of those tests hand written, or is there some generation in there?

All hand written over 10 years. They catch a lot of stuff, but stuff still slips through. Generally the area of the breakage even has tests over it but didn’t manage to catch the particular issue or they had mocked out parts which ended up being the issue.

I can’t see how static analysts could solve it really.

imho, this is a huge reason why ruby fell off the popularity charts over time. i predicted this pretty early on and got a lot of flack from the ruby community as a result.

nobody wanted to write tests to ensure that something would compile... let alone tell you what 'type' an object was. i can't tell you how many hours i wasted watching my pair trying to figure out what 'type' an object was, by using `print`. luckily i was working as a very expensive consultant.

of course these things could be bolted onto ruby, but it never felt natural. running 40k tests to see if something compiles is absurd, takes forever and results in super brittle tests that have to be reworked when code changes. often people would use meta programming in the tests, which only made figuring out the errors even harder since the line numbers would be all wonky in traces.

sorry you're saddled with that legacy of well intention and poor execution.

Not enough.

The compilation step, and the resulting binary, is also very useful if you need to distribute your software. As opposed to creating a ZIP file.

There are tools for creating stand-alone executables from PHP source code, but they're not as nice to use, compared to languages that were designed for this. By distributing software I also mean making your latest code live in prod.

I suppose the benefit of using PHP (or other interpreted languages) is that it's easier to create "plugins", just copy the new source files to the server.

Correct. I had a use case where I needed to run an app on 30,000+ servers and the app would be updated regularly with new features. I wasn't going to use PHP for that because it would involve not only copying the PHP binary around (and maintaining that version), but also my own app code. golang ended up being a perfect solution because I could cut the binary down to about 3-4 megs with compression and build flags. More importantly, it was just one thing to install and maintain.

PHP has a way to compile entire applications into single files, for what it's worth. You can compile it all in your CI/CD and then push the PHAR file to all the servers (instead of the thousands of regular files). I don't know if it accomplishes everything you're after, but it's been a PHP feature for over a decade. https://www.php.net/manual/en/intro.phar.php

As the op said: "There are tools for creating stand-alone executables from PHP source code, but they're not as nice to use, compared to languages that were designed for this."

It’s cool to see PHP getting its second heyday once again. It’s currently a perfect storm of two communities starting to notice PHP. From the JavaScript side, people are comparing React with PHP, and on the bootstrapped start up side, people are talking about just using a single index.php file for your entire product without dealing with a complex tech stack as inspired by Pieter Levels.

> It’s cool to see PHP getting its second heyday once again. It’s currently a perfect storm of two communities starting to notice PHP.

Really? I see no evidence that this is happening

The Frontend / server less / JS ecosystem craziness and high rate of change has left a lot of devs disenchanted.

High profile posts over bundlers, tailwind, and microservices set the scene.

A few popular people on Twitter have been talking about Laravel which has influenced other devs.

Wind is in Laravel's sails, not php's

PHP has never been replaced as the dominant scripting language for the web.

Almost every PHP site also uses JavaScript so I'd say not

awestroke asked for evidence, but your long comment provided none

"500,000 orders per month"

That's like, what, 12 orders per minute? Is this meant to be impressive or something? I bet any language run on a modern laptop can handle that.

I thought the same thing. PHP is a fine tool but that is not a value add statement. The code can "handle" anything, it's the underlying OS and related systems that limit the load.

Or smartphone.

"when hosted on a $6/month server"

Dropping half a sentence will often make it sound goofy, yes.

The point being made is "you don't need a massive K8s infrastructure to handle hundreds of thousands of orders a month". Most people don't; https://www.joelonsoftware.com/2001/04/21/dont-let-architect... is an oldie but a goodie on the subject.

> "you don't need a massive K8s infrastructure to handle hundreds of thousands of orders a month"

This is true of many languages that are slower and faster than PHP. It's not useful as evidence of PHP being a better choice for anyone.

It's not an argument of "this is the absolute best possible choice".

It's an argument that raw language performance in this sort of context isn't going to be the problem for 99.9% of people developing code. If you have 500k orders a month, you can afford more than $6/month in hosting.

I sometimes see folks post on StackOverflow trying to micro-optimize things like string concatenation or single versus double quotes that make perhaps a second of CPU difference in a million executions. The point is directed at those folks; the ones who are thinking "language X is faster, and for that reason alone I should use that instead".

That was a bad way to make the point, because you could serve five orders of magnitude higher with PHP, or node or go or python or pretty much any language right now.

On top of that, You don't need massive k8s infra for any other framework either, so it isn't really a selling point for PHP itself.

Boasting about 0.2 requests per second, even on a minimally spec'd VPS, is damning with faint praise.

An "order" would involve far more requests than just one however...

> "when hosted on a $6/month server"

So with hardware specs better than the Chinese laptop I bought second-hand for 150 EUR (which has a Celeron J CPU), the very same one that can serve 2000 req/s on Elixir and 5000 req/s with Rust, then?

Sure, waiting on the DB is often 95% or more of the request, I get it, but 0.2 requests per second (which is the 500K orders per month when you do the math) is nothing to brag about regardless of which language or DB are being used.

It's even below the level of having a bash script doing the heavy lifting.

Unpopular opinion: If you use k8s mostly for scaling, you're using it for the wrong reasons.

Also the numbers are still irrelevant for the server because if you do 500k orders a month you owe it to the users to respond faster than 1s and also be highly available (just take 3 servers somewhere idc about anything else)

For every request that generates an order, there are probably a dozen or more requests that doesn't generate any order. Also, OS these days are so bloated a $6 vps will barely has any memory left on startup before you actually run any workload on it.

try a nanode from linode. $5/mo and as bare-bones as they come. no bloat there.

A $5 linode with debian 11 has like 950mb usable on boot?

I am an erstwhile PHP apologist. Having come back to PHP after a long time away (not really by choice), I can confirm that the language has improved significantly since PHP5. PSR was a huge success in a lot of ways. However there are still a few things that prevent it from being my language of choice.

First off, there is a surprising number of core behaviors you'd expect from a modern web application that there isn't a clear go-to for in the PHP world. Does anyone know of a well maintained library for publishing and consuming AMQP messages asynchronously?

PHP is still limited by living inside of the context of the request. This has an effect on certain types of application-layer caching, and makes for a poor model for backend scripting.

You also still need to interact with multiple layers of dependency management -- from os packages to pear packages to composer libraries. Configuration can be messy, and many projects still aren't containerized.

Finally, while the language has evolved, many of the projects that use it have not. The longer lived the PHP project, the more likely you are to encounter the exact paradigms that make it so hard to work with. Other languages have benefitted from a much greater percentage of their lifespan being supported by ecosystems that encouraged keeping your dependencies and the parts of your code that exercise them up to date.

That being said, it's great to see that there is a path for starting new projects with a modern framework. But I would have said the same thing about Zend or Symfony, and those seem to have fallen off for reasons I don't know.

Async Messaging: https://symfony.com/doc/current/messenger.html#transports-as...

Some of your complaints are a little weird. * The OS package/pear package thing is highly dependent on what language features you want to add to the base language. If you want, you can install all those features with pear. It's just easier to install with OS packages. * Composer used to add libraries to your code base * The fact that "many projects still aren't containerized" has nothing to do with PHP. I doubt there are many languages where that statement isn't true. * No idea why you think Symfony has fallen off. Laravel has large chunks of Symfony code inside it and the project is going strong with regular releases.

> It can handle more than 500,000 orders per month

How many seconds in a month? 60 * 60 * 24 * 28 = 2,419,200.

So basically, its performance is at least 0.2 requests a second...

Yeah...

OTOH it makes a point that it solves a real problem. A business processing 500k orders a month is not trivial.

I know it's just meaningless numbers, but our php backend handles 10 orders per second peak. And obviously a order requires many more requests than just 1.

Realistically, and speaking from professional experience of over a decade, "creating an order" can be one of the most complex tasks your frontend part (as opposed to admin/cronjobs parts) of the web app is going to do. It is not a rare thing to see dozens of records in a dozen of tables being created/updated at order creation time. All of these "order creation" examples are super naive. Once you develop for a shop that operates in $10M+/year range (i.e. there was probably time and money to bloat all the user/cart/stock/warehouse/sales/dispatch/marketing operations and metadata), god forbid a shop that has lots of legacy code and data structures, you will be fine with anything around 1s at order creation.

(Not that I want to defend Laravel's speed, it's not really anything to brag about, and the typical "cache everyhing everywhere all the time" aswer is not that useful.)

I have a client that handle peaks of 7k requests/s using php-fpm + nginx + MySQL. Using their own custom framework in PHP.

It all sits in a single 5 year old machine with 8 cores and 16GB RAM. Their bottleneck is actually MySQL but they have room to spare so no need for upgrades right now.

While 500k order does not sound as much - you have to remember an order != a request.

Not to mention that as long as you have a direct sync query to a database - your code will have to wait, lol.

I help with an open studio event. We maxed out last weekend at about 350 visitors per minute (about 30%Wordpress and 70%custom php symfony pages) on shared hosting. We have a cdn helping with images and such.

They’re not wrong… PHP7+ is blazing fast, has a huge library, gradual typing support, etc.

If starting a new project in the space where they all “compete”, I would choose PHP7 or PHP8 with Laravel or Symfony (or maybe even WordPress) over Rails, Django and probably over NodeJS.

You lost me at WordPress haha...

Ive a lot of love for WP, but I don't really get the appeal of extending it past blogging... if you're doing anything more complicated it's pretty trivial to implement blogging functions in your site.

The days of WordPress being used for only blogging are long gone. I have many, many multimillion dollar clients using it as the hub for their whole company (none of which have blogs). It's crazy how it just...works. A little PHP-FPM tweaks here, a couple NGINX tweaks there, and you're off to the races. Very little maintenance, almost no downtime ever.

You are probably the cleanest WP + PHP developer in history, who contrary to the messed up ecosystem of WP plugins has clean coding style that puts everyone else in the WP ecosystem to shame then, or those multimillion dollar companies don't actually need that much functionality on their sites.

Even the data structures in a default WP setup, making everything as post types is silly for anything not a blog and I wouldn't build anything on top of that ever again. Most of the examples (all I ever saw?) for themes are silly, because they use concattenation for HTML templating, instead of composition. Not long and a theme will become messy, unless one is very vigilant, but then code reuse inside the same theme obviously suffers.

Basically the whole ecosystem is full of anti patterns that one would avoid usually, but that somehow have become the tutorial samctified way to do things in WP.

> You are probably the cleanest WP + PHP developer in history, who contrary to the messed up ecosystem of WP plugins has clean coding style that puts everyone else in the WP ecosystem to shame then

When you give people the power to do anything and dozens, or even hundreds of millions of people start doing anything and everything they can think of, many will create major messes. That happens with anything that becomes extremely widely used.

> or those multimillion dollar companies don't actually need that much functionality on their sites.

The WP world is so big that it has its own specializations and their subspecializations. You cant imagine what kind of complexity is involved in such systems and the variety of the problems that are being solved.

What WP does is to solve the problem of launching, running and maintaining A LOT of things right out of the bat, allowing you to build even more complex things. There are widely used plugins for many things ranging from using replicated databases to launching full fledged software/app store websites. The enterprise WP world builds on it instead of rejecting what others already built and are maintaining.

WP runs 50% of all the websites at the moment. 30% of all ecommerce websites. And 'website' means anything ranging from the sites of CNN, Reuters to the $5 florist shop site a flower shop owner in Oregon just launched without knowing anything about programming...

It works. That's whats important.

No doubt you're right, but the "just works" part kinda just seems like it's to be attributed to the LEMP stack no?

I just wonder if a lot of these shops would be better off starting from something like OctoberCMS or all the Laravel add-ons like Nova or Spark which give you Admin and Billing UIs pretty instantly?

wp's appeal is the admin/cms backend which can be used by nearly anyone. it can also be deployed nearly anywhere, easily.

there is something to be said about the huge installed base of WP. one radical new plugin that is not deterred by the "blogging" typecasting can change the world.

Not gonna bash PHP, but WP... never again.

My experience with WordPress has been broadly positive under certain use cases. What were the negatives you saw/issues you ran into?

I've had enough problems with WP installs that I won't ever touch it again and I don't even want to list specific issues, but it's all about quality. So for a while it has been the same story, over and over:

    - non technical someone wants a CMS
    - I tell them I'll build them what they need, then give them a quote
    - non technical someone doesn't like my quote and installs Wordpress and a gazillion shiny plugins, because "it's easy with the shiny admin panel and I can install it anywhere for cheap and all the functionality is already covered in plugins"
    - things break, because plugins are meh
    - things go real bad, security issues, loss of data, shitty performance, the whole piñata
    - non technical someone cries over the phone "can you fix my website ???"
    - I won't fix their website because I like to build things, not clean up someone else's mess. Feel free to fill that business opportunity but I want to do something else.

Laravel is probably the top reason why I moved away from PHP to Go. I find it frustrating to have to learn custom DSL and custom syntax to do basic stuff. Which then of course if you learn is going to be useful until the next major version of the framework, at which point you will have to re-learn everything over again. I like how I can just know the Go standard library go into dozens of different projects and still being able to contribute because there are no custom frameworks and DSLs.

I think its a great reminder to code with whatever you feel comfortable. For example, my last project I did in Centos/Apache/PHP5/Code Igniter 3.1 with some WASP for protection I did for 12 years and sold few months ago. It checks out against Qualys Server test and ImmuniWeb very well. I sold it for close to $10MM with annual revenues of $1.6MM. The last question the new owner asked me was "what did you program it with?". They mostly want bunch of boring excel spreadsheets seeing where I am, how the sales are sustained, and how do I believe it can grow. On the final day, their IT guy showed up. He looked in silence through 45 minutes of my code's presentation, which is very much mix of OO and not OO, and his only words were "I don't like frameworks if that was me I would start the whole thing from scratch".

So you never know what or whom you gonna get, but the bottom line is if you have sales and revenues and keep tabs on spending, they will come, and they will not care less about your fancy framework or newest code implementations.

TLDR: code in whatever you feel comfortable but always consider security as top priority (not speed) because in production your code's/setup security mistakes can cost you serious legal troubles.

Gotta love engineers. 45 minutes of reading 12 years of someone’s work and the first thing they say is “yeah I’d rewrite it”.

Every. Dang. Engineer. It’s crazy.

I try to work in a codebase for 3-6 months before coming to any wild conclusions. Usually you find that there’s some warts but it does the job and there’s complexity that was solved that you hadn’t originally noticed, and it’s not worth rewriting it just needs some love in some areas.

People hate reading other peoples code.

A clean rewrite is almost always going to produce better code than what already exists in a project that has grown organically.

The current project has had numerous iterations on requirements over the years, changes in project leadership, paradigm fads come and go, and all that time accumulating cruft and layers. Looking at it at a single moment in time, you have a fixed set of current requirements where all the discovery has already been done, plus whatever your current knowledge of future requirements is, possibly none of which may have existed when the original code was written.

That doesn't mean that everyone is going to sit around on their thumbs patiently waiting for you to rewrite it to be perfect. The more lines of code there are, the more time it will take, and the more hidden features that nobody really remembers exist but are still crucial will crop up.

Few situations are actually best served by a full rewrite, but almost every project would be better off if the world could stand still long enough for it to happen.

Ideally, you want people deeply familiar with the original codebase doing the rewrite.

What usually happens instead is that the rewrite happens because the original code has been handed off to a new set of people. They're not deeply familiar with the code. It's confusing to them. It's not obvious why things have been done in a specific way. And so they decide rewriting it from scratch is the better option.

Unfortunately, they're not in the best position to come up with a solution that incorporates the right lessons from the original design.

a rewrite from scratch is a pipe dream for almost everything bigger than "hello world".

just ask WordPerfect.

any kind of home grown business app will have corner cases and requirements spaghetti that would take much more time to figure out than to write actual code.

and if the person asking you to do a rewrite just shrugs when you ask "where is the test suite?" walk away asap.

I was expecting something about Go.

Same, didn't see anything that was remotely Go other than a generic http handler written in PHP. The other part about handling 500,000 orders a month on a $6/host isn't very impressive. You can do orders of magnitude more with just PHP. You can do that in a minute with Go.

turns out "go" is also a verb.

Thus is why I wish titles quoted names, at least where is there is any possibility of confusion

Not sure how quotes would help?

If referring to the go programming language, the title should say "golang with PHP"

There is no other way to disambiguate one of the most commonly used English verb from the obscure (in relative terms) programming language.

Those of us who program in Go are always looking at the word “go” in that lens. Our mistake.

> Go with "PHP"

And articles referring to Golang could read

> Go with "Go"

That's why I say "golang".

Me too. Some kind of weird Frankenstein of Go mixed with PHP.

You mean FrankenPHP? The Modern Php App Server, written in Go.

https://frankenphp.dev/

Also Roadrunner https://roadrunner.dev/

I built and maintained open source frameworks in both. I left PHP for Go.

1. with http://sqlc.dev I don't have to write ORM or model code anymore. Define all your SQL in an easy to audit file and all your models and interfaces are generated for you.

2. with http://goa.design I can have well-documented OpenAPI API's that any team can generate a client for in any language. It also generates the HTTP JSON and gRPC clients/servers for me so I can focus on my logic.

3. with https://github.com/99designs/gqlgen I can define GraphQL revolvers that play well with sqlc (any RDBMS) or I can use a key-value store.

4. speaking of key-value stores, Go allows them to be embedded! Even SQLite now has the https://litestream.io/ project to make it super simple to use a durable, always backed-up SQLite database even in a serverless context.

Go is faster, uses less memory, uses types, has built-in formatting, package management, benchmarking and testing. Go supports multiple cores in the same process, and has really-well designed stdlib without all the bugs I used to face trying to use the PHP stdlib.

After writing millions of lines of PHP for years, there is nothing I miss anymore. Laravel still wants me to write models, controllers and views by hand and make all the client changes as by-hand code refactors.

Go lets me focus on the actual logic instead of waste my time in PHP writing all the implementation details like controller requests handlers, db fetching logic, and input validation.

It sounds like you haven't touched PHP in a very long time. Your comment reads like a 2015 forum complaint - which, to your credit, certainly would have been all valid points 8 years ago.

The language has evolved since. The ecosystem has evolved since. Most of the things you're complaining about are solved paradigms that no one does manually anymore unless they're trying to drastically improve on ecosystem tooling.

Even your complaints about Laravel are solved by open source tooling in its own ecosystem.

Nothing about your preferences are really unique to go - most, if not all of these tools exist in many popular languages.

The one solid point you have is that go lets you do many of these things by default without adding anything. To which I say: Duh. Go doesn't have a massive ecosystem of backwards compatible projects to continue supporting. It was barely used outside of niche cases until 2-3 years ago. In 10-15 years time, I'm sure people will say the same things comparing Go to a newer language.

You've made a lot of claims here without providing evidence. Care to post some links like I did?

Sure.

1. SQLC is little more than a template generator for Prepared Statements wrapped in a class. [https://www.php.net/manual/en/mysqli.quickstart.prepared-sta...]. It's not exactly a mind bending or time saving tool.

2. There are multiple OpenAPI generators for PHP, in fact, they existed from nearly the start of the OpenAPI protocol (formerly Swagger) when Go was barely a year old. Here's a current popular one: https://openapi-generator.tech/docs/generators/php/]

3. PHP also, (unsurprisingly given the origination point of the spec) has many GraphQL implementations that support any database driver over ODBC, key-value stores, or even flat files. Here's one that plugs into Laravel [https://lighthouse-php.com/]

4. PHP has many mature, modern embedded KV store options... but it's also had one in the standard lib since years before Go even existed, or the concept of KV stores was even popular. [https://www.php.net/manual/en/class.splobjectstorage.php].

On your non-numbered points...

Go and PHP are fairly similar in raw processing speed since the JIT was added to PHP. However raw number crunching is rarely realistic when most applications are going to be using databases, stores, etc. So why not look at a benchmark of popular frameworks in both languages - which shows, again that the two are fairly similar in performance. [https://www.techempower.com/benchmarks/#section=data-r21&l=z...]

PHP has also had types for about 4 years now. It's not statically typed, but that's a preference, not a pro/con situation.

Built-in formatting is also a preference, not a pro/con situation. Many developers strongly dislike languages like Go and Python for this.

PHP has had one of the most powerful and useful package management ecosystems in the entire open source world since composer mostly replaced PEAR nearly a decade ago. It also has mature and well loved testing tooling. Neither of which are built in, because why would you need to build in tools that the community already creates and maintains for free?

I don't know what "bugs" you faced in the PHP stdlib, but I will concede that it is painful to use. Most of the stdlib is little more than a wrapper around C functions of the same name, and they inherit the frustration of using those C functions.

Laravel does allow you to write things by hand. You can also just define them ahead of time and have the Migrations, Models, Controllers, Views, Transformers and more generated for you automatically. [https://blueprint.laravelshift.com/]

There you go, there's your links. But frankly, you didn't need them. There's little you mentioned that's unique to Go at all, you just named a bunch of things that have become popular tools for most modern languages still being actively developed. I'm not sure why you think any of these things are Go-specific - some of them are maintained by the Go core team, like other newer languages have started doing, but that's it.

Also: lets not forget one very important and under-rated side-effect of PHP -- it lets you write server-side code that can leverage a 'public' address. You might think 'well, doesn't everything let me do that?' Not quite. On 'free' VPS servers they usually have 'ephemeral' IPs or IPs that change. So while you get free bandwidth and compute -- it's hard to actually do anything useful with it like run a service if you don't have a public address. With PHP it's assumed it will be accessed from the web so if you run it on free shared hosting you get that accessibility built in.

PHP is very good for writing services that cost literally nothing because you can run it on free hosts like 000webhost that give you everything you need to host complex services (upload, database, sub-domains, and more.) It's perfect for budget devs or maybe devs that want to make their infrastructure more resilient to ah... financial upsets...

Being able to host for free on dodgy free hosting is hardly a benefit anyone should care about.

You can throw it into lambda or vercel for that matter too. Yes you can use sketchy hosts but still can use legit ones too to host for free or very little money.

You can throw basically anything on lambda. That’s hardly a feature of php

Might be useful for teenagers / people with no disposable income to start trying web related stuff from a public library.

Maybe? That’s still not a super great selling point for a language.

When I was a teenager I used to host sites on an old android tablet. These days if you have a credit card, you can make use of the free plans most platforms have and free credit, especially if you have an .edu email.

PHP 8+ is filling-in a lot of the missing features -- type hints, attributes, named parameters, etc.

Nowadays instead of using 'string_you_have_to_remember_and_might_mistype' or abusing associative arrays as in the given code sample, you can usually get full code completion luxury with PHP without magic comments or other workarounds.

PHP 8 is still missing a few critical features such as generics and typed resource handles, and nikic left the project, but I'm still hopeful PHP 9 will deliver on those key additions.

Learned Python a few years back; after being a long time php dev. The named parameters and the *parameter expansion felt so nice in Python and it irked me that we didn't have that in php. Feels good that it is finally coming ^^

If you're looking for a great CMS and were bitten by WordPress back in the day, you should take a look at Statamic (https://statamic.com)

It's a Laravel package and it's the best CMS I've ever used (from a dev perspective). v4 just dropped the other day

PHP has a lot of top tier CMSes. IMHO bunch of them are even better than Statamic. Craft CMS (https://craftcms.com/) is a lot more mature database based CMS. Kirby (https://getkirby.com/) is better at flat-file and has a lot better admin interface. Twill (https://twillcms.com/) is better integrated in Laravel and is fully open-source. Statamic mostly feels like it's sitting besides Laravel and they call themselves Laravel based for marketing.

You're absolutely right! PHP is blessed (or maybe cursed, depeding on your perspective) for that.

I believe Craft and Statamic share a root in ExpressionEngine, which I loved also. I've only used Craft a little bit, for me the biggest issue is that it is (or was when I last looked) built on Yii, which isn't my go-to framework in PHP.

This is in no way a showstopper.

I haven't used Kirby, but it looks like a completely stand-alone application so I'm going to miss being able to co-locate the rest of my application there with the full toolset of the framework behind, which for small sites I really appreciate about Laravel+Statamic having right out of the gate.

I've also not used Twill, but it looks to be similar to Statamic (as it's also a package). Not sure how this can be more open source than Statamic tho... if you mean free as in price, I'm all for paying for great products to make sure the teams behind them can keep on churning out great work. I'm sure AREA 17 will keep supporting Twill for a long time to come, but it doesn't look to be the focus of their business.

I'm also intrigued to know what you mean by "better at flat-file".

UX of the admin interfaces is kinda subjective and less of a concern from a dev perspective (though it's still an important consideration if you're trying to pick the right tool for a client or another team!)

> they call themselves Laravel based for marketing

Same goes for Twill :) nothing wrong with hanging onto the coattails of a popular piece of tech

AFAIK Statamic wasn't built on Laravel at all in the beginning. I believe Jack adopted it because it was clearly a great stack to build on top of. I think he made a great choice and I'm glad of it.

Statamic, Kirby, Craft are all commercial products and not free licensed (as in freedom). Twill is only one that's Apache License 2.0. I agree this is both blessing and curse and for products like this is much safer to get the commercial product that has safer future. But for example if you wanted to start small CRUD SAAS based around CMS it would be feasible to do only with Twill.

I don't think it's a good idea to have your product and your presentation website in one app so for me it's not a feature. They should really be separate concerns.

I haven't used Statamic 4 yet but last time i've used it they didn't seem to use much from the Laravel. It basically publishes routes to Laravel from their own system and that's it. It even recommended it's own templating language Antlers. It just feels they want to really ride the Laravel wagon while still being just separate system. Thats OK but Twill for example really depends on Laravel and feels more deeply integrated with it.

Craft is good simply because it leverages database powers well and it's super mature. Things like relations and search are a lot harder in flat-file systems. Twill does this OK. Flat-file systems generally have ways to use database but it's more work. I would pick Craft for sites where having DB is more advantageous than flat-file.

Kirby is kinda it's own thing. It's oldest and mature, simple, steady but modern. It tries to have as little abstraction as possible. Opposite philosophy to all Laravel magic. It's kinda edgy and zen because of that. The advantage of less code and dependencies - it's super fast and easy to read source code. Not that it would matter in a CMS. Kirby embraces flat-file as kind of nosql database. For example every page has unique identifier that is indexed an can be referenced anywhere. I don't know about CMS that does that out of the box. And Kirby admin interface is also pretty different because it has no preset ways. When you install it it's empty - you have to completely define it. This can be huge advantage or more work for developer depending on what you do. It's more like build your own CMS package than CMS.

Statamic has inspired lots of their features/implementation on Kirby and for years played catch up. Nowdays they are all very feature rich so it's more matter of taste (and price). Statamic has one really nice advantage and that's GUI blueprint builder. If you hate writing YAML to define admin area (which both Kirby and Statamic need) with Statamic you don't have to.

WordPress is not your grandmas CMS anymore, its a full fledged framework and very secure.

That PHP code right there at the very top of the page that is supposed to be representative of how great it is has multiple TOCTOU authorization and validation bugs. In fact, nearly every piece of code on that entire page is riddled with transactional bugs

If you may, could you point out what are the TOCTOU bugs you have mentioned?

Everything between checking if the user can "place-order", and then validating the inputs, and then finally creating the order.

I don't think the request object can be modified by the end user or that it is modified by the server at that point. If my belief is correct, does this code still contain TOCTOU bugs?

It's the underlying state of the database that will change between these different checks. Not the end-user modifying the request object, which is in PHP memory

Thanks for explaining it.

Do you mind elaborating? I can see how the user's ability to 'place-order' might be rejected between the access check and the order creation but that would be an extraordinary edge-case that does not need to be accounted for in 99% of applications.

If you're developing an application that needs to account for such an edge case you could easily do so with an insert w/ join method on the Order model. The author isn't trying to show that the code is bulletproof for every scenario.

That's really the point. The code is deceptively simple for a whiz-bang "look how easy this is!" kinda presentation but the reality is that it's not useful for anything but a toy web store. Maybe it's fine that it only works 99% of the time if you're just trading Pokemon points, but not when you're dealing with people's money.

I'd argue that a vast majority of web applications are not "dealing with people's money" so there's not a need to code for such cases.

The right tool for the right job, etc. etc.

I'd argue being able to stop worrying about your code after writing it and not making decisions like these is a good enough reason to just do it right. Especially when it's not much more additional work

https://jacobian.org/2022/sep/9/quality-is-systemic/

Why would you go with PHP+whateverframework instead of Ruby on Rails or Django?

I haven't touched PHP since 5th version and I'm kind of sceptical it can offer anything RoR can't.

PHP 8 is a vast improvement over PHP 5. Also, the frameworks have become much better - I especially love the Yii framework as well as the Codeigniter framework if you are looking at a Rails replacement.

I'm a Go dev these days and rather looking into TS and Rust.

I was just curious to be honest. With RoR being what it is PHP frameworks has to offer something on the same level (at least) to be of any interest (as a I see it). Not to mention ecosystem\packages\gems\etc.

It is ridiculously easy to setup a full CRUD environment in frameworks such as Yii. It is as simple and selecting some options on a screen and then clicking on a button. The example below is from 7 years ago!

https://www.youtube.com/watch?v=Xi0gH2izUy0

I don't know why you are being downvoted, this is a very legitimate question. These server-side frameworks are all alive and kicking and very competitive. When some other smaller ecosystem comes up with a good idea (like elixir/phoenix) there is a rush to replicate which happens rather fast.

I think in the end the competition will lead to specialization. Python will almost certainly capitalize on its data science / ML links but its not clear (to me at least) how php and ruby will differentiate themselves.

Rails console, metaprogramming, elegant blocks, procs & lambdas, Turbo/Hotwire. Concise Ruby language vs PHP framework code with hideous inlined fully-qualified method paths.

all of that pretty much is available and arguably much better in Elixir/Phoenix

OP was comparing Ruby and PHP.

Use the right tool for the right job. I always use plain PHP for all those things I want to keep running forever without having to spend time and brain space to maintain. You can't beat putting a file on a LAMP server and forget it's running. I have tons of public endpoint that do all sort of stuff , aren't core to my business and don't want to deal with the operation hassle that would come to keep such framework working and running in the long run.

Just a few examples of such PHP script:

1. an endpoint that is being called by my CI to send messages on IRC and telegram when a new build is ready

2. the analytics bit of my project so I know who does what without relying on google analytics but by storing all that stuff in a mysql db. It's under 25 lines of PHP code and has worked a lot better for me than any analytics tools I've tried: https://gist.githubusercontent.com/mickael-kerjean/289d3d0be...

3. the target of the contact me form of my project

4. all the webhooks and other simple marketing automation stuff I need to process one way or another

5. all sort of online tools relevant to my niche to boost the SEO side of my OSS project

6. my status page which is an array of url I look after that is being curl around

7. crud cloud instance of my OSS project

and many many more examples, got about a hundred random stuff running from a single cheapo VPS I don't have to maintain.

Sounds like a scripted and slower (not trying to diminish) version of Go.

But when he wants to add a feature he doesn't have to create a new microservice and a systemd file and a watchdog and setup the reverse proxy, all things needed for a go endpoint.

He just drops a PHP file in a folder and be done with it, it just works.

You don't have to create a new (micro-)service, you can just add new functions to an existing one.

> it just works.

Are you trying to tell me that modern PHP is so cool it does not require LAMP or whatever? I highly doubt it.

You still need and use all the same stack, except you don't have to install thigs separately I guess.

A great many good things that I still use on a daily basis are written in php. Roundcube and Nextcloud for starters.

Some of the most fun I ever had writing basic CRUD apps and simple interactive websites was in PHP and Codeigniter back in the day. I'm pretty much Team Python now just because of the huge ecosystem but maybe it's time to give PHP another chance...

I see no argument at all for using Laravel over Django or Rails.

PHP was always a mess. Why would I want to come back to it now on the off chance they don't screw things up again?

Exactly.

array_filter and array_map, have different order of arguments.

($array, $callback) vs ($callback, $array)

A small example of how inconsistent the language is from the ground up.

Most people can explain their respective web servers, but I've never heard anyone even come close to what PHP/Laravel is actually "doing".

Side Complaint: If you are working with Laravel Queue, it is such a hassle to reload your code changes when developing.

So what's the programming language that's 100% consistent? For example Python isn't.

Ruby, Clojure, Go, Kotlin, Rust.

I doubt any language is at 100% but from my work with them Elixir, Golang and Rust are predictable and a joy to use. I don't remember the last time their API has surprised me.

Perfect is the enemy of good. There are many languages much more consistent than PHP.

Yeah, but these things exist across languages. Laravel has collection methods that fix that and they can be used in any php project too.

https://laravel.com/docs/10.x/collections#available-methods

I used to refresh nettuts.com obsessively in high-school and Jeffrey Way's PHP content was the highlight.

Sadly the site got a refresh ages ago and is nothing like it used to be.

Anyway, if you're reading this thread, thanks Jeff!

I too learnt webdev with Jeffrey back in the jQuery days of 2011 - I subscribed to laracasts at the start of the year (primarly to evaluate Laravael for work) and was delighted to see that he runs the site - he's like the Bob Ross of webdev.

> It can handle more than 500,000 orders per month when hosted on a $6/month server

Is this a statement from the real world? What business sells 500,000 orders in a month from a $6 server? I mean, if you sell that much, you would probably want a high-availability solution and they don't sell for 6 bucks.

The message seems to be targeted at the „webscale“ folks. Something like: Look, one 6$/month server can do more than you ever need. You don‘t need {complicated stack}.

Just use two 6$/month servers.

> It can handle more than 500,000 orders per month

Hilarious because other languages are capable of that per minute not per month

500,000 orders per minute on a $6/month server? Which language is able to achieve that?

If you're going to pull numbers out of a hat at least provide some evidence, especially evidence based on a comparable workload.

I actually wrote a whole article about this myself: https://alicegg.tech/2023/02/06/4dollar-vps.html

TL;DR: go can handle 1000+ RPS on a ridiculously small server

But creating an order isn't just a request. PHP will also handle 1000 RPS of hello world just fine on a 4 dollars VPS.

Maybe (probably) Go is still faster than PHP, but the hyperbole is being pushed a bit too far here.

And what about the database?

I think the point was the $6/month server here.

What stack can handle 500,000 orders per minute - 22.3 billion a month - on a $6/month server?

Most of them? 500k per minute is around 8k reqs/sec. $6 will get you 2 vCPU, so each CPU only needs to handle 4k requests per second.

I'd at least expect that to be possible in Node, and would be somewhat surprised if a Go or Rust framework didn't hit that mark.

Maybe with "Hello world" in Node but not orders. Business-grade Rust web framework? Give me a break.

I think 4k requests per second is quite ambitious even for native languages or garbage collected languages like Go.

Hello world will work, but once parsing, validation, and database queries get involved, you'll need some beefier hardware to get those numbers.

I can't get the cloud benchmarks for 2022 to work (a dedicated PowerEdge is the standard physical benchmark and that's not very realistic here), but according to these benchmarks: https://www.techempower.com/benchmarks/#section=data-r20&hw=... you're going to need some very optimized code to get close to 8k reqs/s.

OK, 10 minutes then ;)

My point was that the article quotes orders per month, while other systems are quoting requests per second. I found it funny that they tried to mask the low speed by using big numbers.

on a $6/month server. Are we also losing the ability to read now because of AI?

There's 2 things to separate here:

1. PHP the language and developer experience (frameworks, tools, community, docs, etc)

2. PHP performance at scale

In my experience, PHP is much improved for 1. and fine to work with. Laravel and composer are great.

For 2. I would never use PHP on anything above a few hundred requests a second. It's slow on its own, but more importantly it's blocking IO model will grind things to a halt at any level of concurrency when talking out to database, caches, or other services. You are also vulnerable to issues like saturating your database with connections due the programming model in php-fpm. I know async php exists but my impression is the mainstream frameworks dont support it (I could be wrong?) so why not just switch language at that point. I speak from experience of scaling a Laravel php app up 5k RPS+ and needing a LOT of EC2 instances to do it. Using Go was a revelation and delivered a 10x improvement in terms of resources required to serve the same number of requests.

So yes, if your rps < 500, why not, PHP is fine. For anything above that, it's a not a great choice.

(And defining your scale in terms of orders per month is a bit silly)

Weird that you get down-voted but I lose more and more respect for HN these days so I can only say I am not surprised that a common-sense post was given the gray treatment.

I have the same experience as you, I've participated in migrating from PHP to JS, to Elixir, and to Golang. The transition to JS was mostly a performance disaster (not much performance was gained) but at least more devs could help so it was still a big win organization-wise, whereas the transitions to Elixir and Golang were a screaming success on every front: we immediately gained anywhere from 7x to 25x more req/s and the DB load was stable and the request timeout errors dropped by 97.9% on the first day (and were completely eliminated a week later), not to mention the cost of our hosting also dropped by at least 70%.

I am past my phase of "hating" languages but honestly, saying "PHP is not the right tool for jobs X and Y" is a "hate" in the eyes of many anyway. And yeah it's not good enough for big scale. I mean, if you make $1M a month then you likely don't care much if you pay $50K in hosting, sure, but why do you have to spend 5% of your revenue on hosting? There are a lot of modern technologies with which you'd be hard-pressed to justify having more than 2 application servers and 1 DB server (with read-only backups and replicas if sh_t hits the fan).

Thanks, I was confused with the downvotes as I was just relaying the facts of my experience!

Good to hear someone else has had a similar experience. Nothing against PHP at all, but it's definitely not suited for scale.

I think I'll stick with rails if I want cute DSLs and lots of magic ("… broadcast an event to update the frontend in real time …"). But sure, it's great that php has come a long way since php3.

That aside:

> It can handle more than 500,000 orders per month when hosted on a $6/month server.

Surely it can do more than 700 orders per hour, 1 order every 5 seconds?

> The only additional fees are for a CDN (if you want your assets to be served faster) and a domain name

Uh, so no managed database, but you recommend paying for a CDN before slapping Varnish in front of your static assets?

I get that php might be eminently usable at this point - but this seems like an odd pitch.

I've been using Laravel for the past year at work, not a hater type but still find it meh even with all the improvements.

I too was a junior that was plagued by wordpress and php custom plugins, never again will I touch this language if I can.

I agree with the message, but the example has:

- hidden global state

- arbitrary string literals

Is that Laravel?

It's been a long time since I had to deal with Laravel, but that code snippet looks very similar to the Laravel version I had to work with ~6 years ago.

I hated it (Laravel) for those reasons, along with the madness that was the DI container. Guess I'm just not "web artisan" enough.

The other day I finished a side gig I was doing - a Wordpress site recreated using the Wayback Machine - the site went down a while ago and the admin stopped answering phone calls, not to mention emails.

It was a largely pleasant experience, taking me back to my early years as a "web developer". I had to modify some PHP files because the theme used didn't offer slots for widgets in places I wanted it to.

That being said uncached the site takes over 20 seconds to render. CPU load wasn't high so I can't help but wonder what was it doing all this time.

I’d had a site in a similar state, and I did figure out what it was doing.

Client had launched a product that was a bit more successful than typical. Nobody could access the site though. I dig around a little, come to find a neat little snippet of template looking for a featured user for some markup.

The genius who set this up iterated through each record trying to find the featured item. One query at a time, testing each record in the application for the flag.

Php is fine, some very inexperienced “developers” use it though so you find a lot of gems like that in the space.

Any programmers here who've used PHP to build command line tools in PHP? What is the experience like compared to, let's say Python or node.js? How good are the facilities? What are the limitations?

I have rewritten more-or-less the same tool, 100KLOC, in Rust and PHP. I can't tell you about Python or Node.js

Use PHP if

- you're in a hurry and you already either know PHP, or the script is going to call other PHP code you've written

- execution speed is not important (ditto for Python and Node)

If neither of the above is true, give Rust a whirl.

Symfony command is great for this https://symfony.com/doc/current/console.html

But it really depends on what you need the command for.

I use Symfony command for general things, Node.js for eg PDF generation, Python for ML, Rust for calculating Ranks/Scores

Development time is the same for all of them.

For whatever reason Node.js scripts always feel dirty to me. I can not even pinpoint why.

It's really good. Using the Symfony Console component you get sane argument and option parsing and validation (optional/required, single or array values), output styling, interactive inputs, tables etc.

If you're wanting to build a TUI I haven't seen any libraries as advanced as the Python or JS ones.

Very easy to do. Check out the getOpt function for argument parsing etc.

here's a nice goodie https://github.com/nunomaduro/termwind

I tried to write a CLI tool for orchestration by wrapping some sub-processes. I found PHP very limited in its ability to handle subprocesses (streams, error handling, signal forwarding). I tried to avoid using frameworks, but eventually used Symfony's "Process" lib. It helped with Linux but Windows support is very limited.

This experience was pretty disappointing, but also pretty niche. Overall I agree with the general sentiment that PHP is very nice to use nowadays, especially for web development.

Performance is always a good argument, but, be realistic and be honest, most applications did not need ultra fast performance and most applications did not have hundreds of parallel users.

The problem is this page advertises Laravel, not PHP. Ruby on Rails has many similar "demo worthy" snippets that make complex tasks seem readable and intuitive to the layman. Laravel and Ruby on Rails have something else in common: due to the focus on these "natural" interfaces, they compromise in every other way. Architecture, performance, testability and so on and so on.

For those who know PHP, this code is full of singletons masquerading as static classes (which Laravel incorrectly calls "Facades") which mean no isolation and clear flow of dependencies in your code. In a nutshell, every line of code you write this way comes loaded with a pound of irreducible, unfixable tech debt. Enjoy.

Making "complex tasks seem readable and intuitive to the layman" is no bad thing - besides other engineers, future you could become a 'layman' easily. Readable, expressive code is something I've come to value highly after almost 20 years

And from first-hand experience, while the specific code sample shown on this page shouldn't be treated as a practical example of how to architect a larger application, there's nothing compromised here in terms of performance or testability.

All tech is tech debt at some level or at some time - what has happened to pragmatism? Laravel has actually helped me write the most performant, tested and least-refactored code I've ever written.

Like any tool, used properly it will do its job well; simply grumbling and shooing it away does not stop it being a perfectly fine tool in the right hands.

I guess I wasn't clear enough? I said "it makes complex tasks SEEM". My point being, they SEEM SIMPLE in a DEMO. But in real application it quickly turns into a quagmire, due to the problems I already listed.

Oh look, you even say so in your own comment: "the specific code sample shown on this page shouldn't be treated as a practical example".

So... you're saying the page makes it SEEM simpler than IT IS, hmm? Is this what you were asking me about "why is it bad"? You don't think parlor tricks in demo code is a bad thing?

So what are you even objecting to here? I said something bad about Laravel, and you use Laravel, so you have to go on the offensive out of loyalty? I don't know why people need to identify so religiously with their tools. If we start picking apart this demo code, you'll probably admit that every line contains an anti-pattern you'd avoid in a real project of more than a modest size.

So what is this demo demoing then? It's essentially misleading people about what it takes to write a good app. If we'll go by simple demos alone, PHP needs no framework at all for a good demo:

    <?php
    echo "5 + 5 is: " . (5 + 5);

Boom, everyone understands this, now you can write your own Google!

This is why RoR declined and it's why PHP with Laravel and WordPress as their poster boys is declining.

PHP itself is no longer as terrible as it used to be, although all the good people seem to have left the internals. But the frameworks people use on it are terrible, incompetent and aggressively misleading people into bad practices for the sole purpose of marketing to newcomers.

    5 + 5 = <?= 5 + 5 ?>

why use echo? php _is_ html :D

I have one name for you: Symfony

More or less directly opposite of what Laravel is preaching. It's the popular choice for anything that is being build long term. It is very popular in Europe and we have a far bigger community around it than Laravel does.

Symfony made many architectural mistakes early on, including with the way they used to do injection and so on, but to their credit, the community seems curious and strives for quality, so over time it has become a very interesting project. I stay away from frameworks, in general, but the Symfony components are excellent.

> , they compromise in every other way. Architecture, performance, testability and so on and so on.

Architecture: The default structure of the app is good to start out and can be changed at any time. You are not locked into that. If you apply your fancy patterns, you can do whatever you want. It's rather a devs fault than the frameworks fault.

Performance: Guess depends on what you compare it to. Surely a rust service will be more performant, however you can scale laravel just fine if you are not writing shit code. There is enough apps built in laravel that handle more load than the average pro reddit coder will ever see.

Testability: Not sure what you mean, you can test in different ways and anything you need to test. It's fairly simply too. Yes, there are sometimes issues where you can run into memory leaks but those can be fixable after some digging.

You can but don't need to use facades, you can go full DI, you can swap the IC.

The Irreducible, unfixable tech debt is created by the developer that wrote it and does not know php or laravel. Yes, laravel makes it easy for newcomers to get right into the traps you mentioned, but then again - we are talking about junior that would not know any better and probably would fail without it.

If you use facades there's no fixing that unless you reconstruct and reweave every component in your application to pass relevant context in and out, instead of lazily reaching into globals for it.

What you call "full DI" in Laravel is still globals in disguise, because there's a single global container.

Most defense of Laravel comes from people who have no idea how to write a good app. And unfortunately, due to bad frameworks, the number of those people is multiplying. I blame Spring and RoR. So much pain came from them. Laravel is just a pale copy.

> In a nutshell, every line of code you write this way comes loaded with a pound of irreducible, unfixable tech debt.

And worst of all, you are stuck with a shitload of churn every time a new Laravel version comes out. But this is true for Rails and CakePHP and probably many others as well. At least Django seems to be moving a bit slower and not deprecating loads of features on every release.

Absolutely, having worked with Laravel I can only recommend not to use it, Symfony does a much better job.

There is also Phel (Lisp-like language that compiles to PHP).

https://phel-lang.org/

Use pretty much any language. It mostly doesn’t matter.

We are pretty much at that point. Choose the language that works best with the tools or libraries you want to use… and if there aren’t any specific requirements, use any language you want then.

The last time I used PHP was in 2004 or 2005, PHP was at version 4.something, and I did not like it. That kind of formed my opinion on the language, even though I know it's come a long way since. OTOH, I have no reason currently to take another look.

But it's nice to be reminded, I guess, PHP isn't the dumpster fire it was 18 years ago.

5 seconds per request isn't anything to shout about in 2023.

Laravel gets over 2000 requests per second in PHP 8.1

https://kinsta.com/blog/php-benchmarks/

Unless you specify the hardware and compare with the OP your claims are meaningless.

Where does this 5s/request come from? Are you misreading the word "requests" instead of the word "orders" that is in the article?

I hosted a phpBB forum as a kid in the early 2000s.

15 years later I joined a marketplace startup that was doing 10,000 transactions a day.

Built as a PHP monolith.

I was sooooo confused at first. “PHP??? That strange language I used to host a forum is powering this app??”

Turns out the founding engineer was self-taught and PHP had the most tutorials or something lol

And come check out NativePHP[1] where you can build native desktop apps using Electron or Tauri + PHP

Starting with Laravel support and launching soon

[1]: https://twitter.com/search?q=nativephp&src=typed_query

Even if you write modern strongly typed PHP and make sure to handle all your exceptions you will still encounter null (and other) errors at runtime. The language is ok these days and far faster than Python & Ruby etc but still I would not choose a new project to use it.

I don't like that in the code validation rules are applied to a "request" (and written in a controller) but not to a model. This means that if you want to create a model somewhere else, you cannot reuse validation code.

    $request->user()->orders->create($request->validated());

This looks so wrong from an architectural point of view! A request has a user (which in the context of HTTP should be more or less only an authenticated principal), which has orders, which are created from the same request, where the journey started. There is no separation of technical and business concerns.

See: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...

It's terrible indeed but Laravel pushes for this kind of "fluent" apis

I actually think this article undersells PHP, as it doesn't mention the incredible additions that PHP 8 introduces, nor does it mention excellent static analysis tools like PHPStan.

I recently rewrote a PHP web app in Rust (https://soapstone.mradford.com/riir/) and although it was interesting, I think it would have been better staying a PHP app. As nice as the Rust compiler was, I felt PHPStan would have automatically caught a similar number of bugs, all the while feeling less combative.

The problem with PHP is not that you can't write great maintainable codebases in it -- you certainly can.

The problem is how easy it makes it to write obscenely unmaintainable anti-architected code bases in it. The average PHP production code base is deeply offensive. I'm knee deep in one right now.

You can still have awful code bases in Rails or Django or Go, but the opinionated nature of those ecosystems makes the average much better than PHP.

If "PHP" were synonymous with "Laravel", that would be different. But it's not.

For me the best platform is one that's easy to debug and the debugging story for php is one of the worst. Otherwise it would still be quite hard to read. But at least it's cheap to host.

xdebug is pretty okay. PHP is single threaded, the entry point well defined, var_dump/die/echo works wonders, debugable by curl and simple php -S nowadays.

it has orders of magnitude less complexity than the JVM, or even the various Python server runtimes (gunicorn, uwsgi, etc)

at least in my experience. can you elaborate on what you see as the debug support deficiencies of PHP?

Not sure what exactly you refer to with "debugging", but I'm personally much happier with XDebug in VSCode, spamming my breakpoints and stepping through the code inside of the editor where I edit the code.

I can set breakpoints in my react app too, but it feels weird to inspect code in the browser console. And since modern frameworks get compiled for the browser, it is all even less familiar at a glance.

I'm mostly interested if this is a tiny hobby project by someone who wanted a nice example to use in arguments.

Or an advert by someone involved with Laravel/Laracasts.

As the former it's quite effective.

The latter would be funny.

There's a lot of reasons to both use or not use PHP, but of all the ecosystems I've developed in, PHP has the most lovely dev tooling.

Every popular piece of dev tooling in the PHP ecosystem feels like it was made to solve a problem, do so as simply as possible and let you know all the information as cleanly as possible.

There's contemporaries to most of those tools in every other major language, and all of them have problems or annoyances that I feel simply don't exist in PHP's tools.

I just don't get why people in php use lazy comparison when you know that "0e4"=="0e5" in php.

and yes, Laravel use lazy comparison (hundreds of times). And yes at least three bugs where caused by this use.

see: https://github.com/laravel/ideas/issues/698 for why I'm a bit grumpy with php ecosystem

Can anyone with experience in both compare modern PHP and Laravel vs modern Ruby and Rails? Which one would you choose and why, assuming you have the same experience in both?

I’m asking because I keep hearing Ruby on Rails is the best for starting a SaaS, etc but from my little experience on it, it seems to me Laravel is way better. Is it just a “language” thing? That most people prefer Ruby to PHP?

(sits quietly in the corner wishing Hack had taken off, or at least that one of the things PHP took from it was native XHP.)

Nice. I needed this today. I teach "Advanced" Web Programming and my classes start next week. I've been generally ignorant of most of the kazillion fancy Javascript frameworks and have more or less kept PHP as the base of the course. This is what more-or-less has felt right most of the time.

For "Advanced" Web Programming, I don't really feel like you're hitting the mark by sticking with PHP. Sure, it works, and will probably get the job done for most web projects any of your students will ever work on, but if you want to get people excited while making them employable, it's important to teach new tools and frameworks. Unless the "Advanced" part is more about the techniques and patterns and less about the language, I think you're doing them a disservice by not branching out. And, of course, you can teach patterns and techniques in any modern language.

I'd expect to see some discussion of async job processing and front-end web frameworks in any advanced web programming course, high-school or college level. Honestly, just teaching the usual react stack with a typical node backend would probably be ideal since JS is approachable, react is still "cool", and you still only need to use one language.

Coming from Rails, how does Laravel compares? If you know both languages, which one would you pick? I've this hunch that there's no reason to lick Laravel over Rails, since that latter is the bees and knees for web development.

Alternatively: what would you suggest someone getting into web development to learn? PHP or Ruby?

Personally Rails. From a business perspective both are fine.

> If you know both languages, which one would you pick?

The one with the best density of good developers in your hiring region if the application ends up scaling.

> Alternatively: what would you suggest someone getting into web development to learn? PHP or Ruby?

Neither. I would tell them to get into the Javascript ecosystem - not because I think it's necessarily good, but because that's where most of the work is. I'd also reccomend picking up at least one other general purpose language to be a bit more rounded such as Golang, Java, C#, Python.

I would use the PHP Yii framework - it has generation of CRUD, controllers, models etc.. and excellent customisability.

I have worked with both Laravel and Rails. I would still pick Ruby on Rails for my projects because I feel the Ruby's ecosystem is more mature than Laravel's.

Don't get me wrong –– Laravel (the framework) has some polished first party packages however, as soon as you step out to third party packages the quality drops significantly.

what this page means is: go with laravel.

wordpress is also php. dont go with php.

I thought this is a workaround showing off how they use Go lang and PHP together, fell for it!

PHP is pretty nice these days but salaries for PHP roles are terrible. I can get paid 50% more being half as productive writing Go (for no reason bc 90% of people using it don't actually need any of it's features or performance)

The fact that you can build a whole app inside just one index.php file is highly underrated and I understand how newbies finding this out are getting excited.

I remember when Rails first launched and I wanted to try it but it was so complicated to get started.

You can do that with any language using CGI.

I always dislike the "requests per month" metric because it seems like a transparent attempt to impress with a larger absolute number: 500k requests/month is 5sec per request, which feels pretty underwhelming

We are talking about 500k orders/month, not requests/month.

Placing an order from the Web will almost always involve multiple requests.

You are touting the language's ecosystem or tooling but the language itself is horrid. PHP is carried by Laravel.

Another language carried by tooling is Go. The language itself doesn't even have sum types, lmao.

No thanks. Those code examples are full of indirection and the bottom example reminds me of the object nested spaghetti mess of large PHP frameworks.

Just because code reads well doesn’t mean you can understand easily what it actually does.

There's joke amongst PHP companies that modern PHP has finally, completely become Java.

Replacing PHP/Laveral with JAVA/SpringBoot is not different at all.

Yes because PHP5+ is pseudo-Java.

We're now at Laravel 10. Take a look at the Laravel Bootcamp for a quick intro https://bootcamp.laravel.com/

> Read the following code as if it were a documentation page:

If I read this as a documentation page, this makes me scared:

`Order::create($validated + ['status' => 'pending']);`

What does it mean to add an array to something?

As someone who likes PHP that stumped me as well, I *really enjoy working with PHP 8.1, but I could not really grok the code either.

Exactly the same as the spread operator in JavaScript or even the exact same syntax in Python, but we don't hear you complaining about those, do we?

> the exact same syntax in Python

No, because the example is showing concatenation of associative arrays. In Python, you'd use a dict, and you can't do `validated + {'status': 'pending'}`:

``` >>> validated = {} >>> validated + {'status': 'pending'} Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'dict' and 'dict' ```

You can do `validated | {'status': 'pending'}` since 3.9, though. I think using union or the * operator (e.g. `{*validated, 'status': 'pending'}`) looks less weird, but if you're a PHP programmer, you already know what + does here. In the end, it becomes bikeshedding.

No complaints about the spread operator :-) But the plus in javascript produces this:

    [1,2,3] + [1,2,3]
    // '1,2,31,2,3'

(never tried this in js before; so was amused by the result)

It would be shorthand for:

`$validated = ['key' => 'value']; $validated['status'] = 'pending'; Order::create($validated);`

This could be rewritten as:

Order::create([...$validated, 'status' => 'pending']);

Ah, makes sense. Thank you.

I mean yeah as a php dev for 12 years since i've started picking up python , i find myself nowdays coding stuff in python :)

PHP has 99 problems, but shipping code ain't one

A major downside of phps model is that there is no continuously running service, so you can’t run timers or background cleanups.

Isn't it too much "string oriented"?

I see couple singletons calls in those examples. Is it considered a good practice in PHP now, or was it made to simplify the demoed code?

Maybe you mean 'static' calls?

Depends on the context but in most cases these are a convenience, syntactic sugar.

Take SendOrderToVendor::dispatch($order)->onQueue('orders'), for example.

This could also be written as:

$job = new SendOrderToVendor($order);

$job->dispatchOn('orders');

(Exact function calls may not be correct, I'm on my phone)

Functionally identical - same code path. The main gain is ergonomics, but it's entirely your choice how you prefer to write this code.

The issue isn't the exact syntax that's used to access the service object. It's the fact that any random chunk of code anywhere in the codebase can reach out to any other random piece of code. Syntactic sugar or not, that's considered to be an antipattern in pretty much any community outside of Laravel's.

Laravel calls them "Facades". And no, they're not considered good practice outside the Laravel community.

I’ve been writing PHP for over 20 years. I use it for my hosted (backend) programs.

Works a treat. It’s robust, fast as hell, easy to make secure, runs on the cheapest, crappiest hosting, and has an enormous support infrastructure.

That said, I’ve never particularly liked the language, and have never become an advanced adept at it. I use it to manage the less-glamorous part of my work. I’m mostly a native Apple developer (Swift).

As someone more familiar with js/react, is there an equivalently mature reactive frontend framework?

Laravel has inertia, livewire or alpine to get reactive/snappy frontends if you want to have an SPA. Inertia lets you use your react while not needing to write an api. Livewire drops the js completely and does the SPA-esque frontend with php, alpine is just a smol lib to make parts of the website interactive.

Generally speaking, if you use PHP to build an API, you can use react still as is.

It's one of those posts again. I have no clue what compels people to write things like this.

I have a soft spot for PHP. I love code I can write, then just refresh the page.

Okay, but you didn't mention Go at all in the article.

Jeffrey Way is a really good teacher, btw.

of course php is best, but how do u do in app(web app/browser) notification with 6$/month apache & php? for example if there are 2000 users who need to push a message to when a queue job finishes in php backend?

Laravel lets you run tasks in the background. You just queue up those notifications and then some other task you wrote will come along and start sending them. Apache isn't involved.

Thanks. My queue is done and working, but how can i make php to have websocket for thousands of devices ? I know it's javascript in the frontend and i could do some kind of timeout loop to check job status, but that's not good..

From the title, I thought someone implemented PHP in go. facepalm

Sounds like a threat TBH

In 2001 I started a PHP project and it was cool, lots of people were going that way. In 2008 folk we telling me it's a terrible security risk. In 2014 they told me it's the WORST choice. In 2023 it's cool again?

PHP malware on windows is a thing now too lol

There is a syntax error in the example shown by that article. If you must use any time to find it then you should not go with PHP.

sorry to break it to you, but symfony is much more superior and flexible than laravel.

Still a lot more to type than with Python and especially Django

Go where exactly?

The "Good Luck" at end speaks for itself.

Reply on news.ycombinator.com