I still love PHP and JavaScript (2022) | Hacker News Reader

I still love PHP and JavaScript (2022)

the.scapegoat.dev

124 pointsjonfelsar92 comments

This is a preemptive plea for people who last wrote PHP in 2012 not to opine on what writing PHP is like in 2025. It is not a hammer with two claws. It’s a modern language with types and tooling and package management.

I've certainly seem some lovely PHP code. Even phpBB has been very clean for a long time.

But at the same time, you run into the same problems that you often see with C++. Yes, there's a clean, semi-modern dialect of the language that has 80% of what you'd ideally want. And 80% is often more than enough for practical engineering purposes. But the actual project you get hired to work on may not be written in that cleaner, modern dialect. The last C++ project I cracked open had gone almost 20 years since its last serious update. It wasn't terrible. But wow, did it take a lot of very tricky code to accomplish anything before boost and TR1 became popular.

And old PHP was one of the worst languages ever invented: the core C code was hopelessly insecure (I had to read it for a client during the dotcom boom), the database APIs were different for every single database (and all of them made SQL injection techniques too easy), the default configuration allowed hostile users to inject global variable values using CGI parameters, and I could go on for a week. Yes, I saw some ugly stuff in other languages during the dotcom boom. But ancient PHP was often on a whole other level.

And when a language's history includes that much ugliness, you need to be very careful about old production code bases. Maybe you get a nice Symfony app! Buy maybe you get mixed HTML/PHP/SQL with a hundred security holes inherent in the APIs being used.

Not to mention, the people who've been writing code in 2012 are still writing PHP code like it's 2012, and plenty of people are learning to write PHP the same way.

I haven't seen too many PHP codebases in the past decade, but every one has been full of a mix of commits that are beautiful, clean, functional code... and just the worst mishmash of garbage I've ever seen.

PHP might be fine, but I'm still not sure if I'm ready to work with other PHP developers.

Last time I touched PHP in 2018. It was a website my company bought from a french developer. After many unsuccessful attempts to add even basic functionality to the site, I announced my employer that they paid for the domain and the audience, but the code has to be rewritten from scratch.

It was typical PHP mix of HTML and PHP code in one file, an unreadable sequence of several crazy long HTML lines, then several lines of PHP code, then again HTML.

Lots of copy paste.

SQL statements were created by concatenation of user input with the text of the query. In 2018.

Back then I promised I'll never ever touch any PHP code. Live pretty much happily since then. I know there's some typing added to the language and other modern features. Still pretty sure, that if I open any random PHP file from any random PHP project, I'll still find the same mess as ever before.

Skill issue.

I don't understand. The point of my comment was that from my experience PHP code always has worse quality than code written in other programming languages. It's a broad assumption and I have no proofs. But it is my experience, I've never seen exceptions. Any PHP codebase I've looked at, had lots of issues with code readability, maintainability, robustness, security.

I think it was a huge mistake to allow mixing code and HTML. On the other hand, without this feature, PHP probably wouldn't become popular at all.

If you have a few minutes, I'm curious what will be your opinion about this code base: https://github.com/tirrenotechnologies/tirreno

I'm in this comment and I don't like it.

More seriously I picked php because it lets me get away without having to strictly define anything and just get away with fuzzy logic. I want to jump on the bed god damn it!

you can replace the word "PHP" in this post with any other language and it would still be true.

Does PHP have the tooling to lint/warn away the bad 20%? We do that with JavaScript, don't we…

I've heard that a lot, but my gripe with modern PHP is what's the hook? What feature does it offer that other scripting languages don't?

- Can you use the same rendering logic on client and server like JavaScript?

- Does it have the performance of Java or C# or Go?

- Does it allow for expressive DSLs like Ruby?

- Does it have an extensive, cutting edge ML ecosystem like Python?

Back in 2010, PHP's stand out features were very straightforward installation, good support for templating, and a large collection of C library wrappers (even if the interfaces were a bit raw). Those hooks were compelling enough to make people put up with the PHP4 core language.

But other languages have caught up on those three points, which leaves modern PHP utterly unremarkable. It doesn't have any feature that stands out enough to make me want to switch back.

