PHP in 2024 | Hacker News Reader

PHP in 2024

stitcher.io

105 pointstheThree119 comments

I was never able to move from PHP to something else. I tried nodejs for a few months but it always seemed much more complicated. Especially the dependency and build system.

With PHP to move my code to a production system I just need to run `git pull` and the new codebase is instantly live. No builds, no server updates.

The Markup system of PHP is also very very handy. No more messing with handlebars or external libraries.

Realistically you can start a small site with PHP and HTMX and no external PHP package dependencies in an evening.

I'm in the same boat! PHP is so insanely functional. There are a lot of powerful frameworks but I personally like to keep my projects very simple with minimal dependencies and nothing comes close in terms of how fast I can go from idea → prototype → production. PHP + SQLite is a beast.

Nit: Most code written in PHP is the (an) opposite, of what many people discussion programming languages would call "functional". It is procedural, and maybe object oriented, although important things are missing, like generics/parametric polymorphism.

In case it wasn't obvious from the context of the rest of my comment, I was using this dictionary definition of 'functional':

> designed to be practical and useful, rather than attractive.

It gets the job done. Really well.

Functional here means that it functions well. Not that it's a functional language.

all he said is that he can get his work done.

definition of "functional" is "designed to be practical and useful, rather than attractive"

And all I said is, that most people understand something different under that term, when talking about programming languages ...

But thanks everyone, for the dictionary definition lookup.

I spent years making money off of PHP. I was doing PHP when shitting on PHP was cool.

I spend most of my time writing GO now.

Go + htmx + tmpl is all you need for a basic site. The go runtime produces binaries... While you're still installing php and a web server, my binary is already running and in systemd.

Need validation, grab validator. Need a DB, grab sqlc and write sql and then have the code for your API calls generated for you!!! (This bit of code generation feels like magic candidly)

Need a command line tool? GO.

Have to build a Key Value store? GO

Want to build a database? GO

Do you need a container deploy system ... well Kubernetes is already in GO...

There was a magic to LAMP and PHP 4... it was the right stack at the right time. When I work in go now I feel all that magic again.

Why? Like, besides some basic cli tool, and some “system” network programming (what google meant in their marketing, as go is definitely not a system language), I fail to see any benefit of that thoroughly uninteresting language.

It’s basically Java 1.2, sold in “Unix-flavor”, somehow making it acceptable to the people that otherwise hate to touch anything non-C (and in extension, never having used anything more modern)

Why go:

I like Rust, and zig. Both end up with better performance than go. All three will output portable binary.

I like Ruby and Django. I can get a V1 site out faster than I can with go.

Java is java. Its great if its huge, but hard to do "simple" in java... and the specter of "is this the year oracle fucks every one" looms large in the java ecosystem.

The compile/test loop for GO is stupid fast. How go deals with dependency is fist class. Go nailed concurrency model has found a sweet spot between safety, ease of use and developer performance that is unmatched.

Go is the "brutalist architecture" of programing. Most people look at it and go "why" but if you embrace it, and adopt it, there is an effective sensibility that you're not really getting elsewhere.

If third party libraries are important to you, it's hard to recommend Go over PHP. Everything is available in PHP. Go is still very new. Maybe you can code all that you need by yourself, but that's a pill some companies won't swallow.

On another note, whether or not I can make a database in Go is irrelevant. We're talking about replacing PHP, a web language. Why would I need my web language and database language to be the same?

>> Go is still very new.

Well over a decade old.

>> If third party libraries are important to you, it's hard to recommend Go over PHP.

