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.
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.
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!
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
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).
> 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.
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.
> 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.
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).
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.
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.
> 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
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 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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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)
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!"
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.
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.
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 :)
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)
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.
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.
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
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?".
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?
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.
Laravel focus a lot on branding & communication to create a hype by overselling their functionality, you are a "Web artisan" when using it, the ORM is not like other ORMs, it is an Eloquent ORM etc.
A facade cuts out the boilerplate to achieve the same ends as a contract, which is to provide a dependency of some kind.
I agree with the documentation sentiment. The documentation is enough to get one started, but not nearly enough to get the job done well. The community is overran with beginners, and you are left to your own devices once you really want to get your hands dirty.
The 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
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 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).
> 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.
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.
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.
> 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.
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!
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.
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.
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?
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'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.
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.
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?
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.
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 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 :)
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.