- Kinda with templates, but I don't think this is a pro for JS tho

- Yes there is LLVM for example

- Have you heard of Laravel ?

- No, there is already python for that, use the right tool for the right job

Today PHP is a really really good language to get scalable apps up and running, moreover with frameworks like laravle that comes with tons of batteries included without tanking the performances. But so so many people remains on the good old PHP dead trend just because it's easier to ignore all the great evolutions pf the past decades

That’s a perfectly valid argument. I’m not saying people shouldn’t make that argument. I’m just saying I don’t want to hear about mysql_real_escape_string.

To answer your question, I don’t know that modern PHP has big advantages over other modern languages. I’m not knocking on doors to spread the gospel of Symfony. But there’s no need to switch away from it either. And hosting is still easy and cheap. Prototyping your product as a Laravel or Symfony app is a reasonable choice.

Share nothing request handling. It's like lambdas but without cloud bs.

That’s a really good analogy, thanks.

The appeal of something like PHP these days is not that it has any particularly unique features, but that it is ubiquitous, has withstood the test of time (meaning it's relatively bug-free), is well supported (meaning it won't disappear any time soon), and is relatively easy to find developers for. Those features alone make it a contender for projects that don't need a specialized language.

I don't buy that. You can't have it both ways. You can't discount PHP4/5 criticism because PHP7+ is good and then in the same breath hold PHP above other tech stacks for passing the test of time, not when PHP7 is younger than Rails, Django, and React (and even Vue). Those frameworks have passed the test of time more than PHP7+.

Those other projects have also had plenty of backward-compatibility-breaking major versions.

> What feature does it offer that other scripting languages don't?

It has pretty much the best type support of all other similar languages (typescript is a different category). It also has the best implementation of class-based object oriented features (interfaces, classes, abstract classes, etc). These features are incredible for designing OO systems from scratch. The only big feature missing is generics.

PHP got a lot better. Their types are actually awesome and better than average. The problems are now about the developers more than the language. Legacy PHP is the majority of PHP and it'll still make you go insane since you'll have to deal with that awful, ugly code someone wrote in the Summer of 2004 when they were an intern that is now core to a business. The people that have been writing PHP and only PHP for two decades also don't usually have great patterns they follow, so when you step into their code base, there's hell to experience.

Had this at my last job where I wrote PHP full time for two years. There were so many bugs caused by things that PHP has since remedied. I updated everything we could and it was huge step up (the available linting and static analysis tools are very solid), but there's still some deep, dark legacy code there that no one wanted to touch. Hell, a good part of my problem with that code base was actually because of Apache and mod_php.

If you have a fresh PHP code base, it's not that bad anymore. It wouldn't be my first pick, but definitely not my last.

Edit: I never got to work with Laravel, but I've played around independently and read their docs and it seems like a good dev experience.

The developers come in all flavors, too. I spend my time writing Drupal code and the average quality is fairly high. (Code quality in the Drupal project itself has always been high, in fact, even when PHP was a disaster on wheels.) So it depends on what those people writing PHP for two decades have been working on.

Absolutely true - I can't group all of any kind of dev together

> It’s a modern language with types and tooling and package management.

Last I used Php (v4 to v8), it had type hinting, which was fine but I think its going to become harder for newcomers to approach as there stronger and stronger types, which is what made Php so special to begin with IMHO.

Your own PHP code doesn't have to use typing. It's opt in.

Glad to hear that's still the case!

The “PHP sucks” mainly comes with working with software built in PHP. Like magento, Wordpress, drupal… it’s such a miserable experience.

Working with Drupal as a user is not the same as working as a Drupal developer. If you know Drupal well enough that you’re not flailing around trying to figure out how to do things—if you actually know the framework and you build sites with it regularly—it’s remarkably pleasant from a code perspective. The main problem with Drupal is the learning curve. It’s much easier to get started writing, say, a Laravel app. But for the narrow case where you need a heavy-duty content management system with features like multilingual and robust cache integration, and you’re willing to put in the time learning it, Drupal is not a miserable experience. It’s actually good software.

