If you are thinking about building a web application, take a look at Laravel. I not a huge PHP user, but Laravel is always on the top of my list for building web applications. It's the greatest web framework to ever exists, even better than Rails IMHO.
The ecosystem around Laravel is really incredible and unlike any other framework. They have libraries for every stage of a web application from taking payments all the way down to server management and hosting.
They even have awesome libraries like Inertia which are built for Laravel but can be used with other frameworks.
It's the only reason I still stay fresh on my PHP.
+1 for laravel as well. I joined a php project for a fresh rebuild in laravel and had mostly .net experience. Laravel was great.
The documentation is an almost perfect blend of examples and nitty gritty detail. The documentation is almost engaging if you’re coming from other frameworks.
I found myself thinking “wow that’s almost no code, what about this feature or that” and the next section would be the exact topic I was wondering about. Had a blast and could learn more php details as I went
Laravel is great if you just want to get something simple done as fast as possible with the simplest, most elegant (at a glance) code possible and don't care at all about understanding how it works, what's going on under the hood, performance, doing anything the devs didn't expect, etc.
Everything in Laravel is as obscured, "magical" and opinionated as possible for the sake of making the code "beautiful" (again, at a glance) to the detriment of basically everything else. I really have no idea how any experienced programmer can look at it and think it's usable for anything beyond the most simple project.
The mere fact that models are PHP classes but none of their properties that exist in the database are actually declared as properties in the class because the ORM just "magically" puts them there at runtime should be enough to drive away any sane person. And let's not forget the amazing "Facades" a.k.a. glorified global variables filled with magic methods that you're expected to make extensive use of.
Can you give me a few real life examples where you got bit by the "magic" conventions or ran into any serious issue from not explicitly setting properties on your models?
Facades are not global glorified variables with magic methods. Usually they're just a way to instantiate and access a class with less code. People complain that facades limit testability. In fact, they're easily mocked. Etc.
The docs do a very good job of explaining how things work and how you can override any "magic" you may not like. If something is doing something you didn't expect, you probably didn't read the docs. In fact, a delight of working with Laravel is it's so intuitive that you can often guess how to achieve something and be right.
> Can you give me a few real life examples where you got bit by the "magic" conventions or ran into any serious issue from not explicitly setting properties on your models?
I shouldn't need "real life examples" to explain why using objects with magic dynamic properties instead of declaring the properties on the class is stupid. If I can't look at a model class and know what properties and methods it has, why is it even a class? With all the improvements made to PHP in the past decade, it feels like going back to the days when I was just using associative arrays to represent database objects.
> Have you worked with Laravel in practice?
Yes, I tried using it, was immediately put off by the issues I've described, then tried Symfony and never looked back. For every piece of dumb nonsensical magic Laravel does, you can look at Symfony to see how it should be done properly.
You can look at a Laravel (Eloquent) model and easily see what methods it has. Nothing is hidden -- at least no more than any ORM that inherits from another class which gives it functionality.
As for properties -- yes, they're not explicitly described but mapped to the database schema. Other ORMs, like that in Ruby on Rails, also do not explicitly set model properties and just map to database columns. People have been upset about this forever, but everyone else has happily used Active Record and had no major issues, all while enjoying not having to add a dozen lines of code to annotate props.
In both Rails and Laravel you can define accessors and setters, either overwriting the magic property for the column or defining new properties.
If not seeing the properties on the model is a huge problem, there are plugins to generate them and put them in the model. My IDE gives me direct insight by inspecting the table.
I'm happy not to have to write out all the props twice when there's no tangible performance issue and I've never had any other problems with dynamically getting the model attributes from the schema.
You're taking a matter of taste and context-based tradeoffs and acting like those reflect unchallengeable principles.
Symfony is a great piece of software. So is Laravel. Github numbers alone will show you how compelling so many developers find Laravel. Of course, there will be haters who think they're all stupid, uneducated, bad, idiotic, lazy, etc.
Everyone makes trade-offs based upon taste or prior decisions. Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, and then run that migration. I really like that pattern. Removes tedium of writing migrations, preserves ability to modify the migrations, and makes things explicit.
When I used SQL Alchemy in Python, it completely allowed me to not write migrations, only models. That was very nice, until it wasn't. But then I just had to do a few things manually -- a reasonable price to pay for saving a bunch of time in the other 19/20 of cases.
These are all just different ways of getting to the same place. Each has benefits, each has drawbacks, the extent of each which will depend on the project and the developers' tastes.
The only benefit you've mentioned is writing less code. Which just proves my original point about Laravel being for people who want to get things done as fast as possible with the minimum effort possible, regardless of how much sense it makes.
>Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, and then run that migration. I really like that pattern. Removes tedium of writing migrations, preserves ability to modify the migrations, and makes things explicit.
This is exactly what Symfony with Doctrine does, and it's the correct way to do it. The benefits vastly outweigh the "drawback" of having to write slightly more code.
When I work in Django, instead of other frameworks I use, I think "I like this more, I like this less; this works better for me in these circumstances, this does not." But I've never felt it made any sense at all to pronounce one as objectively better than another.
In most cases, it is a matter of taste and tradeoffs that vary based upon circumstance.
You can keep saying "this is the correct way" with all the conviction in the world, but it won't turn matters of opinion and circumstance into universal fact.
It's not a matter of personal opinion, it's a fact that the data mapper pattern (like doctrine) allows for a better and more maintainable architecture than active record.
Separating the data access layer, the models and the business logic (basically a 3-tier architecture) is a widely used and proven industry standard to keep a sane, maintainable and testable codebase.
Active record ORMs like Eloquent mixes everything in a single layer (business logic in the model events, data accesses are done by the models), but as soon as you reach a significant level of complexity, it is unmaintainable.
Even Laravel codebases that grow in complexity often ends-up wrapping Eloquent in a repository layer.
> Symfony is a great piece of software. So is Laravel.
And to be clear, Laravel is a piece of Symfony software, and a good example of what you can do with Symfony packages and a bit of opinion.
There are 13 Symfony dependencies in https://github.com/laravel/framework/blob/9.x/composer.json alone, and many of the Laravel packages listed in there also depend on them; the Laravel Request class extends Symfony\Component\HttpFoundation\Request, the Response class extends Symfony\Component\HttpFoundation\Response, etc.
Technology companies routinely use/license technology from other companies in their products. If, for example, Apple relies upon Samsung for displays and memory in their laptops, it does not follow that you're actually buying a Samsung laptop.
In any event, Laravel has never been shy about its debt to Symfony.
It's a lot more than "a bit of opinion". It's a huge framework with tons of unique and original features. You're being very reductive. Yes it does use Symfony components for some core functionality, but that's just a small part of what Laravel offers.
I think we largely agree; I just think "Laravel or Symfony" is somewhat a false dilemma because of this. You can build your own system on Symfony libraries... or you can use Laravel's system that's heavily built on Symfony libraries, with a lot of the plumbing done for you.
> And let's not forget the amazing "Facades" a.k.a. glorified global variables filled with magic methods that you're expected to make extensive use of.
Each of the facades comes with a corresponding dependency injection if you prefer. You can write an entire Laravel app without ever touching a facade.
So I suppose you also write your own compiler, your own operating system, and built its computer from bare transistors as well? Because all of that looks like magic to me too.
At some point you have to accept the foundation you have as something that works, it's battle proven, and it's built by experienced and reliable developers and you build on top of the shoulders of giants. Reinventing everything from scratch so that you understand it makes you the only one that understands it.
There was a famous phrase by Arthur C. Clarke that I think applies here along the lines of "Any sufficient advanced technology is indistinguishable from magic".
Laravel is a decent web framework, that comes with batteries included and _often_ has sensible ways to override and avoid things if you don't want them.
For example, you don't need to use the ORM at all and can just use their query builder (which is pretty good). It's there if you want it, but the framework works happily without it and doesn't get in your way in that regard.
I inherited a Laravel codebase from a previous contractor and it was reasonably ergonomic to navigate and extend, because I was able to lean on the framework documentation to understand how it all worked. But there were several points where it was _not_ reasonable, because of Laravel/PHP magic and those were pretty painful to figure out and debug.
The reason I wouldn't choose it myself anymore is the magic, the little surprises and hard to debug idiosyncrasies that it provides in order to look pretty. Also generally Laravel, PHP and related ecosystems are moving too fast and are difficult to keep up to date without breaking and/or misunderstanding things. It's not quite JS/npm level of churn, but unnecessary regardless. A more minor point is the baseline performance tends to be on the lower end of what I need.
There are ecosystems out there that value stability and clarity more and provide better tools to test and debug the code if necessary, and I've come to appreciate those things much more with experience than other factors such as reducing the initial development time.
What other ecosystems and frameworks are you talking about? I've tried many things across many ecosystems in the last 20+ years and so far, despite any drawbacks it could have Laravel is the best one by a long shot. So I'm curious what those other better solutions you mention are and what are its trade offs.
> [Laravel]'s the greatest web framework to ever exists
Back when I worked with PHP, we used Symfony and several coworkers very much looked down on Laravel. Symfony was modular and you could easily switch whichever component for your own by just implementing the interface and overriding the dependency injection thing. Word was that Laravel hardcoded many things and was less customisable.
What is your take on this? In what way is Laravel superior to Symfony?
This is the big reason I use Symfony for most of my projects.
I do lots of refactoring and modernizing of legacy or non-scalable codebases as a freelancer; with Symfony you can replace it module by module and slowly implement the Symfony framework structure.
Through some configs, it can do dependency injection, event listener stuff, etc, but the framework is mostly glue around components.
With Laravel, you need to go "all-in", and you had to do things the Laravel way. If I strayed from that path, it would make things really difficult.
I still work on projects with either of the frameworks, but if I had a choice, it would almost always be Symfony.
Laravel is great for prototyping and fast building. If you want to make a big application with Laravel, it's better to use Symfony-like approach with interfaces and DI (you can do it by using Laravel).
What I personally do not like in Laravel is their ORM, too much magic calls involved.
Yes, the magic involved in Eloquent ORM, also the central use of Facades or that the models are based on migrations (which uses code comments as a crutch for auto-completion), instead of the migrations being based on the models (how Symfony uses simple PHP objects, from which then Doctrine generates the "missing" migrations).
I can live with both frameworks, but Symfony just feels cleaner and more transparent in its workings without using magic to make things look simpler.
I think that people believe they'll switch out components more than they really end up doing, but in Laravel, you can override things within Service Providers, and then use the built-in dependency injection to get the thing you want.
I don't know about that. I have been looking at Rails 7 and there's a lot things in Rails now I like better than Laravel.
Symfony did most of the heavy lifting with getting PHP relevant again, Laravel was just better at marketing. Laravel is good, don't get me wrong but everyone seems to think Laravel is the only good thing in PHP and a lot of Laravel is built with Symfony libraries.
I'm rebuilding an old online community / forum in the TALL stack. It's awesome. I do have to do a lot of raw sql query building to keep it performant though.
- Laravel has many "admin libraries" (Voyager, Orchid, Filament, Twill, Backpack, ...), some of them open core, each with their own idiosyncrasies. Symfony has EasyAdmin.
- Laravel uses Inertia for Vue.js or React integration while Symfony has an integrated solution with Symfony UX
- Symfony has become more modular with Symfony Flex
- Symfony has put a lot of effort into improving "developer experience" in the Symfony DX initiative
- Symfony has brillant docs in many languages including a new open book by Fabien Potencier and other Symfony collaborators
Looking at the Laravel site, I’m concerned about Laravel’s reliance on an ORM. Not only because ORMs are widely derided, but because I have a legacy MySQL DB and PHP 5 project I want to resurrect. I’m down to rewrite the server, but how do I restore a database full of user data with Laravel?
I work on a project like this and you'll run into some papercuts, but it's not hard.
You can take a model for anything in your legacy code, and just set properties on the model to teach Laravel how to deal with things that don't follow conventions.
For example, you can override the table name. Suppose you had a legacy table called "postdata". In Laravel, this table would be called posts, and a model would be Post.
So you'd just tell Post to query postdata rather than posts.
Likewise, you can tell it which fields to cast as dates, booleans, etc. You can tell it which fields represent timestamps for updating, creating, deleting and so forth.
You can setup relations that don't follow naming conventions the same way.
The only issue I've run into is doing things like setting up relationships across databases. You can do it, it's just not super straightforward.
I think you'll find it's a breath of fresh air to have a modern wrapper around your legacy code, and that your legacy stuff will then fit in quite nicely with your new work.
Laravel is “linked” together via a combination of Composer dependency manager and Dependency Injection. You can easily customize your setup to remove the dependency on Eloquent ORM and use something else.
What I'm doing is recreate everything the Laravel way and worry about importing the data (millions of pictures, videos and comments) later. I figured that once I'm proficient at Laravel that writing some import jobs would be relatively easy.
Does your DB have a classic design? You can very easily map an existing DB with a fresh Laravel install, just write a couple Models, their relationships and you're almost set.
I have been working with Laravel on a daily basis since 6 years and have never felt more efficient with code.
Were building some internal tools for customer service on Laravel's Orchid package and its the first truly RAD I've had in php that doesn't hold me back. Building interfaces is a pain and I lost touch with Javascript a decade ago, but it handles all of that for you.
Next.js is great but can't compare to Laravel, they are not for the same use case. Laravel comes with an ORM, a job queue, a mail framework... And it can also scaffold a complete auth system for you
You can just add Bull/Temporal, Prisma/Knex and Braze and you can swap stuff when needed but I understand that for new people it's nice to have everything integrated when starting out.
Still seems like most people write separate backend and Nest.js is most popular. I am not a biggest fan yet personally.
How so? Nextjs only offers ssr and routing. Nothing else. Not even close to the full stack functionality you find in a default laravel or rails project.
It also has API routes and Middleware. But yeah, Laravel includes more by default. With Next.js, you need to pick a few more tools to go along with your stack. E.g. Next.js, NextAuth, Prisma, SQL database. You end up in a similar place, it's just not all part of the same package. That may or may not be beneficial for your team.
And the advantage of Next is that you can leverage React components server side and client side, and share code between them.
Laravel Livewire is pretty nice for basic interactivity, which is all many sites need, but React becomes useful as soon as you start needing app-like features. At that point, using Next, which is already plugged in to that ecosystem, is a very nice experience.
Next is great for static sites, too, so nowadays I prefer putting my time into that vs. fragmenting between a more purely server-side framework like Laravel.
Inertiajs is the right solution if you need more interactivity than livewire. It can be used with react or vuejs out of the box (probably svelte too but haven't looked it up).
Next.js is great as long as what you're building is not much more than a landing page, or you're proxying to a real backend system (by another team, etc).
Trying to build a "full stack" application with just Next.js is suiciding everyone that comes to the project after you leave.
I spent a week learning Laravel and modern PHP for a project that never materialized. I am so grateful the project never materialized, because for all the past 2 decades of improvement PHP remains a language I never want to work with. There may be some details in "A Fractal of Bad Design" that no longer apply, but the phrase itself still very much applies - PHP (and Laravel) remain a fractal of bad design.
PHP was my first language back when I was a teenager in highschool - it all started because I wanted to get some data from users and store it (I just knew basic HTML and CSS back then), when a friend mentioned he used a PHP snippet to send an email from a website. That sounded like magic to me so I bought a book on PHP and my mind was blown by the possibilities.
Several websites and years later I had a pretty good understanding of backend/frontend concerns, web security, SQL and databases... although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT!
After University I then started working as a software developer doing full stack work (mostly Java & Python backends) and Angular, then React for frontend.
In many ways I prefer TypeScript + React in the frontend with a Java/Nodejs + TS GraphQl backend, but I remember the speed with which you could get a website up and running, self contained, with no CI/build/deploy issues and it was the best thing ever to learn really
I'm almost curious to see what it'd be like to build a website super professionally now with PHP, but I'm pretty sure it'd feel very similar to typed python or Java
Hey, I'm the author of the post. A while ago I made a video where I built a small but serious hobby project in PHP with Laravel. It was a five hour recording, but I condensed it into a commentated 20-minutes timelapse: https://www.youtube.com/watch?v=mmtVkDh9RGw
Which leads me to start to think if there is a way to make timelapse videos that filter out some of the too quick movements, like windows and dialogs opening ... to make you mostly see how the code grows. App idea perhaps? :)
I think the amount of front end building we do for the web nowadays is absurd. We transpile everything - JS, CSS HTML, and then we bundle them in odd ways to circumvent all kinds of issues. The way we make webpages is so disconnected from the technologies that browsers offer us.
Makes you wonder when people are going to realize that we're way past serving static pages and don't need the next big front end tool, we just need a better way to run actual applications in the browser.
> The way we make webpages is so disconnected from the technologies that browsers offer us.
Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React apps almost always leverage the capabilities of of course HTML/CSS/JS, history, AJAX/HTTP, cookies, and so on. As the JS distributions evolve, the build systems do too in terms of output.
Maybe I misunderstand something, but in general the idea that just writing vanillaJS or some analogue would be sufficient to deliver the quality of apps enabled by frameworks (and talented devs) seems a bit naive to me.
> Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way;
React is everything the web (in its initial conception) was never meant to be.
HTML was meant to be used for static documents. CSS (single file, linked to by all documents) was meant to add styling to all those documents. JS was meant to add simple interactivity to documents. Navigating between documents reloads everything and no state is kept (other than user sessions of course). We broke every single one of those concepts and the way they were meant to be used.
Now, our HTML consists of a single index.html with a div#app and primarily content in the <head>. Elements are entirely generated by JS. Most of the time you just load a single big JS file that contains everything and navigating just replaces elements, state-wise you're still on the same document. We want all kinds of fancy CSS features that won't be implemented for another 25 years so instead we use transpilers. That is, if we don't include our CSS in the JS. Did I say JS? I meant JSX, because we don't even write HTML directly anymore. The point is, we don't use any of the 3 the way they were meant to be used.
We've built layers on top of layers of abstraction to be able to add a level of interactivity that was never meant to exist on the web. Instead of coming up with a new way of building actual applications that meet all our needs, we keep (poorly) patching old technology to get it to play nicely with our modern needs. It's a constant fight and a gigantic waste of everyone's time. We can do better.
Sometimes the best platform is the one you have though. It’s not conceptually good, but its ubiquity is good. Slowly we creep towards HTML/CSS/JS as solely a compile target haha.
Also, just because of tone-death in text, I’ll say I agree with you! The web as an application platform is a bodge. Humanity loves bodging though!
So? What does that have to do with "technologies the browser offers us"? The browser now offers a thorough set of DOM bindings in JS, which is definitely not meant to be used for static documents. Quite the opposite.
> CSS (single file, linked to by all documents) was meant to add styling to all those documents.
That's still how it works?
> JS was meant to add simple interactivity to documents
Before the DOM, sure
> Navigating between documents reloads everything and no state is kept (other than user sessions of course)
Which was horrible UX
Everything you go on to say seems to be some puritanical bend on never evolving software. The platform and its usage have co-evolved, and now we have a complete app distribution platform where a 1MB bundle can deliver equivalent functionality to an app taking hundreds of megabytes on the phone platform, except this 1MB bundle can support screen sizes from the smallest phones to the largest desktops.
I genuinely don't understand what kind of complaint this is:
> We've built layers on top of layers of abstraction
Should we go back to writing Assembly? Wait, isn't this a higher level than machine code? Wait, isn't that still interpreted by the CPU into microcode? ...
> Instead of coming up with a new way of building actual applications
Honestly, I don't get it. We did come up with a way of building actual applications, it's called the browser, using HTML/CSS/JS. I don't care that some people write it in a file called .jsx or .tsx - is using TypeScript also offensive to you? - I still deliver a static HTML/CSS/JS bundle to users. That seems like the ultimate validation of the original concepts in those technologies, they are so expressive that we're able to circumvent the need to start from scratch yet again, instead evolving themselves to be a performant, compact app delivery platform.
> It's a constant fight and a gigantic waste of everyone's time
The gigantic waste of everyone's time is thinking that starting from scratch will solve more issues than it will introduce. Good luck writing a new platform that supports not only many classes of devices and small packages, but also doesn't kill accessibility features, screen readers, and billions of man-hours of development that still works today.
This is better than it was. Not sure what kind of person simultaneously argues "we can do better" and then rails against the evolution of usage of technologies that... made them better
> > HTML was meant to be used for static documents
> So? What does that have to do with "technologies the browser offers us"? The browser now offers a thorough set of DOM bindings in JS, which is definitely not meant to be used for static documents. Quite the opposite.
I think they mean that syntactically, HTML is best suited to static documents, since that was the original design consideration. While the DOM has had things added to it to make it work as a declaritive UI language, that doesn't change the fact that the HTML spec at it's core is very focused on information hierarchy, typography and print-style layouts.
--
> > CSS (single file, linked to by all documents) was meant to add styling to all those documents.
> That's still how it works?
Yep! <link rel="stylesheet" href="./style.css" /> on every document, and you just keep adding to that file. (Not advisable but possible)
--
I could totally see us building a BETTER target platform; imagine a declaritive UI language that allows binding nativly? No "JS Main Thread" blocking weirdness, and frameworks would all use it making views/templates/components intercompatible. HTML is a weak solution to the problems modern web development faces...
BUT it's also a globally available solution making the annoynaces that come along with it just acceptable enough that we'll take the extra step to emulate a better platform with frameworks. It's available everywhere, and global change is hard or even impossible. It's working with what we have and I think that's good. But pushing for something better is also good. :)
Haha we had the exact same experience. My mind was blown by PHP as a teen and I even made decent money in high school making websites - all without ever setting up a local environment.
I didn’t keep doing dev work and had a different career but changed back to development a few years ago (also mostly TS). I’ve also been curious for a while about what it’d feel like to start a new project in Lavarel instead of Next.js or Sveltekit like usual.
> although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT!
That was serverless before serverless was even a thing.
However it came with its fair share of problems. One being that to be usable on a wide range of hosting providers, applications had to be written for the least common denominator.
I started my career with PHP. Created my own apps, created client websites etc. Full of footguns, but I didn't know any better. Once I learned more languages, I never used PHP again. I actually started to feel like I'd been fooled into using PHP.
Now the small PHP community keeps trying to justify their language choice with articles like these and comments like the ones on this submission. They claim it's a no brainer to use Laravel for new apps, because it has a big ecosystem and good ergonomics, and pretend that this description somehow does not apply to hundreds of other frameworks. They claim that the article A Fractal of Bad Design (which was really cathartic to me when it came out) is out of date, but when I look, all the old footguns are still there, all the problems with the standard library are still there and stdout still writes directly to the browser. The foundations are rotten.
Go ahead and use it, I don't care, but stop trying to convince me to use it.
And now the downvotes begin. PHP devs hate dissent it seems.
I don't wish to be the bearer of bad news, but nobody is trying to convince you to use it: nobody cares what you're using for software development... and you're working with out of date information if you think that A Fractal of Bad Design is relevant any more. PHP has evolved a great deal over the last decade, as have the people using it and as has the ecosystem.
Personally, as my username might hint, I've been using PHP for a long time, and, as I've commented on HN before, I would not choose PHP if I was building an engineering organisation from the ground up, and I do not use PHP professionally at the moment, but I absolutely choose to use PHP for my own projects and can enthusiastically say it's a great language in 2023.
If you're not willing to try out modern PHP, that's fine, but ranting and raving about PHP based on your experience more than a decade ago is not relevant any more, given this is a post about the improvements made in the last decade. Many people with experience beyond PHP think PHP is a great language today.
> They claim that the article A Fractal of Bad Design (which was really cathartic to me when it came out) is out of date, but when I look, all the old footguns are still there, all the problems with the standard library are still there and stdout still writes directly to the browser.
You can quote yourself ad nauseam but that does not turn your incorrect statement into a correct statement. If you spent any amount of time looking at a modern PHP codebase, you'd discover that the type of code people write today is radically different to the type of code you'd have seen at the time A Fractal of Bad Design was written. There are still aspects of modern PHP that stand to be improved, absolutely, but that's true of all languages.
No, my argument is that most of the footguns described in A Fractal of Bad Design have been long since fixed and those that remain are being removed as and when it's feasible and the PHP community has matured a great deal to the point where the remaining footguns don't really apply in modern codebases because of libraries, static analysis and testing.
Spend any amount of time actually using PHP and you'd discover that it is meaningfully different to what it once was. It's far from perfect, and still has a long way to go, but if you reflect on where it was and what had to change to get where it is today, the improvement and progress has been excellent.
So dramatic. No one cares what you use, and I suspect you could just not read articles about PHP and voila your problems would go away. Choose your own destiny!
You have to ask yourself why such a large proportion of work gets done in two objectively bad languages, PHP and Javascript. They dominate the space. I think it tells us that it's not actually that important to have a 100% perfect language, when it comes to building stuff.
tbf, TypeScript has taken over a huge part of the JS ecosystem, and while doing so has fixed lots of common "meme" gripes with the language. It has also introduced new issues, but alas, the web is typesafe.
Learning PHP though is exactly as the article describes. I had to do it in college and even using a modern version of PHP, the language felt as if it had been written by 3 first semester students under pressure to meet a deadline.
> You have to ask yourself why such a large proportion of work gets done in two objectively bad languages
I did ask myself that, and I came to the same conclusion as the author of "Fractals of bad design": The majority of work gets done by amateurs and amateurs, per definition, don't know any better.
> And now the downvotes begin. PHP devs hate dissent it seems.
I mean, write stupid comments win stupid prizes?
> Now the small PHP community keeps trying to justify their language choice with articles like these
How would you expect people to react when you frame it like that. I assume you're one of those people that think you have good opinions, but wonder why others don't want to hang around and hear them.
I'm sure theres also still tons of skilled engineers for Perl around. Or Fortran. Definetely Java. But the TIOBE index looks more like taking inventory of existing skill throughout the industry and less like it tracks disruptive trends.
whats your metric for a large community? internet traffic? github projects? number public repos? number of packages? by every metric i can think of php is has a large community, not as large as java or python but still large.
how twisted does your dislike of a language have to be for you to not even acknowledge that a lot of people use it
I don't get how people can say that. WP is almost ~50% of all websites. PHP is ~80% of the websites. There is a whopping 30% in between.
And moving WP to a 'modern' language (whatever that modern means) is not something possible. ~60,000 plugins, similar number of themes, 30% of all ecommerce websites, billions of dollars of businesses with dependencies ride on it.
> Right now, WordPress only has beta support for PHP 8.0. Now, to be clear: PHP 8.0 was released in 2020, and is now end of life, three years later — and WordPress doesn't yet support it…
There are dozens of alternatives better than WordPress, if upgrading it meant a complete tooling change I think many would take the opportunity to replatform to something else. The only thing WP really has over them is it's expansive plugin library, and buy in from clients.
But it's not really up to devs. I don't think many devs believe it's the best system, but it is desired by clients very often.
> The only thing WP really has over them is it's expansive plugin librar
The expansive plugin library that WP has is due to its ease of use, stability and the extent it goes to acommodate users, developers and businesses at the same time. Its no small factor, its no small feat.
You probably dont make content sites. The reason PHP is still relevant today is because no other language has CMSes as good as those from PHP. And i dont mean WP or Drupal.
Craft, Kirby, Twill, October, Grav, Statamic, Bolt, Processwire…
All of those projects have big active ecosystems around them and are used for serious projects. Most other languages dont have a single CMS. There is no CMS in Go or Elixir. Javascript have some but they are super immature and mostly hype. Python has some super ugly ones based around Django.
Now people may look down on these PHP cmses but many web projects like ecommerce grow as extensions of CMS. And most of these CMSes are suited to this because they are nice web framework with customizable admin area. So it often doesnt make sense not use PHP.
Out of curiosity, what language are you using for backend now?
Not a fan of PHP like most of professional PHP devs, I guess but the utility of Laravel for example is unbeatable IMO.
It’s funny because when I think of “fractal of bad design”, Javascript is the first thing that comes to mind. I love Javascript but it makes me ask “why?” a lot.
PHP is kind of the same league, a lot of hate comes because some senior employee told a bunch of juniors after years of working in Wordpress that PHP is a garbage language and you should not touch it. "It's cool to hate PHP!"
PHP can make absolute garbage, and it can make a elegant product. Just like Javascript can. And same with Python and Ruby and what ever else everyone recommends.
It may be a lot harder to make garbage in Rust, but it's possible. PHP has a problem where it gets out of your way, gives you the entire toolbox to build a house. But the problem is which one of the 17 types of hammers do I use to hammer in one of the 104 different types of nails. Where as Ruby, gives you 3 hammers and 4 different nails, and 7 magic nails that appear after you're done hammering.
I hope you realize that "fixing" these types of early mistakes is almost impossible for PHP, a language which tries hard not to break things, especially something that's going to be used everywhere. But if this is such a deal-breaker and your IDE is dumb as a stump and can't remind you nothing prevents you from wrapping the stdlib or using something like psl to do it for you.
I think fixing as in "removing and replacing" is indeed impossible, but defining a new convention and making alternative names for the same function would work fine.
Let's say the new convention is that functions are named str_*(), then keep strpos(), but create a new one called str_pos() that is the same, and mark the old one as deprecated (but don't remove it).
I am sure there are edge cases where both str_* and str* exist already and do different things, but we can figure something out.
Notice that lots of (probably most of; maybe even all) examples in the linked talk are due to unreasonable inputs. `true + true` doesn't make sense; `{}.toString().call(new Date())` or `+[] === +![]` don't make much sense either. This is just not what developers do. Meanwhile, iterating over arrays is absolutely what developers do, on an hourly basis. Which is why I said that javascript doesn't have things like that — the papercuts it inflicts on you hour after hour after hour.
Laravel's Collection class means I don't ever touch a raw array, and I've never had a "left-pad" scenario happen to me with PHP. Both languages have their warts; neither's tends to be an issue in actual practice with an IDE and experience.
Many of the statements in that article were misleading or outdated already in 2012, though. E.g. the part about PHP being tied to Apache… At that time I had been using php-fpm behind nginx for years.
I didn’t go back to all the points, but I get the feeling the configuration and security parts are mostly fixed, while the functions related issues and type looseness stayed mostly the same.
What really struck me was the statement: "In total, $580,000 was raised in 2022
The Foundation pays 6 developers to work on PHP" which made me realise how easy it is to take for granted the development and maintenance of these open-source languages and ecosystem as a whole.
Say what you will about PHP, but we all rest on the shoulders of the incalculable effort that goes into the software we use everyday without thinking twice, and is something I'm very grateful for.
Similarly, cURL has been maintained by Daniel Stenberg for nearly 30 years. Billions of installs, every major tech company probably uses it... labor of love.
Absolutely, writing modern PHP with Laravel as a framework makes the whole language feel totally different compared to just even a few years ago. I do also really like the statelessness of how PHP is ran.
At the day job we are using it to serve tens of millions of API's a day, without having any issues concerning stability and/or scalability.
The video from that site (also https://youtu.be/x9bSUo6TGgY at youtube) is really quite well done. I wish more language comparisons were done in this way, with two speedy minutes in an editor accompanied by taut voiceover. Very impresssive!
I used to work way back in the day on PHP too, but even though I'm sure this will be downvoted, it's really sad people still take it seriously as a language in 2023. There's nothing remotely elegant about it. It's not expressive or programmatically succinct in the way Ruby is. It's not beautifully well thought-out the way Python is. It's not fast and modern in the way Rust is. It's not elegant or composable or client-side renderable in the way React.*script is. It just brings nothing to the table. It's an ugly hodgepodge borne out of an over-engineered homepage from 28 years ago. Various business interests have kept it afloat, and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
This is your issue - PHP < 5.3 is very different to PHP 7+. Not just at the language level - but the community, frameworks and best practices too. No more random scattering of SQL statements in HTML files!
Modern PHP (with a framework like Laravel or Symfony) is probably one of the most productive ways to build web applications.
> It's not beautifully well thought-out the way Python is.
This is definitely an interesting take... Python hasn't even solved package management yet. And the 2.7 => 3 migration is probably the most famous example of making a mess of an ecosystem with backwards incompatible changes. In contrast PHP has Composer and 5.3 code is pretty much compatible with 8.0 (although ideally all code from the 5.3 era should be burned at the stake).
> and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
You've basically just said that PHP devs are too inexperienced to be able to scale a codebase past 10k LOC? Pretty much every serious web dev using Symfony/Laravel would disagree with you.
Sure, there's been a lot of progress since the PHP 5 days, but the core of the language has been left mostly untouched by design, and we haven't seen the kind of drastic moves like JS moving to ES6 syntax.
It's a matter of taste, so there's no absolutr truth. I hate PHP's function and property access syntax differenciation and wildly prefer ruby's approach or instance. And there's so much more nice things coming in languages that have been designed from the ground up to be nice to use.
I understand PHP's pragmatism, but can't find it pleasant to use TBH.
PS: we got arrow functions, but they stay limited to anonymous functions for instance...
Maybe PHP can add a "stricter" mode that gets rid of all the cruft? Enable it per-file, allow it to simmer for 10 years, remove legacy support in PHP 12.
This would really help in a lot of way IMHO. PHP has good aspects, getting rid of the weirder one, even if compatibility gets sacrificed, would be a boon for building new applications.
I’m in agreement with you that it came a very long way.
Now, most of those have been present in many other languages [0], often with less limitations.
And as usual the old ways haven’t all been deprecated either, so it stays weird. For instance typed properties were a chance to reset the clock on type handling, but no, declaring a type will force cast parameters to that type instead of throwing an error (i.e. passing 0 for a string argument will convert it silently)
[0] Constructor property promotion isn’t, but TBH I’m of mixed feelings about it. We get conciseness in exchange for weirdness as the properties aren’t declared outside of the constructor, where they would be otherwise. I wished it was done the other way round.
Yes, except it has to be set on the _caller_ side.
I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the strictness set. [0]
So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.
[0] Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system. And it still doesn’t work for native functions.
> Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system
There was this RFC[0] but it seems to have fizzled.
> And it still doesn’t work for native functions.
The page states: 'Function calls from within internal functions will not be affected by the strict_types declaration' (emphasis mine). Outside of array_map I don't think this happens all that much.
> So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.
That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?
> That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?
It is completely unelegant, but works decently in practice (fits the subject perfectly…). We’re extensively using phpstan, especially as it’s the best way to expose in array types.
Phpstan still has blind spots, including the ability to disable it on the caller side (in particular, as far as I know you can’t disable specific errors inline, so if you have to do it for one parameter for instance, it applies to all parameters), and the option to overwrite a variable type just for phpstan. Those comes from developer error, but that’s exactly what we want to protect the system from.
Actually checking at runtime that a value is of the right type is more secure.
Yes, the backward compatibility is a crux on the one hand, on the other hand it has made upgrading PHP versions a breeze. In the past 6 months I updated several code bases from PHP 7 / 8.0 to PHP 8.1 / 8.2, the PHP part was easy (just the deprecated dynamic properties in 8.2 caused a wall of text in our loggers), the framework was a bit more difficult. The most problematic were the exotic packages that the clients had installed ages ago and that are not properly maintained anymore, so I have to figure out a replacement for those code modules.
Constructor property promotion is fine, I think. I think it ties in well with the readonly property.
public function __construct(
public readonly Company $company,
)
{
}
There's just so much info & functionality + type safety crammed into there that wouldn't have been possible previously; it's really nice.
The one feature on PHP that I wish was more commonplace is the `use` keyword in function expressions as it is one of the few ways to limit what names are in scope at a given point in the code
IIRC Rust's `mod` declarations can behave similarly.
GP’s take was way too salty, but to be honest I understand where he comes from.
Yes, it’s a matter of personal preference, but I also never worked with people that thought PHP was beautiful. Not that we look down on it, but it’s probably the same feeling construction people have towards their white vans. We value the good parts, hate the jagged parts, and if tomorrow it made more sense to ride Miata for whatever crazy reason, we wouldn’t look back. But I’m not holding my breath to have any decent reason to get out of PHP at my current job, and I appreciate the reasons why.
> No more random scattering of SQL statements in HTML files!
And yet you will still find this, because the long-tail of bad PHP is near infinite.
> although ideally all code from the 5.3 era should be burned at the stake
I guarantee you that a decent amount of real PHP coding right now is maintaining legacy stuff, not the new fangled 8.
It is, of course, the same in the Java world - most of the day job is not using Java 17. It's just that Java 6 code forced onto Java 8 isn't as bad as PHP 4 code hacked into PHP 5 code still struggling along in PHP 9. (Especially because as a scripting language, it will more likely fail at runtime, not build-time).
Sorry to be dismissive, but elegance, expressiveness or succinctness are not mandatory for "making things". Gatekeeping a programming language on esthetics is quite shallow in my opinion.
Ease of use and deployment, breadth, availability, low cost of maintaining, are sometimes more important, and PHP offers plenty of value in these respects.
I don't want to work with it, but I will never presume to look down on people that do. PHP has been a cornerstone for a whole generation of programmers and I think the current web-development ecosystem would not be where it is without it.
It doesn't matter what happens, anytime something good PHP is mentioned the thread always turns into a fight. Why can't we just stop gate keeping programming languages and let people enjoy them. PHP gets tore apart all year long, and 1 nice article comes out and everyone jumps on it like it's preaching Delphi or VBA.
PHP has continued to done wonders for me, I continue to write huge apps in it, I continue to love it. I've used every other language you wrote, and continue to this day to write in PHP. Not because I'm not able to grasp how good another language is. But because it works. If I need something I go to packagist and search, it's always there. If I need to deploy something, there is tons of ways, and even basic ones. I don't need no fancy deployment setup, but I can have a fancy deployment setup if I want.
But people are more then welcome to hate it, and every time a positive post comes out about PHP I will continue to post my statement and then carry on building stuff. As there is ALWAYS a negative comment.
Everyone's at a different step in their journey. But I do agree if you're building stuff then exactly, who cares? End of the day it's definitely about what's built, not how.
HN does a lot of stuff well, but there is a ton of gate keeping here and PHP is one part of it. It does not deserve the hate it gets, it's popular to hate PHP here. It's actually less popular to like PHP. So articles like the above always get torn up.
It's rather sad to see, we should be encouraging people to build however they want. Point students in the direction of best practices and discuss ways to improve. Rather than talk about how much we hate the fact that PHP continues to be in the top 10 and pretty much the entire web is built with it.
I’ve made a few “serious” projects with PHP and has been great, I never feel like I’m fighting against it to do what I need to do, the code can be very concise, its very fast and has a lot of batteries builtin.
Python is not beautifully well thought out, the syntax is awful and the version conflicts make it a mess.
You’re comparing to React which is not a language or in the same domain is confusing and makes me doubt your credibility.
React isn't a language, it's an elegant pattern layered on top of (Java|Type)script which are languages. Not sure what versioning conflicts there are with Python but there are a lot of community solutions in the form of pyenv, virtualenv, etc. Python is well thought-out, imho, but I think it can take a certain type of person time to realize it. I used to hate it but the way I ultimately came around to understanding it was someone explained to me it's essentially extremely close to pseudo-code, which I think is ultimately why it can seem very natural and why so many universities and the larger STEM/ML community have all adopted it.
That's such a strange statement, you can compare PHP and React because they both can return a HTML string? Even though one is built entirely within another language, and it isn't is not a "language". More of a toolkit. Same as say Symfony html framework is.
Many of those questions have answers that point out you are comparing two very different things. Some of them are explicitly comparing Laravel and React, which makes a bit more sense. The rest seem to be AI generated trash.
The easiest way to explain it is that you could reasonably use react within a PHP project.
I wouldn't use the term "idiot" but rather "ignorant". A good article that answers the PHP vs React question would be mostly explaining the differences in the function and usage of both tools.
For reference, I'm working with both React and PHP. And yes, for example WordPress uses React components.
I'm a 42 year old software architect. But hey, maybe I've been ignorant all this time.
React vs PHP is a decision you can make, because... the intention of both is to output HTML.
edit:
> The easiest way to explain it is that you could reasonably use react within a PHP project.
I can use C within a Python project. Does that mean I can't compare the two? One is compiled while the other is interpreted, so maybe you can't compare those?
> React vs PHP is a decision you can make, because... the intention of both is to output HTML.
Often PHP is used when no HTML rendering happens at all (Apis, scheduled jobs etc.)
> I can use C within a Python project. Does that mean I can't compare the two? One is compiled while the other is interpreted, so maybe you can't compare those?
Those are at least both programming languages. Several major python libraries are written in C (or other compiled language) so a pure python project is probably fairly rare. Someone asking for "Python vs C" is probably more in need of an explanation of what the broad categories mean and tend to be used for than a point by point breakdown of specific language features and ergonomics.
In this specific instance, the complaint was that PHP, a server side language, doesn't offer client side rendering built in. This a point that should be brought up comparing JavaScript to PHP, not React.
If you complain your tesla doesn't float very well, then you might be a little ignorant of what cars are used for (and that you probably should have used a ferry.)
React can be used both on the server and client side. That is a benefit over something that can be only used on the server side.
React can even be both on server and client using 1 codebase (see Next.js). But it seems the PHP police here on HN does not allow me to compare that solution to a solution in PHP.
It's funny how we both think of each others statement how strange it is.
For me, not being able to compare the two is like saying: You cannot compare a horse with a car as a means of transportation because a car is not an animal.
For me, I don't care one is a programming language and the other is a framework. For me they are both ways to generate HTML. PHP was/is mainly intended to generate HTML. It started as "Personal Home Page" and now is "Hypertext Preprocessor".
Yes, but that doesn't make it a programming language. A lot of things can render HTML. I am pretty fluent in Javascript, HTML, CSS, jQuery, React, Nodejs, Nextjs, PHP, Python, and a beginner in Java and a few others. React is not a programming language.
Someone who worked with Python / Django and JAVA / Spring for years professionally, I see PHP / Laravel as absolute superior way to build web apps, especially if you are in a team and people might come and go.
> and people who don't know any better keep championing it
Experienced developers understand that there are different tools for different jobs. They also understand that languages are not successful for 30 years without providing some legitimate value.
I think that PHP isn't that bad for some use cases. What I really disliked about PHP as a developer was how much control the host has over tweaking the runtime; this can be"problematic" in some shared hosting setups.
However, I'm also a bit of a hypocrite here because I worked for a hosting company, and also loved that feature.
So, I think in the context of something like a container (or vps/dedicated) it can work well.
I think PHP gets a lot of hate because it used to be a nightmare. I know friends who still use it, and they claim it's a day and night experience from the olden days. It probably wouldn't be my first choice for a project, but I probably wouldn't groan either, if I had to reach for it now
I agree with all of those points, except that it does have one thing going for it - it is easy for end-users to deploy PHP apps: FTP your files onto any random cheapo shared web-host, done.
I’m amazed that it’s been so long and no other language comes close to that :(
Re-deploy, sure. Deploy? PHP packages still need installing, modules need enabling/configuring, PHP version needs to be chosen, etc. Unless it's a tiny project, the days of "just put the files on FTP" are almost gone.
Meanwhile for small, low traffic projects, serverless services are pretty close to the "just copy to deploy" model. And fly.io is all trivial for quite a few frameworks.
Compared to moat languages, if you have no visitors, php takes up 0 system resources from your system to just sit there and wait.
So you could have hundreds of small sites on the same machine for an extremely low resource cost. That is something it brings to the table and its very beneficial for hosting solutions where there are a lot of small webaites sharing on the same resource.
I might be misinterpreting "taken seriously" with utility, but to me it is very valuable that a PHP script can just be dropped on almost any web server and it can start doing stuff, and that alone is reason enough not to not dismiss it.
I used to agree with this and think of it as a main benefit, but setting up a server to use Nodejs is easy and a lot of servers come prepped with node, npm, etc, so it's just as easy ad starting up a PHP project, if not easier because package.json can easily install dependencies.
Kinda, you have to make sure all the extensions you need are installed, then fix php.ini so it's not doing anything wrong, and then it usually works if you haven't missed anything, until something becomes deprecated.
It's more productive as Ruby and Python and much faster than either? Is that not reason enough for some to choose it? I'd argue that of the PHP, Python, and Ruby it is Ruby that should die. It's the same use case as Python, but harder to read and just as slow.
PHP had design flaws (many of which have been addressed since the 5.x days), but what language doesn’t?
A significant cause of it’s bad rap is touched on briefly in this article, Wordpress.
Even back in 5.3 days, you could write elegant and scaleable code, it just took work to do. At a former employer using PHP 5.3 on 2005 era hardware, we could do 500+ req/sec per machine with an average response time under 100ms and a P99 response time of under 250ms, with a zero downtime SLA and hundreds of millions of requests per day. Yeah, it wasn’t easy, but it worked.
As a dear friend used to say, PHP is a ball of nails. You throw it and it sticks. Just exercise care when picking it up and all is well.
> we should show this comment to facebook that uses hack (php originated lang) in millions of files to run their little website and infrastructure.
Appeal to authority isn't a valid strategy.
Facebook used PHP because they wanted to build something really quickly and afterwards it became too costly to switch, as it always does, so they built an entire engineering department to work around PHP issues.
Your average PHP dev team can't do that.
Plus, what are you comparing it to? Reasonable people don't compare it to Vlang, they compare it to Python, Ruby, Java, C#/.NET, Javascript/Typescript, Golang, and PHP ranks at best averagely against those regarding language, standard library and ecosystem consistency.
appealing to authority? lol.
no. read my comment again.
it shows real production example of a juge, complex, website that serves billions.
average php devs can't do that? maybe. but the php lang doesn't block them.
The language is valuable and a good choice because it’s easy to read and your codebase Be(when used with a framework) are very maintainable. We have Java Perl and python and php has been the easiest to get people working on existing code.
I loved the straightforwardness of just having a nice simple HTML page with some <?PHP ?> sprinkled in. Now everything has to be done through a million layers of indirection. Which is fine when it's necessary, but I still like to write my own pages as simple unstructured PHP.
I agree with the author about the superset, this is how it should be done. The current PHP type system has many weaknesses (e.g. generics, typed collections, etc.) that aren't easily solved, and I don't want to use some static analysis tool that relies on comments to type my code properly.
PHP has always been and will always be my goto language when it comes to personal projects.
I don't use it professionally, but it's such a breeze coming back to it whenever I work on my own stuff.
And the ecosystem (especially Laravel) is light-years ahead of ANY competition in ANY language in terms of ease of use while still having all the necessary features.
It's the only language for which I always read the release notes because it's so exciting to see it become even better as the years go.
I learned programming with PHP back in the mid-2000s, and worked professionally with it until about two years ago. I haven't touched it since 7.4 or so, except to help some friends with WordPress sites and such.
It might be me getting old and grumpy, but PHP seemed to peak in terms of usability and syntax around 7.2. Lots of the new type syntax in the article is... inscrutable to me. I'm all for strong typing in general, and I don't miss the type coercion and weirdness of PHP, and I'm glad to see it continue to move forward. It's just the syntax.
Back when PHP 7 was being discussed, I followed the arguments on the mailing lists closely and was rooting so hard for those advocating adding much more explicit and strict typing, and I remember me and a coworker getting rather upset at the old timers like Zeev who were adamantly opposed (and who mostly lost the fight). I'm only 33, but I've got nearly 20 years history with PHP, and I suppose now I'm the old timer.
My last project in PHP was forced by business concerns to support PHP 5.4 through (at the time I left) 7.4. The massive pain required to make that work might have colored my perceptions of the whole situation.
Maintaining a legacy project might as well be a different language entirely than building a fresh project with modern PHP. I've been doing both, maintaining and modernizing a 17 year old PHP codebase, while building fresh apps with Laravel. And I would say the language is certainly not the limiting factor, but rather prior decisions causing debt.
I used PHP in my university days, 20 years ago, and went on to build a few websites with it that I still run today e.g. https://caption.me
It was a fantastic student language - the docs were great, the code was simple and imperative, there was loads of prior art online. It was empowering to tweak code and see immediate results in the browser.
These days I prefer the strictness and ecosystem of Scala on the back-end, and the developer-friendliness of ReactJS on the front-end. And I think the separation of concerns (model-view-controller) is helpful.
So I am gradually migrating caption.me PHP code to Scala/ReactJS. A migration like this can be done piece by piece. After implementing the back-end for a feature in Scala, I write the ReactJS component, then alter the PHP code to render the ReactJS component tag in place of the former PHP implementation, then use some simple javascript plumbing for the React DOM binding.
I have a Grafana chart that shows the number of lines of PHP code remaining, so I can track my progress over time. It's quite satisfying.
If you are the sole developer working on migrating the project and you want to have the frontend in React.js why not use Node.js/TypeScript instead of Scala for the backend? This would save you from context switching between two languages and consequently increase the development speed.
Also why the rewrite? If it works (in PHP) it works. Perhaps instead you could maybe add some frontend JS for better caption UI/UX?
Does everything have to be done in React nowadays, as opposed to plain static HTML? (Speaking as a React/Node dev myself)
I tried Node.js on the backend but it didn't have the expressiveness and ecosystem of Scala.
I run a few simple Node and Python apps behind the scenes of caption.me, but for the core code, I want the power of Scala, its functional style, rich type system, monadic composition, immutability-by-default, avoidance of nulls etc. As well as great libraries like http4s, Doobie etc, Scala also gives me access to the entire Java ecosystem.
The PHP->Scala/ReactJS rewrite is partly a learning and experimentation project for me. I use Scala in my day job, and when I make technical/architectural decisions, I benefit a lot from the stuff I've learnt in my side projects, particularly on the front end side.
PHP has had its day in the sun (as shown in the job market trends on https://www.itjobswatch.co.uk/jobs/uk/php.do ), so I think it's more valuable to get exposure to modern languages as I still have a few years of professional coding ahead of me :-)
The shade cast on Wordpress at the end is the article is a little disappointing. Ok, they’re behind on versions but for many years there was not much progress in PHP. Now PHP is flying and dependent projects are not keeping up. What can the PHP team do to help facilitate?
The fact that WordPress doesn't run on PHP 8.x is honestly the least of WordPress' problems.
There are MANY reasons to cast shade on WordPress, it's an absolute pile of garbage from top to bottom.
I recently developed a WordPress plugin as a personal project for my blog and it just puts in light how bad this software is, from non-existant documentation (on 10 years old functions?) to practices that were already not recommended in PHP 5.
WordPress as a product is great, but WordPress as a technological piece is absolute garbage, made by grossly incompetent developers.
It's not the PHP internals team's responsibility to prop up a private company (Automattic, who owns WordPress) who are lagging behind on maintaining their product and ecosystem. They're already strapped for resources as it is.
Because people can make whatever decisions they want based on their own list of tradeoffs. I can tell you from experience laravel is far easier to get going than any c# or Java framework. You can SPRINT through a project in laravel and then break it into pieces after the fact.
I would pick it if I wanted to launch something new without getting stuck in premature optimization hell. Bigger org I probably would not unless I was building an isolated POC.
Personally I'd reach for PHP because I think Eloquent is a great ORM. I've built applications with Eloquent, Doctrine, Entity Framework, and Prisma and although I'd prefer to write my own SQL queries when working with a team that has little to no SQL knowledge Eloquent has been one of the best ORMs I've used.
Why "locked into"? When choosing JavaScript, you're locked into JavaScript (and Ecma International), when choosing Kotlin, you're locked into Kotlin (and Jetbrains). You're always "locked into" the language and its ecosystem, no matter what you choose. I don't find that to be a real argument.
Speaking of which, how good is .NET on Linux nowadays?
I know it was possible for a long time (with the release .NET Core), but heard it was kind of broken/cumbersome on Linux. Maybe now it's easier to just develop an ASP.NET app, host it on Linux and use Posgres/Mysql instead of SQL Server?
In the front end you have no choice but in the backend you have all the choice into the world. No you’re not always locked in the backend if you have a decentralized system where each service can be based on a different language but yea, I don’t like Java or Java like languages so I will never use especially one maintained by microsoft.
PHP runs a lot of my projects.
Always grateful for the effort that goes into it.
Deploying is very easy using git. Composer makes it easy to install libraries.
For the makers: with these packages you can easily make a nice blog/site with minimal amount of code and files.
seems like 2023 is finally the year to pick up PHP and get that limbo.
just kidding, I am getting paid multiple times the salary of PHP devs by shipping JS blobs to Lambda functions that render HTML and have DB calls in between them. Totally different from how PHP works, last but not least because I can have a fancy AWS certification for configuring things instead of FTPing a .htaccess file!
sarcasm aside, I really think with cutting edge serverless we are ending up where PHP has been like forever, just with _much_ better tooling and processes compared with FTP-deployments.
These days - I use swoole/openswoole with any PHP project.
it brings connection pooling, async, concurrency, event loop, io parallelization and much much more.
Started my career as a PHP dev, I dislike it so much I migrated to JavaME and Blackberry development. Then to Android. Best decision ever to ditch PHP.
My main issue with this report is that it gives all figures without any context:
- $500K in the foundation. Is this a lot or not, compared to other foundations? Is this more or less than the previous year/last decade?
- 6 developers. Again, what does this figure mean?
- "many users still use old versions" -- again, at which % should the community be worried?
The only meaningful info I found was the chart showing that after 7.0, its popularity stopped falling (though, the chart should have been rendered as stacked to see the full sum of downloads).
Regarding the language, I guess people get their job done with it, but the code in the presentation makes an impression that it's the same hassle as back in 2010 (v 5.3) when I quit using it. (Used it since 1999.)
What are authoritative documentation sources for php these days? For javascript and browser apis, that would probably be mdn.io, and possibly web.dev. Any equivalents for php? php.net/manual looks like it might be it; but it contains numerous comments from years if not decades ago.
The English version of php.net/manual is the authoritative source. It covers all the features found in the latest version. Just because it contains comments from decades ago doesn't mean that the content itself hasn't been updated for decades.
I work in PHP each day. I prefer the Yii2 framework and sometimes use Symfony. For some reason I just can't get into Laravel. I tried but the rapid development speed of Yii2 really is the best for my workflow.
I miss the simple days. I want a PHP that has no classes (procedural only), stops around 5.6 for its syntax (none of these shorthand things) and fixes some of the needle/haystack and function naming inconsistencies. Just give me strings and arrays and floats/ints. I'll add in named parameters, but I think that's the only new thing I'd want to take.
Oh and for everything else in the normal PHP world, I tell people to use a framework, and for that framework I tell them to use Laravel. Period. To me it's the jQuery for modern PHP (note: I don't even code using it myself, but I tell people to have their dev team start with it)
Just hit up laravel and get building something quick and easy. I’m sure a lot of the laravel core contributors actually have some good advice for general env setup outside laravel as well.
I used PHP in mid-2000s, and then again in ~2017. By 2017, with the power of IDEA/WebStorm at my hands, it felt pretty much like developing a Java or a C# application: the stuff you needed was there, at your fingertips.
And I still prefer PHP docs over pretty much any other language doc.
As of PHP 5, it lost its way and started imitating the Java OO model with a worse botched-on syntax. PHP 4 used to be a compact "hypertext preprocessor" with many built-in groups of functions, enabling you to process forms, talk to databases or process images without much code.
It grew up from a poorly thought out hacky scripting language to a major programming language. All the nasty code you could write in PHP 4 or 5 is still possible, but everyone will look at your code and laugh.
There are many other possible directions the language could have evolved in since then. For example, an emphasis on its dynamism and statelessness rather than introducing a static Java-like OO model for building hierarchies of classes. Or a modular system that encourages the user to put “complex” code in C modules, making application development as simple as calling a few functions.
Maybe because there are already major programming languages at that level already, which arguably do things better: if you are going to have a Java-like OO model, then just use Java (and leverage its ecosystem, tooling etc). Whereas there is a niche for a quick-and-dirty scripting language for just getting something up and running.
... You can still hacky script in it, my dude. I have to do that several times a year for stuff like one-off ETL's for customer data, or to verify an idea before rewriting it properly..
Absolutely nothing about modern PHP stops you from writing like the crayon-muncher you were back in the early 2000's...
You just also have the option, to, you know, use battle tested libraries and work with cohesive community driven standards now as well.
It's a pretty dumb argument to make on the basis that no functionality was lost (There is both the MySQLi extension, and the more general PDO one), and if you really, really can't get the budget to refactor it, you can drop a single shim file in to "get those functions back" while using either of the mentioned extensions to do the actual work.
If you wanna hang your hat on that, go for it. The hacky approach the parent poster yearns for is still entirely possible, even if you have to update a half-dozen lines of mysql_connect to mysqli_connect.
Both of those are currently hobbyist projects. They may develop further and become useful to the average PHP dev, but they're definitely not there yet.
Yeah, Matt is absolutely right. I'm working on PXP as a passion project, something that I've been trying to do over the last year or so and only started to invest serious time into the last couple of months.
The goal isn't to completely replace PHP but to complement it. You can think of it like a playground for future PHP syntax. Something could be added to PXP and released in a week, PHP on the other hand has 1 big release a year. If something is successful and widely used in PXP, then it could be a contender for PHP core.
What's the point? You can use types in the vast majority of places in PHP and it works well, so I don't really see the point of that instead of contributing to the native typing system.
Javascript already set the precedent. If you don't like the way a language works, it's preferable to have a proxy language that does work the way you want that compiles to it, rather than accept the language for what it is and learn to work with it.
Javascript can't be compared with PHP, javascript is the only scripting language that all browsers understand except wasm.
And there are multiple interpreters that may work different or have not all features avail.
PHP is used on servers that can run many different languages.
Additional there is only one php interpreter that is widely used (yes there was hhvm and some others ), that means you can rely on all features of this version.
It's unlikely to happen. 10-20 years of use for many of those community generated functions is a lot to break. It may happen eventually, but I wouldn't count on it.
used php in 2015, decided that it's not that nice. last couple of months, I've been banging my head with php7. granted, it's a legacy project, but it is still the same php 7-8 years ago.
If you're inherited a legacy project thats a mess then the chances are it was written by some ass who's not following the languages generally accepted PSR standards. Proper PHP code is extremely easy to dive into and maintain.
The benefit and downside of the PSR standards is they are optional. Sadly some think they know better and opt to roll their own convoluted 'standards' that just end up creating hell for the next person to come along and have to maintain their mess.
You're just wrong. PSRs are widely accepted and all serious frameworks and PHP libraries implement them as needed. I haven't seen a PHP package in quite a long time that didn't implement PSR-4.
What statistics source are you using to determine the 'largest framework' here?
Even if we go back to the 2021 Jetbrains developer survey (https://www.jetbrains.com/lp/devecosystem-2021/php/) out of the 11 named frameworks/platforms people are using all but 2 of them use PSR and composer.
You keep making these assertations which frankly are coming across as absolute bollocks from someone who's stuck in the early 2000s.
If you actually think that you dont know the language very well. It's baked into Composer, all the major frameworks fully use it as to almost every major opensource project that isn't prevented from doing so by legacy code.
And honestly if you're a PHP dev intentionally avoiding the widely adopted standards and know someone else is going to have to maintain your code then shame on you.
if its a legacy project then of course it would be the same php from 7-8 years ago, what exactly were you expecting?
if you want to try modern php then start fresh or put in the work updating the legacy. its no different than being given a jquery project from 7-8 years ago and expecting a modern experience
Exactly my thoughts. In the end it gets up to the developers are to blame by not taking time to upgrade their projects and end up with a legacy project.
PHP does the deprecation and backward compatibility better than many languages (hello Python!) but still some effort is needed as a developer to ensure your codebase is updated. I'm not even talking about the architecture here, which of course is harder to change, but language features.
PHP 7 is actually pretty good and was the version I stopped at. Upgrading to 8 shouldn't be all that bad and mostly you can just install the new version side by side with the old one. As with any interpreted language, you have to hit every page and what not in order to see if there are any issues that will arise. I don't know if at this point if PHP has a compiler as that would save a HUGE amount of time upgrading to new versions of the language.
The ecosystem around Laravel is really incredible and unlike any other framework. They have libraries for every stage of a web application from taking payments all the way down to server management and hosting.
They even have awesome libraries like Inertia which are built for Laravel but can be used with other frameworks.
It's the only reason I still stay fresh on my PHP.