There are plenty of third party libraries for go. This is where most of Go departs from PHP/java/ruby. Php/ruby you might look to something like larval or rails. Java had spring/hybernate/struts/grails (there's a lot there). Is there A framework you're going to jump on in Go? No, Go isnt Rails, it isnt omakase. Go has a ton of parts that "just work" and work well together.

You can pick an ORM (gorm) or use code generation like SQLC (magic!). There is a clean validation implementation that covers 99 percent of your use cases and is easy to extend. If you hate that there are 3 solid alternatives. Do you want a custom router, there are lots of choices but the standard library is good enough. How about logging? Works fine out of the box but plenty of choices here too. Auth, Identity and Access control what do you need there is a middle ware for it already or you can build one in 10 minutes. Are you parsing massive JSON files? hey if the standard lib is too slow there's 4 other choices depending on your use case.

Want to recycle all your code for CLI tools or service workers ... go is a hell of a lot more elegant than ruby or PHP for this (better concurrency primitives).

> On another note, whether or not I can make a database in Go is irrelevant.

I have a little project: the web server, the DB the, images, everything. One simple binary, one config file. Im not installing web servers, run times, databases. It's clean simple and out the door. Im playing with a search engine in go that looks like it could be mixed into that same binary and be 75 or 80 percent of what a solr/open search server would be.

Would rails or larval be faster to launch. Sure. Are they going to keep getting features out ahead of go after 6 months or a year. No things are gonna be really even. And when ruby or PHP hits the wall (and they have a point where scaling them stops making sense) then what do you do? Port to java... or go? You could just pick go from the start and scale it all the way out. Binary blob monolith to scaled services you can just stick with go....

I think you're underestimating how big the PHP ecosystem is compared to Go. Auth, Routing, and Sql code generation are basic things that every ecosystem offers. Even obscure languages have these things. Furthermore, Golang is a famous pain in the ass to parse other people's Json, but is fine for known data structures. It's a great example of where the simplicity of the language falls short as well.

As a side note, golang doesn't seem to offer anything even close to what other ecosystems offer for Auth without using a third party service. They have some pretty basic libraries from what I've seen, but I could be wrong. These are not things that you're gonna roll in 10 minutes.

When working for clients, and they need to connect to an obscure payment processing service, you could roll your own. But I don't want to be the one to tell them why we can't connect to these services without writing these things ourselves when their competitors can because they chose a language like PHP

>> As a side note, golang doesn't seem to offer anything even close to what other ecosystems offer for Auth without using a third party service.

https://awesome-go.com/authentication-and-oauth/

Theres ORY if you want your own in house auth zero...

There are piles of other things out there.

>>> They have some pretty basic libraries from what I've seen, but I could be wrong

Basic, maybe... Minimal closer. I like to think of go as brutalist architecture its so drab and functional that it feels ugly, void, and lacking.

Look at go's standard library. It's complete, but there isnt a lot of flash there. Good go packages maintain that stance. They give you enough to finish the job. Your not gonna find a package with a lot of "utility" functions in it, your not gonna find a lot of "left pad" like micro libraries.

And when you adopt this sort of thinking you dont really need as many choices. When every thing is boiled down to "this is functional/working" it doesn't leave a lot of room for implementation details or interfaces as distinguishing features.

I like Go. But how come they have not fix the issue with implicit nulls? Null guards everywhere... I cannot believe that a company as mighty as Google did not choose to use decades old insights on how to fix this.

Now it's really hard to fix. The std lib already does implicit nulls all over the place.

Kotlin kind of fixed it for Java, and it really helps us.

PHP is old, and makes it easier to forgive it's mistakes. But Go?

> I like Go. But how come they have not fix the issue with implicit nulls? Null guards everywhere... I cannot believe that a company as mighty as Google did not choose to use decades old insights on how to fix this

They relied on decades old insights of persons who worked on C and Unix. That said, I'm honestly still on the fence about if nil checking is really braindead, or just what it boils down to in the end and the rest like exceptions and Options/Result is just theatrical.

What I don't get is that they are not more pedantic about checking nil errs in the compiler. They error hard during compilation on unused variables, but err checking is simply not done.

I also use PHP this way and the speed I'm able to get something from a database to the page and iterate is still unmatched.

And that's why people look down on it - it's the same as how movie reviewers don't like regular movies, or book reviewers only like complex barely-readable books.

The simple stuff is just too boring once you are an expert in the subject.

Personally I never shat on php because of simplicity but because of lack of expressiveness, limited language constructs and bugs. Combined with the massive new crowd going into programming with it, it gave rise to immense walls of pain (I remember wordpress sociable code source 12 screens long loops visually..).

Later they started to move away from all that with PSR, typed object layer and more es6/py3 set of features.

I would argue it's not the same at all.

If you're very much into art, you've probably seen the simple stuff already, and you would prefer to see something that surprises you or makes you think instead of the nth iteration of the same tropes.

But PHP is a tool, and you want your tools to be boring and reliable. (Whether PHP fits the description is a different discussion.)

You'd be surprised. A lot of programmers want complex tools because they are more interesting. They also tend to write unnecessarily complex code.

For example instead of just doing something there are multiple levels of indirection and instead of simply operating on a variable they tend to setup overly complex types that get passed around. Obviously sometimes you need that, but I'm talking about adding this complexity when it's not necessary.

Of course those people exist, and they also exist in PHP land because as soon as you start using its more advanced features it is as complex as the other mainstream languages.

But I would guess that a majority of developers that are not CS researchers value simplicity over complexity, at least in theory. After all they’re just trying to get shit done.

Similar to how Stephen King will never win the Literature Nobel but he is such an incredible writer.

> And that's why people look down on it

Okay fair enough...

> > I was never able to move from PHP to something else.

But that's why people like PHP, they have little exposure to something else.

People that have experience with langs like Rust, Java or C#, Kotlin, Haskell or Elm, OCaml of F#, they usually do not like PHP. Why would that be?

People who only every have used PHP (and maybe some JS) they are usually the only ones raving about the language.

If you have seen a lot of movies (critics usually have) you are better at judging the merits of movies. Same for languages.

I suspect it's actually you that doesn't have exposure to PHP. I have exposure to about half of those, and I like PHP.

> are better at judging the merits of movies

Their definition of "merit" is "surprises me and brings something new to the table", while a regular person wants "is entertaining". i.e. they are better at judging the merit of something not actually wanted.

I shit on php because when you develop professionally with it, you want strong types so what happend was that people started to use comments to hint types.

Those hinted types are than enforced through an IDE.

Thats just horrendes langauges missuse / misdesign.

Maybe upgrade to a recent version of PHP from the last five years. It has strong typing, not just hints in comments.

If you like strong typing, great, but many popular languages have weak types and dynamic types by design. It’s not some horrendous oversight.

interesting that it finally landed.

But just because PHP apparently added reasonable typing in >7.2 still makes it a ranchy languages for most of its lifetime.

Anyway ranting about it doesn't imply that i hate it or that i haven't used it. Its one of my first languages, but from my personal view, php is a shitty language in comparision to most others

You would have to compare PHP to the alternatives available at the time. Originally PHP replaced Perl and ASP, which have their own problems and no static types (back then). Ruby/Rails came out and got traction but was slow, buggy, and still no types. Python also slow, no types, and not great for web development.

Then we got Javascript and Node, with even less sensible types (no integers!) so you have to use Typescript and lots of tooling to get what PHP offers.

In enterprise environments Java and then C#/.Net dominated and did have strong typing, but that’s not the world of PHP.

Comparing PHP from a decade or longer in the past to Go et al. hardly seems apples to apples.

So if you want to dismiss PHP as “shitty” compared to “most others” define shitty and identify the others.

PHP without types / types in comments existed in parallel to spring boot for years.

And im pretty sure that the history of PHP is still everywere inside PHP, like php function inconsistencies across the board.

Or whats the current situation on unicode support?

When i started with PHP4 and Lamp, what a great time. JavaEE was bloated, not a lot of good free webservers available, granted.

But while PHP5 was great and had a loooong shelflife, JEE became much cooler and had fundamental critical things like CDI and really good CDI Frameworks.

Eclipse Java IDE was always really good, something PHP hadn't had for ages.

And if you look at the fundamental difference between lets say java and php: In Java you have specs and reference implementations (partially also thanks to oracle, you now have mulitply companies having their JVMs) which made the JVM very robust and fast.

When Facebook did the hhvm/hack stuff, that was great and pushed enough nerves to rethink the performance of PHP but the performance gains were stupid crazy. Thats a very good indication when a language with so little money and support has such a huge performance gain after such a long time existing.

The fact that Facebook than threw the PHP community under the bus with hhvm/hack didn't make it better.

I don't think PHP and Java really compete for mindshare. Java has mainly thrived for larger enterprise projects, whereas PHP appealed to individual developers and smaller businesses, and applications like WordPress. Of course there's overlap and companies may use both, but writing a web application in Java requires significantly more investment than choosing PHP.

Eclipse supported PHP from 2007, and the PHPStorm IDE from JetBrains dates to 2010 or 2011. Java has always had better tooling because of the enterprise focus. PHP IDEs are very good today.

PHP 7.x and 8.x have seen big performance improvements. I haven't seen hack/hhvm get much traction outside of Facebook but maybe it did.

I don't wish to put words in your mouth, but it certainly sounds like your argument is essentially, "PHP was bad, therefore PHP is and will always be bad, no matter what improvements it makes."

This...doesn't seem particularly reasonable?

You're not required to like PHP, and you don't need a reason why things you dislike are objectively bad in order to be allowed to dislike them.

Its just a discussion and my personal opinion i'm sharing.

Its hn, i think its reasonable to discuss asthetics of langauges?

But yes the history of PHP is murky and i do believe, that a few small changes could have big advantages for PHP and because PHP was one of my first languages and i also developed for it for a few years, i do have some type of connection to it.

Just imagine having a more community / sig driven approach defining a spec first, than having a reference implementation and opening it up to others.

And a PHP base rework would also help. Rethinking the architecture and code, cleaning it up and fixing issues which are still there because of it like unicode support.

> It has strong typing, not just hints in comments

Even for arrays?

PHP arrays are ordered maps, not arrays of a homogenous type as in Go or Java. Array is a type in PHP, but all arrays have the same type, regardless of what they contain.

You can describe the expected value or key/value types of an array in PHP doc comments for IDEs and static analyzers, but PHP won't enforce those.

I write go so... types.

Types are great and they have downsides. Perl, PHP, Python, Ruby, JS, Lua, lisp, objective c are proof that you dont NEED them to have working code.

Go’s types are like talking about how cool internal combustion engines are, and you bring up a crank.

there are many loosely typed languages that are used professional (in addition to PHP). dynamic typing it has its pros and cons but that doesn't stop it from being used professionally.

My point was that the professional side of PHP developers at that time, decided that they want to have a strong type system.

What did you have to build? `node index.js` and it works, without build.

And what did you mean with "no server updates"? PHP has to be updated and the server processes has to be restarted.

The markup of PHP is a mess, OK js is not much better :D

Sure you can start PHP without any dependency, cause it has a "million" dependencies included.

And yes, i use both. The right tool for the right job.

> Sure you can start PHP without any dependency, cause it has a "million" dependencies included.

This is exactly what good/great languages are doing: providing a standard large standard library.

I do not agree, that this is the only way of great languages. Great languages in my opinion are those, that implement concepts in a way, that they compose well and enable you to do anything you want elegantly. With the concepts they implement, they give you an answer to any situation might come across, without forcing you to write tedious ugly code as a workaround for lacking facilities.

Perhaps what you refer to are great ecosystems of programming languages?

> And what did you mean with "no server updates"? PHP has to be updated and the server processes has to be restarted.

This is not true. You can update a PHP file without restarting your server, and it will run your updated code.

> With PHP to move my code to a production system I just need to run `git pull` and the new codebase is instantly live. No builds, no server updates.

Make sure your .git folder is not "instantly live" as well...

low-skill sounds much more negative than "not complicated enough to constantly fail" :P After so many sightings of bespoke build tooling I kinda miss this part the most.

I mean, if I had been doing PHP-only professionally for years and then as an alternative merely checked out NodeJS, I wouldn't budge either, I think. But NodeJS is not known to be an elegant, fascinating or even horizon expanding language. None of that. So I am not surprised. Additionally it is kind of in the same language family as PHP is (while there are differences). Add to that all the overhead you have with minifiers, bundlers and whatnot, and I can understand easily, how one would not want to switch to NodeJS coming from PHP.

However, it might be a good idea to try languages, that are encouraging different paradigms, belong to another family of programming languages, or are often used for other things than PHP usually is. Try a Haskell, try an Erlang, an Elixir, a Scheme/Racket, a Rust. Languages so significantly different, that they add value for your learning experience as well as enabling you to do new things and get to know elegance in programming language design.

PHP has a special place in the story of the web-dev.

The whole "no build step" was the most underrated factor for its success, because it was such a low-skill tool to pick up.

The tightness of that edit-test-move loop was why I used it, even if the "edit" included "sftp it to a vhost".

That bit is what made it successful & I can't think of anything I've used in the last decade which felt as easy as PHP for that particular style of self-taught programmer.

Back in the day when VS Code didn't exist and even sftp was rare and the world ran on port 21 classic FTP, we had code editors with built in FTP like PHPEdit, we would literally hit Ctrl+S and save and upload the file on production in one stroke. Refresh the page in browser on the live site and there it is. Those were the insane days before terms like agile and CI/CD were even invented.

Yes insane and after upload "bang error", sh...t, fast fix the error and upload it quick again, befor anybody register the error :D :D

Ctrl-Z, Ctrl-Z, Ctrl-Z, Ctrl-S!

I still do this! Often still over FTP, sometimes over folder mounted over SSH.

Scrum is older than Linux.

I didn’t touch PHP for a long time but it have a nice place in my heart especially for the reasons you gave.

I have a hard time with people joking about PHP because while it wasn’t perfect back in the day, it’s probably the culminating point of the non elitist computing. PHP was accessible to anyone who had the basics of creating an HTML website (which was a skill any random person could acquire in a day or two).

Also, the people making those jokes are most of the time working on projects with micro services and SPAs everywhere for a boring business app with CRUD and forms. Which I find pretty ironic since a single PHP monolith solved this exact use case 20 years ago.

Also, it had dirt-cheap hosting, as a single process could host multiple sites (though it did come with some security implications).

Nowadays we tend to bring up a whole virtual OS.

An interesting direction in this area might be GraalOS, which might allow running multiple applications in a single OS process, doing the necessary isolation itself. (Not affiliated)

I'm taking the "no build step" thing to the extreme in one of my projects.

PHP has libraries for compiling SCSS and minifying JS, and filemtime() is very fast. So if you wire them together in just the right way, you can edit any script or stylesheet under the project hierarchy and have them compiled, minified, and bundled together on the fly. Cache the bundle until you edit one of them files again, and automatically bust the cache once you do.

No need to build anything whatsoever, both on the frontend and on the backend. It's like REPL over HTTP.

I can confirm, this approach works great!

I use this in production for a system with 3k requests per second that runs in a single Apache+PHP web server and a single 80GB MySQL database. Never needed to optimize anything.

You have no idea how happy it makes me to see someone else was bold enough to try this and it worked for them too.

Simple, maintainable, instant SCSS and JS build pipelines with all the benefits and no drawbacks! Plus any junior can understand and change it in minutes.

> PHP has libraries for compiling SCSS and minifying JS, and filemtime() is very fast

If you do compiling and minifying, that's a build step.

Every human-readable programming language must be compiled into some sort of bytecode (opcode in PHP) and/or machine language in order to work. The question is whether a human ever needs to be aware of that step. In PHP, you generally don't. In the aforementioned setup, you don't need to be aware of SCSS compilation and minification, either. Not even if you use devtools, because the map file will point to the correct line in the original source.

The usage of the term 'step' here is in the pre-deployment development process sense. I think what this person is doing is converting SCSS to CSS on request, at runtime.

Regardless of which steo, compilation process is typically done as part of a build step, where the SCSS files are transformed into the final CSS that will be served as a bundle to the end users' application.

Web browsers can't understand SCSS natively.

To be truly extreme (performance), devs should consider tree-shaking unused CSS and JavaScript. This may require using Vite (Rolldown is in the works/Rollup) if there are no other options or it makes no sense to serve bloated resources. That's the reason, I chose Astro as I care about users, not prioritse the developers' minimalistic workflows.

I prefer Tailwind because it allows me to avoid duplicating classes (mine and vendors), which is an advantage over other approaches.

I did dogfooding in Go development.

Hot Module Replacement and Live Reload in Node-based web dev servers bring some of that magic feeling back, although you will quickly need to learn about module resolution and other intricacies.

The criticism is that those things comes with mountains of complexity.

That is the problem of the tool developers not of the app developers. For us, it is easy to use.

It also breaks easily. Npm is a very unstable platform.

I liked the documentation. The old documentation, in a .chm file.

This also lead to shitty tool integration.

While it was always easy to debug java based apps and the debug support is great (remote connection, drop frames, all types of breakpoints etc.) people struggled with this in php.

I showed a professional a few years back how to debug with php, after 2 weeks he stoped using it...

It's only easy to start up to hello world kind of projects.

To build anything useful you quickly discover that it's hard to build from source (both the lang and extensions), some parts unmaintained for years. There are many counterintuitive idiosyncrasies you must deal with to be productive. The ecosystem suffers from the overuse of indirection and reflection. Php only looks easy, but the rabbits hole goes deeper than most other langs.

Why on earth would you need to build PHP or its extensions from source to build a useful web project?

> It's only easy to start up to hello world kind of projects.

Sure but the important part here is it’s also easy to deploy to the internet for free or a few bucks.

All you said is right but still, I don’t think there is anything comparable nowadays and if I had to explain to my son how to create a basic non static website without using proprietary PaaS, I’d have a hard time (without PHP).

Was it the best option when you were a company building a product ? idk but at least it was a viable option. Was it the best option for any kiddo wanting to learn creating things on the internet ? Totally and we never got anything better for this since PHP.

How would you describe something useful?

Can you give examples of counterintuitive idiosyncrasies you must deal with to be productive?

PHP and the ecosystem around it, especially Laravel, makes developers incredibly productive: everything is so damn easy.

Nothing comes close to it in Go, Ruby, JS (Node), Python; from what I've seen. Laravel is one step ahead.

I worked with Laravel and trust me, it's a pain in the ass when you have a medium/big project. The "documentation" (more a how-to) is full of bad practices, the facade pattern makes it hard to refactor or change the underline logic, you can break the contract easily (it's just php annotations, not real type-hints), the ORM is a pain to test and has too much magic, you use strings to set the validation makes it hard to understand when it's not trivial, the request->input() takes query/body so you end up mixing everything and some clients use the API in various way, there is helpers to get the config/service anywhere (even in static methods) which makes it painful to test and refactor, etc. I strongly recommend to use Symfony instead, the documentation is great, the profiler is built-in, the cache is better (faster), it's type-hinted and strict, there is interfaces, it scales well because it's flexible and well thought.