My problem with php is that I’ve never seen modern php with types and tooling. I’ve seen a lot of php, and it was all awful 2012 style nightmare magic stuff lol.

Which is probably because php isn’t the top choice for new web based projects anymore. I have nothing against modern php, but old php causes me lots of pain, and that’s the only php I’ve ever known!

Unless they broke backwards compatibility all the trash from the standard library is presumably still there.

They have, in fact, been willing to break backwards compatibility when it matters. mysql_real_escape_string(), for example, my personal favorite bugaboo from the early days, was removed in 2015.

+1.

I have recently had to delve in PHP and it was much better and more mature than what people painted it to be 10+ years ago.

A night and day difference.

Jira gave me the same experience. I hated it remembering the 2020 times, yet going back to it now...I actually liked it way more than the alternatives.

ŠDoes Šit Šstill Šrequire Šwriting Ša Šdollar Šbefore Ševery Švariable, Šmaking Šcode Šannoying Što Šread?

I get your point but I disagree with your timeline. 2012 was already past 5.3 which was a long-lived version with most of the quirks of early 5 fixed.

There was a lot of what people call modern PHP, basically just without the types. I'd say the PHP 4 days are the darker ages that most people reference, but maybe your experience in 2012 was like 2007ish. (TLDR: If you found it fine in 2012 it's probably still fine in 2025, but I don't see the huge wins. I stopped using it for reasons other than "dislike").

I picked 2012 because that’s when the claw hammer discourse was happening, but I agree with you. You could write pretty nice-looking PHP by 2012, and a lot of people did. The claw hammer thing was itself looking back at PHP from several years before.

The point made in the article:

* resource leaks are non-existent

Can not be emphasized enough imo. The amount of absolute ridiculous levels of pain instigated by expecting a core code loop to run -forever- and doing so well while being written for some web project or other is just too much to fathom. Just use PHP and serve the request. Then let it die. Then serve a new request.

This is, indeed, my favorite feature of the language.

It's not a language feature but a runtime feature. There's no reason why JS or Python or Java could not be run like that.

The language itself, though, does absolutely have this assumption built in. If you want to run it in an endless loop, you’ll have issues.

No you won’t, other runtimes like Swoole, FrankenPHP, and even amphp let you do that, just spin up a PHP process.

I wouldn’t recommend them, though.

“You’ll have issues” was my way of saying “I wouldn’t recommend them.” IMO if you want to run in a loop, pick a language where that’s the standard practice.

I find some of the language around FrankenPHP difficult to parse - is FrankenPHP always in loop mode (ala ReactPHP) or is it simply an option? I can't tell.. my gut reaction upon reading the intro material is that they "simply" replaced Apache/Nginx with Go's inbuilt, and much lighter, server structure and that PHP itself is left to run completely isolated as per usual?!

edit: indeed https://frankenphp.dev/docs/classic/ indicates normal runner capability similar to Apache.

Agree that it’s good to get the certainty of zero memory leaks (assuming there’s no associated bugs in apache) but it’s not that hard to write code that doesn’t cause memory leaks for stateful apps as long as you are able to follow certain simple principles and avoid bugs in the third party libs you use.

It‘s called „shared nothing“. Also makes scaling easier and you can restart processes anytime without impact, because every request starts at zero anyway.

It also makes scaling across multiple servers an absolute breeze when there's no shared state across requests to worry about.

This has got to be a joke.

What if you need any kind of in-memory cache? Or in general, any kind of application maintaining state, for, say, performance reasons?

PHP has apcu as the in-memory cache

And it’s not a joke, PHP is actually the most secure runtime environment out there for web hosting, PRECISELY because of the shared-nothing architecture.

Faster runtimes exist, like Swoole and recently FrankenPHP, to do evented programming like Node JS. But let me tell ya — you risk all kinds of leaks, both of unfreed memory and of secrets, across requests. It ain’t worth it most of the time!

Where I worked we had to reboot the php-fpm servers periodically because they had a leak…

There's a configuration to cycle php-fpm workers every X requests:

