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!
> 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.
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.
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.
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.
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 ;)
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.
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.
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.
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.
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.
> 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.
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.
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 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.
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.
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.
We do a lot of work with large datasets. PHP 7&8 are so much better than 5 in terms of memory usage for large datasets.
Its not magic though, and I'm not surprised a compiled executable is many times faster, especially for math heavy stuff. Slow is often "good enough" though and deploying is quite straight forward.
I’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.
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
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.
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.
PHP was the right tool at the time especially when everything on the web was somewhat Wordpress first. PHP felt like a blast with WAMP/LAMP.
Since then I have moved on and honestly it never occurred to me, that PHP still could be an option in my tech stacks, neither one of my devs recommended it.
No one hates or disliked PHP, there are simply other options.
Looking back, recommending PHP today feels like "You can do this with jQuery, too" in the Frontend domain. Yes, you can, but maybe you shouldn't or only if you have the right people. And PHP is a rare skill now.
I'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.
>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.
Developer advocacy is such a weird thing, do it right and people will line up for you to mentor them and pay you for it, do it wrong and you will people scratching their heads asking "so you can do with this thing what you could do with Perl + CGI 15-20 years ago and still not get more performance out of it?".
Sadly this article is the latter.
I'm working on both sides of the fence -- dynamic strongly typed language (Elixir) and static strongly typed languages (Golang, Rust) -- so I am already sold on the advantages of dynamic languages. That page is doing a poor job selling PHP to me though, f.ex. it's not clear when you do `$request->user->orders`, does that automatically go to the DB? Does it first fetch the user and then all their orders, or does it do it in one go? Is the whole thing prone to N+1 queries like Rails is (was? no clue about it nowadays)?
Posting cute little coding snippets is skipping 99% of the story. The code must remain small and simple and understandable and easy to dissect / troubleshoot, long-term, and allow for adding metrics / telemetry, analytics and such.
So OK, we get it, you're so hyped about PHP that you made a website about it. Alright. Now do a cookbook. Next show us a 5-year old project and tell us how long does it take to add a feature or fix a bug exactly. Tell us of the issue that took you the longest to troubleshoot -- and why did it take so long.
Before that this is basically a surface-level marketing page that says almost nothing and is not even accentuating the strong sides of your loved technology because what I am seeing here I can clearly remember 5 other languages I've done it successfully with: JS, Golang, Elixir, Rust and Ruby.
Planet php has a strange and probably unique geography. It has its large continent of modern generic web frameworks but it also has these countless small but thriving islands of specialized platforms that solved specific problems.
But islanders and continentals dont talk or help each other.
You can obviously build from scratch a blog, a wiki, lms, forum, analytics, e-commerce, survey etc. etc. site in Laravel. The funny thing is that it is quite likely that the leading open source solution for what you want to do is already in php (wordpress, mediawiki, etc) yet you cannot benefit much from it. You definitely cannot import it, but you cant even learn easily from it unless you dig deep into a complicated codebase.
Because php is so old and so adapted to web development people went on and built wonderful things with it, capturing complex domains with all their peculiarities. But that valuable knowledge base remains fragmented and locked within each one of these monoliths.
Going forward there is ever more intense competition between open source language ecosystems. A lot of improvement efforts look inward (making languages faster, safer).
The php community might also be able to draw unique advantage looking more "externally", taping the enormous domain knowledge of all these projects. How that could be done in practice is an open question, but it could become the USP for php, the way data science has become for Python.
Why do most PHP related posts on HN read like repentance ? If you want to promote the language -to the point of buying a domain and making a webpage-, please show interesting stuff, not something that is equally trivial to solve in gazillions of web frameworks written in gazillions of languages.
I don’t get that feeling. And I like that people are doing their best to try to improve the reputation of the language. The reality is that modern php is very decent, but a lot of people that have never used it or have used a very old version mock or look down upon it for no apparent reason.
It’s important to try to improve the reputation so that it gets new developers interested in it in order for the language to keep being relevant.
If you want a concrete reason why I think php is great and has many things that are very useful compared to its competition:
Extensive native support for classes and types.
Php does class-based OO better than its competition (JavaScript, python).
Designing a traditional object oriented system using classes and interfaces is better in PHP than in JavaScript and python, if we limit ourselves to the native features of the language.
For example, you cannot define a native interface or an abstract class in python or JavaScript. JavaScript classes, since they’re just syntactic sugar, have a lot of unexpected behavior.
In python you have to accept the this/self object in every method definition.
Here are a couple of links about php classes, interfaces and types for anyone interested:
You just prove my point... you start your post with something that reads like "it's decent now, please look at PHP again". But:
- you make bold claims about PHP OO
- you make downright false points about other languages
- you nitpick things that are non-issues in other languages
All in all, nothing in your post really seals the deal about PHP. It's not about mocking or looking down on PHP for no apparent reason. I'm pretty sure most of us on HN have used it already and most of us have followed its development. I sure did. And every time a new version comes out, I welcome the improvements although it's just mostly catching up with the competition. So what compelling reason do I have to use it again in 2023 for greenfield projects ? None. It used to be "the web specialist", but now all platforms have great web frameworks along their distinctive features.
Because there is a lot of negative propaganda against PHP out there, especially within academia.
You can meet people fresh out of university telling you that PHP is bad even though they have never written a line of PHP. They just know.
This is quite bad for the industry as a whole, because it plays right into large companies that is pushing their technology in an effort to subvert web.
I've been using PHP for about 19 years and what I can tell is that both the language and its community have evolved the right way. Writing modern PHP is a joy, IDE support is great and we have tools for everything.
Modern PHP is about community standards, not about any particular framework and exposing Laravel as the best way to get started with PHP is questionable. I wouldn't recommend it to anyone wanting to learn (real) PHP.
The article praises PHP but it is sad that doesn't link to any other resource or project which ditches the value of PHP community.
Laravel is great for RAD which is attractive for small projects. The kind of stuff "business with 500K orders runs on a $6 VPS" thing. For clients wanting a robust software system you can use a better tool.
The only bad part of the PHP community is the people that have never done anything else other than WordPress. The shittiest more careless horrible and bad practices riddled codebases I’ve seen in my life come from WordPress developers. It has nothing to do with the language though, it’s just that part of the ecosystem which I think is what drives all the negativity and looking down towards PHP.
Laravel only seems to be for small stuff like
- the backends of Apples Webapps
- spiegel.de, the biggest German news site
- the New York Times website
- backend services at Disney
- About You (large online retailer)
Seriously, though, I myself work for an enterprise that runs big parts of the European energy grid and we use Laravel for all sorts of stuff. At a previous job Laravel powered a whole ISP.
Notice when people say Laravel is good for small stuff and early prototypes, they never explain why.
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.
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.
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.
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.
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.
Readit News
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.
That's a state of the art WebApp. You old PHP developer!
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.
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.
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.
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 ;)
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
But when a dev says X is objectively bad, that is not a good sign. Languages are tools, not a way of life.
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.
This just sounds like PHP Stockholm syndrome with extra steps.
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.
Guess that is why selling Laravel tutorials seems to be a fruitful business.
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.
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).
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.
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.
Obviously Go and PHP are two very different languages but they bring me peace in ways JS never did. Especially when reopening older projects.
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!
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!
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.
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?
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.
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.
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.
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?
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.
If you do, please share your experience in a comment. I’d love to hear it. I architected this framework over the last decade :)
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.
But in any case, great job with the platform!
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.
Mostly xdebug. There is also ZRay on IBM if you use Zend, but I've never used it.
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.
Deleted Comment
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
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 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.
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.
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.
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.
If you’re willing to give up magic, it’s worth it.
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.
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...
PHP was the right tool at the time especially when everything on the web was somewhat Wordpress first. PHP felt like a blast with WAMP/LAMP.
Since then I have moved on and honestly it never occurred to me, that PHP still could be an option in my tech stacks, neither one of my devs recommended it.
No one hates or disliked PHP, there are simply other options.
Looking back, recommending PHP today feels like "You can do this with jQuery, too" in the Frontend domain. Yes, you can, but maybe you shouldn't or only if you have the right people. And PHP is a rare skill now.
I 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.
Deleted Comment
Dead Comment
>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.
Deleted Comment
Sadly this article is the latter.
I'm working on both sides of the fence -- dynamic strongly typed language (Elixir) and static strongly typed languages (Golang, Rust) -- so I am already sold on the advantages of dynamic languages. That page is doing a poor job selling PHP to me though, f.ex. it's not clear when you do `$request->user->orders`, does that automatically go to the DB? Does it first fetch the user and then all their orders, or does it do it in one go? Is the whole thing prone to N+1 queries like Rails is (was? no clue about it nowadays)?
Posting cute little coding snippets is skipping 99% of the story. The code must remain small and simple and understandable and easy to dissect / troubleshoot, long-term, and allow for adding metrics / telemetry, analytics and such.
So OK, we get it, you're so hyped about PHP that you made a website about it. Alright. Now do a cookbook. Next show us a 5-year old project and tell us how long does it take to add a feature or fix a bug exactly. Tell us of the issue that took you the longest to troubleshoot -- and why did it take so long.
Before that this is basically a surface-level marketing page that says almost nothing and is not even accentuating the strong sides of your loved technology because what I am seeing here I can clearly remember 5 other languages I've done it successfully with: JS, Golang, Elixir, Rust and Ruby.
Rails has had the ‘include’ method which solves n+1 since version 3.0 around 2010. Before that it also had preload which worked similar.
But islanders and continentals dont talk or help each other.
You can obviously build from scratch a blog, a wiki, lms, forum, analytics, e-commerce, survey etc. etc. site in Laravel. The funny thing is that it is quite likely that the leading open source solution for what you want to do is already in php (wordpress, mediawiki, etc) yet you cannot benefit much from it. You definitely cannot import it, but you cant even learn easily from it unless you dig deep into a complicated codebase.
Because php is so old and so adapted to web development people went on and built wonderful things with it, capturing complex domains with all their peculiarities. But that valuable knowledge base remains fragmented and locked within each one of these monoliths.
Going forward there is ever more intense competition between open source language ecosystems. A lot of improvement efforts look inward (making languages faster, safer).
The php community might also be able to draw unique advantage looking more "externally", taping the enormous domain knowledge of all these projects. How that could be done in practice is an open question, but it could become the USP for php, the way data science has become for Python.
It’s important to try to improve the reputation so that it gets new developers interested in it in order for the language to keep being relevant.
If you want a concrete reason why I think php is great and has many things that are very useful compared to its competition:
Extensive native support for classes and types.
Php does class-based OO better than its competition (JavaScript, python).
Designing a traditional object oriented system using classes and interfaces is better in PHP than in JavaScript and python, if we limit ourselves to the native features of the language.
For example, you cannot define a native interface or an abstract class in python or JavaScript. JavaScript classes, since they’re just syntactic sugar, have a lot of unexpected behavior.
In python you have to accept the this/self object in every method definition.
Here are a couple of links about php classes, interfaces and types for anyone interested:
https://www.php.net/manual/en/language.oop5.variance.php
https://www.php.net/manual/en/language.oop5.interfaces.php
You can meet people fresh out of university telling you that PHP is bad even though they have never written a line of PHP. They just know.
This is quite bad for the industry as a whole, because it plays right into large companies that is pushing their technology in an effort to subvert web.
Modern PHP is about community standards, not about any particular framework and exposing Laravel as the best way to get started with PHP is questionable. I wouldn't recommend it to anyone wanting to learn (real) PHP.
The article praises PHP but it is sad that doesn't link to any other resource or project which ditches the value of PHP community.
Laravel is great for RAD which is attractive for small projects. The kind of stuff "business with 500K orders runs on a $6 VPS" thing. For clients wanting a robust software system you can use a better tool.
Honestly asking. Haven't written PHP in over 20 years.
Seriously, though, I myself work for an enterprise that runs big parts of the European energy grid and we use Laravel for all sorts of stuff. At a previous job Laravel powered a whole ISP.
Notice when people say Laravel is good for small stuff and early prototypes, they never explain why.
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.
Dead Comment
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.
But I really like compilers, they catch a whole class of bugs, before I run things.
I can't imagine not having Psalm or PHPStan in our build pipelines.
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.
Oh and the garantiert that no one can modify it post the compile step.