> I worked with Laravel and trust me, it's a pain in the ass when you have a medium/big project

Every language is...

My thought on NodeJS is I've experienced incredible productivity with Astro web framework, as everything is written in TypeScript.

I'm familiar with Livewire and have used AlpineJS, but I plan to adopt Qwik (Resumability) as a component in Astro, which addresses frontend performance. One step ahead of others now that I don't have to maintain Go language as a backend which took me months to migrate to TypeScript for a medium size platform.

I'd love to see something like laravel/symfony in go/rust. If anyone is willing to give it a shot I would've switched yesterday

I've thought about doing a Laravel-like framework in Go, but one of the superpower of PHP/Laravel _is_ the possibility to have very loose / no types, which gives a great DX when used correctly, but in Go, you'd have to interface{} so many things that the resulting code would be non idiomatic / not as performant as go can be.

And then, you'd need to have an ecosystem as strong as Laravel which... wow... would take a _lot_ of investments.

Honestly it’s pretty hard. We are talking about frameworks with decades of development. It’s not something that can be done by one developer, you need corporate levels of investments at least to bootstrap it.

Well, no, that's not really a fair assessment. Someone is quite literally doing "rails but for Rust" with loco: https://loco.rs

As far as I know, the bulk of this effort has been one developer pushing it along. I wouldn't personally use it but it _does_ exist.