https://www.php.net/manual/en/install.fpm.configuration.php#...

Good to know!

One of my biggest issues with php was the number of imports and file reads involved. It made running something like wordpress _really_ slow on slow disks or over nfs. I don't remember apcu or opcache helping much for that because I think it still did a stat on every file iirc.

For single-file php apps or just not using a big framework, it's not really a problem.

You can configure opcache to never stat unless it's reloaded

Huh, well that sounds like it would have been useful. It's been at least 10 years since I did any php dev work, but maybe I'll find an excuse to use it again for something.

Not only can you configure it to never stat; it has also been on by default since PHP 5.5 afaicr

I don't think it can be emphasised enough how big of a deal the ease of deploying applications written in these languages is. The fact you can just upload the files with FTP, SSH, by pulling them from version control, etc makes learning so much easier than it'd be otherwise, and really speeds up deployment for software using these languages.

Like, this genuinely might be one of the big reasons that scripts like WordPress, MediaWiki and XenForo still use PHP. The people installing these things don't have to be technically minded in the slightest, and can get their sites running on a 5 quid a year shared hosting service without the need to understand the command line, shell scripting, containers, server management, etc.

Is it secure? Probably not. Is it best practice? No. But you can test your changes near instantaneously, and it takes like 30 seconds to get set up. Ease of use is huge.

I often reach for PHP or JS, because anything more seems like over-engineering a simple problem. I'm usually looking to make simple, quick, internal tools that just run without much maintenance or support. PHP has been perfect for this. A lot of them are just single files and run for years without me doing a thing.

Over the last few years, I've found that most sites clients want can be built with static site generators and JavaScript. PHP is also great and easily hosted! But most times when there's a sprinkling of dynamism needed, it's OK if its happens at build/run time rather than when the page is rendered on a seever. This leads to faster page load and less to worry about security-wise. No shade! I've just been finding this has lead to good outcomes for me.

Your static site generator can generate PHP instead of html and have some server-side dynamism sprinkled in your mostly static site, same way that generating JS can sprinkle some client side dynamism.

This is not the definition of a static site.

Definitions are blurred. PHP file can be almost HTML file.

No clue how relevant they are today, but server side includes (SSI) solves the problem of wanting a _mostly_ static page with a little bit of dynamic content in it.

You mean to say some basic company site, blog or photo gallery that only gets updated once/twice a month, with zero dynamic content otherwise doesnt need a whole LAMP stack?

Honestly though with GH/CF pages type hosting and how simple static sites can be its a direction I'm ever thankful things have been moving. Just seems so much less painful for those who arent here to be security experts and just want a bloody site that 'just works'

When I started https://github.com/Qbix/Platform over a decade I go I went with PHP for most request handling and Node.js for optional realtime handling (delivering messages over websockets, delivering notifications to devices etc)

And I have never regretted it. PHP powers 80% of all web sites in the world, still today! And it is the only language and runtime out there that is shared-nothing for web serving. Eliminates all kinds of leaks, including of memory, and secrets etc.

PS: This was the early PHP framework that the platform grew out of: https://www.reddit.com/r/webdev/s/hETCmkpWFW and this is how long ago I posted on HN about it: https://news.ycombinator.com/item?id=2464112 !

Its so easy to just get things done in php, even if its in an ugly way that you would never show to another developer.

And with strict types and Psalm used right, I’d be happy to show it to anyone. The OO paradigm in general always has its valid criticism but modern PHP written correctly for its usual problem domains is perfectly fine actually it’s great at what it does.

...but you have got working code and a nice refactoring job where you do everything to the agreed on coding standards, learn a bit from your colleagues in the peer review and end up with something that is done the right way that you can take pride in.

That’s why I’m currently driving the astrojs lane. It feels like PHP but it’s JavaScript.

(2022) Not that it matters much - PHP 8.1 had been out a while when the article was written.

(Vs. 8.4 was released Nov'24; 8.5 is scheduled for Nov'25.)

Where would one get started with PHP without picking up Laravel or Drupal?

* https://symfony.com

* https://getcomposer.org

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

