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.
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.
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...
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?
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.
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.
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.
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.
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.
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'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!
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 :) )
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.
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.
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><script>alert();</script></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.
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.
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.
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 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.
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.
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.
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
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:
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?
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:
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.
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?
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.
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.
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'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.
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!
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).
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.
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
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 :)
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.
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.
> 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.
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.
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%.
> 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.
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.
> 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.
> 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
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.
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).
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
One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that.
Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.
Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.
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.
> 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.
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.
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.
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:
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.
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.
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.
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.
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.
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
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!
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.
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?
> 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.
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.
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.
> 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.
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.
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.
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 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.
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 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.
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.
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.
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.
>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).
> 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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?
> 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 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.
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.
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?
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.
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...
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.
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.
530 comments
[ 0.23 ms ] story [ 399 ms ] threadIf 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.
And articles referring to Golang could read
> Go with "Go"
https://frankenphp.dev/
Or an advert by someone involved with Laravel/Laracasts.
As the former it's quite effective.
The latter would be funny.
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.
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.
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.
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.
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?
That's quite misleading however
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.
This seems like a pretty basic thing to fix, but then I only have your snippet to go by.
If an ORM/builder casually puts =/IS and LIKE in the same method, don’t touch it.
The snippet also validates request inputs, so clearly it doesn't assume that inputs are safe.
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
i.e. $request->query(‘password-reset-token’);
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!
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!
Of course, this can be a double edged sword if you aren't comfortable in the language yet.
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.
Some example: https://www.gnu.org/software/guile/manual/html_node/Reading-... (no installation of anything third party required)
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.
Take this template:
In most templating languages, for a title of "<script>alert();</script>", the result will end up being: In PHP, which is a templating language, the equivalent seems to be: But this will print the title unescaped, which is a security vulnerability, and incorrect. In reality, the equivalent is: 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.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.
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.
Really? I see no evidence that this is happening
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
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...
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?
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.
https://laravel.com/docs/10.x/collections#available-methods
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.
If you do, please share your experience in a comment. I’d love to hear it. I architected this framework over the last decade :)
But in any case, great job with the platform!
Your copywriting gives off strong old school enterprise sales vibes with a dash cryptomania. You are not going to get much organic product led growth among the US under 40 crowd here. I suggest taking a look at https://payloadcms.com/ and study their design, execution, and copywriting.
I checked out payloadcms though, that site is pretty terrible…
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?
But what i meant is that with that defensive approach you have… it is going to be tough to make it better.
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.
Instead of clear text sizes and simple messaging like in https://qbix.com/communities, there are texts of at least 5 different sizes jumbled in.
Instead of contrast so you can read text — there is white text on black over white text on black.
There is also text that is gray and low contrast until you scroll it into view, but then it gets covered up by code examples. Most regular customers are scared by code examples.
Instead of one clear button or call to action per section, there are 20 on the screen, making the user unsure what to click and what the Information Architecture / hierarchy is.
And moreover, all the links are black on white or white on black — just like the text. No clear visual separation of where to click. It violates like every UX guideline I have read in the last 12 years.
It has GIANT TEXT HORIZONTALLY SCROLLING ACROSS THE SCREEN the minute you start to scroll down. Then when you get past that, it has a GIANT VIDEO THAT DOESN’T FIT and doesnt look like a video, more like some more text in many font sizes.
I could go on… but why? Do you actually prefer this monstrosity to clean design: https://imgur.com/a/IMT6pgB
By contrast, if you land on https://Qbix.com it looks empty and clean, and asks you who you are before showing you a page: a customer, an investor, a developer, etc. Then that page is specifically tailored to what you need.
Text is text. Colors are colors. A large black menu bar is unmistakably at the top, organized neatly so you don’t get lost, not scrolling out of the way.
Unless you think apple.com is old outdated design and modern UX is the payloadcms site?
Apparently it triggers you. I don't claim that it's perfect by any means (actually I think some of what you're saying is right).
My response was simply a reaction to the scope of criticism and the claim that this is the new best practices. Because the other site was held up as an example of what I should spend days emulating and making my site look like, the sheer time investment and “well, if you think it isn’t good, then you can’t be helped” made me believe that this is some canonical example of best practices and design. So I naturally critiqued it and said exactly why I thought the latest design standard was crap. That’s why it came out like that.
If I knew the author would be reading it, I would have been a lot more tactful in my criticism. But I do stand behind what I am saying. (For what it’s worth, the developer section of Qbix also needs a lot of work, but the OTHER sections + overall design of the site I think are good — but happy to take specific and constructive criticism in the same vein I gave it.)
It's hard to get under my skin. That's actually I think what your takeaway should be here - - you can't please everyone, but you should take all feedback as valid and try and deliver something that solves for your problem the most widely.
If someone feels something, then they felt it. Including your reaction to my site, and the others' reactions to your site.
The Qbix Communities page is definitely cleaner and more linear than the Developers/Platform page, no doubt. But it still looks very basic and again doesn't give enough focus to specific features. Instead it presents two videos (which aren't necessarily a good way to get people interested, since they may not even click on them). And at the bottom, it has two dense columns of smaller text packed together, which doesn't really invite people to really think about the features. Would be better if the text points were spaced out, given larger header text sizes, and accompanied by representative icons or even screenshots.
I also watched the first video, and the example Yang 2020 app you demonstrated also looks cluttered and squeezed due to the similar text sizing and lack of spacing things out. To me it looks like it's from 10+ years ago, before flat, material design really took hold of the mainstream and became consistent across many web apps and SPA. (Pity about Yang 2020!)
Sometimes it's best to question why others are having such a contrasting response to you. It does mean something. Letting go of your own opinions and preferences can be helpful for finding greater success in a wider community. Seriously, think about getting opinions from a few UX professionals, and give them some weight when you evaluate them, even if you disagree with them.
People often point out problems in design aesthetics, and imagine that the opposite solution somehow can be realized in a consistent way that makes everyone love the result and will make the difference in platform usaage, but no. That’s not how it works at all. It’s like the people who say “your app doesn’t work” to a developer (with no details on a solution should be), and imagine that somehow this will lead to a much better app with no bugs that everyone will use.
At the end of the day, adoption matters far more. Facebook is cluttered and ugly compared to many other clean beautiful apps, but people are super used to it. Discord is totally bewildering, with tiny gifs for flair and many controls are extremely hard to discover and operate, but people are used to where things are. Craigslist is ugly but at least it’s straightforward. Many more beautiful sites fell by the wayside as they tried to take it on (remember kajiji? others?)
As for Yang 2020… your criticisms are fine but you should realize the design wasn’t ours. It was, in fact, following the design guide here since each community designs their own portal:
https://cdn.hackaday.io/files/1665227124477248/Yang%20Gang%2...
You see, when you are designing a tool can be reused in many different environments with hundreds of variations that could go either way, and still has to work, then you realize that the design decisions aren’t so simple and that these may be the least bad after having gone through exactly the process you described.
Look, if Payload’s GIANT SCROLLING TEXT and white text in black over white text on black was the unavoidable result of hundreds of iterations, then I’d accept it. I personally think there are good reasons for what we have done, having tried tons of other variations. But I don’t think the GIANT SCROLLING TEXT, or making all links look exactly like the text, is necessary or the inevitable result of iterating. We HAVE been listening to criticism and THIS is the result.
https://i.imgur.com/RYEo7Gv.png
Thanks in advance!
It's quite brilliant really, even for modals etc. "look ma, no javascript!". Of course it does JS for you, you just don't see it. That's my favourite kind of Javascript - someone else's problem. Livewire is a mid-way between front-end backend, it's a progressive back-end with long polling like NextJS I suppose. From your end though, it takes care of all the security of running your own API, and correctness. You basically have dynamic front-end from the backend.
If you want a full SPA or you need an application that is very responsive without network requests, I recommend VueJS - Livewire recommends AlpineJS, but of course you might be a React guy, that's fine, and use Laravel as a regular API.
You can even use GraphQL if you want to die of a young age, have some weird kinky thing going or you have something to prove... Unless you're Facebook of course you probably don't need GraphQL.
It’s kind of funny that this is the new best thing, when this is almost the same model JSF did decades ago.
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.
To note, you'll need strict mode for type hints to be useful. https://www.php.net/manual/en/language.types.declarations.ph...
The fun part is, instead of going for a generic strict mode system we would have expected, PHP went pragmatic: as most application won't be 100% strict typed, you need to declare it file by file, the icing on the cake being that the restriction applies on the caller of the functions, not the function itself.
It makes for complicated situations, where for instance you can make an utility class that is 100% typed and follows strict typing, but if the caller of your class isn't, none of it will matter and types will be fuzzily coerced anyway.
This is not really true — those type hints can be read by static analysis tools, preventing you from many of the issues that would also be caught in strict mode at runtime.
Unfortunately, it’s taking far too long for Laravel to catch up so parts of its API are a black hole for types.
Especially things like request input, which returns a union of string and array as opposed to using a conditional return type.
You end up with assertion soup every time you touch Laravel so over time the project uses less and less of it.
A well-typed framework and set of libraries would be very nice.
Thanks!
In PHP, typing is for function signature documentation.
false.
Utterly false, I don't know where you came up with all of that nonsense. All type hints work as expected, just you can't typehint variables. Only parameters/class properties/return types.
And the `strict mode` is a failed experiment no longer recommended in new code (no side effects but no benefits either).
I do understand hiring someone who has that tradesman programming ethic and is comfortable with Linux, but that’s more requiring certain positive traits.
On the one end of the scale you've got the PHP Laravel monolith, and on the other you've got the completely serverless bits of JS over lambdas, with 12 different technologies, buckets up the wazoo, to store 300mb worth of data.
Then you're told 'yeah, but this is distributed'! Okay cool, so you save 50ms of latency. Super... How long does your javascript takes to start returning content? Right, much longer. What the hell is even a cold start? How is that a thing in 2023?
PHP is unsexy. And people don't like unsexy. I, on the other hand, I like my vacations uninterrupted.
But yeah, before you jump through the whole ecosystem of JS and require 3 different third party services, only to make a website, that does not work with JS turned off and cannot be build and run any longer 3 month later, due to dependency fup, you are much better off with unsexy PHP.
That's a state of the art WebApp. You old PHP developer!
Though to be fair, devs lose employability when they don't get to use (in their work) technologies that are gaining wide popularity. It's a balance to be struck by the CTO/architect (assuming the devs want or are able to demand that skills development in the first place).
However, I'm not yet sure a complicated edge deployment would actually fix the 10% problem.
So PHP was and might still be a shitty language.
And PHP was my first language I'm fine with scripting with it but it was ugly as hell to write big code
Sure, it's perfectly possible to grow numb to those pains and some will even pat themselves on the back, claiming pragmatism over principles, but wow, if you're not used to that level of make-believe in computer languages you'll be paralyzed by disbelief. An endless series of "this can't be true!"
Depends on the reasons. One good reason for preferring another language is .NET/Java business app developers can earn a lot more here than PHP developers ;)
There are good reasons to avoid/switch-away-from PHP... Like weak compile time quality guarantees, messy std lib, low quality of available libraries, many security issues; all WHILE great alternatives exist for free! (e.g. Kotlin, Rust, C#, Java)
This just sounds like PHP Stockholm syndrome with extra steps.
It's fine to be excited about programming but those that build their whole identity around it are just super obnoxious and not fun to work with.
I personally never liked PHP, so I haven't kept up with how it has developed and I don't expect to start, to be honest. Of course, if you've got an otherwise interesting project that happens to be PHP and want to pay me to help you with it, I'll be professional about it, but there are too many alternatives that appeal to me more than PHP for anything where I have a say.
I found the (Laravel) community to be more about object-level discussions ("how to do x feature the best way possible") rather than meta-level discussions.
Python is no more "proper" than PHP as a language.
In fact, they're both identical as far as footguns go.
> Note: In the years since releasing Lumen, PHP has made a variety of wonderful performance improvements. For this reason, along with the availability of Laravel Octane, we no longer recommend that you begin new projects with Lumen. Instead, we recommend always beginning new projects with Laravel.
Serious question, what does that argument consist of ?
Bottom line is that the language being so flexible, unassuming, and swamped by needless features almost everything can be debated the point of exhaustion.
Python, being more straight to the point and not overkilling oop allows for more focus on doing what matters: business logic.
This also reflects in their salaries.
And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed?
If so I want to learn how they did it. That's some heavy duty language evolution work.
If that was a metric for language quality, then Javascript would be undeniably the most perfect language ever designed by any intelligent species in the universe, judging by the number of frameworks.
> to an almost decent language
And now I would like to hear a good reason why I should use an "almost decent language", when I can use a decent one instead.
> It can be used properly if you know what you are doing
It doesn't matter what I do, the language still insists of having multiple modes of error handling, a massive amount of builtins all of which sit in my global namespace, it's configuration is still seperated between compiler flags, a system wide ini, and local config. The base deployment mode is still "dump files into folder and let CGI do the rest".
What i am saying is that the offering of tools has matured in php - instead of a basic template engine like smarty you now have “advanced” templating engines, packages and so on. Python has less packages but that can also he because python packages work better and there is no need for an overwhelming number of packages.
Regarding error handling that’s precisely one of the many issues with php. There are so many ways of doing the same thing that it becomes exhausting. And what many php devs do is they work around these issues either by endless hair splitting debates or a dubious amount of made up design patterns.
You shouldn't use php, i am totally against it. I think it’s as bad as it can affect your mental health. Just saying that by comparison to it’s previous versions it has come a long way.
However it does handle character encoding quite well and you can scale as much as you want to literally. Probably because thats too complex for the average php developer and it was left to core language developers which are pretty competent and experienced.
This is why so many basic php 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? No.
Much of it? Absolutely (and the more widely a particular point is agreed upon, the more likely it's fixed). The article is eleven years old.
What's that George W Bush line, Fool me once, shame on...shame on you. Fool me—you can't get fooled again. But we're not talking about getting fooled just once, or twice, we're talking about eight times.
No one got “fooled”. The got a useful tool that got better over time.
This is a language built by people who didn't really know any better, so I don't blame them, but it's ludicrous to pretend that it's a "red flag" to have noticed that this keeps happening and learned from that experience.
I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance.
There are developers who don't like PHP because of outdated reasons and possibly because they are snobs. Sure, that's a red flag.
But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore. Even though PHP has evolved (with regular breaking changes...) and tries its best to put something useful on top of a shaky foundation: The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.
However I would say there are three very good reasons why you should use or at least consider the language:
- You want to quickly hack together something useful with minimal fuss, AKA its original purpose.
- Buy-in of the OO, code generation, IoC/DI, magic framework stuff that Laravel/Symphony provide.
- You have to.
The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described.
Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design.
Again: Trade off.
That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.
If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier.
Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.
Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all.
I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go.
I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money.
As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity.
This happens a lot more frequently than you think.
We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.
debug_backtrace() has always been my friend in situations like this
Have you actually used Symfony?
It's an absolute pleasure in its domain and includes rich debugging abilities through its dev toolbar.
Apparently there's now something called annotation routes. Which appear to be inferring functionality from comments.
You made me look though. I suppose I had it coming.
[0] https://www.php.net/manual/en/language.attributes.overview.p...
Unknown attributes are also ignored silently, which isn't really a good sign.
It may technically be forwards compatible syntactically (`#[foo]` will, as you say, just be ignored by PHP 7), but that's an anti-feature (assuming that the attribute isn't a no-op, it'll presumably break something else).
> `#[foo` used to be legal PHP 7, but is illegal in PHP 8).
So it is not a comment in PHP8 then.
I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.
It is the magic part that is the problem, regardless if it is the framework or your own code that it is doing it.
One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that.
Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.
Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.
> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore.
I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? No because they are "outdated reasons" as you say
> The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.
Do you have an example of this?
Yes. And I say that as someone who has been developing "modern" Typescript web apps full-stack for the last few years.
My issue with JavaScript are fundamental to language design decisions that can't be removed due to major breaking changes. Things like having to deal with `undefined` AND `null`. `==` vs `===` (more specifically, type coercion), prototypal inheritance in addition to ES classes in addition to TypeScript classes. Array.push causing mutations. Having `for of` in addition to `Array.forEach` etc. etc. etc.
And then you have the fact that it is neither OOP nor Functional. So you get people from both backgrounds, and ideologues from both backgrounds, trying to squeeze JavaScript into their preferred paradigm, within the same code-base ... and JavaScript obliges. Because it is neither.
Every single JavaScript application looks radically different from each other and, worse, in a large organization with many teams working on a common code-base, consistency becomes damned near impossible to enforce.
And so you start adding lint rule after lint rule after lint rule until you have an entire team dedicated to maintain your custom linting bullshit.
JavaScript is a complete shit show to this day even if it does have nice features and even if you can get up and running with it quickly.
If it weren't so popular, and if it weren't the "language of the browser", I wouldn't recommend it for anything other than small teams who can decide on which "version" of a JavaScript adventure they want to strictly adhere to.
It is not only bad for the developer, but for the users, too. The overall confusion and frustrations are abundant.
I’m also very loyal and pragmatic. I really tried.
I don’t want to start a language war here either. What I said above was a counterattack on the idea avoiding tech that doesn’t agree with you is somehow a red flag.
My general point is: consider that there are people who have earned their opinion the hard way. Even if you disagree.
This applies to absolutely every language or stack. You switch to Ruby because the grass is greener, and 5 years down the road you feel the same. Then you switch to Kotlin or Erlang or JavaScript and you'll end up hating it anyways if that's how you roll.
But when a dev says X is objectively bad, that is not a good sign. Languages are tools, not a way of life.
Hard disagree. Sorry, I don't have a computer science degree, why does their documentation make that assumption. I find their docs very hard to grok.
PHP.net docs are no-frills no-fuss, straight to the point. Other frameworks are documented very well too, CakePHP comes to mind (at least, when I was using it last in v2 and v3).
I can't say I've read the absolute latest version of their v10 docs, but when I was neck deep in 5.8 I found I had to switch to older versions of the documentation to read up on some of the most basic of Laravel features. eg. What's the syntax of using Form in Blade templates? I had to go back to v4.x docs to read up on it, Blade templating hardly got a mention in v5.x documentation, despite it being critical component in a Laravel application.
If there was a bug in a project and I had management breathing a fire down at me because it's breaking the site / losing sales / stopping monthly reports from going out, I shouldn't need to decode computer science terms, or look through previous versions of documentation to find the solution.
This is why, in my opinion, Laravel documentation sucks hard.
All that being said, my overall experience of working with PHP / Laravel is quite pleasant, probably more so than other technologies I've worked with in recent years. Everything has its issues I suppose.
[1]: https://laravel.com/api/10.x/Illuminate/Database/Eloquent/Mo...
Ah yes, the Ansible approach. I've used it for a decade, and I routinely get lost in its utterly terrible by-example documentation.
They are the golden standard on how not to write documentation.
God, I hate the Ansible docs so much, they are the reason I burned 30% of my Kagi search quota this month.
- tutorials;
- how-to guides;
- technical reference and;
- explanation.
1: https://diataxis.fr
It doesn't get more clear than that.
https://docs.ansible.com/ansible/latest/playbook_guide/playb...
On this page there is no quick index of all the functions available, their argument and a short summary of how they work. You need to synthesize this information yourself by reading through ALL the examples, and hoping your niche use case is listed.
There are more than one type of documentation, with different use cases. There's the tutorial/list of examples, which Ansible excels at, and is ideal for a first timer reading the docs from cover to cover. Then there's the API reference with quick index, for intermediate to advanced users, where they know roughly what they need, they just need to find it. In this, Ansible's docs fail dramatically.
The authoritative answer to what filters are currently available in your distribution is by running `ansible-doc -t filter --list` which does include a summary line, although for some of them it's "geez, thanks" just like any open source collection of disparate modules glued together
I used to actually build the ansible docs locally with singlehtml because I despised that chopped-up view, but now that they're all "galaxy all the things" it's practically useless again (although I will also say that building it locally and eliding all their tracking bullshit makes the pages load like a bazillion times faster, so ... still valuable in that way)
eg. https://laravel.com/docs/5.8/contracts – talks a lot about how Contracts are powerful additions (like all the other features of Laravel, the docs are good at telling you they're powerful) and the examples show just some barebones code that doesn't really do much without a lot more work. The examples in the documentation seem to be more on the side of being some code snippets that don't convey much context.
Additionally, there's lots of "congratulatory" text in the documentation ("Laravel has a powerful feature called <x>", "in Laravel adding <feature y> is actually really simple", "some developers enjoy using <feature z>". You simply don't see this in PHP.net's docs, it just tells you what the function / feature is, gives you examples that work straight out of the box, lets you know of any pitfalls or differences in PHP versions to watch out for, and there's a whole list of comments contributed by other PHP devs spanning years, that are up/downvoted.
Another example of powerful documentation was that I learnt what MPTT is, and how to implement it effectively, purely from CakePHP docs back in the day (I'm talking v2 here). I can't see how anything as remotely useful would be able to be taught from Laravel docs alone; for someone who doesn't have a computer science degree, there would be a LOT of tabs open, full of rabbit holes that need to be explored. This is not effective documentation in my eyes.
The difference between these sets of documentation is like night and day to me. The Laravel docs needs to stop patting itself on the back, and be more like other software projects' documentation.
Don't get me wrong, I love working with Laravel, it is powerful. My issue is with the documentation, which leaves a lot to be desired.
EDIT: I just noticed that Contracts are still in the current version just got moved in the docs, so I your point still stands.
I agree with the documentation sentiment. The documentation is enough to get one started, but not nearly enough to get the job done well. The community is overran with beginners, and you are left to your own devices once you really want to get your hands dirty.
Guess that is why selling Laravel tutorials seems to be a fruitful business.
I’m sure that plenty of us used PHP in the day, have been doing something else for a while, and see these HN posts from the people that stuck by PHP singing its praises. Let’s not forget that there’s probably been a steady stream of newbies coming through the system the entire time - which makes the language, and by extension Laravel, a prime target for bottom feeding ‘one step ahead of the audience’ “educational” content producing scum.
Thanks to Laravel (along with Livewire and Alpine.js), and an ecosystem of libraries enabled by Composer, PHP is a great choice for web development. I'd not use it for, say, coding machine learning stuff though!
Most mature programming languages are nice to work with these days though. At least in my opinion. About the only one I dislike is C#, and that is mostly because whenever I need to use C# I need to use it with a combination of libraries (Odata, Entity Framework, Asp.versioning) as an example which simply don’t work together unless you overwrite/extend half of them. Because for most use cases C# is as excellent as all the rest.
But PHP was essentially build for the modern use case of everything being web-based and it’s weird to see the reputation it still has. Then again, django is also an excellent tool for most modern work that doesn’t see the adoption it should. I’m so sick and tired of having to deal with things like umbraco failing at things that have been a fundamental part of django for longer than some of the people reading this post have been alive. :p
But I guess its all those things that keep me well paid. So maybe I shouldn’t be too angry about it.
Thanks to JVM you have really good out of the box debugging features including hot code replacement and profiling.
You can use kotlin which is a really really good language in comparison to PHP.
There is no need in my opinion to write real applications with PHP.
IME, Laravel's "easy deployment" story is heavily linked to the paid service Forge, and installing dependencies during deployment is a bit slow plus takes a /lot/ of memory (we're using old Composer and Laravel versions though). What's your take?
Personally, I do like the way the standard library is - almost all cases of where people whine about it being inconsistent, it is a consequence of the PHP standard library and many of its extensions being extremely thin wrappers around libc and C/C++ libraries in general.
That, in turn, makes it often possible to just take straight C library example code, copy it into a PHP file, add a $ in front of all variables, and have it magically work.
(IMHO, it's no surprise that the whiners tend to be younger programmers who have grown up with Java in their university education - us older "neckbeards" are so used to the C world that its conventions are second nature for us)
* head explodes awesome
I know what I'm doing this afternoon!
Obviously Go and PHP are two very different languages but they bring me peace in ways JS never did. Especially when reopening older projects.
That said, PHP does have complexity to running like node does with pm2, Apache or Nginx in front. Is it as bad, depends on the person, but it does suck IMO.
You could make it single threaded. But the standard is multi threaded, and if you have more then 100 users will be have to deal with locks.
That said, locks/threads are still easier to manage then async code.
Unless you’re getting shared hosting, then it’s true for most things now. You don’t need a specific OS or cloud provider for .NET, Java, Go, Rust… etc
> When I consider the solutions of flask and microservices I've left behind, the many node processes running with pm2, the complexity of .NET solutions... PHP just works, and it's easy to make reliable... And if it's slow, it's because I'm doing dumb stuff, not because of dark corner edge case I happened to be tripping into.
.NET isn’t anymore complex than a PHP app. Unless you write many layers of abstractions. And nothing stops you from doing the same thing in PHP.
Fast, the most overrated feature that we developers endlessly look for. How fast? How much are you winning, milliseconds, nanoseconds, picoseconds? It's extremely likely that if something is slow is because you're doing something wrong regardless the language and/or framework.
It's reliable PHP? Well, so are Python, Ruby, Go and other friends, right?
> Laravel is pretty darn rock solid.
Again, so are: Rails, Flask, Django and many other matured frameworks out there that have been baked for years now. Unless you pick some toy framework project written in a weekend I'd say there are plenty of rock solid options out there.
> Just ignore the fugly standard library inconsistencies of (old) PHP...
I'll just prefer to pick a language that narrows/discards that dark side as much as possible. Very long time ago I couldn't finish reading a page whose author painstakingly detailed every single inconsistent feature of PHP (literally it could have taken a whole day to read). After that horrifying testament I said myself to ever get my feet wet with PHP. Now in a team with PHP you will need to agree which "inconsistencies" should be left out either by adding some tool to automatically watch for that or educating onboarding members of your team.
> Oh and it's free. All of it. PHP, Laravel.
Aren't the other friends out there also free? All of them?
> When I consider the solutions of flask and microservices...
Flask AND microservices are two completely different things. You can have a full fledged monolithic Flask application or go with the microservices rabbit hole with ANY technology and/or programming language that you want.
So PHP, well... Nah. At least not for me. There are plenty of interesting languages and technologies out there to be learnt and PHP for me is definitely not one of them.
One question aside out of ignorance. How do people debug in PHP? Many many many years ago I worked for an extremely short time for a company that were heavily using Laravel. I didn't know how to debug a PHP program at a time. People told me to simply do "prints" to the rendered template. If I remember correctly I also tried to find some tutorial or howto on debugging with PHP only to be unsuccessful. I'd be interested to know because with Python is just a joke to do that. Install ipython and ipdb. Then set `import ipdb;ipdb.set_trace()` and you are done, you get the full fledged mighty console where you can see everything you need to track down an issue. Up today I haven't got the opportunity to testify someone using a similar capability with PHP but hey I might be wrong and something of the like is out there.
Mostly xdebug. There is also ZRay on IBM if you use Zend, but I've never used it.
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
How should I interpret this? The language is cool? Can perform cool tricks?
PHP makes simple stuff easy and difficult stuff possible. (But you're not going to win the Tour de France on a BMX bike.)
Nowadays, a lot of other things also do this, but PHP was the first to really "get" this. I understand it's not for everybody, and for certain things, other languages are certainly better. But there's precious little that you can't do with PHP, since it's been around for so long and has been growing with the Web from pretty much the very beginning.
Sorry, could not resist! lol :-D
Would you mind sharing your insights into why one should go with modern PHP+Laravel instead of NodeJS+Express+Typescript? what does the PHP equivalent of pm2 load-balancing look like and how does it compare?
API Platform is really good for scaling CRUD endpoints too (its a Symfony project, or at least tightly Symfony adjacent)
Of course, this is my experience (albeit over many years) however I wanted to just throw out a worthy alternative people really should look at.
But for web, I personally prefer Typescript frontend and backend combos. It's amazing to be able to write everything in one language. I largely tune out the arguments and new flashy frameworks, but I get why people call the JS ecosystem a hellhole. There are a lot of options out there. That being said, when your team is competent and balances functionality with new shiny stuff, it can be a real treat to have access to npm for frontend and backend.
https://phel-lang.org/
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.
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.
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.
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.
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.
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!
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...
OTOH it makes a point that it solves a real problem. A business processing 500k orders a month is not trivial.
(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.)
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.
Not to mention that as long as you have a direct sync query to a database - your code will have to wait, lol.
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.
>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.
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?
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).
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.
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.
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"
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.
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
Probably a configuration missing.
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.
>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.
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.
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...
If you’re willing to give up magic, it’s worth it.
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.
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.
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.
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.
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.
You make some interesting counterpoints but people aren't going to see them because of the counterproductive language surrounding them.
You should take a look at the HN guidelines.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
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.
But I really like compilers, they catch a whole class of bugs, before I run things.
Oh and the garantiert that no one can modify it post the compile step.
I can't imagine not having Psalm or PHPStan in our build pipelines.
Also, out of curiosity, are all of those tests hand written, or is there some generation in there?
I can’t see how static analysts could solve it really.
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.
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.
Alternatively: what would you suggest someone getting into web development to learn? PHP or Ruby?
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.
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.
- hidden global state
- arbitrary string literals
Is that Laravel?
I hated it (Laravel) for those reasons, along with the madness that was the DI container. Guess I'm just not "web artisan" enough.
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.
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.
If you're wanting to build a TUI I haven't seen any libraries as advanced as the Python or JS ones.
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...
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.