It's also worth noting that these older frameworks all come from a different era of development - nowadays most newer devs seem to want to build microservice-after-microservice, where these don't quite fit into the picture.

They are doing it and I hope they succeed and prove me wrong but last time I checked Loco was still far from Rails.

> Nothing comes close to it in Go, Ruby, JS (Node), Python; from what I've seen. Laravel is one step ahead.

I can't really agree with that when Express and Django exists in this world. But Laravel is indeed amazing piece of software

Express from Node? That's not even comparable. Express is a simple routing solution, Laravel is a framework packed with features.

Express is not in the same category as Laravel, what gets closer to Laravel in the NodeJS world would be Adonis (that I know of). Express is essentially a modular router (for people that think that server-side JS is a good idea)

If you run `laravel new my-app`, you got an application with caching, database, queue, views, translations, whatever else you can think of, ready to use with things like Oauth / Payments / E2E Testing / Feature flags / Search... a command away.

You don't get that with Express, you don't get that with Django, from what I've seen (but I'd be very happy to be wrong!)

Express is simple but it’s pretty barebones, nothing comparable to Django or Laravel.

But yeah Django is nearly perfect, my dream framework is Django officially typed in a world where the python community get its shit together with type checking.

We are not far but I miss having good IDE auto completion and not having errors in my IDE as a reliable source of confidence.