https://www.processwire.com

Every PHP file can work without frameworks. The route is your filename, PHP by itself can do templating and input data is handled by the super globals.

But if you want some small and simple framework as guidance you can also try out Slim Framework.

Refactoring a PHP application is very satisfying.

OT, but I wish other languages had the templating power php has.

I've recently worked on an ecommerce written in php after years of Vue/React and it was surprising to me just how much convenience and performance your websites have out of the box as opposed as the monstrosity of single page applications, island, server components, etc.

I just made a comment that made me realize that the complaints I heard in the early 2000’s about PHP are mostly the same as I heard today and they are all due to one thing: skill issues.

They need a language or IDE that can hold their hands. They need a code base that doesn’t require much thinking. This is all for good and for the better, BUT, they are all due to skill issues.

You hate PHP because you are not good enough to tame it.

I started working with PHP back in 2002, it was cool, the first code I had to study was phpBB. By now I have made about 10 applications that have survived to production. I learned how to configure Linux servers, understand the front-end (sometimes), architecture, security, management and do a lot of things that now usually require a whole team to do.

Hear, hear!

PHP and JS have been my favorite languages since I first picked them up. I know they have a bad rap which was more deserved back when I started with them but, like the author points out, they have come a long way since then.

Edit: Correcting “here, here” -> “hear, hear”

> Here, here!

It's Hear, hear! as in, listen to what was said, I guess.

Thank you, I’m an idiot. I’ll fix it.

Discussed at the time:

I still love PHP and JavaScript - https://news.ycombinator.com/item?id=32325055 - Aug 2022 (393 comments)

I still think of Peter Levels who has the $100K/mo saas projects using PHP and jQuery

Me personally I've moved on from PHP unless I have to work on it, I'm now just full stack JS for my own projects.

I dont have to touch php too often these days but frankenPHP is one the best things to happen to php in a long time, especially now that the php foundation has decided to officially support it.

I hadn't heard of frankenphp before this thread, but it looks cool. Thanks for mentioning it! I might play around with it sometime soon.

(2022)

Some discussion then: https://news.ycombinator.com/item?id=32325055

Good arguments. I got an overdosis of PHP in my early career, but I have quite the same feeling for perl, both command line, and cgi

I made lots of money developing enterprise PHP over the years and there were always jobs available, even in a bad economy.

To me PHP is just a weirder Python or Ruby. In some ways I like it more than Python.

But what I've never liked about it is the big ini file. I don't really begrudge there being runtime settings for an interpreted language, but I've always found PHP to have waaaay too many settings, many of which have potentially odd defaults and/or can be asinine footguns by accident.

That said, I can't get myself to love JS no matter how much I use it. On some level not having separate numeric types for floating point and integers just annoys me a lot. It is obviously the interpreted language that benefited most from typing for a reason. I'm sure there's more to why I don't really love, despite using my whole career.

PHP package management actually works, for one thing :P

Just me that love to vibe code PHP?

I can't say I love PHP, but I no longer hate it. And given how much I used to hate it, that's a massive improvement. I still consider it borderline unusable without having the composer ecosystem handy though -- worse even than perl without CPAN.

As for JS ... I like TypeScript, even love it in many ways. I can deal with raw JS, but I won't write full apps in it. Ironically, I'm favorably inclined to PHP's OOP features, but I avoid them like the plague in JS, where I stick to static closures instead.

every server provider and their cousin support it

Which is great for beginners, and for anyone who couldn't care less about managing a server. You can get a shared hosting for literally less than peanuts and it will come with php support and a SQL database.

Back in the day I had one of those, even when I was broke, because the value was fantastic. There were tons of "self-hosted" type apps built with that stack (php+mysql), so you could have all sorts of apps running on there. I haven't checked in a while, but I guess nowadays that type of thing will be made for node, docker, etc.

In the endless framework wars where one day we are friends with server side rendering, the next with client side rendering and the next with eurasia, I keep seeing people reinventing what we already were doing with PHP long ago. I doubt it will happen, but I keep waiting for a PHP renaissance.

Reply on news.ycombinator.com