Event Loop no longer needed for Connector / Browser classes .. what's implications for php fibres, what's in the black box?

[gidzr]

Hi Christian and team

You mentioned to me recently about the updated approach for reactPHP for connector and browser classes, that event loop is no longer required.

Does that mean:

1. that async is now automatically embedded or built into those classes?
2. is the async approach for reactPHP now migrated to fibres (or should I wrap my browser class in a fibre for async)?

      $this->fiber = new Fiber(function() {
         return $this-> browser().then()... etc;
      });

Cheers

[clue]

Hey @gidzr, some good questions here, let me try to clarify.

The default loop was introduced back in 2021 specifically to make async code easier to write and not get in your way, see release notes (https://github.com/reactphp/event-loop/releases/tag/v1.2.0) and the announcement blog post (https://clue.engineering/2021/announcing-reactphp-default-loop) for more background. On the code level, it's a simple static class that forwards all method calls to a single loop instance, simply facing the fact that there can only ever be a single loop realistically.

The new Async component was introduced in 2022 to make async code much easier to write and look just like synchronous code using async() and await() semantics, see release notes (https://github.com/reactphp/async/releases/tag/v4.0.0) and the announcement blog post (https://clue.engineering/2022/announcing-reactphp-async) for more background. On the code level, this means you can now use synchronous types and will no longer have to work with asynchronous concepts such as promises unless you want to. It will take advantage of the new Fiber class in PHP 8.1+ when available automatically, so you wouldn't ever have to interface with Fiber instances in your code.

Looking forward, we've announced our plans for ReactPHP v3 in late 2022 and have continued working on this vision ever since, see announcement (https://github.com/orgs/reactphp/discussions/481) for more background. ReactPHP v3 will take advantage of the above improvements automatically and will make writing async PHP much easier, noticeably faster and more awesome than ever. This is a massive effort, and while the development is seeing some steady progress, we're still actively looking for more sponsors to achieve these goals faster.

As you can see, all pure PHP, no magic involved 🪄

I hope this helps! 👍 If so, consider supporting this project, for example by becoming a sponsor ❤️

[gidzr]

That's awesome background - yes it helps.

I also code javascript and python, and have an intense love-hate(hate) relationship with async promises in javascript. I much prefer php's assumption of sync, but would be great if PHP natively layered async (with promises when required) over the top. Yes technically javascript is sync, but underlying async processes can severely mess this up - and traceability goes out the window. Whereas php is strictly sync to the extent of being (for all intents and purposes) forced promise resolve which prevents the traceability and promise chain nightmares. Which should in theory make php a better form of async if it were ever to become native. ie. assumption of deep sync, adding async when required, and make blocking for resolved promise with await, vs Javascript's return resolve(), reject(), promise chains with thens and await, and 10 different syntaxes to achieve the same thing :(

If I could wave a magic wand, I would have php with the python flavour of async - particularly with asyncio styling. That's what reactPHP's async await is doing right - using more of a python flavour for async?

Re fibres, good to know I was going to wrap my reactPHP function in fibre which now I don't need to.