Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8.6 Closure Optimizations

wiki.php.net

Post reply on HN
Print view View original

11–20 of 53 posts

Re: PHP 8.6 Closure Optimizations

#11

Post by klaussilveira »

typia wrote: post #7

Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.

I have a few:

- Batteries included, everything you need out of the box. No need to npm install left-pad

- Optional, per-file strict types, without the need to transpile from another language

- No need to build anything, lightning fast scripting language

- Is its own HTML templating language (or XML), no need for JSX

- No supply-chain fiascos, stable and mature ecosystem

Re: PHP 8.6 Closure Optimizations

#13

Post by Tadpole9181 »

Gormo wrote: post #10
typia wrote: post #7

Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

As someone who prefers PHP in general and find the TC39 committee has kneecapped the JS language in the past few years...

> PHP has a vastly simpler toolchain

Firmly disagree.

You can install Node and have a basic server running in a few seconds.

PHP requires installing and setting up a server tied into FPM and then reconfiguring a slurry of bad defaults. If you don't avoid the footgun of "traditional" deployments, you get to deal with mixed versions of source. If you don't avoid the footgun of "native" sessions, you get to deal with INCOMPLETE_CLASS errors galore.

And if you want a dynamic frontend, you're still going to want to bust out JS.

> I can't find any reason why I wouldn't use PHP instead

Using a single language for both frontend and backend with (largely) the same availability of tooling and the ability to share code (i.e. type definitions).

> generally better runtime performance

I find this hard to believe? Intuitively, I would assume that the Node / Bun engines are significantly faster than PHP - which doesn't even come with it's JIT enabled by default on the (perfectly valid) note that backends are almost always constrained by DB times.

> a package ecosystem with Composer that isn't overrun with inane vanity projects and supply-chain vulnerabilities.

Functionally, Composer is worse than any of the NPM package managers IMO. PHP's global, shared namespaces preventing monkey patching and nested dependencies is a huge burden when you need to use Lib A and Lib B, but both have conflicting dependencies on Lib C.

But the only reason it doesn't suffer (as many) supply chain issues is two-fold:

1. Packagist's source of truth is the repo and tags. It's much easier to notice a Github account being compromised, which is already harder because it's always had better account security expectations, than NPM. But this comes at costs - such as being unable to rename a package in-place, because Composer gets really confused when it clones a trunk that has a different name than what you asked for. And it's not intrinsically more secure, since tags are not immutable and people can host on less secure VCS platforms.

2. But more than that... it's just less used? The PHP ecosystem is noticeably smaller and has way less happening.

So its very much trade-offs.

Re: PHP 8.6 Closure Optimizations

#14

Post by runjake »

Tadpole9181 wrote: post #13
Gormo wrote: post #10

Earlier quoted context omitted.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

As someone who prefers PHP in general and find the TC39 committee has kneecapped the JS language in the past few years... > PHP has a vastly simpler toolchain Firmly disagree. You can install Node and have a basic server running in a few seconds. PHP requires installing and setting up a server tied into FPM and then reconfiguring a slurry of bad defaults. If you don't avoid the footgun of "traditional" deployments, y…

> You can install Node and have a basic server running in a few seconds. PHP requires installing and setting up a server tied into FPM...

Without mentioning more, the PHP equivalent to your Node example is `php -S`.

Re: PHP 8.6 Closure Optimizations

#16

Post by dgb23 »

Gormo wrote: post #10
typia wrote: post #7

Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

Re: PHP 8.6 Closure Optimizations

#17

Post by ethan_smith »

hyperionultra wrote: post #3

~3% performance gains. I didn’t understood part about $this.

In PHP, closures defined inside a class method automatically capture `$this`, which means the closure holds a reference to the entire object even if it never uses it. This prevents the object from being garbage collected and adds overhead. The optimization detects when `$this` isn't actually used and makes the closure static automatically, dropping that unnecessary reference.

Re: PHP 8.6 Closure Optimizations

#18

Post by g8oz »

dgb23 wrote: post #16
Gormo wrote: post #10

Earlier quoted context omitted.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

I agree that PHP's request oriented "shared nothing" approach has its advantages.

That being said there are very decent options for long running processes/application servers these days - see RoadRunner, Swoole and Frankenphp.

Re: PHP 8.6 Closure Optimizations

#19

Post by Meekro »

dgb23 wrote: post #16
Gormo wrote: post #10

Earlier quoted context omitted.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

There are advantages to the lack of application state, though. Memory leaks and similar bugs became largely irrelevant, for instance. Regarding performance, a simple LAMP stack on a dedicated machine can easily give you <250ms pageloads for many web apps. If that's not fast enough, or you're averaging dozens or hundreds of requests per second, you're probably big enough that you can use parallelization or more exotic architectures to speed things up.

Re: PHP 8.6 Closure Optimizations

#20

Post by ragnese »

eurleif wrote: post #9
kevincox wrote: post #4

It is an interesting comparison that JavaScript always ensures that different evaluations of a closure expression results in unique instances. So in general the closures will require allocations for each (unless the allocation is otherwise prevented such as via escape analysis). Of course much of the underlying data may be shared, but the identity itself will be unique. I don't know how strict JavaScript garbage coll…

The part that would violate guarantees in JavaScript is not function objects being kept alive longer, but function objects which should be distinct not being so. function foo() { return function() { }; } console.log(foo() === foo()); // This must log `false` in a compliant implementation

This is also a problem, IMO, in having this optimization in PHP. Anonymous functions are instances of a Closure class, which means that the `===` operator should return false for `foo() === foo()` just like it would for `new MyClass() === new MyClass()`.

But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP all the time and it's still a terrible language even in 2026)

Post reply on HN