PHP is slowly gaining ground on strict typings and every update brings new features. It’s really fun to see losely typed methods over time being refactored to typed methods, giving you that slight peace of mind in every step. Big kudos to the PHP and Laravel community.

Django is comparable. A little harder to deploy (well we have docker now so who cares) but still incredibly productive.

I mean, with Django, literally just defining your database models in models.py and not touching anything else is enough to have a working application with a full featured admin backend with authentication already built in.

If you define your models correctly with the good constraints you are literally left with writing your HTML views and/or API endpoints, adding permissions and call it a production app.

I’ve never touched Ruby but it also sounds like we shouldn’t discard RoR in terms of productivity.

> I’ve never touched Ruby but it also sounds like we shouldn’t discard RoR in terms of productivity.

I'm doing some Ruby for work and I hate it with passion every time i have to touch it.

Official tutorial-style documentation for Ruby is largely non-existstant (except for a book from 2002 that teaches outdated stuff from ruby 1.3). Learning ruby is 99% monkey learning, as in reading some random tutorial off the web and then doing some monkey-see-monkey-do. It's awful and it's frustrating.

Python on the other hand is extremely well documented:

* Tutorial: https://docs.python.org/3/tutorial/index.html

* Standard library reference: https://docs.python.org/3/library/index.html

* Language reference: https://docs.python.org/3/reference/index.html

Guess which language is thriving and which is slowly losing relevance?

I've worked with both, Laravel and Django, for many many years.

Laravel is miles ahead of Django, in every single aspect. The template system is incredible while the django one is stuck in the 90s. The integrated job queues, scheduling, asset bundling, etc, etc. And yes, you also have Admin interfaces for Laravel, both paid and free, and they're as good or even better depending how you look at them. Community is also a lot bigger which means more packages and better maintained.

> I’ve never touched Ruby but it also sounds like we shouldn’t discard RoR in terms of productivity.

RoR is insanely productive.

Python has been doing web frameworks for quite a while now - starting late 1990s with Zope & Plone.

Laravel is Rails clone afaik

java/kotlin with either spring boot or quarkus.

PHP is a great language to learn OOP, classes, interfaces, abstract classes, traits, managing dependencies and unit tests. I'm not using it anymore but I learned basically everything with it a decade ago. Thanks PHP!

A good language to learn OOP is Pharo or Smalltalk.

I thought the blog post would introduce me to how PHP in 2024 somehow got rid of all the cruft from ages ago, but instead it merely talks about some frameworks. Probably high level frameworks are what saves PHP from dying, because they mean, that people don't have to deal with as gnarly PHP all the time, but going so far as being excited about them? Sounds more like a justification to still keep using this language, despite all the other often better language options out there. Heck, I would even prefer writing Java these days, than going back to PHP.

PHP these days is pretty much fine, it is nothing like PHP 5, IMO. I started working on something a year ago and it was way better than using any frameworks. Initially I did start with a framework (Laravel), but it had its own limitations (and bloat) so I decided to do it from scratch. The code was much more manageable, understandable, etc.

Could you share a project you did? I would like to compare to my past PHP writing.

I also found, that doing my own plain PHP imports/requires worked better than what WordPress by default wants you to do for example, so I can well imagine, that something similar can happen with Laravel.

I am by no means an exceptional dev, but some PHP code I've written can be found on my GitHub. None of it uses frameworks, and a bunch of it is small libraries ('components') that make up my own personal functional 'framework'/toolkit: https://github.com/aaviator42/

Edit: Link that shows only PHP repos: https://github.com/aaviator42?tab=repositories&q=&type=&lang...

I took a look at https://github.com/aaviator42/izi/blob/main/izi.php. Basically the first repository that was listed. It looks a lot like what I wrote years ago, which unfortunately, in my book is not a positive. What I take issue with are the following things.

    iniSettings();
    enforceHTTPS();
    session_start();

Global state things directly exposed to the user (programmer in this case). The problem here is, that this kind of thing immediately fails, when things start to use concurrency of any kind, because suddenly one has multiple processes concurrently setting global settings, without any kind of mutex in between. But this seems firmly part of the language??? That is worse! Because it encourages people to use global state just like this.

    if(isset($_GET["m"]))

Apparently it is still common practice to have such "if bla is set, when do blub" everywhere in ones code? No functions with decorators or a similar or alternative concept? I would think there should be some kind of easy to use mechanism in place, that tends to avoid forgetting these ifs.

There are ... 60 lines of global logic, that is not encapsulated in any function or so?

Some of the functions are quite long. But I think mostly because they render out HTML.

At line 107 with the procedure printHeader starting, what I call PHP nightmare starts:

Switching back and forth between PHP, HTML and HTML with integrated JS (!!!) and CSS. All of course without syntax highlighting, but that is a minor issue. The major issue is treating HTML and JS and CSS as mere strings, instead of structured data, and the very bad readability of having procedures suddenly "end" and spit out some wild HTML, then suddenly continuing again, because some server side logic/decision is required at some place in that stream of unstructured data, whether some part is to be included or not, then the stream continues and then at some point one needs to actually check, that one did not forget to truly end the procedure. This has some of the worst readability. Maybe C code with bit magic is worse.

One can find this kind of approach in many, if not most, Wordpress plugins. What's more is, that this is also terrible for writing tests. The procedures do not return a value to check against. All is a side effect. Perhaps there is some PHP library that manipulates the PHP system, so that one can at least do string comparisons on the side effects. Like mocking, basically. But still terrible for testing.

For a comparison of how it should be done instead, check any templating engine, that at least separates template files from PHP code. Better, checkout SXML libraries, that treat HTML as structured data, a tree that can be traversed and pattern matched against, without pulling out arcane string manipulations or regular expressions. And then consider how one could write tests based on such structured data.

If this "HTML is a string, even on the server side before sending it" kind of approach is how a language treats HTML, then the language is not suitable to be directly used for HTML templating, without any additional library. This alone has caused uncountable security issues in so many projects.

I realize, that this is probably kind of a "one off script" and may not reflect other kinds of PHP code.

I did all of those things myself, years ago. And when I already had moved away from such an approach, I had to maintain a project, that was written this way. It had no tests of course. No fun. It has not that much to do with you personally being a good dev or not. I think it has to do with the ecosystem encouraging you to do these things. Outputting HTML like that should be declared illegal and should be impossible.

https://github.com/aaviator42/StorX/blob/main/StorX.php in comparison looks much better. It seems it does not output things directly. Everything seems wrapped nicely into methods. One obvious footgun seems to be another global state thing, that I really hope is not a thing in PHP itself:

    const THROW_EXCEPTIONS = TRUE;

Please, please tell me, that this is not an official part of PHP itself.

> iniSettings();

> enforceHTTPS();

> session_start();

> Global state things directly exposed to the user (programmer in this case). The problem here is, that this kind of thing immediately fails, when things start to use concurrency of any kind, because suddenly one has multiple processes concurrently setting global settings, without any kind of mutex in between.

No offense but I take it you don't have much experience with PHP (and that's fine).

Because your complain is exactly one of the beautiful things in PHP.

It's all per request.

It doesn't break.

You don't have to think about mutexes.

The project is private, but I hope I will be able to make it open source in the foreseeable future.

That said, I do have some book recommendations and some useful links.

Books:

* PHP & MySQL: Novice to Ninja by Tom Butler

* PHP 8 - Quick Scripting Reference by Mikael Olsson

* PHP 8 Objects, Patterns, and Practice by Matt Zandstra

* Programming PHP (2020) by Kevin Tatroe and Peter MacIntyre

Links:

* https://phptherightway.com

* https://www.php-fig.org/psr/

* https://web.archive.org/web/20230110234256/https://www.cases...

I read a bit of https://phptherightway.com/#errors_and_exceptions and it makes me doubt whether the author has ever worked with a big PHP project:

> The only real difference is that Python will freak out over any small thing, so that developers can be super sure any potential issue or edge-case is caught, whereas PHP will keep on processing unless something extreme happens, at which point it will throw an error and report it.

Wtf. The real difference is, that in the real world people will ignore notices, because they are "merely notices" and because "it works right now", when there surely is a code path, that will rely on the variable being defined and that will catastrophically fail at a later stage or point in time, when the issue is much bigger than right when the undefined variable usage was introduced. How the F is this not an exception. If it can lead to errors and wrong results, which it both very realistically can, it should prevent people from continuing to run it. What happens instead is, that people will obliviously go on with broken code, possibly getting wrong results for years, before someone fixes it. Do not forget the manager people breathing down ones necks when things "work" but one still wants to "improve" things.

The statement is so disconnected from reality, it really makes me doubt the quality of rest of the content. Like a thinly veiled justification saying: "Oh but this is not actually an issue, believe me, all is fine!" when the house is on fire.

PHP is used by so many beginners, but actually due to all the foot guns is more suitable for mature developers, who are very vigilant and strict with themselves, to avoid these foot guns. Basically you cannot let a beginner anywhere near PHP, without a tonne of project setup to safeguard against all of this stuff.

Yeah, to begin with, the default php.ini is pretty bad, too.

> it really makes me doubt the quality of rest of the content.

I have not read all of it, all I know is that I have found some parts informative, but I have not used this website as my major source. It was mostly the books I have mentioned, especially the first one.

> nothing like PHP 5

Nor PHP 4 for that matter.

IMO what PHP has going for it is: (1) no build step, and (2) built in templating. Ease-of-use very high in terms of web development.

Posts related to PHP usually become discussion if the language sucks or not here on HN. I am co-founder of a PHP PaaS and I can confirm that almost all clients are using frameworks or even CMS systems on top of PHP to build stuff. Why not?

I am interested how PHP and frontend tooling will work out in the future. Nobody is compiling JS/CSS with PHP (as far as I see). That is usually done with Node.js. Livewire (and Inertia.js) are bridges. Sometimes PHP becomes a backend to provide an API for an SPA frontend.

Will 2024 be the year that PHP users finally feel they no longer have to tell everyone else that PHP doesn’t suck?

I've been being productive by solving real business problems with PHP since 2007. Hope to continue doing so in the future.

Have been using PHP since 2008 and will continue to do so. The community, ease of development and ecosystem around Laravel is unbeatable.

Laravel rocks though I am more of a Symfony man myself, been working with it since 2.1. API Platform has no equal. At $job I built a fully DDD system on top of it and its been a breeze.

In April 2024 PHP reached its lowest position ever in the TIOBE index. It's not even in the top 10 anymore.

https://www.tiobe.com/tiobe-index/

Tiobe also has Visual Basic at number 8. I would not rely too much on their rankings.

It's true there are some odd things when I compare it to my own anecdotal bubble but for the most part it does reflect what I see.

Python, C#, C++, and JavaScript are super popular. Ruby, Go, and Kotlin have been getting more popular. Etc.

I know people who are just now getting into Laravel and I'm sure it will remain a valid framework for years. That said PHP's popularity has only been going down since it peaked around 2010. This is reflected in all metrics you can think of.

https://www.tiobe.com/tiobe-index/php/

https://trends.google.com/trends/explore?date=all&q=php&hl=e...

https://insights.stackoverflow.com/trends?tags=php

Ironically, PHP is a pretty awesome language now compared to the days of v4 or v5.

Using PHP with docker the default way would require several docker images to run in parallel, i.e., php-fpm, webserver, etc... I use nginx unit to have a standalone docker image with php, webserver and application, similar as you would have it for a node or spring boot application. nginx unit has no support for http 2/3 and you would require a proxy to support that, FrankenPHP seems to be an interesting alternative for my setups, will definitely check it out!

Second this, FrankenPHP is on my list to check out someday and linda already forgot about it. Seems like a pretty decent option. I did however end up using a Docker image to run a small local project (using Caddy instead of nginx)

Can anyone help me as a newbie? I see many comments saying php is so simple to use, but I'm getting bogged down with Docker / Composer etc etc. There seems to be a lot to learn, am I going about it the wrong way? What's the simplest setup that I can use for production as well as dev (otherwise I'd just use laragon). Thanks.

For me the journey kinda started by checking which was the most common way of installing PHP on the OS I'm using. If you're on MacOS then nothing beats homebrew. The main thing is to try and use the latest stable version and then go from there. This should make life easier when it's time to update or when you start to deal with having to install/enable certain extensions. I've tried setting up Docker but finally just set everything up in Debian so I can use VSCodium without issues. In production (for a newbie) I would just go with something like a small 5-10$ VPS running Ubuntu with Plesk control panel which will help you setup and keep things updated (you'll have the option/warning of changing PHP version for each website in the control panel)

One (hacky) way to learn is to just install WordPress (apparently not fashionable these days, but I love it) and start messing around with the PHP in theme files. Turn on error reporting and just start breaking things.

Just install Apache and PHP. There are plenty of LAMP stacks prebuilt out there. Amazon Lightsail has a prebuilt LAMP VPS.

Laravel is never going to be competitive with Django/Rails simply because PHP as a language is just not as easy to master as Python/Ruby. There, I said it. Lots of PHP fans write these articles about how PHP is catching up in terms of usability, but nobody is choosing PHP in 2024 (other than truly uninformed people who are just picking their project language at random).

The one area where PHP is useful in 2024 is for prototyping a website quickly. As a one-person team, PHP without a framework (and without OOP) is the fastest way to build a fully-functioning complex site. I built a massively complicated site this way, in very little time. This is great because if it ever becomes popular, I can simply hire developers to rewrite it in the latest framework du jour (probably Next/Nuxt/whatever)

LOL

Reply on news.ycombinator.com